Cómo DevSecOps puede hacer que su SGSI basado en ISO 27001 sea más maduro

Prefacio

Empecemos con una imagen un poco sobredimensionada de la Seguridad de la Información. ¿Por qué? Porque es algo extraño. Casi todo el mundo la conoce. La mayoría de la gente ya ha entrado en contacto con ella directa o indirectamente. Te dicen lo importante que es y lo malo que sería que se produjera un ciberataque. Pero, por otro lado, los responsables de seguridad que intentan aplicar medidas de seguridad, a menudo tienen que enfrentarse a negativas:

• Los "chicos de la seguridad" siempre bloquean o ralentizan los proyectos más rentables para la empresa.
• Los desarrolladores y administradores de sistemas sólo ven la carga de trabajo adicional que se añade a sus puestos debido a la seguridad.
• Para muchos usuarios finales, burlar las medidas de seguridad de la forma más creativa parece una especie de deporte.

Cómo puede ser práctica la seguridad

No queremos ser catastrofistas, no siempre es tan malo como acabamos de describirlo, pero las personas que trabajan en Seguridad de la Información podrían reconocer algunas de las historias anteriores durante más tiempo. Quejarse no es la razón de este artículo; explica cómo se puede implementar la seguridad práctica en una fase muy temprana del desarrollo de software utilizando DevSecOps.

Al mismo tiempo, se relaciona con los Sistemas de Gestión de la Seguridad de la Información (SGSI), más teóricos y orientados al cumplimiento, que la mayoría de las empresas tienen implantados hoy en día. Existen varias ideas sobre cómo combinar ambos enfoques. Nos centraremos en una relativamente nueva: OWASP DSOMM, el modelo de madurez DevSecOps del Open Web Application Security Project.

ISO 27001: conocida y ampliamente utilizada

Empecemos por la ISO 27001, la norma de seguridad de la información en la que se basa el SGSI de la mayoría de nuestros clientes. Mientras que la ISO 27001 define los requisitos generales, la ISO 27002 asociada ofrece una lista detallada de los documentos requeridos y recomendados. Mide los controles desde temas organizativos como una Organización de Seguridad de la Información bien definida sobre los procesos (on-/offboarding, respuesta a incidentes, gestión de proveedores), hasta requisitos detallados como una política de contraseñas o una matriz de funciones y responsabilidades bien definida.

Lo que realmente se necesita

La gente se queja de los requisitos y controles de la norma ISO porque cambia su actividad diaria; es demasiado de alto nivel. Muchos quieren tener requisitos precisos que puedan utilizar y aplicar directamente, pero, por desgracia, la ISO 27001 / 27002 pura no funciona a ese nivel. Se necesita una correspondencia entre el alto nivel y la aplicación práctica de bajo nivel para las operaciones cotidianas.

Por lo tanto, nos centramos en una nueva idea de mapeo: una parte de los requisitos enumerados en la norma ISO 27002 es un "proceso de desarrollo de sistemas documentado" (sección A.14). Aquí es donde DevSecOps y el Modelo de Madurez DevSecOps (DSOMM) de OWASP entran en juego.

Por qué DevSecOps tiene sentido para su organización

DevOps (combinación de desarrollo de software, "Dev", y operaciones de TI, "Ops") también es bien conocido en el sector del desarrollo de software desde hace años. Su objetivo es acortar el ciclo de vida de desarrollo de sistemas y proporcionar una entrega continua con una alta calidad de software. Este desarrollo de software basado en DevOps se aplica a menudo en el marco de enfoques ágiles como Scrum o Kanban, ya que ambas ideas persiguen el mismo objetivo: ciclos de vida cortos y entrega continua.

DevSecOps (DevOps con seguridad profundamente integrada - "Sec") se añadió a DevOps más tarde, cuando la gente se dio cuenta de que implementar la seguridad ya en una fase temprana del desarrollo tiene varias ventajas. Los posibles problemas de seguridad se detectan pronto y no es necesario corregirlos durante la fase de desarrollo o en una fase posterior. Como regla general, cuanto más tarde se identifique un problema de seguridad en el ciclo de vida del software, más costoso será solucionarlo.

