Fundamentos de seguridad de la información para desarrolladores

La mayor parte de la seguridad del software es sentido común aplicado, pero el campo tiene un vocabulario preciso, y usarlo a la ligera conduce a controles que no dan en el blanco. «Hazlo seguro» no es un requisito; «el registro de auditoría debe hacer detectable cualquier manipulación y conservarse siete años», sí. Esta guía cubre los conceptos que un desarrollador encuentra en requisitos de seguridad, registros de riesgos, informes de pruebas de penetración y revisiones de incidentes: lo suficiente para leer esos documentos con precisión y defender el control adecuado.

Es deliberadamente básica. Cuando un tema tiene su propia guía, esta ofrece el panorama general y remite a ella: las debilidades concretas de la web están en el OWASP Top 10, la práctica de diseño en arquitectura de seguridad de aplicaciones, y todo lo relativo a cuentas y permisos en gestión de identidades y accesos.

Las propiedades que conviene nombrar

La tríada CIA (confidencialidad, integridad y disponibilidad, por sus siglas en inglés) nombra las tres propiedades clásicas de la seguridad.

Confidencialidad: la información solo está al alcance de quienes están autorizados a verla. Se rompe con un bucket de almacenamiento expuesto, un log que contiene números de tarjeta o una API que devuelve el registro de otro cliente.

Integridad: la información y los sistemas no pueden alterarse sin que se detecte. Se rompe con un mecanismo de actualización sin firmar, un importe total que el cliente puede recalcular o un log de auditoría que un administrador puede editar.

Disponibilidad: el servicio se puede usar cuando hace falta. Se rompe con un ataque de agotamiento de recursos, pero con mucha más frecuencia por un certificado caducado o un despliegue fallido, y por eso la disponibilidad es tanto una propiedad de ingeniería como de seguridad.

Hay dos propiedades más que merecen nombre propio. La autenticidad consiste en saber que un mensaje o un actor es realmente quien dice ser: la propiedad que aportan la autenticación y las firmas digitales. El no repudio consiste en poder demostrar más tarde que una parte concreta realizó una acción, de modo que no pueda negarlo de forma creíble; exige a la vez una autenticación fuerte y un registro inmutable, y es la razón por la que los sistemas financieros y legales se preocupan por firmar y no solo por autorizar.

Formula los requisitos en estos términos. «Los registros de aprobación deben hacer detectable cualquier manipulación» es un requisito de integridad comprobable; «el sistema debe ser seguro» no lo es.

El riesgo en términos de seguridad

El trabajo de análisis de riesgos usa cinco palabras de forma coherente, y confundirlas produce registros inservibles.

• Un activo es algo de valor: un conjunto de datos, un servicio, una reputación, una clave.
• Una amenaza es una posible causa de daño: un actor con un motivo o un suceso como una inundación.
• Una vulnerabilidad es una debilidad que una amenaza puede aprovechar: una librería sin parchear, una comprobación que falta, un usuario sin formación.
• La probabilidad indica lo verosímil que es esa combinación, a la luz de la exposición y de la capacidad del atacante.
• El impacto es lo que cuesta si ocurre: en lo económico, lo regulatorio, lo operativo o la reputación.

El riesgo es la combinación de probabilidad e impacto de una amenaza concreta que explota una vulnerabilidad concreta contra un activo concreto. Una vulnerabilidad sin ninguna amenaza plausible es un riesgo bajo; una vulnerabilidad modesta en un sistema expuesto a Internet que guarda datos regulados, no.

Existen cuatro respuestas, y el sentido del ejercicio es elegir con plena conciencia: mitigar añadiendo un control, transferir mediante un seguro o un contrato, evitar renunciando a hacer lo arriesgado, o aceptar con un responsable designado y una fecha de revisión. Aceptar un riesgo de forma deliberada es legítimo; descubrir en una revisión posterior a un incidente un riesgo aceptado que nadie recuerda haber aceptado, no.

La criptografía que un desarrollador necesita de verdad

En el código de aplicación, la criptografía falla sobre todo por errores de categoría: se usa una primitiva que no aporta la propiedad requerida. Cuatro categorías, cuatro garantías.

La codificación convierte datos entre representaciones. Base64, la codificación de URL y el hexadecimal no tienen clave ni secreto; existen para que los datos binarios sobrevivan a un canal de texto. Un codificador y decodificador base64 revierte cualquiera de ellos al instante, y precisamente de eso se trata.

El hashing transforma una entrada en un resumen de tamaño fijo, de forma determinista e irreversible. Aporta integridad e identidad del contenido, no confidencialidad. Usa SHA-256 o SHA-3 para checksums y huellas; MD5 y SHA-1 están rotos para cualquier uso relacionado con la seguridad, porque se pueden fabricar colisiones. Verificar un artefacto descargado contra un resumen publicado es un uso legítimo de un generador de hash; almacenar contraseñas no lo es: para eso hace falta una función lenta y costosa en memoria.

