Modelado de amenazas: ¿incluidas las amenazas que no se pueden mitigar?

2

Al modelar amenazas, ¿debería incluir las amenazas que un sistema no puede mitigar?

Si es así, ¿dónde debería parar? Podría llevar mucho tiempo listar todas las amenazas que uno no puede mitigar.

    
pregunta user5508297 11.09.2016 - 03:42
fuente

4 respuestas

1

Depende de por qué no puedes mitigarlos y lo que obtendrías al escribirlos. Sin duda, desea buscar categorías, en lugar de enumerar amenazas individuales.

Por ejemplo, puede ser que no puedas defenderte contra la raíz. Si sigue apareciendo, escríbalo y continúe apuntándolo cuando aparezca la siguiente variación. Escribirlo es útil porque te permite salir de ratholes. Desea escribir la categoría ("Root wins" vs "1. root puede cambiar este archivo de configuración; 2. root puede detener este proceso ...")

Puede ser que tengas una gran cantidad de amenazas porque te tomas una dependencia de algunas revoluciones de (por ejemplo) Ubuntu, que incluye una gran cantidad de ataques de superficie, en cuyo caso, escribirlo puede ayudar a alguien que pueda autorizar el traslado. Ubuntu a una distribución más pequeña.

Una lista de amenazas que no puede abordar puede ser útil como parte de su documentación de seguridad (MSFT hace esto con "10 leyes de seguridad inmutables") para administrar las relaciones con los clientes y los buscadores de errores.

    
respondido por el Adam Shostack 11.09.2016 - 18:28
fuente
1

Aunque creo que Jonah B cubrió las cosas bastante bien. Solo para ser más directo.

Yo diría "Sí", sin duda.

Los riesgos que no puede mitigar son tan importantes como cualquier otro riesgo.

El riesgo residual es la medida importante. Este es el riesgo que permanece después de la mitigación. Usted toma en cuenta todos los riesgos residuales al calcular el riesgo general. Donde no hay mitigación, el riesgo residual es el mismo que el riesgo inicial.

Luego, como dice Jonah, debe tener una discusión abierta dentro de la organización sobre los riesgos residuales y lo que significan para el negocio. También debe comprender el apetito por el riesgo . ¿Cuánto riesgo querrá asumir la organización? Esto requiere que todos los riesgos organizativos se gestionen de forma integral, por supuesto.

ACTUALIZACIÓN: ¿Dónde debes parar? Cuando los riesgos son irrelevantes.

Esto también depende de para quién estás haciendo el modelado. Las personas mayores y de nivel C solo querrán los artículos caros que impactan en el negocio en general. Los gerentes de proyecto querrán cualquier cosa que pueda impactar la entrega del proyecto. Los gerentes de servicios desean riesgos que afectarán el funcionamiento en vivo, los SLA, etc.

Si está modelando un cambio de sistema que mejorará la rentabilidad de una organización en $ 2 millones por año, es posible que le interesen los riesgos que podrían tener un impacto de monitoreo de unos pocos cientos de dólares en un año, a menos que también tengan otros importantes impacto como la confianza del cliente o problemas legales.

No existe una única solución única para la gestión de riesgos.

    
respondido por el Julian Knight 11.09.2016 - 11:42
fuente
0

Depende del contexto, la audiencia, etc. En general, el alcance es importante, y en cualquier alcance en particular, debe haber una comprensión del impacto de las amenazas significativas no mitigadas.

A nivel de la empresa u organización, las amenazas no mitigadas significativas pueden ser señales para salir de un área particular de práctica, o para obtener un seguro comercial adicional, o para contratar, o para tomar alguna otra acción estratégica.

A nivel de sistemas, las amenazas no mitigadas significativas pueden sugerir áreas de mejora arquitectónica.

En el nivel de una aplicación, las amenazas no mitigadas significativas en el ámbito de la aplicación generalmente deben incluirse en el registro.

Las aplicaciones cambian con frecuencia, por lo que las amenazas a ese nivel contribuyen al cambio de la aplicación. Los sistemas y las empresas cambian más lentamente; Las amenazas en esos niveles no necesitan ser revisadas constantemente.

    
respondido por el Jonah Benton 11.09.2016 - 04:25
fuente
0

Hay un valor definido en la inclusión de amenazas que no puede mitigar. La mitigación de amenazas es solo una de las formas en que se puede manejar una amenaza. Los riesgos que plantean las amenazas pueden ser:

  1. Evitado (por ejemplo, no tener la función que crea la vulnerabilidad)
  2. Transferido (por ejemplo, seguro)
  3. mitigado
  4. aceptado

Para elegir la forma correcta de manejar el riesgo que representa la amenaza, debe conocer la amenaza (es decir, que existe) y qué impacto podría tener en su sistema.

Otra razón por la que es importante incluir amenazas que no se pueden mitigar es porque esas amenazas pueden potencialmente usarse como habilitador para una amenaza diferente para su sistema (que usted podría mitigar).

    
respondido por el stuffy 21.09.2016 - 21:12
fuente