Actualmente estamos construyendo un ciclo de vida de desarrollo de seguridad en nuestra corporación de desarrollo de software. Nuestra idea principal es tener un enfoque basado en activos, donde nosotros:
- Introduzca los activos en un inventario de activos a medida que se construye el sistema;
- Determine los objetivos de seguridad para cada activo (e implícitamente la criticidad del activo);
- Siga los activos críticos a lo largo de su ciclo de vida y aplique las mitigaciones adecuadas cuando lo consideremos necesario.
Si bien los activos como el hardware y la infraestructura general están protegidos en su mayoría después del fortalecimiento del sistema y otras actividades basadas en listas de verificación (así como la seguridad física), nos preocupan especialmente los activos de datos electrónicos, utilizados y manipulados por el software.
Como el sistema es bastante grande y hay una gran cantidad de datos, encontramos que mantener el inventario de activos puede ser una actividad agotadora. Es decir, hay una gran cantidad de activos de datos que requieren alta integridad ya que este es un sistema de infraestructura crítica, por lo que no podemos permitirnos pasar por alto estos activos de datos.
En nuestro enfoque, cada activo tiene un propietario, una persona que es responsable de introducir el activo en el inventario, y esto es más a menudo un arquitecto que entiende el panorama más amplio del componente. Sin embargo, nuestros desarrolladores tienen la libertad de agregar nuevos activos de datos menores en forma de estructuras de datos para mantener los resultados de cálculos o cálculos parciales. La pregunta entonces se convierte en: ¿deberían agregarse al inventario?
Esencialmente, esta es una cuestión de la granularidad de los activos de datos en nuestro inventario. Si profundizamos demasiado en los detalles, creamos documentación que no se puede mantener, pero si agrupamos activos específicos en categorías de activos, corremos el riesgo de perder activos específicos que podrían resultar insuficientemente protegidos.
¿Cuál sería un nivel óptimo de granularidad? ¿Cómo razonarías sobre esto?
Información adicional sobre nuestro enfoque anterior centrado en el software
El método de modelado de amenazas de MS (descrito en Modelado de amenazas: diseño para la seguridad) fue algo que implementamos inicialmente. Desarrollamos materiales de capacitación y utilizamos la Herramienta de modelado de amenazas de MS en el proceso, que se enseñó a nuestros arquitectos de software. Desafortunadamente, el proyecto no fue un éxito debido a varios factores, especialmente la financiación adecuada.
Encontramos varios problemas con este enfoque, que no pudimos abordar adecuadamente (debido a nuestra falta de experiencia). Esto incluye:
- Garantía de seguridad: fue difícil convencer al cliente de que los activos de datos en particular estaban protegidos sin rastrearlos;
- Análisis de riesgo: sin examinar los activos que un componente de software estaba manipulando (y cómo una amenaza podría poner en peligro el objetivo de seguridad de ese activo), no pudimos determinar de manera confiable el nivel de riesgo.
- Prioridad de modelado de amenazas: sin activos no pudimos determinar qué componentes eran "más críticos", es decir, qué componentes requerían un análisis de amenazas más profundo y la ayuda de los recursos muy limitados del equipo de seguridad.
Una vez más, todos estos problemas pueden haber sido causados por nuestra inexperiencia con el método, y no por culpa alguna del método en sí.