Evaluarea riscurilor

/+32

Acceptați imaginea de mai sus? Este corectă? O consider ca fiind baza de la care trebuie pornită
discuția legată de evaluarea riscurilor securității sistemelor informaționale! Dilemele mele
filosofico aplicative se limitează strict la acest domeniu. Pentru alte domenii, managementul
riscurilor, așa după cum este el matematizat, este aplicabil.

Mai am o motivație pentru care scriu despre acest subiect: mi se pare că se scriu prea multe
materiale, oarecum independente unele față de altele, în loc de a se încerca o combinare a tot
ceea ce practica a validat.

Mă voi ajuta în cele ce urmeză de un exemplu din „Iluzia utilizatorului. Despre limitele
conştiinţei” (o recomand celor ce doresc să deslușească modul în care funcționează creierul
nostru):

 
 

Care sînt liniile ce apar în prim plan?

Normalul este dat de percepţia majorităţii. Un exemplu? Îmi aduc aminte de ceea ce îmi povestea
un fost coleg cînd a ajuns să muncească într-o ţară nordică: să te uiţi la ceas, să vezi ca este
miezul zilei, dar afară să fie întuneric. Asta era o stare de normalitate, acolo!

ISO Guide 73 defineşte riscul ca fiind probabilitatea unui eveniment de a produce consecinţe
negative. Voi relua unele lucruri deja scrise, cu riscul de a plictisi, avînd această definiție drept
punct de plecare.

Posibilitatea – este o condiţie. A fi sau a nu fi. Zero sau unu!

Probabilitatea este cea prin care verificăm posibilitatea!

Cutremurul este posibil sau imposibil! Dacă spunem că este imposibil, evaluarea s-a încheiat.
Dacă luăm în calcul posibilitatea trebuie să estimăm probabilitatea! Din acest moment mai
intervine o variabilă: impactul acestui eveniment! Prin urmare, putem greşi nu numai în cazul
estimării probabilității ci și în cazul estimării impactului! Altfel spus, estimarea noastră se
bazează în fapt pe frecvențe probabile și pe impact probabil!

Metodele de evaluare cantitativă a riscurilor operează cu probabilități și cuantificări monetare în

încercarea de a estima o pierdere viitoare. Obiectivul evaluării îl reprezintă estimarea pierderilor
anticipate. Pierderea anticipată este produsul a trei factori: ameninţarea, rata apariţiei şi
pierderea pe apariţie

În cazul asigurărilor se elimină evenimentele cu probabilități reduse dar impact cu consecințe

majore. De exemplu, de ce ar trebui să ne mai doară capul în cazul unui război atomic
(amenințare)? Sau dacă lucrezi în orașul în care există o centrală nucleară….Mai contează
vulnerabilitățile?

Problema cea mai spinoasă este dată de credibilitatea estimărilor. Pentru ameninţări cu
consecinţe mari sau mici putem face estimări exacte: nu putem estima cu exactitate
probabilitatea apariţiei unui cutremur, dar putem spune care este impactul său asupra companiei.
Probabilitățile nu mai contează, în aces caz.

Estimările sînt dificil de realizat pentru evenimentele care nu sînt la extreme, pentru
evenimentele normale!

Cum tratăm însă pierderile datorate nefuncționării serverului de baze de date ca urmare a unui
atac DDOS (exemplu pur teoretic). Întreruperea unei afaceri este un caz, să spunem, special
deoarece suma pierderilor datorate acestei amenințări depinde de durata întreruperii funcţiilor
companiei ! Alte variabile! Dacă serverul cu pricina nu este accesibil 10 ore, vînzările suferă?
Sau Contabilitatea? Sau Logistica?
Ameninţările au orar de funcţionare? Altfel spus o amenințare se suprapune pe intervalul în care
trebuie îndeplinită funcţia respectivă? Să presupunem că pe serverul de aplicații ce se bazează pe
serverul de BD ce tocmai a picat, avem două aplicaţii “A” și “B”. Dacă serverul BD nu
funcționează 1 oră, nu avem pierderi. Dacă nu funcționează 1 zi vom avea pierderi potențiale de
10.000 lei. Orarul de funcționare a celor două aplicații este diferit: aplicația “A” rulează zilnic
timp de 10 ore, “B” rulează o dată pe lună timp de 10 ore….Va fi pierderea aceeaşi?

