it-swarm-es.com

¿Cómo calcular la deuda de seguridad de su aplicación?

Deuda de seguridad de la aplicación tiene algunas similitudes con la deuda técnica, pero hay algunas diferencias en las que debemos pensar al decidir si nuestra carga de deuda de seguridad ha aumentado demasiado y debe pagarse. ¿Me gustaría saber cómo calcular las deudas de seguridad en nuestras aplicaciones bancarias?

11
Filipon

En este punto, no existe un método estandarizado para calcular el tamaño (inventario) de la deuda técnica. He estado trabajando con un equipo de investigación compuesto por investigadores de doctorado de la Universidad de Glasgow y MIT) para comenzar a crear un marco para abordar esto. Estamos combinando el Análisis de proceso teórico de sistemas del MIT para Seguridad ( STPA-Sec ) y los conceptos de la arquitectura de la nave Naval, conocidos como Diseño de vulnerabilidad . Si bien las técnicas están destinadas a analizar una organización y cualquier subproceso, es También es adecuado para una sola aplicación como objetivo de análisis.

Lo siguiente está en desarrollo y prueba. Los conceptos son útiles, no obstante.

Ingeniería de vulnerabilidad de teoría de sistemas

Calcular "Deuda de seguridad de la aplicación", para mi equipo, es solo otra forma de "Ingeniería de vulnerabilidad de teoría de sistemas". Esto es diferente de la gestión de vulnerabilidades típica que se puede abordar con escáneres automáticos y parches y configuración. En cambio, analiza el "sistema" en cuestión (su aplicación, en este caso) en su contexto completo de personas, procesos y tecnología a medida que se conecta a otros sistemas. Desde esta perspectiva de la teoría de sistemas, usted determina dónde están las vulnerabilidades y debilidades (vulnerabilidades en el futuro cercano).

Estas vulnerabilidades pueden estar en el espectro de:

  • SQLi oculto detrás de las mitigaciones (las vulnerabilidades SQLi desnudas y expuestas son un problema , no una deuda )
  • subsistemas no parcheados
  • procesos de parches manuales que requieren intervención humana para activarse y completarse
  • falta de auditoria

Todas estas cosas representan una "deuda de seguridad" o una "vulnerabilidad de los sistemas".

Tenga en cuenta que este enfoque no tiene que ver con amenazas aunque las vulnerabilidades se pueden definir a través de la comprensión de las amenazas. Este no es un proceso de modelado de amenazas (consulte la última sección).

Paso 1: Análisis de vulnerabilidad (forma hipercondensada)

  1. Defina el problema de seguridad (¿qué le preocupa?)
  2. Identifique tipos de control no seguro (por ejemplo, lógica de programa, mantenimiento del sistema, garantía)
  3. Identifique causas de tipos de control no seguros (por ejemplo, procesos, tecnología, recursos, conocimiento, cultura, etc.)
  4. Determine si esas causas existen actualmente (estado constante o intermitente)

Terminas con un análisis sistémico de las vulnerabilidades actuales de tu sistema.

Pero ahora todavía necesita determinar si necesita hacer algo al respecto.

Paso 2: Análisis de control de respuesta (forma hipercondensada)

  1. Determine los controles de respuesta/recuperación alrededor de cada vulnerabilidad identificada (¿podemos detectar y responder a eventos inseguros?)
  2. Determine qué controles de respuesta/recuperación no pueden contener suficientes incidentes que exploten o sean causados ​​por las vulnerabilidades
  3. Determine si los suficientes controles de respuesta/recuperación sufren de vulnerabilidades actuales que podrían resultar en un control insuficiente.

Termina con una lista de vulnerabilidades de seguridad con mitigaciones insuficientes. Esta es tu deuda.

Tenga en cuenta que no todos los elementos que resultan de este proceso son tecnológicos (de hecho, de nuestros estudios de caso iniciales, pocos elementos son tecnológicos). Es posible que descubra que su problema de SQLi es en realidad una debilidad en los procesos de revisión de código que son el resultado de una cultura de desarrollo del enfoque de características y no del enfoque de la calidad del código. La deuda, en este caso, es cultural.

Paso 3: alineación de riesgos

Aquí es donde comienza a diseñar las compensaciones entre 1) reducir las vulnerabilidades de varias maneras (personas o procesos o tecnología) y 2) mejorar los controles de respuesta para que los objetivos del sistema puedan ser compatible .

Al igual que cualquier proceso de mitigación de riesgos, debe mantener los costos de mitigación más bajos que las pérdidas esperadas y todo debe completarse para respaldar los objetivos del sistema.

Modelado de Vulnerabilidad vs Modelado de Amenaza

Al adoptar un enfoque centrado en la teoría de sistemas y la vulnerabilidad, hemos descubierto que este proceso promueve remedios que son rentables y apunta a la causa raíz de los problemas, no a los efectos de los problemas. También identificará áreas que deben eliminarse para reducir las vulnerabilidades (un proceso sustractivo).

Los enfoques centrados en las amenazas tienden a ser reactivos, caros, tecnológicos y aditivos (hay una nueva amenaza, ¡necesitamos más cosas!). Esto tiene el efecto de crear más deuda, no reducirla.

6
schroeder

El mejor consejo que he escuchado es elaborar una lista de todos los diferentes tipos de eventos que podrían ocurrir como resultado de su deuda de seguridad. Luego, trate de estimar el costo de cada uno de esos eventos. Luego, calcule la probabilidad de que ocurran esos eventos por año. Tu fórmula final debería verse como

Probability(event type 1) * Cost(event type 1) + 
Probability(event type 2) * Cost(event type 2) + 
... +
Probability(event type N) * Cost(event type N)

Por ejemplo, supongamos que determina que hay dos problemas que podrían ser explotados por su débito de seguridad: Inyección SQL + CSRF. (He inventado números para facilitar las matemáticas):

  • Esperamos 5 ataques exitosos de inyección SQL por año, cada uno de los cuales tendría un costo de recuperación de $ 100,000
  • Esperamos 10 ataques CSRF exitosos con un costo de recuperación de $ 25,000 cada uno

Su costo estimado de la deuda de seguridad para el año en cuestión sería:

(5 * $ 100,000) + (10 * $ 25,000) = $ 750,000

6
Dan Landberg