Mentre eseguivo una valutazione del rischio, ho scoperto che in alcuni vecchi documenti RA, dopo che i controlli erano stati posizionati, l'impatto nel valore forcasted era cambiato e non aveva senso per me. Per me l'impatto non cambia mai poiché l'impatto di un servizio critico che è inattivo è lo stesso sia che il controllo sia in atto o meno. Ciò che cambia, tuttavia, è la probabilità che abbassi il rischio (Risk = Probability x Impact). È corretto?
L'impatto può cambiare se il controllo messo in atto altera le abilità di un potenziale attaccante se il problema viene sfruttato.
Un buon esempio di dove cambierebbe l'impatto è quando la mitigazione comporta la segregazione delle reti. Prima della segregazione, un exploit su OldCorp Legacy Daemon X non supportato potrebbe portare qualcuno a ottenere l'accesso alla rete interna, quindi a estrarre tutti i tuoi deliziosi documenti interni dalle condivisioni SMB. Dopo la segregazione, la casella su cui si trova OldCorp ULDX non è più in grado di instradare i pacchetti alla rete "regolare" di corp, quindi l'impatto che ne deriva è ridotto.
dipende da cosa intendi per "controlli" allora. dato che si utilizza un sistema di monitoraggio, si avrà comunque l'impatto di un servizio in calo, ma si noterà molto presto e si potrà avviare il ripristino. oppure, se si esegue il monitoraggio in modo intelligente, farsi notare e agire prima che un servizio possa interrompersi.
i sames vanno per sistemi di standby implementati che potrebbero prendere il sopravvento su sevices, completamente o halfautmated, o cose come i piani di emergenza-risposta. tutto ciò che aiuta a mantenere il tempo di recupero breve, limiterà l'impatto.
cercherai sempre di evitare interruzioni, ma la ridondanza è costosa, quindi la tua opzione è molto spesso per limitare il tempo di recupero, se si verifica un'interruzione. Se si prende il calcolo da Feral Oink, Impact (evento) potrebbe essere descritto come Impact (outage * outage_time) in cui si è in grado di influenzare l'outage_time, diminuendo così l'impatto.
La tua definizione di rischio è Risk = Impact(event) * Probability(event) .
Il caso generale è il valore previsto o E(x) = x * Prob(x) .
Se vogliamo descriverlo in termini misurabili, il valore in dollari è la metrica di scelta più generale di cui le persone possono essere convinte a preoccuparsi, quindi
Dollars-at-Risk = Loss due to event * Probability of event occurring
Le tue politiche di rischio abbasseranno il Probability of the event occurring (il livello di incidenza), speriamo!
In assenza di documentazione, sembra probabile che i vostri predecessori, che hanno redatto le vecchie politiche di rischio, abbiano commesso l'errore di modificare entrambi i termini. L'unico modo in cui l'altro termine, Loss due to event cambierà da qualcosa di esterno ma causale, ad es. passaggio di tempo, o a causa di contingenza. Diciamo che l'incidente è una violazione della rete che provoca un'interruzione del sistema.
Passaggio del tempo
La perdita del dollaro dovuta a un'interruzione potrebbe essere aumentata da quando i tuoi colleghi hanno redatto i documenti di analisi del rischio. Ad esempio, i costi dovuti a interruzioni e la conseguente perdita di produttività potrebbero essere più elevati perché il personale attuale, cioè i dati scienziati, è più qualificato e più altamente retribuito rispetto ai loro predecessori, cioè gli statistici applicati.
L'impatto sull'interruzione del sistema potrebbe essere diminuito . Per esempio, gli statistici, intendo gli scienziati dei dati, fanno tutti i loro computing ad alte prestazioni nel cloud AWS EC2 (tramite smartphone BYOD) ora, invece di un Cray o mainframe nel seminterrato.
Contingency
La valutazione del rischio basata sull'impotenza sarebbe eccessivamente improbabile senza una spiegazione di accompagnamento. Qualsiasi spiegazione di questo tipo sarebbe inclusa, come parte della politica di controllo del rischio.
Inoltre, sarebbe difficile da fare con qualsiasi precisione. Semplicemente come un esperimento mentale, estendiamo questo scenario di interruzione. Un'interruzione potrebbe non interessare gli scienziati dei dati, ma potrebbe prendere l'elaborazione di fatturazione e buste paga, il che sarebbe molto costoso! Ma ciò significherebbe che il mainframe del seminterrato è andato offline. Nessuna politica di mitigazione del rischio è in grado di coprire tale evento estremo anomalo , né dovrebbe, non fintanto che ci sono mainframe in esecuzione MVS / TSO e RACF.
Leggi altre domande sui tag risk risk-analysis