Todo lo que necesitas saber para trabajar como especialista en ciberseguridad.

Todo lo que necesitas saber para trabajar como especialista en ciberseguridad.

En España no existe una excepción de investigación de seguridad. El Código Penal castiga el acceso no autorizado a sistemas aunque no haya daño y aunque la intención sea avisar, de modo que lo que separa el trabajo profesional del delito es un documento: la autorización escrita del titular del sistema, con alcance y ventana temporal definidos.

Casi todo el contenido en español sobre hacking ético está traducido del inglés y escrito con la mentalidad estadounidense, donde la investigación de seguridad tiene cierto margen reconocido y existe una cultura consolidada de divulgación. Por eso insiste en herramientas, certificaciones y mentalidad, y apenas menciona lo único que determina si puedes ejercer esta profesión sin arruinarte la vida.

Este artículo cubre eso: el marco penal real, qué tiene que decir la autorización, qué hacer si encuentras un fallo sin que nadie te lo pidiera y qué normas están generando la demanda ahora mismo. Para el panorama general del oficio funciones, especialidades, quién contrata y cómo entrar está qué hace un especialista en ciberseguridad, que es la página de referencia del sector en este blog.

El punto de partida: la buena intención no es una eximente

Conviene decirlo sin rodeos, porque cada año hay quien se mete en un problema grave por no saberlo.

El artículo 197 bis del Código Penal castiga a quien, por cualquier medio y vulnerando las medidas de seguridad establecidas, acceda sin autorización al conjunto o una parte de un sistema de información, o se mantenga en él contra la voluntad de quien tenga el legítimo derecho a excluirlo. También castiga la interceptación de transmisiones de datos no públicas.

Hay tres detalles que cambian todo el planteamiento:

  • No hace falta causar daño. El acceso en sí ya es el hecho típico. No es necesario borrar, modificar ni publicar nada.
  • No hace falta ánimo de lucro. Avisar al titular después no convierte el acceso previo en lícito.
  • No existe una excepción de investigación. A diferencia de otros ordenamientos, el español no contempla una causa de exclusión para quien actúa con fines de seguridad.

Daños, obstaculización y herramientas

A eso se suman los artículos 264 y siguientes, sobre daños informáticos y obstaculización de sistemas, que alcanzan conductas como dejar un servicio inoperativo. Un escaneo agresivo que tira un servidor puede entrar ahí sin que nadie lo pretendiera.

Y hay un artículo que casi nadie conoce y que afecta a herramientas: el 197 ter castiga la producción, adquisición, importación o facilitación a terceros de programas informáticos concebidos o adaptados principalmente para cometer esos delitos. En la práctica, el uso profesional de herramientas de doble uso no es el problema; distribuirlas con una finalidad distinta, sí.

La conclusión operativa es simple. Mientras no tengas una autorización válida, cada paquete que envías a un sistema ajeno es un riesgo penal. Por eso el primer entregable de un proyecto de intrusión no es técnico: es jurídico.

La autorización: el documento que hace legal el trabajo

Aquí está la diferencia entre un profesional y alguien que se mete en un lío con buena fe. En el sector se le llama a veces carta de autorización, y conviene tenerla en tu poder durante toda la prueba, no archivada en algún correo del cliente.

Qué tiene que contener

  • Identificación del titular del sistema y de la persona física que firma, con constancia de que tiene capacidad para autorizar.
  • Alcance delimitado y cerrado: dominios, direcciones IP, rangos, aplicaciones, cuentas de prueba. Lo que no está en la lista no está autorizado.
  • Exclusiones explícitas: qué sistemas no se tocan y qué técnicas quedan fuera, por ejemplo las de denegación de servicio o la ingeniería social sobre personas concretas.
  • Ventana temporal, con fecha y hora de inicio y de fin.
  • Reglas de parada: en qué supuestos se interrumpe la prueba de inmediato y a quién se avisa.
  • Contacto técnico localizable durante toda la ventana, con teléfono y no solo correo.
  • Tratamiento de los hallazgos: quién los recibe, cómo se custodian y cuándo se destruyen las evidencias.
  • Autorización del proveedor de alojamiento o de nube, si el sistema no está en infraestructura propia del cliente.
  • Confidencialidad, con el detalle de qué puedes contar después y qué no.
  • Responsabilidad civil, con mención del seguro si trabajas por tu cuenta.

Quién tiene que firmarla, que no siempre es quien te contrata

