La tragedia de la seguridad muere en el crisol de DevOps

La seguridad ya no es lo que era. O quizás siempre ha sido así y solo parece distinta debido a la lenta degradación de mi idealismo juvenil.

La seguridad está bifurcada. Por un camino nos esforzamos por mantener seguras a nuestras organizaciones. Detener a los actores maliciosos, proteger datos y activos, y defender a los usuarios de las amenazas e incluso de sus propios errores. Por el otro camino está el cumplimiento normativo. Asegurar que la organización cumpla con los estándares regulatorios, contractuales y de otro tipo. En ambos caminos gestionamos riesgos: los riesgos de brechas de seguridad e interrupciones, o los riesgos de multas regulatorias.

La tragedia de la seguridad es un reflejo de la tragedia de los comunes. Según Wikipedia:

La mayor parte del cumplimiento normativo en seguridad está diseñada para reducir el riesgo de seguridad. Al menos sobre el papel. Pero con el tiempo hemos visto estándar tras estándar, regulación tras regulación, desacoplar el riesgo del cumplimiento normativo. La naturaleza misma de los estándares de cumplimiento impide que las organizaciones adapten las medidas de seguridad a sus riesgos organizacionales. No digo que esto sea siempre cierto, pero lo es en gran medida, especialmente a medida que se escala hacia organizaciones más grandes. No hay evidencia de que exigir el restablecimiento de contraseñas cada 90 días para usuarios con MFA u otras restricciones condicionales de uso común hoy mejore la seguridad. La persona que inventó los requisitos de complejidad de contraseñas literalmente se arrepiente de ello y dice que no funcionan. No hay evidencia ni una base científica sólida para exigir el cifrado no predeterminado de todos los volúmenes de almacenamiento en un proveedor de cloud.

La seguridad es un recurso compartido y finito. Solo tenemos cierta cantidad de dinero, cierta cantidad de profesionales de seguridad y cierta cantidad de tiempo que el personal ajeno a la seguridad puede dedicar a la seguridad a costa de sus otros objetivos. Cuanto más nos inclinamos hacia el cumplimiento normativo, menos queda de ese fondo para la seguridad. Cuanto menos se alinea el cumplimiento con la seguridad, menos esfuerzos reducen los riesgos de seguridad.

Esta es la tragedia de la seguridad. Desacoplamos el riesgo del cumplimiento normativo, convirtiendo la falta de cumplimiento en el riesgo mismo. Cuanto más se desacoplan los riesgos reales del cumplimiento, más rígido es el régimen de cumplimiento, menos recursos de seguridad quedan disponibles para la defensa y menor es el apoyo de otros equipos a los esfuerzos de seguridad.

Un gran ejemplo surgió en una conversación con Chris Farris. Parafraseando,

A los desarrolladores sí les importa la seguridad. Lo que les irrita es el cumplimiento normativo. Ayúdelos a asegurar su aplicación y lo apoyarán. Dígales que asuman una interrupción de 4 horas un fin de semana para reconstruir su base de datos con cifrado porque un fanático del cumplimiento lo exige y solo logrará molestarlos.

No digo que todo el cumplimiento normativo consista en reglas tontas, pero algunas reglas de cumplimiento sí lo son, y la mala aplicación de buenas reglas desacopladas de los riesgos es realmente tonta.

DevOps se convierte en el crisol del futuro de la seguridad porque en el mundo del cloud y DevOps los equipos de aplicaciones individuales se vuelven responsables de toda la pila, incluida buena parte de la seguridad. Nuevos servidores, redes y firewalls están a un simple git commit y algunas llamadas a la API de distancia. Esto también impone una mayor carga a esos equipos para gestionar su propia seguridad y cumplimiento normativo. Seguimos teniendo seguridad centralizada y recursos de seguridad compartidos, pero cuando se trata de la punta de lanza dependemos mucho más de los equipos de DevOps. No podemos crear una gran DMZ para el cloud. Las líneas entre redes internas y externas ya no pueden clasificarse en zonas estandarizadas. Muchas aplicaciones construidas sobre servicios nativos de cloud ni siquiera tienen ya una red y dependen de reglas de IAM y políticas de recursos escritas en JSON que los equipos de aplicaciones publican mediante infraestructura como código.

Por eso, buena parte de mis proyectos recientes de cumplimiento normativo enfocados en cloud y DevOps tratan más de hacer primero buena seguridad y luego averiguar cómo redactar un informe que parezca cumplir la letra de la norma aunque no lo haga, incluso cuando es más seguro.

Hay dos soluciones posibles.

La primera es revisar los estándares de seguridad para que se ajusten mejor al cloud y a DevOps y reducir la cantidad de reglas tontas o inaplicables. Parte de este trabajo está ocurriendo, pero he llegado a creer que requiere un cambio generacional que no tenemos tiempo de esperar. No nos rindamos, pero no tenemos que esperar.

La otra es usar la automatización para quitar a las personas la mayor carga posible de seguridad y cumplimiento normativo, permitiéndoles a la vez la libertad y el control para construir rápido. No sugiero que el fondo general de seguridad se reduzca, sino que usemos la automatización y otras tecnologías para disminuir la necesidad individual de gastar ciclos en las cosas de menor valor.

Se trata del tiempo y del enfoque de recursos limitados. Y en realidad, ¿qué es más valioso… una buena prueba de penetración o una auditoría de cumplimiento? Ahora observe cuánto gasta en pruebas de penetración y cuánto paga por una auditoría.