Pasar a ciberseguridad desde el rol de desarrollador de software

Cambiar de área técnica siempre es un reto. Pero cuando entré a trabajar en una empresa de ciberseguridad, me di cuenta de que mis habilidades de seguridad "estándar" como desarrollador simplemente no eran suficientes. 😅

Llevo años trabajando como desarrollador. Pensé que entendía bien la seguridad porque conocía las prácticas estándar: aplicar hash a las contraseñas, usar HTTPS, sanitizar las entradas a la base de datos y nunca subir secretos a GitHub.

Pero durante mi primera semana de reuniones, la enorme cantidad de acrónimos como SIEM. IPA. IDP. PII. SPII. me hizo sentir completamente perdido. Sentí como si estuviera aprendiendo un idioma nuevo.

Después de un mes, empecé a entender mejor todo. Me di cuenta de que no son solo palabras corporativas complejas: son la base de la confianza. Como desarrolladores, nos concentramos en crear funcionalidades. La ciberseguridad se concentra en proteger esas funcionalidades.

Si estás dando el salto a la ciberseguridad desde un rol de desarrollo, este artículo es para ti. Es la guía que me hubiera gustado tener en mi primer día. Aquí te comparto una explicación sencilla de estos términos desde la perspectiva de un desarrollador. En lugar de verlos como obstáculos, empecé a verlos como capas de una estrategia de defensa.

Empecemos por cómo manejamos el "ruido" y los eventos de seguridad.

SIEM: mucho más que simples logs

A los desarrolladores nos encantan los logs, ¿verdad? Guardar registros nos sirve para corregir errores. Si la aplicación falla, revisamos los logs para ver qué pasó.

Pero en ciberseguridad, los logs son mucho más que eso. Vas a escuchar el término SIEM muy a menudo. ¿Pero qué es un SIEM? En resumen, significa Security Information and Event Management (Gestión de Información y Eventos de Seguridad), pero ¿qué significa en la práctica?

Imagina que tu aplicación es una casa. Revisas las cerraduras (autenticación) y quizás instalas una cámara (los logs). Un SIEM es como una estación central de seguridad que vigila todas las cámaras del vecindario al mismo tiempo. Recolecta logs de tu aplicación, pero también de firewalls, servidores, bases de datos y routers. Utiliza reglas lógicas e inteligencia artificial para encontrar conexiones entre distintos eventos.

Si un usuario falla al iniciar sesión 5 veces en tu app, eso es un log simple. Si esa misma dirección IP intentó acceder al servidor de la base de datos 2 segundos antes, el SIEM conecta ambos eventos y alerta al equipo sobre un posible ataque.

Tus logs no son solo para ti; son datos para el SIEM. Si generas logs de mala calidad (como console.log("error here")), el SIEM no podrá entenderlos. Para solucionar esto, debes estructurar tus logs en formato JSON e incluir contexto clave como el ID de usuario, la dirección IP, la acción realizada y la marca de tiempo (timestamp). Solo ten cuidado de no registrar datos sensibles, lo que nos lleva directamente al tema crítico de la protección de datos.

Las herramientas más comunes que vas a encontrar son Splunk, muy popular para analizar volúmenes masivos de logs, y Google Chronicle, diseñada para ser rápida y que se siente como buscar tus logs directamente en Google.

Sin embargo, saber qué pasó en los logs es solo la mitad de la batalla. También necesitas saber quién lo hizo, y aquí es donde entran la identidad y el cumplimiento normativo.

IdP y HIPAA: identidad frente a cumplimiento

Si antes necesitaba crear una funcionalidad de autenticación de usuarios, como una página de login, creaba una tabla users y listo. Pero en el mundo real, la historia es mucho más compleja.

¿Qué es un IdP?

En un sistema grande, no quieres que cada aplicación gestione sus propias contraseñas. Quieres un lugar centralizado para administrar a los usuarios. Un IdP (como Okta, Auth0 o Microsoft Entra ID) es ese lugar central. Confirma quién es el usuario y le entrega un token a tu aplicación.

Break Glass o la llave de emergencia

¿Qué pasa si el sistema de login (el IdP) deja de funcionar? ¿O si el administrador pierde su teléfono y no puede usar la autenticación de dos factores (2FA)? Para esto necesitamos una cuenta de Break Glass (romper el cristal). En términos sencillos, es una cuenta especial con permisos totales que nunca usamos para el trabajo diario. Se guarda en un lugar seguro y solo se usa durante una emergencia real. Es como una llave de emergencia para entrar a tu casa. Asegura que, si todo lo demás falla, no nos quedemos fuera de nuestro propio sistema.

¿Qué es HIPAA?

Al principio pensé que se escribía "HIPPA" o que era simplemente una regla médica cualquiera. Significa Health Insurance Portability and Accountability Act (Ley de Portabilidad y Responsabilidad de Seguros Médicos). Si manejas cualquier dato relacionado con la salud, debes cumplir con esta norma. Define cómo se cifran los datos, quién puede acceder a ellos y cómo debes auditarlos.

Reconocer quién accede al sistema y qué regulaciones aplican es solo el primer paso. El siguiente es entender la naturaleza de los datos en sí.

PII frente a SPII: el tipo de dato importa

¿Qué es PII (Información de Identificación Personal)?

Cualquier dato que permita identificar a una persona específica, como su nombre, correo electrónico, número de teléfono o dirección IP.

¿Qué es SPII (PII Sensible)?