Esta es la parte donde más se falla. El responsable de sistemas que te llama no siempre es quien puede autorizar la prueba, así que conviene reconstruir la cadena de legitimación antes de empezar.

Tres casos frecuentes:

  • La aplicación está en un proveedor de nube. El cliente es titular del dato y de la configuración, mientras que la infraestructura es de un tercero con sus propias reglas de pruebas de seguridad. Hay que comprobar esas reglas y, si lo exigen, pedir su autorización.
  • El sistema es de un tercero que presta servicio al cliente. Un portal gestionado por un proveedor externo no se puede autorizar desde dentro del cliente sin más. La autorización tiene que venir de quien es titular del sistema.
  • Hay subcontratación en cadena. Si te contrata una consultora que a su vez trabaja para el cliente final, la autorización del cliente final es la que importa. Un contrato con la consultora no sustituye a ese documento.

Dicho de otro modo: la pregunta no es quién te paga, sino quién tiene el legítimo derecho a excluirte del sistema.

Cuando la prueba toca datos personales

Si el proyecto implica acceder a información de personas identificables y casi siempre implica, además del contrato de servicios hace falta otra cosa.

El artículo 28 del Reglamento General de Protección de Datos exige un contrato de encargo de tratamiento entre el responsable y quien trata datos por su cuenta, con contenido mínimo: objeto, duración, naturaleza y fin del tratamiento, tipo de datos, categorías de interesados, obligaciones del encargado y régimen de subencargo.

Reglas prácticas que conviene incorporar a tu metodología:

  • Minimización, conforme al artículo 5.1.c): se accede a lo mínimo imprescindible para demostrar la existencia del fallo, no a todo lo que el fallo permite.
  • Parar en la prueba de concepto. Demostrar que se puede acceder a una base de datos no requiere descargarla. Descargarla cambia la naturaleza del asunto, también penalmente.
  • Cadena de custodia documentada de las evidencias, con control de quién accede a ellas.
  • Destrucción pactada de los datos obtenidos, con constancia escrita de que se ha hecho.
  • Aviso inmediato si durante la prueba descubres indicios de un incidente real en curso, porque entonces entra en juego el plazo de notificación del artículo 33 del RGPD y deja de ser tu decisión.

Encontrar un fallo sin que nadie te lo pidiera

Este es el escenario más peligroso del oficio y el que el contenido traducido trata con una ligereza inquietante.

Imagina que navegando detectas una vulnerabilidad en un servicio español. La intuición dice avisar. El problema es que, si para confirmarla hiciste algo más que observar, puedes haber cometido ya el hecho descrito en el 197 bis, y el aviso no lo repara. Hay casos documentados de personas que avisaron y acabaron investigadas.

La regla que usan los profesionales: pararse en la observación. No confirmar, no profundizar, no descargar nada y no probar credenciales.

Qué hacer, y en qué orden

Y después, conviene usar un canal que exista:

  1. Busca una política de divulgación publicada. Muchas organizaciones publican un fichero security.txt en la raíz de su dominio, conforme al estándar RFC 9116, con el contacto de seguridad y las condiciones. Si existe, es la señal de que aceptan avisos y en qué términos.
  2. Si hay programa de recompensas, sus reglas son tu autorización. El alcance publicado es el contrato. Lo que queda fuera del alcance no está autorizado, por mucho que el programa exista.
  3. Si no hay nada de eso, usa el intermediario. INCIBE-CERT dispone de un procedimiento de divulgación coordinada de vulnerabilidades y actúa como intermediario con el afectado. Para sistemas del sector público, el equipo de referencia es el CCN-CERT del Centro Criptológico Nacional.
  4. No publiques nada mientras el proceso esté abierto, ni captures pantallazos con datos de terceros, ni lo comentes en redes. La publicación prematura puede generarte responsabilidad adicional.

Si ya hiciste más de lo que debías antes de leer esto, lo sensato no es improvisar: consulta con un abogado penalista antes de contactar con nadie.

Las normas que están creando la demanda, y una fecha de 2026

La parte de mercado del contenido traducido habla de finanzas, sanidad y Gobierno en Estados Unidos. En España la demanda la está empujando la regulación europea, y conviene conocerla porque es lo que se pregunta en las entrevistas de consultoría.

