Hoe de blootstellingsfactor te berekenen?

U kunt geen enkele verliesverwachting (SLE) berekenen zonder een werkelijke, historische, geschatte of geschatte blootstellingsfactor (EF ). Ik denk dat wat ontbreekt in de meeste INFOSEC-trainingsmaterialen voor risicobeheer die kwantitatieve analyse behandelen, is dat ze niet veel richtlijnen geven voor het vertalen van de algemene risicodefinitie [risk = f (asset, threat, kwetsbaarheid)] in een EF en in de SLE- en ALE-formules. Ik heb zojuist online gekeken en ik heb “niemand gezien die het goed behandelde.

Om een risico te laten bestaan, moet er een kwetsbaarheid zijn die kan worden misbruikt, en bedreigingen tegen die kwetsbaarheid. Die bedreigingen hebben ook een kans van optreden (die kan zijn gebaseerd op waargenomen aanvallen). De dreigingskans vertaalt zich in de kwantitatieve analyse in de geannualiseerde frequentie van voorkomen. Uw EF is dus meestal gebaseerd op de kwetsbaarheid en de gevolgen ervan voor het activum wanneer de dreiging zich voordoet.

Veel EFs per risico (dit betekent per bedreiging / kwetsbaarheidspaar) resulteren in een 0 EF of een 1 EF wat een deel van de werklast voor risicoanalyse vermindert. Het helpt soms ook bij het maken van EF-schattingen om ook rekening te houden met eventuele mitigerende factoren die zijn ingevoerd om de kwetsbaarheid te helpen verminderen of elimineren.

Enkele simplistische voorbeelden van triviale 0 en 1 EFs:

• Asset: het saldo van een online toegankelijke bankrekening

  • Bedreiging: hacker gebruikt vis-e-mails om bankrekeningaanmeldingen te krijgen om accounts leeg te maken

    • Kwetsbaarheden: HUMINT: accounthouder wordt misleid om zijn gebruikersnaam & wachtwoord te onthullen
    • Mitigators: geen
    • Resulterende EF om bankrekening saldo: 1.0

  • Bedreiging: hacker gebruikt vis-e-mails om bankrekeningaanmeldingen te krijgen om rekeningen leeg te maken

    • Kwetsbaarheden: HUMINT : rekeninghouder wordt misleid om zijn gebruikers-ID & wachtwoord
    • Beperkende factoren te onthullen: de bank staat niet toe dat externe overboekingen online worden gestart; de bank toont geen rekeningnummers of nummers online routeren
    • Resulterende EF naar bankrekening ba lance: 0.0

  • Bedreiging: hacker gebruikt recente lijsten met gestolen gebruikersnaam / wachtwoord van een sociale-mediasite

    • Kwetsbaarheden: HUMINT : veel accounthouders gebruiken dezelfde wachtwoorden op alle sites en AUTHEN: veel sites (inclusief deze bank) gebruiken het e-mailadres van een gebruiker als gebruikers-ID
    • Beperkende factoren: de bank heeft twee-factor-authenticatie in de plaats
    • Resulterende EF naar saldo bankrekening: 0,0

Voor de meeste andere risicos moet men de kwetsbaarheid beoordelen , de dreiging en eventuele risicobeperkende factoren om een geschatte EF te bepalen. Als iemand niet veel echt geobserveerde gegevens heeft om de EF te baseren, afhankelijk van het risico, dan kunnen deze individuele SLEs enorm uit de pas lopen. Wanneer het wordt samengevat in geaggregeerde verliesverwachtingen op jaarbasis, kan het een zeer grote foutenmarge hebben vanwege alle slecht geschatte individuele EFs.

Maar met de banksector als voorbeeld voor een bank die -operatie gedurende vele jaren, ze hebben gedetailleerde historische verliesgegevens (inclusief cybergerelateerde verliezen). Een bank kan deze waarden (EF, SLE, ARO, ALE) eigenlijk vrij nauwkeurig berekenen voor hun geschiedenis tot op heden, en ze vervolgens gebruiken voor voorspellingen van toekomstige verliezen.

Ook gezien die gedetailleerde verliesgeschiedenis , kunnen banken een relatief nauwkeurige wat-als-kosten-batenanalyse maken van de implementatie van nieuwe beperkende factoren (zoals tweefactorauthenticatie).

1. Bepaal de totale kostenraming om die beperkende factor te implementeren en in te zetten .
2. Bereken de geaggregeerde ALE gegeven huidige EFs over een tijdsperiode (zeg 10 jaar).
3. Tweak alle EFs die de mitigator beïnvloedt.
4. Bereken de nieuwe geaggregeerde ALE over dezelfde tijdsperiode
5. Bereken het verschil tussen de nieuwe geaggregeerde ALE en de huidige geaggregeerde ALE (wat het gehoopte voordeel is omdat de nieuwe ALE idealiter kleiner is dan de huidige ALE)
6. Als het voordeel (verliesvermindering) groter is dan de totale implementatiekosten, doe dat dan; als het voordeel (verliesvermindering) aanzienlijk lager is dan de totale implementatiekosten, dan zou een kosten-batenanalyse aanbevelen om de mitigator niet te implementeren.

Opmerkingen

• Welk " academisch " gebied behandelt deze schattingen? Het lijkt nogal actuarieel van aard.
• Veel academische gebieden gebruiken en doen onderzoek naar risicoanalyse.Financieel / verzekeringsrisico is een goed voorbeeld, en na het behalen van mijn MBA weet ik dat risicoanalyse deel uitmaakt van dat curriculum. Risicobeheer is vanaf het begin de feitelijke basis van alle cyberbeveiliging en als gecertificeerde INFOSEC Risk Assessment Professional weet ik dat het wordt onderwezen in het computerwetenschappelijk curriculum. Risicoanalyse maakt waarschijnlijk ook deel uit van Human Behavioral Science, Disease Management Science en vele anderen.
• Bedankt. Het kwam me voor als een rudimentair equivalent van premieprijzen in algemene verzekeringen (kosten van een claim x kans op genoemde claim).