Mai bine puţin şi bine decît mult şi prost

Cum postul precedent doar a zgîndărit lucrurile, să mai facem un salt.  ….Anul trecut citeam
într-o evaluare de riscuri despre avalanşe în mijlocul Braşovului……Cireaşa de pe tort a fost însă
evaluarea riscului legat de inginerie socială…..Cum poţi să evaluezi care este probabilitatea ca
cineva să folosească aşa ceva pentru a obţine acces în sistem, în condiţiile în care nu ai nici cea
mai mică informaţie istorică? Eu unul nu ştiu…..

Voi repeta unele lucruri deja scrise. Atunci cind avem date istorice despre evenimentele din
organizatie putem folosi aceste frecvenţe relative pentru a obţine probabilităţi. În lipsa datelor
istorice, empirice, intervine subiectivismul, ca să nu spun ghiceala. În ambele cazuri însă, vom
dori să obţinem o apropiere de realitate. O estimare.

Este greşit să folosim valori punctuale în loc de distribuţii în evaluarea riscurilor securităţii. Este
ca şi cum am fi profeţi şi am avea date certe despre viitor. Singurul lucru cert, existent înainte ca
ameninţarea să devină realitate, este INCERTITUDINEA! Nu sistemul pentru care estimăm
riscurile se va comporta aşa după cum dorim noi! Dincolo de ce este scris în cărţi, în realitate
facem o estimare a incertitudinilor şi o analiză!

Atît metodele calitative cît şi cele cantitative au limitări practice. Fără a intra în detalii teoretice,
cea mai folosită formulă cantitativă este:

Annualized Loss Expectancy (ALE) = Single Loss Expectancy (SLE) * Annual Rate of
Occurence (ARO)

Adică suma pierderilor directe şi indirecte în urma unei ameninţări şi probabilitatea de apariţie.
Pentru un an calendaristic. De ce? Pentru ca evidenţele contabile sînt anuale!

Dacă ne ducem către modele calitative…tot peste probabilităţi vom da. Cine decide intervalele
astfel încît să avem o diferenţiere cît mai clară a ceea ce este considerat risc important: 0-25, 25-
50…. sau 0-20 sau 0-33? Cum poţi să faci o analiză cost-beneficiu dacă nu există exprimare
monetară? Doar în baza unor elemente calitative? Cum justifici controalele selectate în faţa
managmentului? Spunînd că pierderea este “mare”?

Deşi sînt greu de folosit şi consumatoare de timp, modelele cantitative sînt de dorit! Metoda
Monte Carlo pomenintă în postul precedent, ca instrument de analiză şi suport decizional (şi nu
de evaluare!), generează valori pentru o variabilă probabilistică în intervalul 0-1 şi ia în calcul
funcţia de distribuţie cumulativă. Teoria spune că numerele din intervalul 0-1 sînt uniform
distribuite. Greutatea în utilizarea metodei este dată de proiectarea modelului pe care vrem să îl
folosim.

Orice ameninţare la adresa securităţii unui sistem informaţional poate avea două stări: succes sau
eşec. În aceste condiţii se spune că probabilitatea acesteia va avea o distribuţie binomială. Pentru
a putea aplica da capo a fine metoda Monte Carlo trebuie să calculăm atît probabilităţile cît şi
funcţia de distribuţie.

Un exemplu

Ameninţarea luată în calcul este un atac de tip brute force. Variabila probabilistă este numărul
de atacuri. Dar ajungem la o primă problemă. Dacă presupunem că în decursul unui an s-au
înregistrat 10 astfel de atacuri, nereuşite, care este probabilitatea ca în anul viitor să se
înregistreze atacuri reuşite?

Prin urmare, distribuţia de probabilitate este binomială deoarece un atac poate fi reuşit sau eşuat,
iar atacurile sînt independente unele faţă de altele (aici am forţat puţin nota deoarece
independenţa este greu de stabilit). Metodele evoluează, tehnologia evoluează.

Alte calcule? Formulele statistice din Excel, add-on –uri etc….Nu ştiu dacă are sens să
reinventez roata….