El cifrado simétrico usa una única clave compartida para cifrar y descifrar. AES en un modo autenticado como GCM es la opción estándar; es rápido, sirve para grandes volúmenes de datos, y todo el problema se reduce a cómo consiguieron la clave ambas partes. No reutilices nunca un nonce con la misma clave, y no uses nunca el modo ECB puro, que filtra la estructura de los datos.

El cifrado asimétrico usa un par de claves: la clave pública cifra y solo la privada descifra. RSA y los algoritmos de curva elíptica son lentos en comparación con los cifrados simétricos, así que los sistemas reales los usan para establecer o envolver una clave simétrica y luego cambian a ella: el esquema híbrido que usa TLS.

Las firmas digitales invierten el par asimétrico: la clave privada firma un hash y cualquiera con la clave pública lo verifica. Eso aporta integridad, autenticidad y no repudio a la vez, y es el mecanismo que hay detrás de los certificados, los tokens firmados y los artefactos de release firmados. Un código de autenticación de mensajes como HMAC también aporta integridad y autenticidad, pero con un secreto compartido, así que no puede demostrar cuál de las partes lo generó.

Hay una regla que lo sustenta todo: usa una librería contrastada y una construcción estándar. Los protocolos caseros y los «le hacemos un XOR con un secreto» fallan de maneras evidentes para los especialistas e invisibles para sus autores.

TLS y la cadena de certificados

TLS aporta a una conexión confidencialidad, integridad y autenticidad del servidor, y es el control que el resto de la pila da por sentado sin decirlo. TLS 1.3 (RFC 8446) simplificó el handshake a un único viaje de ida y vuelta y eliminó los cifrados y opciones antiguos que causaron la mayoría de los fallos históricos.

Client                                          Server
  |-- ClientHello -------------------------------->|   supported groups, key share, cipher suites
  |<------------------------------- ServerHello ---|   chosen suite, key share
  |<------------- {EncryptedExtensions, Certificate,|
  |                CertificateVerify, Finished} ----|   everything after ServerHello is encrypted
  |-- {Finished} --------------------------------->|
  |<========== application data (AEAD) ===========>|

Cada lado aporta una parte de clave Diffie-Hellman efímera y ambos derivan el mismo secreto de sesión sin que este llegue a cruzar nunca la red. Como la clave es efímera, grabar hoy el tráfico y robar mañana la clave privada del servidor no permite descifrarlo: es la propiedad llamada forward secrecy (secreto hacia adelante), ahora obligatoria. El servidor demuestra que posee la clave privada de su certificado firmando la transcripción del handshake en CertificateVerify, lo que impide que un atacante reproduzca un certificado que simplemente ha copiado.

La confianza procede de la infraestructura de clave pública (PKI). Una autoridad de certificación verifica el control de un dominio y emite un certificado que vincula ese nombre a una clave pública, firmado por una autoridad intermedia cuyo propio certificado está firmado por una raíz en la que tu sistema operativo o tu navegador ya confían. La validación recorre esa cadena, comprueba la firma en cada paso, las fechas de validez, que el nombre coincida y la revocación. Lo que demuestra es limitado y conviene decirlo claramente: estás hablando con quien posee la clave privada de ese nombre, y nadie en medio puede leer ni modificar el tráfico. No responde por el operador.

Consecuencias prácticas para un desarrollador: sirve TLS 1.3 o 1.2 con suites modernas y nada más antiguo; activa HSTS para que los navegadores se nieguen a degradar la conexión; automatiza la renovación, porque la caducidad es la causa principal de incidentes de TLS; usa TLS también dentro de la red, ya que la posición en la red no es una frontera de confianza; y no desactives nunca la validación de certificados para que pase un test: esa costumbre acaba llegando a producción con toda seguridad. Cuando ambas partes deben autenticarse, el TLS mutuo hace que el cliente presente también un certificado, y es la opción habitual para las llamadas entre servicios.

Gobierno, normas y políticas

Las organizaciones gestionan la seguridad mediante marcos de referencia, y los requisitos que llegan a un equipo de desarrollo casi siempre nacen de uno de ellos.

ISO/IEC 27001 especifica un sistema de gestión de la seguridad de la información: definir el alcance, evaluar los riesgos, seleccionar controles, documentarlos, medir y mejorar, y someterse a auditoría. La certificación es un activo de negocio porque los clientes la piden, y sus controles se convierten en las expectativas a nivel de equipo: gestión de cambios, revisión de accesos, registro de eventos, evaluación de proveedores, desarrollo seguro.

El NIST Cybersecurity Framework 2.0 organiza la actividad en seis funciones: Govern, Identify, Protect, Detect, Respond y Recover. Es un vocabulario para estructurar más que una certificación, y resulta especialmente útil para detectar desequilibrios: muchos equipos invierten mucho en Protect y casi nada en Detect y Recover.

