SecDevOps: buenas prácticas de seguridad desde la fase de desarrollo

Durante mucho tiempo, desde las áreas responsables de la gestión de la seguridad de la información se han desarrollado auditorías de diverso tipo sobre las aplicaciones y servicios desplegados en la organización. Su objetivo, identificar vulnerabilidades que pudieran permitir la materialización de ciertas amenazas y, consecuentemente, ocasionar un incidente de seguridad, así como para valorar el impacto potencial de dichos incidentes sobre los activos de la organización y en los procesos de negocio que sustentan dichos activos.

Estos procesos de análisis de riesgos se han enfocado tradicionalmente sobre las aplicaciones y servicios ya en entornos de producción o, en el mejor de los casos, en los entornos de integración previos a la producción.

Afortunadamente, la lógica de la eficiencia nos ha llevado a fundamentar la gestión de los riesgos asociados a las aplicaciones y servicios, en el análisis de dichos riesgos desde las fases de diseño y desarrollo. Han ayudado a ello las diferentes normativas y regulaciones legales que, desde hace tiempo, vienen recomendando (cuando no imponiendo) la necesidad de gestionar la seguridad y la privacidad desde esas fases iniciales.

Sin embargo, cometeríamos un error si diseñamos la estrategia de seguridad en el desarrollo de aplicaciones delegando esa función en los propios equipos de desarrollo, en los programadores.

En otros ámbitos, por ejemplo, hemos asumido que el empleado es responsable de seguir la normativa interna y las buenas prácticas en la gestión de la información que maneja, sin entender por ello que sea su responsabilidad decidir qué controles aplicar o que riesgos gestionar de forma prioritaria. Hemos definido con las áreas tecnológicas a cargo de la implantación y operación de sistemas las normativas y los controles que deben implementar en sus actividades y en los sistemas en su ámbito funcional, sin entender por ello que sea su responsabilidad es decidir el alcance de dichos controles, la tipología de las amenazas a gestionar, o la forma de escalar el riesgo tecnológico a la gestión de riesgos corporativa.

Por ello, definir, gestionar, monitorizar y evaluar la componente “Sec” cuando se añade al “DevOps”, no puede sino ser una pieza más de la estrategia de gestión de la seguridad corporativa, alineada con los objetivos de negocio de la organización, integrada en la gestión, evaluación y tratamiento de riesgos, y, en definitiva, contribuir, desde su ámbito, a mantener la integridad, disponibilidad, privacidad, control y autenticidad de la información de la entidad.

¿Cómo implantar SecDevOps?

Una vez definido como un ámbito más de la gestión de la seguridad de la información, Sec+DevOps, debemos abordarlo también en las mismas líneas de actuación que utilizamos en otros ámbitos: personas, procesos, tecnología y gobierno.

En la línea de actuación relacionada con las personas, es obvio recordar que constituyen el mayor activo para la eficiencia (o ineficiencia) del resto de líneas de actuación. En muchos casos los equipos de desarrollo han estado únicamente dirigidos a la reducción del tiempo necesario para la construcción de nuevas aplicaciones (o la adecuación de las existentes) que den soporte a los cambios en los procesos de negocio. Deberemos, en su ámbito, crear metas compartidas con los responsables de la gestión de la seguridad y enriquecer su cultura de innovación, siempre presente en las áreas de desarrollo, con la propuesta de un marco de desarrollo seguro que, lejos de hacerla más difícil, la mejore.

En el ámbito de los procesos, deberemos tener en cuenta que las estrategias actuales de desarrollo han alcanzado un alto nivel de eficiencia combinando los objetivos de velocidad y calidad, por lo que deberemos intentar simplificar el modelo de controles de seguridad tanto como sea posible sin sacrificar la gestión de riesgos corporativa. La mejor aproximación a este objetivo será, sin duda, la automatización de la aplicación de la mayoría de los controles y su implantación en los procesos de desarrollo ya establecidos. Aprovechar los procesos existentes e incorporar el pensamiento, desde el diseño, en la modelación de las amenazas. La aproximación Shift left que vienen utilizando muchos equipos de desarrollo puede aprovecharse para mover los requerimientos de seguridad a la fase en la que todavía no se ha escrito una línea de código.

En la tecnología, existen un buen número de herramientas, muchas basadas en la nube, que los equipos de desarrollo pueden utilizar para maximizar la seguridad del código sin penalizar los ciclos de entrega de versiones. Líneas de trabajo como las prácticas de security as a code y compliance as a code permiten incluir los controles apropiados desde el diseño de las aplicaciones y a lo largo del desarrollo de su código.

La aproximación tecnológica cubre los modelos de análisis necesarios para la prevención, mitigación y resolución de las vulnerabilidades que podrían quedar residentes en el código:

• Análisis SAST (Static Application Security Testing) o análisis estático, dirigido a analizar el código fuente para identificar vulnerabilidades de seguridad que pueden permitir el éxito de ataques dirigidos a la capa de aplicación, ofreciendo a los desarrolladores notificaciones en tiempo de desarrollo que pueden aplicar antes de que el código pase a la siguiente fase de su ciclo de vida.
• Análisis DAST (Dynamic Application Security Testing) o análisis dinámico, dirigido al análisis de la seguridad de las aplicaciones en tiempo de ejecución en los entornos de desarrollo, preproducción o integración. DAST se aplica de forma sistemática, integrándose con los procesos de validación funcional ya establecidos en el ciclo de vida del desarrollo.
• Análisis IAST (Interactive Application Security Testing) o análisis interactivo, que permite la monitorización de las aplicaciones en tiempo de ejecución, recogiendo información sobre su modelo de trabajo y comportamiento y realizando test automatizados mediante agentes o sensores durante la fase de evaluación de la calidad de las aplicaciones.

Cuando este tipo de herramientas se implementan en los procesos adecuados, la acción de los equipos de seguridad y de desarrollo se unifica, los costes asociados a los problemas de seguridad se reducen o eliminan y la calidad de los desarrollos mejora en consistencia.

Finalmente, en el ámbito del gobierno de la seguridad corporativa, no cabe duda de que incrustar la seguridad en los ciclos de desarrollo, en el diseño de las aplicaciones, requiere de un conjunto de herramientas y controles consistentes con los procesos ya definidos, y favorecerá enormemente la tarea de los equipos encargados del cumplimiento normativo y legal. Como cualquier otro ámbito del gobierno de la seguridad, la estrategia de seguridad en el desarrollo debe estar alineada con el resto de la estrategia de seguridad, y esta, con los objetivos de la organización y sus focos de negocio.

La transformación digital, la metamorfosis como la proponemos desde Izertis, que toda organización está abordando, o deberá abordar en algún momento para garantizar su supervivencia, transforma el modo en el que las organizaciones trabajarán en el futuro. El gobierno corporativo, especialmente en los ámbitos de la seguridad y de las tecnologías de la información marcarán el éxito de una compañía.

La estrategia adecuada, aprovechar el conocimiento de las empresas especializadas y disponer, con su colaboración, de una hoja de ruta crítica, con hitos definidos y métricas que permitan evaluar su desarrollo, serán los factores claves del éxito de la implantación de la seguridad y la privacidad desde el diseño: Sec + DevOps.