Comentarii

1. dpopa spune:

18/04/2010 la 09:57

Oare e clar ?
Daca probabilitatea de aparitie a unui incident este o data la zece ani, atunci ALE este
1/10 din SLE. Iar SLE este pierderea cauzata de un incident.

2. Adrian Munteanu spune:

18/04/2010 la 19:42

Nu știu cît este de clar pentru alții….Nici măcar nu știu dacă reușesc să lămuresc
lucrurile. Doar încerc…..
 Mă interesează însă ca, în practică, să lucrăm corect, dincolo de a avea niște “hîrtii”
cerute de unii sau alţii. Pentru că în funcție de estimarea asta se vor investi niște bani!

Repet: pe baza informaţiilor din trecut trebuie calculată distribuţia de probabilitate nu

doar probabilitatea. În caz contrar calculele sînt lipsite de fundament!

Ca să exemplific voi lua cazul întreruperii serviciilor (asta şi pentru că “ţi-ai vîndut
sufletul” cui ţi l-ai vîndut ). Este situaţia cea mai dificilă pentru calcul de riscuri. Pentru
că pierderea este acum direct proporţională cu timpul/momentul de manifestare. În acest
caz particular ar trebui să definim un set standard de durate de întrerupere posibile: 5
minute, 15 minute, 30 minute, 1 oră, 2 ore, 1 lună, 2 luni, 4 luni, 6 luni…..Depinde!
Depinde de contextul organizației!
Pentru fiecare ameninţare ar trebui să identificăm procentul/probabilitatea apariţiilor care
vor conduce la întrerupere, pentru fiecare durată identificată anterior. Unele ameninţări
(întreruperea energiei electrice, de ex.) pot avea efecte minime.
Estimăm pierderea potenţială datorată întreruperilor pentru fiecare funcţie şi pentru
fiecare durată.
Calculul trebuie să pornească de la faptul că apariţia unei ameninţări nu are un orar de
funcţionare!!!! Altfel spus nu se suprapune pe intervalul în care trebuie îndeplinită funcţia
respectivă.

3. dpopa spune:

18/04/2010 la 20:25

Adi, pentru ca ai aruncat migea la fileu (asta cu serviciile), o sa o “plesnesc”. Pierderea e

directa proportionala cu momentul de manifestare – tu ai spus. Ai vazut tu vreun contract
care sa specifice daune mai mari in momentele de inchidere de luna, sau daune mai mici
in perioada pranzului cand toti sunt la masa ? Exemplele pot continua. Nu zic ca nu
exista, poate sunt. Dar pana nu vad, nu cred.

Din tot ce am vazut pana acum, lucrurile sunt cam standard : serviciul disponibil 24 x 7 ,
98% uptime…s.a.m.d. Daca dai peste unii care ofera granularitate, si fac analize de
riscuri pe o numita perioada de impact, sa-mi zici si mie. Ma astept ca daca fac astfel de
analize, cineva sa alinieze si contractul de servicii cu asta …

4. Adrian Munteanu spune:

19/04/2010 la 08:48

Nu, nu am văzut. Şi nici nu cred că voi avea ocazia să văd prea curînd. Cred însă că, în
momentul în care se va constata că întreruperea a generat pierderi mai mari decît ceea ce
a fost estimat, se vor alinia şi prevederile contractuale. Se va învăţa din greşeli.
 Discuţia comportă două perspective: a furnizorului şi a clientului. Din experienţa mea, la
nivelul furnizorului cunoştinţele sînt mai avansate decît la nivelul clientului.
Ceea ce încerc eu să spun: evaluarea riscurilor trebuie făcută pentru a obţine beneficii
financiare şi nu doar pentru a se asigura conformitatea cu o cerinţă sau alta. Evaluarea
riscurilor este şi trebuie să fie responsabilitatea celor din business şi nu a IT-ului. Şi nu
trebuie realizată de un singur om.

Preluarea unor informaţii din cărţi/frameworkuri fără corespondenţă în contextul

organizaţiilor este doar pieredere de timp. Procesele, indiferent că sînt economice sau
naturale, sînt ireversibile.