Norma A quién afecta Qué genera trabajo
Esquema Nacional de Seguridad (Real Decreto 311/2022) Sector público y sus proveedores Auditorías periódicas de seguridad y cumplimiento por categorías
Directiva (UE) 2022/2555 (NIS2) Muchas más entidades que la norma anterior, en sectores esenciales e importantes Gestión de riesgos, notificación de incidentes y requisitos a la cadena de suministro
Reglamento (UE) 2022/2554 (DORA) Sector financiero y sus proveedores tecnológicos Pruebas de penetración basadas en amenazas para determinadas entidades
Reglamento (UE) 2024/2847 (Ciberresiliencia) Fabricantes y distribuidores de productos con elementos digitales Gestión y notificación de vulnerabilidades, y seguridad desde el diseño

Dos matices que marcan la diferencia

Estos son los dos puntos que distinguen una conversación profesional de una recitación de siglas.

El calendario del Reglamento de Ciberresiliencia es escalonado, y las obligaciones de comunicación de vulnerabilidades explotadas activamente se adelantan al resto del reglamento, cuya aplicación plena llega después. Es decir, ya hay fabricantes con obligación de notificar mientras siguen preparando el resto del cumplimiento. Si trabajas con empresas que venden software o dispositivos conectados, ese es el proyecto que tienen abierto ahora.

La transposición de NIS2 al derecho español conviene comprobarla antes de afirmar nada en una entrevista o en una propuesta, porque el plazo europeo venció en octubre de 2024 y el estado de la norma nacional ha ido cambiando. Cita la directiva y verifica la norma española vigente en el BOE.

Cómo se entra en el carril ofensivo

El recorrido general para entrar en ciberseguridad está en qué hace un especialista en ciberseguridad. Aquí va solo lo específico de la parte ofensiva.

Laboratorios legales, y la regla que no se salta

Practicar es imprescindible, aunque solo hay tres sitios donde se puede hacer sin riesgo: tus propias máquinas virtuales, plataformas de entrenamiento que ofrecen entornos preparados para eso, y programas de recompensas, dentro de su alcance publicado.

La regla no tiene excepciones: nunca contra sistemas de terceros, ni siquiera para «mirar», ni siquiera si crees que el titular no se va a enterar o que te lo agradecerá.

Certificaciones del carril ofensivo

Para la parte de intrusión, las credenciales que el mercado español reconoce son prácticas antes que teóricas. La OSCP es la referencia por su examen de laboratorio, con alternativas de nivel intermedio más accesibles como las de perfil junior en pruebas de penetración, mientras que la CEH aporta vocabulario y marco conceptual pero no acredita habilidad práctica al mismo nivel.

Ninguna sustituye a un informe bien escrito que puedas mostrar.

El portafolio: lo que sí puedes mostrar y lo que nunca

Lo que convence en una entrevista es un informe completo de un laboratorio propio: alcance, metodología, hallazgos con su valoración, reproducción paso a paso y recomendaciones de corrección.

Y una advertencia que ninguna guía traducida hace. Nunca incluyas hallazgos de clientes reales en un portafolio, ni anonimizados. Te lo impiden tres cosas a la vez: la cláusula de confidencialidad de tu contrato, el artículo 199 del Código Penal sobre revelación de secretos conocidos por razón del oficio, y la Ley 1/2019 de secretos empresariales. Es un error que termina carreras y que se comete por inexperiencia, no por mala fe.

Para construir el resto de la candidatura están cómo preparar un CV compatible con ATS y, para las preguntas por competencias, el método STAR.

El informe es el entregable, no el acceso

Un error muy común de quien empieza es creer que el trabajo consiste en entrar. El cliente no paga por eso: paga por un documento que le permita decidir.

Un informe profesional tiene cuatro capas:

  • Resumen ejecutivo sin jerga, que responda a qué riesgo hay, qué pasaría si se materializa y qué hay que hacer primero. Es lo único que va a leer la dirección.
  • Alcance y metodología, con fechas, sistemas, limitaciones y lo que no se pudo probar. Lo que no se dice que no se probó se asume probado.
  • Hallazgos, cada uno con su valoración de severidad el estándar habitual es CVSS, el impacto en el negocio, la evidencia mínima necesaria y los pasos exactos de reproducción.
  • Recomendaciones priorizadas, con la corrección concreta y, cuando no es posible aplicarla de inmediato, la medida de mitigación provisional.