Identificación de problemas de seguridad

Costes relativos de corrección de errores, en función del momento de la detección

Ocuparse de los fallos de seguridad ya durante la fase de desarrollo (requisitos, arquitectura, codificación, integración, pruebas de componentes) podría ahorrar muchos recursos: tiempo y presupuesto, así como escasa motivación del equipo.

Volviendo a las reticencias iniciales a las que se enfrentan los responsables de seguridad, DevSecOps satisfaría a varias partes:

1. En primer lugar, la vertiente empresarial
   1. no recibe (o al menos recibe menos) "bloqueos" tardíos de la seguridad
   2. consigue costes más bajos y proyectos más puntuales y ajustados al presupuesto gracias a la corrección temprana de errores
2. En segundo lugar, los desarrolladores y administradores de sistemas
   1. tener que hacer frente a menos problemas de seguridad durante las pruebas y la aplicación, lo que podría ahorrar mucho tiempo.
   2. educarse automáticamente para hacerlo de la misma manera y con más seguridad en futuros proyectos, ya que el proceso en general fue más sencillo y menos frustrante.

Como se acaba de describir, realizar el desarrollo de software con el enfoque DevSecOps tiene muchas ventajas. El problema es cómo podemos utilizar este enfoque más bien práctico y orientado al desarrollo como entrada para un SGSI basado en la norma ISO 27001, por ejemplo:

• cómo guardar secretos,
• cómo transferir parámetros confidenciales, o
• cómo hacer un inventario de los artefactos en funcionamiento, etc.

Este enfoque no trata estos temas a un nivel tan detallado. La información es necesaria para documentar y demostrar lo que se hace para alcanzar los controles específicos de la norma ISO 27002. Cualquiera que haya participado alguna vez en una auditoría basada en la norma ISO 27001 sabe lo importante que es esta información y lo centrados que están la mayoría de los auditores en la SoA (Declaración de Aplicabilidad). El SoA documenta exactamente los vínculos entre un control ISO 27002 y la medida técnica u organizativa que una empresa ha implementado para abordarlo.

Combinándolos: el enfoque DSOMM de OWASP

El equipo del proyecto OWASP DSOMM también reconoció esta necesidad. Hace relativamente poco, se ha añadido un mapeo de los temas DS OMM a los controles ISO 27002. Algunos de nuestros clientes que trabajan con DevSecOps ya utilizan este mapeo. El ISMS-maintainer puede mapear directamente las medidas realizadas durante DevSecOps a los correspondientes controles ISO 27002 tal y como se enumeran en el SoA. La mayoría de los mapeos DSOMM se refieren a A.14 (proceso de desarrollo del sistema documentado) y algunos a controles como A.12 (operaciones, copias de seguridad, supervisión, etc.), por lo que la cobertura ya es relativamente amplia.

Por lo tanto, el uso del nuevo mapa DSOMM-ISO27701 podría ser un puente entre el SGSI de alto nivel y el proceso de desarrollo de software de bajo nivel. Recomendamos encarecidamente debatir este tema entre los responsables de productos y riesgos de los equipos de desarrollo y los responsables de seguridad de la información (CISO). Es un paso más hacia un software más maduro y seguro. Al mismo tiempo, también es un paso más hacia un SGSI maduro.

Conclusión

¿Se dedica al desarrollo de software en su empresa, ya sea para uso propio o como producto para terceros? ¿Le preocupa la seguridad de la información, no sólo en teoría, sino también a nivel práctico? Bueno, entonces definitivamente debería echar un vistazo más de cerca a DevSecOps en general, especialmente si sus equipos de desarrollo ya trabajan ágilmente. En CISO AG le ayudamos a automatizar las principales tareas de seguridad e implementarlas en su flujo de trabajo DevOps.