Riscuri şi proiecte
M-am confruntat de curînd cu acest subiect: evaluarea (se cerea de fapt un audit) riscurilor într-
un proiect de dezvoltare software.

Pentru că sînt un adept al teorii sistemelor afirm de multe ori că se omite contextul. Sau banalul
de acum, “suma părţilor este mai mare decît întregul”. Consider orice proiect ca fiind tot o
schimbare/change pentru absolut toţi cei implicaţi. Şi în acest caz trebuie înţeles
“contextul”/sistemul, relaţiile dintre componente (preluarea orbeşte, a celor scrise în frameworks,
are ca efect decontextualizarea IT-ului şi ca efect bătăi de cap inutile). Dacă în analiza top down
căutăm să “fărîmiţăm” lucrurile, vine un moment cînd acestea trebuie agregate. Controalele sînt
proiectate şi funcţionează bottom-up…..În cascadă.

Nu voi discuta procesul şi componentele sale aşa după cum sînt prezentate ele de către PRINCE2
sau PMI (să nu uităm că multe poze sînt precedate de “Example”). Acolo este procesul, cu
management, inputuri şi outputuri. Îl vizează pe PM.

În opinia mea, în cazul dezvoltării unei aplicaţii ar trebui avute în vedere 3 variabile:
dimensiunea proiectului/complexitatea, structura şi experienţa membrilor.

Am luat în calcul dimensiunea pentru că în orice proiect sînt incluse alte variabile: costuri, timp,
resursă umană, procese/funcţii afectate. Toate acestea prezintă riscuri. Aici intervine ceea ce se
spune în metodologii.

Structurarea este relativ simplă: se lucrează după o metodologie sau nu? Dacă nu se lucrează este
posibil să nu poată fi identificate multe controale documentare. Este direct legată de
complexitate.

Experienţa este poate cel mai subiectiv aspect. Spun asta pentru că nici un proiect nu cred că
seamnă cu altul. Au elemente comune, dar nu seamănă. Una este să faci o aplicaţie pentru
banking şi alta pentru o şcoală. Chiar dacă se folosesc aceleaşi resurse umane şi tehnice. Cu cît
mai multe proiecte cu atît mai bine. Aici aş aplica regula 80/20: 20% din membrii echipei să fi
participat la 80% din proiectele din portofoliu…..Greu….Lumea academică din zona riscurilor
este plină de lucrări care spun că înţelegerea comportamentului uman este cheia înţelegerii
riscurilor…..

Prin prisma COBIT aş avea în vedere cîteva documente ce nu pot lipsi: studiul de fezabilitate, 
specificaţiile  proiectului, analiza cost beneficiu, integrarea proiectului, cerinţele
funcţionale/procedurale, controlul, arhitectura sistemului, testarea şi acceptarea, aprobarea finală.

Ce trebuie sa contina un plan de management al riscului unui proiect?

Evident ca primul pas este sa intelegem ce reprezinta un proiect. Merg pe ideea ca atunci cand ati
spus "proiect" va referiti la un proiect de afacere, la o noua activitate ampla in cadrul unei
companii etc. si nu la un proiect tip cerere de finantare (dar si aici se pot vorbi de riscuri si de
planuri de management al riscurilor - si am sa vorbesc la final putin despre aceasta latura).
Diverse metodologii (vezi Mehari, Octave, Coso, PMI etc.) propun abordari diverse in
construirea planului de management al riscului.
Dar, intr-o parere personala, un plan de management al riscului ar trebui sa surprinda
urmatoarele capitole:

 Introducere (se descriu: domeniul de activitate al companiei, zona in care se va aplica

procesul de management al riscului - financiar, operational, tehnologic, toate -, data la
care se efectueaza si cum vor fi folosite rezultatele procesului de management al riscului
etc.)

 Descrierea modului de abordare(descrierea pasilor de realizare a managementului

riscului)

1. Identificarea riscurilor (se descriu tehnicile prin care se va incerca identificarea

riscurilor - brainstorming, checklists, discutii libere, supravegherea din partea
echipei de management al riscului etc.)
Atentie: identificarea riscului este un proces amplu care presupune mai intai
identificarea valorilor de protejat in cadrul acelui proiect, apoi identificarea
vulnerabilitatilor prezentate de acele valori si apoi identificarea riscurilor care pot
sa apara in acea combinatie de valori-vulnerabilitati.