La diferencia entre un perfil junior y uno experimentado casi nunca está en encontrar más fallos. Está en ordenarlos por riesgo real para ese negocio y en escribir recomendaciones que el equipo pueda aplicar el lunes.

Si vas a trabajar por tu cuenta, dos cosas más: un seguro de responsabilidad civil profesional, que varios clientes grandes ya exigen antes de firmar, y claridad sobre tu figura contractual. Si acabas facturando casi todo a un único cliente, conviene conocer el régimen del trabajador autónomo económicamente dependiente, que está explicado en trabajar en remoto para una empresa extranjera desde España.

Diez errores que pueden costarte la carrera

  1. Probar «solo un poco» en un sistema ajeno para confirmar una sospecha.
  2. Empezar con el contrato de servicios firmado pero sin la autorización técnica con alcance y ventana.
  3. Aceptar la firma de quien no es titular del sistema, como un responsable de área sin capacidad para autorizar.
  4. Olvidar la autorización del proveedor de nube o de alojamiento cuando la infraestructura no es del cliente.
  5. Salirse del alcance porque has encontrado algo interesante justo al lado.
  6. Descargar datos reales cuando la prueba de concepto no lo exigía.
  7. No pactar la destrucción de evidencias ni documentar que se ha hecho.
  8. Publicar un hallazgo antes de que el proceso de divulgación esté cerrado.
  9. Incluir trabajo de clientes en el portafolio, aunque creas que está anonimizado.
  10. Entregar un informe sin resumen ejecutivo, que es la parte que decide si te vuelven a contratar.

Preguntas frecuentes

¿Es legal ser hacker ético en España?

Sí, siempre que exista autorización escrita del titular del sistema con alcance y ventana temporal definidos. Sin esa autorización, el acceso no autorizado a un sistema de información puede constituir delito conforme al artículo 197 bis del Código Penal, aunque no se cause daño y aunque la intención sea avisar. En el ordenamiento español no existe una excepción de investigación de seguridad.

¿Qué pasa si encuentro una vulnerabilidad y aviso?

El aviso no convierte en lícito un acceso previo no autorizado. La regla profesional es pararse en la observación, sin confirmar ni profundizar, y usar un canal existente: la política de divulgación publicada por la organización, su programa de recompensas si lo tiene, o el procedimiento de divulgación coordinada de INCIBE-CERT como intermediario. Para sistemas públicos, el CCN-CERT.

¿Qué es el fichero security.txt y por qué importa?

Es un fichero que algunas organizaciones publican en la raíz de su dominio, conforme al estándar RFC 9116, con su contacto de seguridad y las condiciones en que aceptan avisos de vulnerabilidades. Si existe, indica que la organización tiene un canal de divulgación y bajo qué términos, de modo que es lo primero que conviene comprobar.

¿Qué debe incluir una autorización de pruebas de intrusión?

Identificación del titular y de quien firma, alcance cerrado de sistemas y direcciones, exclusiones explícitas de sistemas y técnicas, ventana temporal con horas, reglas de parada, contacto técnico localizable, régimen de custodia y destrucción de evidencias, autorización del proveedor de alojamiento si procede, confidencialidad y responsabilidad civil.

¿Hace falta un contrato de protección de datos además del de servicios?

Si durante la prueba vas a tratar datos personales, sí: el artículo 28 del Reglamento General de Protección de Datos exige un contrato de encargo de tratamiento con contenido mínimo tasado. Además conviene aplicar el principio de minimización y detenerse en la prueba de concepto sin descargar información real.

¿Puedo usar en mi portafolio un trabajo que hice para un cliente?

No, ni siquiera anonimizado. Lo impiden la cláusula de confidencialidad del contrato, el artículo 199 del Código Penal sobre revelación de secretos conocidos por razón del oficio y la Ley 1/2019 de secretos empresariales. Lo que sí puedes mostrar es un informe completo de un laboratorio propio.

¿Qué normativa está generando demanda de este perfil en España?

El Esquema Nacional de Seguridad en el sector público y sus proveedores, la directiva NIS2 en sectores esenciales e importantes, el reglamento DORA en el sector financiero que contempla pruebas de penetración basadas en amenazas para determinadas entidades y el Reglamento de Ciberresiliencia para fabricantes de productos con elementos digitales, cuyo calendario adelanta las obligaciones de comunicación de vulnerabilidades explotadas activamente.

TRABAJOS MAS ACTUALES:

Comments

No comments yet. Why don’t you start the discussion?

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *