Granularidad para activos de datos al determinar el riesgo durante el desarrollo de software

4

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:

  1. Introduzca los activos en un inventario de activos a medida que se construye el sistema;
  2. Determine los objetivos de seguridad para cada activo (e implícitamente la criticidad del activo);
  3. 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í.

    
pregunta Nikola Luburić 25.12.2017 - 10:41
fuente

2 respuestas

3

La forma en que razonaría sobre esto es volver a la decisión inicial, que era centrarse en los activos. Los enfoques basados en activos para modelar amenazas tienden a terminar con un problema como el suyo, que es "Haga una lista de todo". Esa larga lista hace que sea difícil concentrarse. (El otro problema que encuentran es "¿qué es un activo?")

A la mayoría de los grupos de ingenieros les resulta más fácil realizar cambios en las áreas en las que están haciendo cambios en el sistema, y centrarse en el software / sistema que está dentro del alcance de la iteración / carrera actual le ayuda a encontrar amenazas que se vuelvan accionables.

Si, en lugar de centrarse en el activo, se enfoca en el software y pregunta "¿esto nos expone a nuevas amenazas?", entonces su pregunta es más fácil de responder. Para módulos menores, esa pregunta puede centrarse en "¿agrega esto una API, cambia los argumentos de una API o cambia los datos que este módulo está procesando?"

Si es así, puedes usar una mnemotécnica como STRIDE para buscar falsificación, manipulación, repudio, divulgación de información, denegación de servicio o elevación de privilegios para examinar los elementos modificados.

Respuestas adicionales (SE perdió mi intento anterior de esto; esto es más corto)

Primero, si su cliente le exige que proporcione un modelo de amenaza centrado en los activos, entonces esa es su respuesta a lo que importa. Usted corre absolutamente el riesgo que identifica, "corremos el riesgo de perder activos específicos que podrían resultar insuficientemente protegidos", pero si no tiene presupuesto, usted enfrenta ese riesgo de todos modos. SE no puede decirle qué activo Las reglas de categorización harán feliz a su cliente. (texto en negrita añadido aquí para corregir un error de edición)

En segundo lugar, parece que estás tratando de hacer algo como riesgo = probabilidad * impacto. Ninguna de las entradas es defendible. Debes arreglar las cosas fáciles y luego enfocarte en tener un diálogo sobre las soluciones potencialmente difíciles.

Por último, tu tercera pregunta coloca el carro delante del caballo. Su modelo de amenaza para determinar qué es importante, no determinar qué es importante, entonces el modelo de amenaza es eso. Si está centrado en los activos, ¿qué activos tiene su directorio activo? ¿Qué tiene tu firewall? Apuesto a que ambos son importantes para mantener su sistema seguro, no por los activos que almacenan.

Por último, si su problema es el presupuesto, los cambios que está realizando, según lo documenta, no solucionan ese problema. Debe encontrar la forma de obtener ganancias rápidas y usarlas para justificar el presupuesto adecuado.

    
respondido por el Adam Shostack 27.12.2017 - 17:39
fuente
2

Esa es una muy buena pregunta. La gestión de riesgos es un negocio complicado. En el proceso del ciclo de vida, debe encontrar el equilibrio entre el nivel de detalle de inventario de los activos.

La definición de activo es Any resource or information an organization needs to conduct its business . Sobre esta base, debe clasificar los activos introducidos por los desarrolladores para saber si realmente son activos. Para identificar un activo, pregúntese: "What are you trying to protect?" . Y para tratar de identificar el hilo asociado, pregunta: "What are you afraid of happening?" . Si no puede encontrar claramente la respuesta para un caso concreto, no lo incluya en su inventario. Quizás este método pueda ahorrarle tiempo.

Desde aquí no podemos saber cuán complejo es tu proyecto. Pero debes seguir el "manual". El modelado de amenazas es algo que se debe practicar una y otra vez para mejorar. Nunca hay verdades 100% universales.

Considera estudiar una certificación enfocada en este tipo de cosas. Por ejemplo, CSSLP (Certified Secure Software Lifecycle Professional) es una certificación ISC. Hay una sección completa que habla sobre la gestión de riesgos. Allí puede aprender metodologías, procesos y algunos consejos y sugerencias a seguir.

Espero que ayude. Pero como dije antes, creo que nadie tiene la respuesta perfecta para esto.

    
respondido por el OscarAkaElvis 25.12.2017 - 12:48
fuente

Lea otras preguntas en las etiquetas