2. Evaluarea riscului (se va incerca o abordare mixta, evaluare calitativa si

cantitativa)
Este poate partea cea mai importanta din proces. Se va descrie modul in care se va
aprecia gradul de severitate (impactul) si nivelul de probabilitate a aparitiei
riscului identificat. (mai exact: descrierea nivelelor mare-mediu-mic intr-o
abordare calitativa si prezentarea elementelor statistice si a costurilor in abordarea
cantitativa).
 3. Analiza Riscului (pe baza ierarhizarii riscurilor evaluate se determina actiunile ce
trebuie aplicate la nivelul fiecarui risc. Actiunile vor fi de tipul: evitare / acceptare
/ respingere / transfer).

4. Monitorizarea riscului (descrierea pasilor ce trebuie realizati in vederea

monitorizarii riscurilor deja identificati si a celor care pot aparea de-a lungul
procesului de implementare a proiectului si dupa).

5. Planul de raspuns la risc (efectiv ce se va realiza pentru fiecare risc in parte -

actiuni care au fost prezentate la pasul de analiza a riscului).

 (obs. pana acum a fost partea teoretica a planului; urmeaza munca de "teren").

 Riscurile (prezentarea riscurilor identificate in lumina celor afirmate mai sus si a planului
de actiune pentru fiecare risc)

La acest nivel pentru fiecare risc identificat se vor prezenta:

1. Cod de identificare a riscului (pentru o mai buna urmarire)

2. Gradul de probabilitate de aparitie (ex. calitativ - mare; cantitativ - 1%)

3. Nivelul impactului (idem ca la probabilitate)

4. Descrierea riscului

5. Analiza riscului

6. Planul de raspuns (tine si de atitudinea fata de risc a managerului de proiect: ii

place sa isi asume riscuri sau nu etc.)

[edit] A Quantitative Approach to Risk Analysis

 Quantitative analysis uses risk calculations that attempt to predict the level of monetary losses
and percentage of chance for each type of threat.
 Quantitative risk analysis also provides concrete probability percentages when determining the
likelihood of threats.
 Each element within the analysis (asset value, threat frequency, severity of vulnerability, impact
damage, safeguard costs, safeguard effectiveness, uncertainty, and probability items) is
quantified and entered into equations to determine total and residual risks.
 Purely quantitative risk analysis is not possible, because the method attempts to quantify
qualitative items, and there are always uncertainties in quantitative values

Sample Steps for a Quantitative Risk Analysis

  Step 1: Assign Value to Assets- For each asset, answer the following questions to determine its
value
o What is the value of this asset to the company?
o How much does it cost to maintain?
o How much does it make in profits for the company?
o How much would it be worth to the competition?
o How much would it cost to re-create or recover?
o How much did it cost to acquire or develop?
o How much liability are you under pertaining to the protection of this asset?
 Step 2: Estimate Potential Loss per Threat- To estimate potential losses posed by threats,
answer the following questions:
o What physical damage could the threat cause and how much would that cost?
o How much loss of productivity could the threat cause and how much would that cost?
o What is the value lost if confidential information is disclosed?
o What is the cost of recovering from this threat?
o What is the value lost if critical devices were to fail?
o What is the single loss expectancy (SLE) for each asset, and each threat?
 Step 3: Perform a Threat Analysis- Take the following steps to perform a threat analysis
o Gather information about the likelihood of each threat taking place from people in each
department, past records, and official security resources that provide this type of data.
o Calculate the annualized rate of occurrence (ARO), which is how many times the threat
can take place in a 12-month period.
 Step 4: Derive the Overall Loss Potential per Threat-To derive the overall loss potential per
threat, do the following:
o Combine potential loss and probability.
o Calculate the annualized loss expectancy (ALE) per threat by using the information
calculated in the first three steps.
o Choose remedial measures to counteract each threat.
o Carry out cost/benefit analysis on the identified countermeasures.
 Step 5: Reduce, Transfer, or Accept the Risk- For each risk, you can choose whether to reduce,
