Resolver el problema con estándares de seguridad



Los modelos de amenazas más explícitos pueden mejorar la seguridad y abrir la puerta a la innovación true y necesaria.

La gente de seguridad ama los programas de cumplimiento. ¡De Verdad! Es por eso que tenemos tantos de ellos.

No. Bien, odiamos los programas de cumplimiento. Incluso cuando trato de contar chistes sobre los programas de cumplimiento, los odio.

La razón por la que odio los programas de cumplimiento es porque son listas de cosas que debemos hacer y, muchas veces, esas cosas no parecen tener mucho sentido. En el modelado de amenazas, hablo de la interacción entre amenazas, controles y requisitos, y bromeo diciendo que «un requisito para tener un control sin ninguna amenaza» es la razón por la que odiamos los programas de cumplimiento (no es broma).

Así que disfruté cuando Anton Chuvakin ofreció recientemente este consejo a los equipos de seguridad en un artículo llamado «Modelos de amenazas y seguridad de datos«:» No implemente controles de seguridad, ya sea seguridad de datos u otros, a menos que sepa qué problema está resolviendo «. Esto me recordó un trabajo que comencé hace varios años y que nunca publiqué (hasta ahora), porque otros trabajos tuvieron prioridad. Se trata del modelo de amenazas que subyace al estándar PCI.

Tuve que aplicar ingeniería inversa a este modelo de amenazas del estándar tal como estaba en ese momento. Otra forma de decir esto es que el Estándar de seguridad de datos de la industria de tarjetas de pago (PCI-DSS) es una forma de responder a la pregunta «¿Qué vamos a hacer?» – que es una de las partes clave del modelado de amenazas. Pero otros aspectos, como las respuestas a «¿En qué estamos trabajando?» y «¿Qué puede salir mal?» – se dejan como ejercicio para el lector.

Y déjeme decirle, querido lector: ¡eso fue mucho ejercicio, del orden de semanas! Fue un trabajo doloroso. Para decir lo obvio, hay algunos problemas reales allí, y todos los que pasan por las auditorías de PCI tienen las suyas propias. Hubo momentos en que me enojé. Hubo momentos en los que estaba confundido. Es más, literalmente no hay ninguna razón por la que debería haber tenido que hacer ese trabajo. Supongo que la gente de PCI trabaja con una lista explícita de problemas que desean abordar en su estándar. Si es así, deberían publicar la lista.

Habiendo hecho ese trabajo, estoy algo feliz de compartir el resultado. Sinceramente espero no tener que volver a hacer ese trabajo nunca más. Pero me gustaría hacerme eco y ampliar lo que dijo Chuvakin: «Los modelos de amenazas explícitas mejoran la seguridad». Deberíamos exigir documentos de modelos de amenazas a quienes elaboran o promulgan estándares.

Cuando digo un documento de modelo de amenazas, me refiero a respuestas a lo que llamo «Las cuatro preguntas»:

  • En que estamos trabajando?
  • ¿Qué puede ir mal?
  • ¿Qué vamos a hacer al respecto?
  • ¿Hicimos un buen trabajo?

Para un organismo de estándares, esas preguntas se modifican ligeramente:

  • ¿Cuál es su modelo de los sistemas que protege su estándar?
  • ¿Qué puede ir mal?
  • ¿Qué debe hacer la gente al respecto para cumplir?
  • ¿Hiciste un buen trabajo? (¿Por qué son estas las amenazas significativas? ¿Los mejores controles? ¿Fue sensato su enfoque? ¿Está alineado con precisión con otros estándares cuando sea posible?)

Ese último punto: cada vez que un estándar united states of america palabras ligeramente diferentes, todos los analistas de cumplimiento en el mundo deben reevaluar sus controles para ver si coinciden. La divergencia es cara. Si viviéramos en un mundo en el que pudiéramos tratar esas diferencias como una oportunidad para acumular pequeñas ventajas porque juzgamos las consecuencias de los programas, entonces apreciaríamos esas diferencias como una fuerza evolutiva. Pero lamentablemente no vivimos en ese mundo.

Los modelos de amenazas explícitos mejoraron la seguridad. El modelo de amenaza que subyace a un estándar defensivo debería existir antes que el estándar. Ciertamente hay trabajo para pasar de la calidad de «uso interno» a la calidad de lanzamiento. Pero publicarlo nos permite pasar del cumplimiento a la ingeniería.

Esta mañana, estaba hablando con algunos científicos de cohetes. (Está bien, en realidad no. Eran ingenieros aeroespaciales). Me enfatizaron que su gente es muy, muy buena en ingeniería, en abordar un problema y resolverlo. Pero se estancan en las listas de verificación de cumplimiento. Si compartiéramos nuestros modelos de amenazas con ellos, podrían crear nuevas soluciones que funcionen en su entorno único. En eso, no son únicos. Hay muchos ingenieros excelentes por ahí. Hay muchos problemas inusuales.

Especificar por qué nos importa no es abrir la puerta a la reinvención de la rueda. No es un argumento para ignorar el catálogo de formas probadas de gestionar los problemas. Pero sería un gran paso para abrir la puerta a la innovación serious y necesaria.

Adam es un destacado experto en modelado de amenazas. Es miembro de la Junta de Revisión de BlackHat y ayudó a crear el CVE y muchas otras cosas. Actualmente ayuda a muchas organizaciones a mejorar su seguridad a través de Shostack & Associates, y ayuda a las nuevas empresas a convertirse en grandes negocios como … Ver biografía completa

Lectura recomendada:

Más información





Enlace a la noticia initial