La fuerza de una cadena se determina por la fuerza de su eslabón más débil. No podría ser más cierto cuando se trata de la seguridad de la información.

Muchas organizaciones y profesionales de la seguridad de la información tienen dificultades para implementar el requisito 3.6.6.6 de PCI DSS, incluyendo una clara comprensión del valor que aporta.

El Requisito dice: 

"3.6.6 - Si se utilizan operaciones manuales de gestión de claves criptográficas de texto claro, estas operaciones deben ser gestionadas con conocimiento dividido y control dual."

La columna de orientación de la Norma proporciona la siguiente explicación:

"El conocimiento dividido y el control dual de las llaves se utilizan para eliminar la posibilidad de que una persona tenga acceso a la llave completa. Este control es aplicable para operaciones manuales de gestión de claves, o cuando el producto de cifrado no implementa la gestión de claves. El conocimiento dividido es un método en el que dos o más personas por separado tienen componentes clave, en el que cada persona sólo conoce su propio componente clave, y los componentes clave individuales no transmiten ningún conocimiento de la clave criptográfica original. El doble control requiere que dos o más personas realicen una función, y ninguna persona puede acceder o utilizar los materiales de autenticación de otra".

Buscar que más de una persona tome posesión de la clave de descifrado de datos tiene sentido, por supuesto. Así eliminas la amenaza de que un solo empleado abandone el negocio con la llave o, lo que es peor, que se convierta en un delincuente.

La cadena

Entonces, ¿cómo encaja esto con el dicho de que una cadena es tan fuerte como su eslabón más débil?

Tratemos de visualizar de una manera demasiado simplista un escenario con y sin un HSM para apreciar la diferencia que hace. Un HSM o Hardware Security Module (módulo de seguridad de hardware) es un dispositivo informático físico que protege y gestiona las claves digitales para una autenticación segura. También proporciona procesamiento criptográfico. Los módulos HSM pueden tener la forma de una tarjeta enchufable, una llave USB o un dispositivo externo que se conecta directamente a un componente informático. Uno de los atributos clave de un HSM es la capacidad de proporcionar pruebas de manipulación. Estos incluyen signos visibles de manipulación o registro y alerta. Además, se compone de una resistencia a la manipulación que dificulta la manipulación sin hacer que el HSM sea inoperable o que responda a las manipulaciones, como por ejemplo, eliminando las claves cuando se detecta una manipulación. En la industria de las tarjetas de pago específicamente, los HSM pueden proporcionar funciones que incluyen, entre otras, la generación de claves, el cifrado y la verificación de los elementos de seguridad de una tarjeta de pago, como PIN, CVV y PVV, por nombrar algunos.

En el diagrama de flujo de datos anterior, tenemos un escenario simple de comercio electrónico con 4 componentes típicos. Los datos del titular de la tarjeta (CHD) se almacenan en la base de datos del sistema y se encriptan de la siguiente manera:

1. Los CHD son introducido en el servidor web basado en Internet por el uso de un consumidor.
2. El servidor web pasa los CHD al servidor de aplicaciones a través del firewall.
3. El servidor de aplicaciones encripta los CHD con una clave de encriptación de datos (DEK) local antes de almacenarlo en la base de datos del sistema.

Ignoremos todos los demás detalles y supongamos que estamos usando encriptación simétrica por simplicidad. El problema que el Requerimiento 3.6.6 está tratando de eliminar aquí, es el conocimiento del DEK por una sola persona dentro de la organización como resultado de generarlo, transportarlo, respaldarlo, insertarlo o simplemente acceder a él.

Una vez más, manteniendo las cosas simples, el siguiente diagrama utiliza el mismo escenario, pero esta vez incluyendo un HSM que proporciona las siguientes funciones con el fin de apoyar el control de doble clave y el requisito de gestión de clave dividida:

1. Generación de claves.
2. Almacenamiento de claves.
3. Funcionalidad de cifrado y descifrado.
4. Doble control de cualquier función de gestión de claves para evitar que la clave de texto claro quede expuesta a un único custodio de claves.

Tenemos un escenario de comercio electrónico simple con 4 componentes típicos donde los CHD se almacena en la base de datos del sistema pero esta vez encriptado por el HSM de la siguiente manera:

1.  Los CHD son introducidos en el servidor web basado en Internet por el uso de un consumidor.
2. El servidor web pasa los CHD al servidor de aplicaciones a través del firewall.
3. El servidor de aplicaciones pasa los CHD al HSM que lo encripta utilizando el DEK almacenado localmente.
4. Una vez encriptado los CHD, el HSM lo devuelve al servidor de aplicaciones.
5. El servidor de aplicaciones almacena los CHD cifrado en la base de datos del sistema.

¿Qué es lo que está mal con esta situación?

¿De momento todo bien? ¡Incorrecto! ¿Qué hay de malo con esta imagen (diagrama) y cómo se aplica aquí el principio del eslabón más débil?

Bueno, empecemos con las buenas noticias antes de llegar a las malas.

Lo que hemos logrado:

1. Hemos descargado la función de encriptación del servidor de aplicaciones.
2. Hemos eliminado la posibilidad de que una sola persona pueda acceder a las claves de cifrado.
3. Hemos conseguido cumplir con el requisito 3.6.6 del PCI DSS.

Bueno, a primera vista esto parece bastante bueno. Pero, ¿hemos reducido el riesgo y, en caso afirmativo, en cuánto? En otras palabras, tratemos de llegar a las malas noticias haciendo las siguientes 2 preguntas:

1. Reducimos la capacidad de cualquier individuo para acceder a las claves de encriptación, pero ¿esto equivale a eliminar la capacidad de que cualquier individuo pueda descifrar los CHD encriptados?
2. ¿Cuál es el eslabón más débil en este escenario?

Bueno, vamos a destacar un par de suposiciones importantes, que representan las implementaciones más comunes antes de responder a estas preguntas:

1. Todos los HSM modernos requieren autenticación antes de realizar cualquier solicitud de cifrado o descifrado.
2. Esta autenticación se basa en las credenciales que normalmente se almacenan en el componente que está destinado y autorizado para "hablar" con el HSM y realizar dichas peticiones (en nuestro escenario, el servidor de aplicaciones).
3. Las credenciales para la autenticación HSM no están protegidas por un doble control, lo que significa que un usuario privilegiado podrá acceder a ellas.
4. El acceso administrativo al componente es capaz de "hablar" con el HSM y ejecutar, por ejemplo, que una solicitud de "descifrado" no está sujeta a un doble control.

Por lo tanto, una vez hechas las suposiciones anteriores, ahora podemos tratar de responder a las preguntas que planteamos:

1. Hemos eliminado la capacidad de una sola persona para acceder o sustituir las claves de cifrado de texto claro.
2. No hemos eliminado la capacidad de un empleado deshonesto con acceso privilegiado o de una persona maliciosa que haya comprometido el servidor de aplicaciones para acceder a las claves de autenticación HSM.
3. No hemos eliminado la capacidad de un empleado deshonesto con acceso privilegiado o de un individuo malicioso que haya comprometido el servidor de aplicaciones para acceder a la función de descifrado.
4. El servidor de aplicaciones sigue siendo el eslabón más débil.

Riesgos y cumplimiento de las normativas

Con estas preguntas en mente, ¿qué podemos decir sobre el riesgo y el cumplimiento?

1. Hemos reducido el riesgo porque hemos eliminado algunos escenarios en los que un HSM resulta muy útil: el robo físico, por ejemplo.
2. Hemos reducido un poco el riesgo al dificultar el descifrado de datos por parte de empleados deshonestos o de los hackers. Sin embargo, se trata de una reducción del riesgo relativamente marginal, ya que la dificultad introducida no debería ser tan alta si se piensa en ello.
3. Aunque queramos asegurarnos de evitar que las claves de cifrado y/o los algoritmos caigan en manos equivocadas, a esas manos equivocadas no les importa eso. Quieren poner sus manos en el oh, tan codiciado CHD de descifrado simplemente comprometiendo y usando el eslabón más débil para simplemente "pedir" al HSM que descifre todos los registros que puedan encontrar en la base de datos.
4. Logramos el cumplimiento, redujimos el riesgo. Pero cuando se piensa en el costo de implementar los HSM, la relación entre la reducción del riesgo y el costo puede ser un poco decepcionante.

Reflexiones finales

Esta es mi conclusión:

1. Los HSM no son una medida infalible como muchos parecen sugerir.
2. Los HSM con funciones como límites de velocidad y alertas, cuando se implementan correctamente, pueden ayudar a identificar y detener un intento de descifrado fraudulento.
3. Un enfoque por capas de la seguridad, en el que múltiples controles en forma de tecnologías y procesos funcionan al unísono, es la única opción viable contra la reducción de riesgos de forma significativa provocada tanto por factores internos como externos e individuales.
4. Ningún requisito por sí solo puede resistir un ataque simple, y mucho menos decidido y persistente.
5. El coste de la aplicación del control no siempre es una indicación de la cantidad de riesgo que puede reducir.
6. Priorizar los pasos de remediación debe tomar en cuenta el costo, el esfuerzo y la reducción de riesgos para buscar el 20% de los requerimientos, lo que nos daría un 80% de la reducción de riesgos al menor costo.
7. Por supuesto, cuando hablamos de priorización nos referimos precisamente a eso: al cumplimiento de todos los requisitos, pero ordenando las actividades de remediación de una manera que reduzca al máximo el riesgo de compromiso tan pronto como sea posible en el proceso de remediación.

Ya que aún estás aquí, y has leído mi opinión, ¿cuáles son tus pensamientos?

¿Estás de acuerdo o en desacuerdo? ¿Le ha resultado útil esta información? ¿Fueron claros y comprensibles los supuestos, argumentos y diagramas? ¿La longitud, el detalle y la profundidad técnica eran de calidad suficiente? ¿Disfrutarías de artículos adicionales que analicen temas controversiales, complejos o desafiantes relacionados con el riesgo y el cumplimiento? Háganoslo saber en los comentarios y pulse los botones de me gusta y comparta.