Otros aparecen en contextos concretos: PCI DSS para datos de tarjetas, SOC 2 para organizaciones de servicios y la regulación sectorial en finanzas y salud.

Una política de seguridad es la declaración escrita de lo que exige la organización, con estándares y procedimientos por debajo que aportan los detalles. Las políticas que los desarrolladores pueden seguir son breves, concretas y verificables; las que se redactan para contentar a un auditor no suelen leerse ni cumplirse, lo cual es peor que no tener ninguna, porque genera un incumplimiento documentado.

Respuesta a incidentes

Los incidentes también les ocurren a las organizaciones competentes. La diferencia entre una mala semana y una catástrofe es la preparación, y conviene conocer las fases de NIST SP 800-61 antes de necesitarlas.

Preparación. Contactos, roles, una vía de escalado, acceso a los logs, copias de seguridad probadas y un plan ensayado. Todo lo que sale caro organizar bajo presión se organiza ahora.

Detección y análisis. Reconocer que algo está pasando, a partir de una alerta, el aviso de un cliente o una notificación de un tercero, y determinar el alcance: qué se ha visto afectado, cuándo empezó y si sigue en curso. Esto depende por completo del registro y la monitorización que se hayan implantado antes.

Contención, erradicación y recuperación. Frenar la propagación (aislar un host, revocar credenciales, desactivar un endpoint) conservando las pruebas, porque una máquina borrada no se puede analizar. Después, eliminar la causa, restaurar desde un estado sano conocido y vigilar de cerca por si el problema se repite.

Actividad posterior al incidente. Una revisión sin culpables de lo ocurrido, la cronología, lo que funcionó y qué cambios evitarán que se repita, con responsables y fechas. Un incidente que no produce ningún cambio duradero es un incidente desperdiciado.

Dos cosas que los desarrolladores deberían saber de antemano: a quién llamar a las tres de la madrugada, y que rotar credenciales, revocar tokens y forzar una nueva autenticación deben ser operaciones que se puedan hacer rápido. Practícalas; un runbook que nadie ha ejecutado es una hipótesis.

Proteger los datos personales

La normativa de protección de datos, como el RGPD, impone principios que se traducen directamente en decisiones de diseño, sea cual sea tu jurisdicción.

• Base jurídica y limitación de la finalidad: recoger los datos con una finalidad declarada y no reutilizarlos discretamente para otra.
• Minimización de datos: recoger solo lo que la finalidad requiere. La forma más barata de proteger un campo es no almacenarlo.
• Limitación del plazo de conservación: definir la retención por categoría de datos y borrar según ese calendario, lo que implica que el borrado tiene que estar implementado, no ser una intención.
• Integridad y confidencialidad: medidas técnicas adecuadas, como cifrado, control de acceso y registro de eventos.
• Responsabilidad proactiva: poder demostrar el cumplimiento, mediante el registro de actividades de tratamiento y de las decisiones de diseño.

Hay dos técnicas que se mencionan a menudo y se confunden a menudo. La seudonimización sustituye los identificadores por tokens y conserva una correspondencia aparte, de modo que los datos siguen siendo personales y siguen regulados, aunque una filtración sea menos grave. La anonimización elimina por completo la posibilidad de reidentificar, lo que deja los datos fuera de la normativa, y es realmente difícil, porque las combinaciones de atributos corrientes suelen ser únicas. Incorpora desde el principio los derechos que otorga la normativa (acceso, rectificación, supresión, portabilidad), porque añadir a posteriori un borrado que llegue a cada réplica, copia de seguridad, caché y exportación analítica es una de las tareas de ingeniería más difíciles en un sistema maduro.

Conclusiones clave

• Confidencialidad, integridad y disponibilidad, más autenticidad y no repudio, te dan las palabras para redactar un requisito que se pueda comprobar.
• El riesgo se expresa con activo, amenaza, vulnerabilidad, probabilidad e impacto; todo riesgo termina en una decisión consciente de mitigarlo, transferirlo, evitarlo o aceptarlo.
• Codificar no es cifrar, un hash no es reversible, lo simétrico es rápido y lo asimétrico resuelve la distribución de claves, y las firmas demuestran el origen.
• TLS 1.3 ofrece forward secrecy en un solo viaje de ida y vuelta; los certificados demuestran el control de un nombre y nada sobre el operador, así que automatiza la renovación y no desactives nunca la validación.
• ISO 27001 y el marco del NIST son el origen de los requisitos a nivel de equipo; las políticas solo funcionan si son breves, concretas y se cumplen.
• Prepárate para los incidentes antes de que ocurran y haz que la revisión produzca cambios; con los datos personales, minimiza, define la retención y diseña el borrado desde el principio.