transfer, or accept the risk:
o Risk reduction methods
 Install security controls and components.
 Improve procedures.
 Alter environment.
 Provide early detection methods to catch the threat as it's happening and
reduce the possible damage it can cause.
 Produce a contingency plan of how business can continue if a specific threat
takes place, reducing further damages of the threat.
 Erect barriers to the threat.
 Carry out security-awareness training.
o Risk transfer- Buy insurance to transfer some of the risk, for example.
o Risk acceptance- Live with the risks and spend no more money toward protection.

Quantitative Risk Analysis Metrics

 Single loss expectancy (SLE) - The amount of loss due to a single occurrence of a threat.
  Annualized loss expectancy (ALE) - The estimated loss per annum.
 Exposure factor (EF) - Represents the percentage of loss a realized threat could have on a certain
asset.
 Annualized rate of occurrence (ARO) – It is the value that represents the estimated frequency of
a specific threat taking place within a one-year timeframe. It can range from 0.0 to 1.0.
 The Relation
o Asset value * exposure factor (EF) = SLE
 Example: If a data warehouse has the asset value of $150,000, and if it is
estimated that if a fire were to occur, 25 percent of the warehouse would be
damaged, then SLE =0.25*$150000=$37,500.
o SLE * Annualized rate of occurrence (ARO) = ALE. If ARO is 0.1 (indicating once in ten
years), then the ALE =$37,500* 0.1 = $3750. This tells the company that if it wants to put
in controls or safeguards to protect the asset from this threat, it can sensibly spend
$3750 or less per year to provide the necessary level of protection.

Results of a Quantitative Risk Analysis

The following is a short list of what generally is expected from the results of a risk analysis

 Monetary values assigned to assets

 Comprehensive list of all possible and significant threats
 Probability of the occurrence rate of each threat
 Loss potential the company can endure per threat in a 12-month time span
 Recommended safeguards, countermeasures, and actions analysis.

Quantitative Pros

 Requires more complex calculations

 Is easier to automate and evaluate
 Used in risk management performance tracking
 Provides credible cost/benefit analysis
 Shows clear-cut losses that can be accrued within one year's time

Quantitative Cons

 Calculations are more complex. Can management understand how these values were derived?
 Without automated tools, this process is extremely laborious.
 Big need to gather detailed information about environment.
 Standards are not available. Each vendor has its own way of interpreting the processes and their
results.

[edit] A Qualitative Approach to Risk Analysis

 In Qualitative approach, we walk through different scenarios of risk possibilities and rank the
seriousness of the threats and the validity of the different possible countermeasures.
 The Qualitative analysis techniques include judgment, best practices, intuition, and experience.
 Qualitative Risk Analysis Techniques
 o Delphi -A group decision method used to ensure that each member gives an honest
opinion of what he or she thinks the result to a particular threat will be. This method is
used to obtain an agreement on cost, loss values, and probabilities of occurrence
without individuals having to agree verbally.
o Brainstorming
o Storyboarding
o Focus groups
o Surveys
o Questionnaires
o Checklists
o One-on-One meetings
o Interviews.
 The risk analysis team will determine the best technique for the threats that need to be
assessed and the culture of the company and individuals involved with the analysis.
 The team that is performing the risk analysis gathers personnel who have experience and
education on the threats being evaluated. When this group is presented with a scenario that
describes threats and loss potential, each member responds with their gut feeling and
experience on the likelihood of the threat and the extent of damage that may result.

Severity of Probability of Potential Effectiveness of Effectiveness of

Personnel
Threat Threat Loss Firewall IDS

IT manager 4 2 4 4 3

DBA 4 4 4 3 4

Application
2 3 3 4 2
programmer

System operator 3 4 3 4 2

Operational
5 4 4 4 4
manager

Results 3.6 3.4 3.6 3.8 3

Qualitative Pros

 Requires simple calculations

 Involves high degree of guesswork
 Provides general areas and indications of risk
 Provides the opinions of the individuals who know the processes best
Qualitative Cons

 The assessments and results are basically subjective.

 Usually eliminates the opportunity to create a dollar value for cost/benefit discussions.
 Difficult to track risk management objectives with subjective measures.
 Standards are not available. Each vendor has its own way of interpreting the processes and their
results.