Hvordan beregnes eksponeringsfaktor?

Du kan ikke beregne en enkelt tabsforventning (SLE) uden en faktisk, historisk, estimeret eller gætte-estimeret eksponeringsfaktor (EF ). Jeg tror, hvad der mangler i de fleste INFOSEC undervisningsmaterialer til risikostyring, der dækker kvantitativ analyse, er at de ikke giver meget vejledning i at oversætte den generiske risikodefinition [risiko = f (aktiv, trussel, sårbarhed)] til en EF og til SLE- og ALE-formlerne. Jeg kiggede online lige nu, og jeg så ikke nogen, der dækkede det godt.

For at der eksisterer en risiko, skal der være en sårbarhed at udnytte og trusler mod denne sårbarhed. Disse trusler har også en sandsynlighed for forekomst (som kan være baseret på observerede angreb). Trussels sandsynligheden oversættes til den årlige forekomst i den kvantitative analyse. Så din EF er for det meste baseret på sårbarheden og dens konsekvenser for aktivet, når truslen opstår.

Mange per-risiko (dvs. per trussel / sårbarhedspar) EFer resulterer i en 0 EF eller en 1 EF hvilket reducerer noget af risikoanalysearbejdet. Det hjælper også undertiden med at foretage EF-estimering at også overveje eventuelle afbødere, hvad der er på plads for at hjælpe med at reducere eller eliminere sårbarheden.

Nogle forenklede eksempler på trivielle 0 og 1 EFer:

• Aktiv: en saldo på en online-tilgængelig bankkonto

  • Trussel: Hacker anvender fiskemails for at få bankkonto-login til at dræne konti

    • Sårbarheder: HUMINT: kontohaver nares til at afsløre deres brugerid & adgangskode
    • Mitigatorer: ingen
    • Resultat EF til bankkontosaldo: 1.0

  • Trussel: Hacker anvender fiskemails for at få bankkontologins til at dræne konti

    • Sårbarheder: HUMINT : kontoindehaveren nares til at afsløre deres brugerid & adgangskode
    • Begrænsere: banken tillader ikke at overføre eksterne saldooverførsler online; banken viser ikke kontonumre eller dirigere numre online
    • Resultat EF til bankkonto ba lanse: 0,0

  • Trussel: Hacker bruger nylige lister over stjålet bruger-id / adgangskode fra et socialt medieside

    • Sårbarheder: HUMINT : mange kontohavere bruger samme adgangskoder på alle websteder og AUTHEN: mange websteder (inklusive denne bank) bruger ens e-mail-adresse som bruger-id
    • Begrænsere: banken har tofaktorautentificering på stedet
    • Resulterende EF til bankkontosaldo: 0,0

For de fleste andre risici skal man vurdere sårbarheden , truslen og eventuelle sårbarhedsreducerende midler til at beslutte et estimeret EF. Hvis man ikke har mange reelle observerede data til at basere EF afhængigt af risikoen, kan disse individuelle SLEer være vildt out-of-line. Når de rulles sammen til samlede årlige tabsforventninger, kan det have en meget stor fejlmargin på grund af alle de dårligt estimerede individuelle EFer.

Brug dog banksektoren som et eksempel for en bank, der har været i -drift i mange år, de har detaljerede historiske tabsdata (inklusive cyberrelaterede tab). En bank kan faktisk beregne disse værdier (EF, SLE, ARO, ALE) ganske nøjagtigt for deres historie-til-dato og derefter bruge dem til forudsigelse af fremtidige tab.

Også i betragtning af den detaljerede tabshistorie kan banker foretage relativt nøjagtige hvad-hvis-omkostnings-fordele-analyser af implementering af nye afbrydere (såsom tofaktorautentificering).

1. Bestem det samlede omkostningsestimat til implementering og implementering af denne udbedringsmiddel .
2. Beregn de samlede ALE-givne aktuelle EFer over en tidsperiode (f.eks. 10 år).
3. Tilpas eventuelle EFer, som mitigatoren påvirker.
4. Beregn den nye samlede ALE over den samme tidsperiode
5. Beregn forskellen mellem den nye samlede ALE og den aktuelle samlet ALE (som er den håbede fordel ved, at den nye ALE ideelt set er mindre end den nuværende ALE)
6. Hvis fordelen (tabsreduktion) er større end de samlede omkostninger at gennemføre, så gør det; hvis fordelen (tabsreduktion) er væsentligt mindre end de samlede omkostninger, der skal implementeres, vil cost-benefit-analyse anbefale, at du ikke implementerer mitigatoren.

Kommentarer

• Hvilket " akademisk " område beskæftiger sig med disse skøn? Det virker ret aktuarmæssigt.
• Mange fagområder bruger og forsker i risikoanalyse.Finansiel / forsikringsrisiko er et godt eksempel, og efter at have optjent min MBA ved jeg, at risikoanalyse er en del af denne læseplan. Risikostyring er det egentlige grundlag for al cybersikkerhed fra starten, og som en certificeret INFOSEC risikovurderingsfagmand ved jeg, at den undervises i undervisningen i datalogi. Risikoanalyse er sandsynligvis også en del af Human Behavioral Science, Disease Management Science og mange andre.
• Tak. Det slog mig som en rudimentær ækvivalent med præmiepriser i almindelig forsikring (omkostninger ved et krav x sandsynlighed for nævnte krav).