Seguridad informática: ¿cómo puedo hacer frente a cientos de requisitos de seguridad?

Independientemente de cualquier riesgo residual posible, como vulnerabilidades de día cero, nuestros expertos de adesso y la comunidad global de seguridad en general tienen un amplio conocimiento sobre lo que debe hacerse en términos de seguridad informática, ya sea en relación con la infraestructura, las aplicaciones u otras áreas. Organizaciones reconocidas como OWASP, NIST y BSI (IT-Grundschutz) han emitido varios cientos de requisitos de seguridad, eso es seguro. Saber cómo abordar cada uno de estos requisitos es un desafío real, incluida la implementación correspondiente, también porque son tantos.

En esta publicación de blog, me gustaría discutir dos enfoques posibles y compartir mi opinión personal basada en mi experiencia hasta la fecha. En términos simplificados, describiré dos enfoques polarmente opuestos aquí, uno siendo una estrategia más tradicional de ingeniería de requisitos y el otro siendo un enfoque iterativo.

Enfoque 1: ingeniería de requisitos tradicional

En la ingeniería de requisitos tradicional, todos los requisitos no funcionales se recopilan y documentan en una etapa temprana del proyecto. La implementación de estos requisitos puede planificarse de diferentes maneras, por ejemplo, pueden priorizarse a través del backlog o mediante una hoja de ruta dedicada.

En el mundo en gran medida ágil en el que operamos, este enfoque ya no parece funcionar bien porque se debe hacer tanto trabajo por adelantado. ¿Y quién realmente quiere comenzar un proyecto con cientos de elementos de backlog de seguridad?

Es cierto que esta es una descripción excesivamente simplificada del problema, pero como se puede ver en mis publicaciones anteriores en el blog, soy partidario de un enfoque diferente.

El objetivo que busca lograr es bastante similar al perseguido bajo una estrategia de ingeniería de requisitos completamente estructurada. Quiero cumplir con los requisitos de seguridad en la mayor medida posible para asegurarme de que el producto que entregue contenga solo riesgos aceptables. La principal diferencia es que:

• a) adopto un enfoque diferente para lograr el objetivo; y
• b) considero la dimensión del riesgo.

Enfoque 2: el enfoque iterativo

El segundo enfoque se basa en un modelo de amenazas inicial en el que se analiza una arquitectura, de ser posible, no demasiado detallada, desde arriba hacia abajo sin pretensiones de exhaustividad. Lo que resulta al final es un mapa de seguridad que destaca los elementos críticos (evaluación de riesgos) y define, así como determina, los próximos pasos. Un ejemplo típico implica identificar una interfaz pública y derivar medidas de alto nivel, como la validación de entrada o la seguridad http, basándose en esto.

El proceso iterativo de ajuste fino comienza entonces con este primer paso. Esto significa que se definen medidas como elementos de backlog en función de los hallazgos iniciales (si el riesgo es inaceptable). Un elemento de backlog de la primera iteración a menudo se define en términos muy generales, siendo la tarea afinarlo en los primeros sprints y derivar medidas de implementación específicas en base a él. Esto encaja bien con el dicho que quizás conozcas, a saber, que la seguridad es un problema fractal. ¿Por qué fractal? Porque al acercarse a la 'imagen', surgen nuevos detalles, que a su vez pueden desglosarse en otros elementos. Lamentablemente, no puedo recordar quién dijo esto primero.

Sin embargo, esto también significa que se deben realizar análisis constantemente, especialmente cada vez que se realicen cambios en el diseño. La seguridad es, por lo tanto, un problema que requiere atención constante. Hablando por mí mismo, siempre confiaría esto a un ingeniero de seguridad que tenga esta tarea específica que realizar en el proyecto (no tienen que trabajar a tiempo completo en el proyecto). Para lograr el nivel deseado de calidad (o exhaustividad), el ingeniero de seguridad recurre naturalmente a su conocimiento existente del tema, como se mencionó anteriormente. Esto incluye, por ejemplo, una comparación con listas genéricas de requisitos existentes.

Mi experiencia en proyectos

Adopté este mismo enfoque en un proyecto hace algún tiempo. Los requisitos se elaboraron en paralelo, aunque el proyecto tenía un cronograma ajustado. Esto es lo que el cliente dijo después de dos talleres y un informe sobre los resultados de la primera iteración: 'Súper rápido y súper sucio, pero los resultados son asombrosos'.

Esto no significa que puedas abordar la seguridad de manera 'rápida y sucia', pero puedes comenzar sin pretensiones de exhaustividad y proporcionar una introducción rápida y dirigida al complejo tema de la seguridad, basándote en las evaluaciones de riesgos. Claramente, hay un largo camino por recorrer. Dicho esto, ¿no tendría mucho más sentido vigilar los problemas de seguridad desde el principio y volver a priorizarlos si es necesario a medida que se obtenga mejor información?

Bajo el principio de "shift-left", es importante implementar herramientas adecuadas para lograr un enfoque más equilibrado, ya que la fase inicial se centra fuertemente en el diseño y los requisitos. Aquí, también es importante evitar tener un gran número de problemas de seguridad sin resolver justo antes de la implementación. ¿No sería mucho mejor proporcionar a la persona que toma la decisión información sobre el estado y los posibles riesgos residuales asociados con el lanzamiento demasiado temprano que recibir una luz roja en una puerta de calidad de lanzamiento?

Conclusión

Una pregunta rápida antes de concluir la publicación del blog: ¿tiene más sentido iniciar una conversación sobre seguridad desde el principio y completar la lista de requisitos con el tiempo, o sería mejor hacer esto como el primer paso en el proceso? Como has visto, prefiero el enfoque iterativo porque permite integrar consideraciones de seguridad desde el principio y utiliza evaluaciones de riesgos para priorizar los requisitos. En mi opinión, el objetivo no es obtener una lista completa de requisitos de seguridad de inmediato, sino abordar los problemas de seguridad desde el principio para poder realizar mejoras graduales. El uso de herramientas adecuadas y el monitoreo continuo minimizan los riesgos antes de la implementación.

Si deseas obtener más información sobre temas relacionados con la seguridad en adesso y los servicios que ofrecemos para respaldar a las empresas, consulta nuestro sitio web.