Esto es todavía más crítico. Si esta información es robada, puede causar un daño grave. Hablamos de números de seguridad social, detalles del pasaporte, datos biométricos como huellas dactilares, historiales médicos o números de cuentas bancarias.

Antes solía ver un campo de "Notas" como una simple caja de texto. Pero si un usuario escribe el número de su tarjeta de crédito en ese campo de "Notas" y yo lo guardo tal cual en la base de datos, acabo de crear un problema de seguridad serio. La clave está en saber qué estás guardando. La SPII debe estar cifrada (la contraseña de la base de datos no es suficiente), y la PII debe estar enmascarada en los logs para no exponer nunca el correo o teléfono de un usuario en texto plano.

Una vez que entiendes la sensibilidad de los datos que manejas, necesitas una filosofía para protegerlos. Aquí es donde entran los principios fundamentales de la seguridad.

La tríada CIA: los principios fundamentales

Antes de este trabajo, mi lista de verificación de seguridad era bastante improvisada. Ahora sé que todo se conecta con tres conceptos principales: C-I-A (por sus siglas en inglés). Representa la Confidencialidad (solo las personas autorizadas ven los datos), la Integridad (los datos no han sido alterados) y la Disponibilidad (el sistema está realmente en línea y accesible).

Cuando construyas una funcionalidad, pregúntate: ¿Esto afecta la Confidencialidad, la Integridad o la Disponibilidad?

La tríada CIA nos da los objetivos, pero ¿cómo los alcanzamos realmente a escala? Usamos marcos de trabajo establecidos para guiar nuestros procesos.

Los marcos de trabajo: NIST CSF y controles de seguridad

Mi mentalidad como desarrollador era que las políticas de seguridad eran solo documentos aburridos. Como vengo de frameworks como Angular, pensé: "¡Esto seguro va a ser código genial!". Bueno, resulta que se trata más de estructura, procesos y estrategia.

¿Qué es NIST CSF (Cybersecurity Framework)?

Es una guía que divide la seguridad en cinco pasos sencillos. Me di cuenta de que mi trabajo involucra todo el ciclo: empezamos por Identificar lo que tenemos y Protegerlo con medidas estándar como autenticación y cifrado. Pero también necesitamos Detectar cuándo algo sale mal, Responder con un plan y Recuperar el sistema después de un ataque.

¿Qué es CISSP?

Es una certificación muy importante para profesionales de seguridad. Para nosotros los desarrolladores, el Dominio 8: Seguridad en el Desarrollo de Software es el más relevante. Te enseña que la seguridad debe ser parte del diseño desde el inicio, no algo que se añade al final.

Esto cambió por completo la forma en que veo los requerimientos de seguridad habituales. Cuando un ingeniero de seguridad pide una lista de componentes de software o "Software Bill of Materials" (SBOM), simplemente está siguiendo el paso de Identificar del marco de trabajo. Cuando solicitan autenticación de dos factores, están implementando un control de seguridad estándar. Ver el panorama completo transforma estas tareas: dejan de ser solicitudes molestas y pasan a ser decisiones necesarias de arquitectura.

Pero incluso la mejor arquitectura puede fallar, y cuando eso pasa, necesitas un plan.

El Playbook: planes de respuesta

Mi mentalidad anterior como desarrollador era simple: si nos hackean, todo el mundo empieza a arreglar cosas a lo loco.

¿Qué es un Playbook?

Un playbook es una receta paso a paso para responder a un tipo específico de ataque. Por ejemplo, un Playbook contra Phishing puede indicarle al equipo que aísle la computadora afectada y restablezca la contraseña del usuario de inmediato. Después, revisan los logs (mediante Splunk o Chronicle) para ver a qué información se accedió y notifican al equipo legal.

Como desarrollador, tu labor muchas veces consiste en crear las herramientas o los logs que hacen posibles estos playbooks. Y cuando el playbook dice "Acceder al servidor de respaldo", es posible que seas tú quien tenga que usar las credenciales de Break Glass para salvar el día.

Resumen rápido

Si estás en medio de un proceso de entrevistas o apenas estás entrando al mundo de la ciberseguridad, aquí tienes un resumen rápido de los conceptos clave:

• SIEM: el "sistema de cámaras de seguridad" para tus logs (como Splunk o Chronicle).
• IdP y Break Glass: tu sistema de login centralizado y tus llaves de respaldo para emergencias.
• PII frente a SPII: la diferencia entre datos personales (para proteger) y datos sensibles (para cifrar).
• HIPAA: la normativa estricta que debes seguir si manejas datos médicos.
• Tríada CIA: los principios fundamentales de Confidencialidad, Integridad y Disponibilidad.
• NIST CSF: el marco de referencia principal para Identificar, Proteger, Detectar, Responder y Recuperar.
• CISSP y Playbooks: la certificación de referencia y tus recetas paso a paso para responder a incidentes.

El mayor cambio de mentalidad para mí fue entender que la seguridad es un proceso, no una funcionalidad. Como desarrolladores, solemos ser optimistas por naturaleza: construimos pensando en el "Happy Path", donde todo funciona a la perfección. Por el contrario, la ciberseguridad analiza el "Unhappy Path", ese escenario donde alguien está intentando romper el sistema deliberadamente.

Durante mis primeros dos meses no he estado atacando ni hackeando sistemas, sino construyendo arquitecturas fáciles de monitorear (SIEM), con autenticación de usuarios segura (IdP) y protegiendo los datos como corresponde (PII). ¿Y la verdad? Ha cambiado por completo mi forma de pensar y de resolver problemas al programar.

Photo by Kalen Emsley on Unsplash