¿Pueden los controles de mitigación de riesgos reducir el impacto?

El impacto puede cambiar si el control implementado altera las capacidades de un potencial atacante en caso de que se explote el problema.

Un buen ejemplo de dónde cambiaría el impacto es cuando la mitigación implica la segregación de redes. Antes de la segregación, un exploit en el Daemon X heredado no soportado de OldCorp podría hacer que alguien tenga acceso a la red interna, y luego exfiltrar todos sus documentos internos de las SMB compartidas. Después de la segregación, el cuadro en el que se asienta OldCorp ULDX ya no está en posición de enrutar paquetes a su red corporativa "normal", por lo que se reduce el impacto de su propiedad.

depende de lo que quieras decir con "controles" entonces. Dado que usa un sistema de monitoreo, todavía tendrá el impacto de que un servicio se está deshabilitando, pero pronto se notará y podrá iniciar la recuperación. o, si realiza una supervisión inteligente, llame la atención y actúe antes de que se caiga un servicio.

lo mismo se aplica a los sistemas de reserva implementados que podrían tomar el control de los servicios, ya sea en su totalidad o en modo semiautomático, o cosas como planes de respuesta de emergencia. Todo lo que ayude a mantener corto el tiempo de recuperación, limitará el impacto.

siempre tratará de evitar interrupciones, pero la redundancia es costosa, por lo que, con frecuencia, su opción es limitar el tiempo de recuperación, en caso de que ocurra una interrupción. Si toma el cálculo de Feral Oink, Impact (evento) podría describirse como Impact (outage * outage_time) en el que puede influir en outage_time, lo que disminuye el impacto.

Su definición de riesgo es Risk = Impact(event) * Probability(event) .

El caso general es el valor esperado, o E(x) = x * Prob(x) .

Si queremos describirlo en términos mensurables, el valor en dólares es la métrica más general de elección que las personas pueden convencer para que cuide, por lo que

Dollars-at-Risk = Loss due to event * Probability of event occurring

¡Sus políticas de riesgo reducirán Probability of the event occurring (el nivel de incidencia), esperamos!

A falta de documentación, parece probable que sus predecesores, que redactaron las políticas de riesgo anteriores, cometieron el error de cambiar ambos términos. La única forma en que el otro término, Loss due to event cambiará sería de algo externo pero causal, por ejemplo. El paso del tiempo, o por contingencia. Digamos que el incidente es una brecha en la red que resulta en una interrupción del sistema.

Paso del tiempo
La pérdida de dólares debido a una interrupción podría haber aumentado desde que sus colegas redactaron sus documentos de análisis de riesgo. Por ejemplo, los costos debidos a la interrupción y la pérdida de productividad asociada pueden ser mayores porque el personal actual, es decir, los científicos de datos, es más hábil y más compensado que sus predecesores, es decir, los estadísticos aplicados.

El impacto de la interrupción del sistema podría haber disminuido . Por ejemplo, los estadísticos, me refiero a los científicos de datos, hacen todos sus computación de alto rendimiento en la nube de AWS EC2 (a través del teléfono inteligente BYOD) ahora, en lugar de un Cray o mainframe en el sótano.

Contingencia
La evaluación de riesgos basada en la contingencia sería sumamente improbable sin una explicación adjunta. Cualquier explicación de este tipo se incluiría, como parte de la política de control de riesgos.

Además, sería difícil hacerlo con precisión. Simplemente como un experimento mental, extendamos ese escenario de interrupción. Es posible que una interrupción no afecte a los científicos de datos, pero podría llevar a cabo la facturación y el procesamiento de la nómina, lo que sería muy costoso. Pero eso significaría que el mainframe del sótano se desconectó. No es probable que una política de mitigación de riesgos cubra dicha evento extremo atípico , ni debería, no mientras hay mainframes que ejecutan MVS / TSO y RACF.