Deuda de seguridad de aplicación tiene algunas similitudes con la deuda técnica, pero Hay algunas diferencias en las que debemos pensar cuando decidimos si nuestra carga de deuda de seguridad se ha elevado demasiado y debe pagarse. Me gustaría saber cómo calcular las deudas de seguridad en nuestras aplicaciones bancarias?
El mejor consejo que he escuchado es encontrar una lista de todos los diferentes tipos de eventos que podrían ocurrir como resultado de su deuda de seguridad. A continuación, trate de estimar el costo de cada uno de esos eventos. A continuación, determine la probabilidad de que esos eventos ocurran por año. Tu fórmula final debería tener un aspecto 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 de SQL + CSRF. (He inventado números para facilitar las matemáticas):
El costo estimado de la deuda de seguridad para el año en cuestión sería:
(5 * $ 100,000) + (10 * $ 25,000) = $ 750,000
En este momento, 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 formado por investigadores de doctorado de la Universidad de Glasgow y el MIT para comenzar a crear un marco para abordar esto. Estamos combinando el Análisis de Procesos Teóricos de Sistemas para la Seguridad del MIT ) y los conceptos de la arquitectura naval, conocidos como Diseño de vulnerabilidad . Si bien las técnicas están destinadas a analizar una organización y cualquier subproceso, también es adecuada para una sola aplicación como objetivo de análisis.
Lo siguiente está bajo desarrollo y pruebas. Sin embargo, los conceptos son útiles.
Para mi equipo, el cálculo de la "Deuda de seguridad de la aplicación" es solo otra forma de "Ingeniería de vulnerabilidad de sistemas-teoría". Esto es diferente de la administración de vulnerabilidades típica que puede tratarse con escáneres y parches automatizados y configuración. En su lugar, 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 con otros sistemas. Desde esta perspectiva de la teoría de sistemas, usted determina dónde están las vulnerabilidades y las debilidades (vulnerabilidades de futuro cercano).
Estas vulnerabilidades pueden estar en todo el espectro de:
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 mediante la comprensión de las amenazas. Este no es un proceso de modelado de amenazas (consulte la última sección).
Terminas con un análisis sistémico de las vulnerabilidades actuales de tu sistema.
Pero ahora todavía debe determinar si necesita hacer algo al respecto.
Usted 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). Podría encontrar 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 de enfoque de características y no de enfoque de calidad de código. La deuda, en este caso, es cultural.
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 apoyarse .
Al igual que con cualquier proceso de mitigación de riesgos, debe mantener los costos de mitigación por debajo de las pérdidas esperadas y todo debe completarse para respaldar los objetivos del sistema.
Al adoptar un enfoque centrado en la teoría de sistemas y la vulnerabilidad, hemos descubierto que este proceso promueve soluciones que son rentables y se dirigen a la causa raíz de los problemas, no a los efectos de los problemas. También identificará las áreas que deben ser eliminadas para reducir las vulnerabilidades (un proceso sustractivo).
Los enfoques centrados en la amenaza 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 de reducirla.
Estimación de la deuda de seguridad de la aplicación Durante el proceso de desarrollo de software, se deben llevar a cabo procedimientos estrictos de programación, análisis de código y prueba de aplicaciones. Estos procedimientos están especialmente diseñados para garantizar que la aplicación desarrollada sea de la más alta calidad posible y que todos los defectos de seguridad estén sellados. Sin embargo, a pesar de la estricta adhesión a los procedimientos de desarrollo establecidos, de vez en cuando la aplicación desarrollada se vuelve vulnerable. La acumulación de estas vulnerabilidades en una aplicación eventualmente se convierte en la deuda de seguridad de la aplicación. En su artículo, Chris describe la deuda de la aplicación como "*
La deuda de seguridad es similar a la deuda técnica. Ambas deudas son de diseño y Construcciones de implementación que tienen aspectos negativos que se agregan. Con el tiempo y el código se debe volver a trabajar para salir de la deuda. Seguridad La deuda se basa en las vulnerabilidades latentes dentro de una aplicación. Las tasas de interés de aplicación son los factores del mundo real fuera de la Control del equipo de desarrollo de software que conduce a vulnerabilidades. teniendo costo real. Estos factores incluyen el costo de una violación de seguridad Y la motivación del atacante para descubrir y explotar lo latente. vulnerabilidades
*. " Modelo financiero de deuda de seguridad de aplicación Actualmente, hay varias métricas de deuda de seguridad de aplicación que intentan estimar el valor de la deuda de seguridad. En este artículo, abordaré una publicación de Russell que creo que ayuda a abordar el concepto de deuda de seguridad.
En su publicación, Russell indica que *
“La deuda de seguridad de la aplicación es un 'préstamo' con capital variable que podría oscilar entre el 0% y el 100% de los costos del proyecto original. los "Principal" es lo que finalmente tendrá que pagar para corregir errores de seguridad o reescribir el código. También tiene intereses variables e inciertos. "costos", que son los costos de las violaciones de seguridad debidas a estos vulnerabilidades Esto incluye la posibilidad de la madre de todos. pagos globales (es decir, un gran evento de pérdida) ".
*
Esto nos da la fórmula de deuda
Deuda = Principal esperado + Costos por intereses
La tarea principal consiste en estimar los valores del capital esperado y los costos de interés.
Principal esperado Una cosa que debemos tener en cuenta es que el valor del capital esperado siempre será un porcentaje del costo inicial del proyecto. Eso significa que el capital esperado puede tener un valor entre 0% -100% del costo inicial. Esto significa que el valor principal esperado puede aumentar con un valor discreto F. La administración se enfrenta a varios escenarios, es decir, puede: No reescribir (0%), ¿Reescritura menor (10%), ¿Reescribir importante (25%), Haga reescritura sustancial (50%) o Pague por una reescritura del 100%. Por lo tanto, el capital esperado será una proporción del costo inicial del proyecto F multiplicado con la probabilidad de que la administración elija esa opción.
EP = ∑_ (i = 1) ^ 5▒ 〖p (F¬¬i) .c (Fi)〗
donde F¬i = escenario de corrección de código (i = 0..n = 5) P (Fi) = probabilidad de elegir un escenario particular C (Fi) = costo de arreglar el escenario elegido. Sin embargo, el capital esperado variará según la industria, el tamaño de la empresa y los recursos de la empresa, entre otros factores. La gerencia determinará la cantidad de recursos para invertir en diferentes circunstancias.
Costes de interés Los costos por intereses incluyen el costo involucrado en cubrir el costo de incumplimiento. Se incurren después de que se explota la vulnerabilidad de una aplicación. Es difícil estimar el tipo de probabilidad y la probabilidad de que ocurra una violación de la aplicación. Esto se debe a que no hay una relación directa que dicte qué tipo de infracción ocurrirá en aplicaciones particulares.
Actualmente, es un conocimiento básico que los intrusos están dirigidos a aplicaciones que manejan datos confidenciales del cliente, pero al mismo tiempo, el nivel de seguridad en estas aplicaciones que manejan datos confidenciales es muy alto. Debido a la naturaleza dinámica de las violaciones de seguridad, una vulnerabilidad en una aplicación podría afectar la seguridad de otra. Por ejemplo, muchas organizaciones prefieren integrar aplicaciones de terceros con aplicaciones internas. La integración de estas aplicaciones puede afectar la seguridad de otra aplicación. Por lo tanto, será difícil estimar la probabilidad.
El uso de datos para estimar los costos de interés podría ser útil para estimar el valor del costo de interés. Los datos de diferentes compañías en la misma industria se pueden utilizar para determinar cuánto incurrirá una empresa para atender la violación de datos.
Lea otras preguntas en las etiquetas web-application banks risk-management appsec risk-analysis