Вы находитесь на странице: 1из 22

ACADEMIA DE STUDII ECONOMICE DIN BUCURETI

FACULTATEA DE FINANE, ASIGUR RI, B NCI I BURSE DE VALORI


DAFI

Securitate IT i managementul
riscurilor IT

Student:
Ivan Elena Mdlina

Bucureti 2015

Introducere
If you know the enemy and know yourself, you need not fear the result of a hundred battles.
If you know yourself but not the enemy, for every victory gained you will suffer a defeat. If
you know neither the enemy nor yourself, you will succumb in every battle.
(Sun Tzu The Art of War)
Securitatea informaional este asigurat atunci cnd informaiile sunt accesibile
exclusiv unui grup autorizat de utilizatori (confidenialitate), este generat, modificat sau
adugat ntr-o manier controlat, consistent i detectabil (integritate i autenticitate) i
este disponibil utilizrii ntr-o perioad de timp (disponibilitate). Este foarte important s
facem diferena ntre securitatea datelor, care se refer la protejarea datelor mpotriva
pierderii datorate unor erori tehnice sau evenimente fizice, i protecia datelor, care se refer
la protejarea datelor mpotriva folosirii, modificrii sau tergerii de ctre persoane
neautorizate.
Principiul fundamental al securitii informaiilor este de a sprijini activitatea unei
organizaii. Toate organizaiile/companiile sunt expuse riscurilor privind incertitudinea, unele
dintre ele avnd efecte negative asupra activitii acesteia. Pentru a proteja compania de
aceste efecte negative, persoanele nsrcinate cu securitatea IT trebuie s fie capabile s ajute
managementul s neleag i s evalueze aceste incertitudini. Managementul incertitudinilor
nu reprezint o sarcin uoar deoarece resursele sunt limitate iar decorul ameninrilor i al
vulnerabilitilor este n continu schimbare. Aadar, persoanele care se ocup cu securitatea
IT trebuie s aib la dispoziie un set de unelte i tehnici care s i ajute s transmit
informaiile privind un potenial impact al anumitor ameninri legate de domeniul IT, ctre
manageri i ctre departamentul de IT. Acest set de unelte i tehnici trebui s fie consistent,
repetabil, s aib un cost rezonabil i s ajute la reducerea riscurilor.
Pe msur ce organizaiile se sprijin din ce n ce mai mult pe tehnologie, ele devin
foarte vulnerabile n faa riscurilor legate de IT. Astfel, apare ca fiind vital o analiz corect
a riscurilor pentru a putea adopta cele mai bune msuri de reducere a acestora. elul principal
al unui proces de management al riscurilor ar trebui s fie protejarea organizaiei i a
capacitii acesteia de a-i desfura activitatea n cele mai bune condiii, nu doar protejarea
activelor IT. Aadar, procesul de gestionare al riscurilor nu trebuie tratat ca un proces tehnic
desfurat de experii n IT i ca o funcie esenial de management a organizaiei.

Capitolul 1. Managementul riscului. Aspecte generale


Managementul riscurilor cuprinde trei procese: evaluarea riscurilor, stabilirea
msurilor de reducere a acestora i reevaluarea periodic. Procesul de evaluare a riscului
include identificarea i evaluarea riscurilor i a impactului acestora, ct i recomandri
privind msurile de reducere. Cel de-al doilea proces cuprinde prioritizarea, implementarea i
ntreinerea unor msuri adecvate de reducere a riscului, rezultate n urma procesului de
evaluare. Dup derularea acestor procese, este necesar o evaluare continu a riscurilor i
stabilirea cilor de implementare a unui program eficient de management. Responsabilul
pentru autorizarea sistemului stabilete dac riscul rmas este la un nivel acceptabil, sau dac
sunt necesare controale adiionale de securitate pentru a reduce i mai mult riscul sau pentru a
elimina riscul rezidual nainte de autorizarea sistemului IT pentru operare.
Managementul riscului este procesul care permite managerilor IT s eficientizeze
raportul dintre costurile operaionale i cele economice pentru msurile de protecie i
atingerea obiectivelor privind protecia sistemelor IT i a datelor care susin activitatea
organizaiei. Conducerea unei organizaii trebuie s determine capacitatea necesar a
sistemului IT al organizaiei pentru a asigura nivelul dorit de securitate n faa ameninrilor
zilnice. Multe organizaii au bugete fixe alocate pentru securitate IT, astfel cheltuielile legate
de securitate trebuie revizuite la fel de amnunit precum orice alte decizii de management. O
metodologie de management al riscului bine structurat, atunci cnd este folosit eficient,
poate ajuta managementul n identificarea controalelor adecvate1.
Minimizarea impactului negativ asupra unei organizaii i nevoia unei baze solide n
luarea deciziilor sunt argumente fundamentale ale unei organizaii pentru implementarea unui
proces de management al riscurilor pentru sistemele IT. Este necesar ca un management al
riscului eficient s fie integrat total n ciclul de via al dezvoltrii unui sistem (Sistem
Development Life Cycle - SDLC, engl.)2.
Ciclul de via al dezvoltrii unui sistem IT cuprinde cinci etape: iniierea, dezvoltarea
sau achiziionarea, implementarea, operarea sau ntreinerea i eliminarea. n unele cazuri un
sistem IT poate trece simultan prin dou sau mai multe etape. Tabelul 1.1 descrie
caracteristicile fiecrei etape aferent SDLC i indic cum managementul riscului poate fi
aplicat n cadrul fiecrei etape.

1 Mc Neil, A.J, Frey, R., Quantitative Risk Management Concept, Tehniques and
Tools, Princeton University Press, U.K., 2015, pp. 34-37
2 Sistem development life cycle (SDCL) reprezint un model conceptual utilizat
n managementul de proiecte care descrie etapele prin care trece un sistem al
informaiei. A se vedea Anexa 1.

Tabel 1.1 Integrarea managementului de risc n SDLC

Etapa 1 - Iniierea

Apare necesitatea unui sistem


IT urmat de documentarea
privind scopul utilizrii
acestuia

Etapa 2 Dezvoltarea sau


achiziionare

Sistemul IT este conceput,


achiziionat, programat,
dezvoltat sau construit

Etapa 3 - Implementarea

Setrile sistemului de
securitate sunt configurate,
validate, testate i verificate
Sistemul devine functional.
De obicei, sistemul este
modificat pe parcursul
utilizrii acestuia prin
operarea asupra elementelor
hardware i software i pe
baza schimbrilor n procesele
organizaionale, a politicilor i
a procedurilor
Aceast etap poate include
eliminarea de informaii, de
elemente hardware i/sau
software. Operaiile pot
include mutarea, arhivarea,
distrugerea sau actualizarea
elementelor deja menionate.

Etapa 4 Operarea sau


ntreinerea

Etapa 5 - Eliminarea

Activiti aferente
managementului de risc
Riscurile identificate sunt
utilizate pentru a sprijini
dezvoltarea cerinelor
sistemului, inclusiv a
cerinelor privind securitatea
Riscurile identificate pot fi
utilizate pentru analiza de
securitate a sistemului IT, care
va conduce la definirea
arhitecturii i a designului
sistemului
Deciziile privind riscurile
identificate trebuie adoptate
nainte de operarea sistemului
Activitile de management al
riscului sunt reactualizate
periodic sau oricnd apar
schimbri majore asupra
sistemului IT (ex. noi interfee
ale sistemului)

Activitile aferente
managementului de risc sunt
realizate pentru componente
ale sistemului care urmeaz a
fi eliminate sau nlocuite
pentru a ne asigura c
elementele de hardware i de
software sunt actualizate, c
datele reziduale sunt verificate
i c aceste procese se
desfoar ntr-un mediu sigur
i ntr-o manier sistematic

Sursa: Stoneburner, G., Goguen, A., Risk Management Guide for Information
Tehnology System, National Institute of Standards and Technology, U.S.A., 2002, pp. 1213

Capitolul 2. Evaluarea Riscului


Evaluarea riscului reprezint primul proces n cadrul metodologiei aferent
managementului de risc. Companiile utilizeaz procesul de evaluare a riscului pentru a
determina ct de mare este ameninarea i care este riscul asociat cu sistemul IT n cadrul
SDLC. Rezultatul acestui proces ajut la identificarea celor mai potrivite aciuni pentru
reducerea sau eliminarea riscului (reducerea acestuia la un nivel acceptabil pentru
organizaie). Pentru a determina magnitudinea efectelor adverse provocate de un anumit
eveniment trebuie s analizm ameninrile cu care se confrunt sistemul IT n paralel cu
potenialele vulnerabiliti. Cnd vorbim despre magnitudine ne referim la impactul care se
transmite asupra activelor IT i asupra resurselor. Metodologia menionat anterior susine c
exist nou pai necesari pentru a evalua n mod corect riscurile.
Figura 2.1 Pai necesari n cadrul evalurii riscului

Sursa: Risk Management Guide for Information Tehnology Systems, NIST, iulie 2002, pp.
15-16 , disponibil la http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf

Pasul 1. Caracterizarea sistemului Definirea Scopului


n primul rnd trebui colectate toate informaiile care fac referire la sistemul IT i
anume:
-

Hardware
Software
Interfeele sistemului (ex. Informaii legate de conectivitatea intern i extern)
Informaii i date
Persoane autorizate s utilizeze sistemul IT
Procesele rulate de sistem
Clasificarea i managementul datelor
Importana sistemului IT pentru organizaie
Senzitivitatea datelor
Alte detalii tehnice, etc.
Informaii suplimentare referitoare la mediul operaional al sistemului informatic i al
datelor acestuia, includ fr a fi limitate la acestea, urmtoarele:

Cerintele funcionale ale sistemului infomatic


Utilizatorii sistemului (ex. utilizatorii sistemului care asigur suportul tehnic al sistemului
informatic; utilizatorii aplicaiilor care utilizeaz sistemul IT pentru a ndeplini funciile de
business, etc.)
Politicile de securitate care guverneaz sistemul informatic (politici organizaionale, cerine
legislative, practici ale domeniului)
Arhitectura sistemului de securitate
Topologia reelei curente (ex. diagrama reelei)
Protecia informaiei stocate i disponibilitatea, integritatea i confidenialitatea datelor
Fluxul informaiei (ex. interfeele sistemului, diagrama fluxului intrrilor i ieirilor)
Controale tehnice folosite n cadrul sistemul informatic (ex. produse de securitate care
asigur identificarea i autentificarea, controlul accesului, auditul, protecia datelor, metode
de criptare)
Managementul controalelor folosite n cadrul sistemului IT (ex. reguli comportamentale,
planificarea securitii)
Controale operaionale folosite n sistemul informaiei (ex. securitatea personalului, back-up,
operaiuni neprevzute, operaiuni de refacere i reluare a sistemului; mentenana sistemului;
stocare extern (off-site); proceduri pentru crearea i anularea conturilor utilizatorilor;
controale ale segregrii funciilor utilizatorilor, cum ar fi accesul utilizatorilor privilegiai prin
comparaie cu accesul utilizatorilor standard)
securitatea fizic a mediului sistemului IT (ex. facilitate de securitate, politicile centrului de
date)
Securitatea mediului implementatp pentru sistemul informatic (ex. controlul umiditii, ap,
energie, poluare, temperatur i chimicale)

Trebuie s menionm c exist anumite metode prin intermediul crora pot fi adunate
aceste informaii i anume:
-

Chestionare - Pentru colectarea informaiilor relevante, personalul responsabil de evaluarea


riscului sistemului IT poate concepe un chestionar ce vizeaz controalele operaionale i de
management care urmeaz a fi implementate sau sunt deja n funciune n cadrul sistemului
informatic. Chestionarul este distribuit echipei de management care proiecteaz sau ntreine
sistemul IT3.
Interviuri cu echipa de suport i management a sistemului IT
Revizia unor documente, proceduri (ex. documente legislative, directive), documentaia
sistemului (ex. ghidul utilizatorului sistemului, manualul administratorului de sistem,
documentaie de achiziie) i documente referitoare la securitatea sistemului (ex. rapoarte de
audit, rapoarte de evaluare a riscului, rezultatele testrii sistemului informatic, planul de
securitate al sistemului, politici de securitate etc.)
Utilizarea unui intrument de scanare automat - De exemplu, un sistem de topologie a reelei
poate identifica acele servicii care ruleaz pe un numr mare de host-uri i furnizeaz o
metod rapid de construire a profilurilor individuale ale sistemului int.
3 A se vedea Anexa 2

Pasul 2. Identificarea ameninrilor


O ameninare reprezint eventualitatea unei surse particulare de ameninare de a
exploata o anumit vulnerabilitate. O vulnerabilitate reprezint o slbiciune care poate fi
declanat accidental sau care poate fi exploatat n mod deliberat. O surs de ameninare nu
prezint risc atunci cnd nu i corespunde o vulnerabilitate care s poat fi exercitat. n
determinarea probabilitii de apariie a unei ameninri, trebuie luate n considerare sursele
de ameninare, vulnerabilitile poteniale i controalele existente4.
n vederea identificrii surselor de ameninare, este esenial s fie luate n considerare
toate potenialele surse de ameninare care ar putea prejudicia sistemul informaional i
mediul n care opereaz. Ameninrile umane pot fi aciuni deliberate ale unor angajai ru
intenionai sau acte unilaterale, cum ar fi neglijena sau erorile umane. Un atac deliberat
poate fi:
a) o ncercare ostil de a obine acces neautorizat la un sistem informatic (ex. ghicirea parolei)
pentru a compromite integritatea, disponibilitatea sau confidenialitatea datelor i a sistemului
b) o ncercare intit spre a nela sistemul de exemplu, un program desemnat s treac de
securitatea sistemului (Trojan horse, engl.).
Motivarea i resursele pentru desfurarea unui atac, fac ca oamenii s fie considerai
surse poteniale de ameninare. Tabelul 2.1 ilustreaz multe dintre ameninrile umane,
motivaiile lor posibile, i metodele sau aciunile de ameninare prin care pot desfura un
atac. n plus, analiza istoricului de spargere a sistemului, rapoarte de violare a securitii,
rapoarte de incident i interviuri cu administratorii sistemului, personalul i utilizatorii n
timpul colectrii informaiilor, vor ajuta la identificarea ameninrilor umane cu potenial de a
duna sistemului ct i datelor acestuia.
Tabel 2.1 Surse de ameninare
Surse de ameninare
Hacker, cracker

Motivaie
-Provocare
-Ego
-Rebeliune

Computer criminal

- Distrugerea informaiilor
- Obinerea ilegal a unor
informaii
- Ctiguri bneti
- Modificarea neautorizat a
datelor
- antaj
- Distrugere
- Exploatare
- Rzbunare

Terorist

4 A se vedea Anexa 3

Aciuni de ameninare
- Hacking
- Social engineering
- Spargerea sistemului
- Acces neautorizat
- Aciuni frauduloase
(intercepie)
- Delicte cibernetice
- Spoofing

- Terorism
- Rzboi informatic
- Atac asupra sistemului
informaional (denial of
service)

Spionaj industrial
(companii, guverne strine,
alte interese
guvernamentale)

- Avantaj competitiv
- Spionaj economic

Persoane din interiorul


companiei (angajai fr
pregtire, ru intenionai,
neglijeni, necinstii)

- Curiozitate
- Ego
- Ctiguri bneti
- Erori i omisiuni
neintenionate

- Penetrarea sistemului
- Falsificarea sistemului
- Exploatare economic
- Furt informaional
- Penetrarea sistemului
- Acces neautorizat n sistem
(acces la informaii
clasificate, brevete i/sau
informaii tehnice)
- antaj
- Atac al unui angajat
- Obinerea unor informaii
brevetate
- Fraud i furt
- Intercepie
- Vnzarea unor informaii
personale
- Coduri ostile
- Sabotajul sistemului
- Acces neautorizat n sistem

Sursa: Egon, F., Corporate Information Security Governance in Swiss Private Banking,
2004, pp. 45-47, disponibil la:
http://www.isaca.ch/files/DO7_Diplomarbeiten/Diplom_CorporateInfSecGovernance_E.pdf

Pasul 3. Identificarea vulnerabilitilor


Analiza ameninrilor unui sistem informatic trebuie s conin i o analiz a
vulnerabilitilor asociate mediului sistemului. Scopul acestei etape este de a dezvolta o list
cu vulnerabiliti ale sistemului care pot fi exploatate de ctre poteniale surse de ameninare.
Spre exemplu, o parametrizare neadecvat a sistemului reprezint o vulnerabilitate care este
posibil a fi exploatat de ctre utilizatori neautorizai (hackeri, angajai nemulumii, teroriti)
care pot obine accesul neautorizat la date critice folosind vulnerabilitile identificate.
Metodele recomandate pentru identificarea vulnerabilitilor sistemului sunt: folosirea
surselor de vulnerabilitate, derularea unor testri ale sistemului de securitate, i identificarea
cerinelor de securitate.
Sursele documentate de vulnerabiliti care ar trebui luate n considerare ntr-o analiz
amnunit a vulnerabilitilor, includ, fr a se limita la, urmtoarele:
Documentaii anterioare privind evaluarea riscului sistemului informatic
Rapoartele de audit ale sistemului IT, rapoarte privind anomaliile de sistem, rapoarte de
securitate i teste ale sistemului

Liste care cuprind vulnerabiliti, cum ar fi baza de date NIST I-CAT (disponibil la:
http://icat.nist.gov)
Consultani n securitate
Consultani n vnzri
Software pentru analiza securitii.
Metodele care implic testarea sistemului pot fi folosite pentru a identifica
vulnerabilitile acestuia, n funcie de importana sistemului IT i de resursele disponibile
(ex. fondurile alocate, tehnologia disponibil, persoane cu expertiza necesar pentru a
conduce testul). Metodele de testare includ:
Scanarea automat a vulnerabilitilor - este folosit pentru a scana un grup de host-uri sau
o reea, pentru a depista serviciile cunoscute a fi vulnerabile (ex. sistemul permite
retransmiterea unor protocoale)
Evaluarea i testarea securitii (ST&E) verific dac controalele aplicate sunt conforme
cu specificaiile de securitate aprobate i dac implementeaz politica de securitate a
organizaiei sau dac ndeplinesc standardele industriale
Testarea intruziunii este folosit pentru a evalua abilitatea unui sistem informaional de a
face fa unui atac intenionat.
O list cu cerinele de securitate conine standardele de baz folosite pentru
identificarea i evaluarea sistematic a vulnerabilitilor activelor (personal, hardware,
software, informaii), procese i transferuri de informaii asociate unui anumit sistem IT, n
ariile prezentate n Tabelul 2.2.

Tabel 2.2 Identificarea vulnerabilitilor


Zona de securitate
Securitate n management

Securitate operaional

Criterii de securitate
- Alocarea responsabilitilor
- Continuitatea suportului
- Capabilitate de rspuns n caz de incident
- Revizuire periodic a controalelor de securitate
- Verificarea personalului i investigaii de
background
- Evaluarea riscului
- Training n securitate i tehnic
- Delimitarea atribuiilor
- Autorizarea i reautorizarea sistemului
- Plan de securitate
- Controlul agenilor de contaminare a aerului
(fum, praf, chimicale)
- Controale pentru asigurarea calitii surselor de

energie electric
- Distribuia extern a datelor
- Protecia facilitilor (camera computerelor;
centrul de date; birouri)
- Controlul umiditii i al temperaturii
Securitate tehnic

Comunicaii (dial-in, interconectarea sistemelor;


routere)
- Criptografie
- Controlul accesului
- Identificare i autentificare
- Detectarea intruilor
- Auditarea sistemului

Sursa: Bandyopadhyay, K., Mykytyn, P., A framework for integrated risk management in
information technology, Management Decision, Vol.37, Nr.5, 2006, pp. 437- 445,
disponibil la: http://www.emeraldinsight.com/doi/abs/10.1108/00251749910274216

Pasul 4. Analiza controalelor


Scopul acestei etape este de a analiza controalele care au fost implementate sau care
sunt n curs de implementare de ctre organizaie, pentru a minimiza sau elimina
probabilitatea unei ameninri de a exploata o vulnerabilitate.
Controalele de securitate implic att folosirea unor metode tehnice ct i nontehnice.
Controalele tehnice sunt plase de siguran incorporate n hardware-ul, software-ul sau
firmware-ul computerelor (mecanisme de control al accesului, mecanisme de identificare i
autentificare, metode de criptare). Controalele nontehnice sunt cele de management i
operaionale, cum ar fi: politicile de securitate, procedurile operaionale i de personal,
securitatea mediului etc.
Categoriile de controale att pentru metodele de control tehnice ct i nontehnice pot
fi clasificate n continuare ca i controale preventive sau detective:
a) Controalele preventive blocheaz ncercrile de violare a politicii de securitate i includ
controale cum ar fi: implementarea controlului accesului, criptarea, autentificarea.
b) Controalele detective avertizeaz asupra violrilor sau ncercrilor de violare a politicii de
securitate i include controale cum ar fi: audit trail, metode pentru detectarea
intruziunilor, etc.
Pasul 5. Determinarea probabilitii
Pentru a determina probabilitatea materializrii unei posibile ameninri, urmtorii
factori trebuiesc luai n considerare:
Motivaia i capacitatea sursei de ameninare
Natura vulnerabilitii
Existena i eficiena controalelor
Probabilitatea ca o potenial vulnerabilitate s fie exploatat de o anumit surs de
ameninare, poate fi descris ca mare, medie sau redus5.
5 A se vedea Anexa 4

Tabel 2.3 Definirea probabilitii


Mare

Medie
Redus

Definiie
Sursa ameninrii este foarte motivat i suficient de capabil astfel nct
controalele i msurile adoptate n vederea prevenirii expunerii vulnerabilitii
sunt ineficiente.
Sursa ameninrii este motivat i capabil, dar unele controale pot mpiedica
expunerii vulnerabilitii.
Ameninarea nu este motivat sau capabil, astfel nct controalele pot mpiedica
expunerea vulnerabilitii cu succes.

Sursa: Boukouras, A., Rajabi, M., An Ordinal Game Theory Approach to the
Analysis and Selection of Partners in Public-Private Partnership Projects, Journal of
Optimization Theory and Application, 2015, pp. 15-20, disponibil la:
http://link.springer.com/article/10.1007%2Fs10957-015-0844-3

Pasul 6. Analiza impactului


Urmtoarea etap major n stabilirea nivelului de risc este de a determina impactul
advers rezultat n urma exercitrii cu success a unei vulnerabiliti. nainte de a desfura o
analiz de impact, urmtoarele informaii sunt necesare:
Misiunea sistemului (ex. procesele desfurate de sistemul informaional)
Importana sistemului i a datelor pentru organizaie
Senzitivitatea datelor i a sistemului
Impactul unui eveniment de securitate poate fi descris ca i pierderea sau degradarea
oricruia dintre urmtoarele inte de securitate: integritate, disponibilitate i confidenialitate.
Pierderea integritii - Integritatea datelor i a sistemului se refer la necesitatea protejrii
informaiilor de modificri incorecte datorate fie unor aciuni intenionate, fie unor accidente.
Dac pierderea integritii sistemului sau a datelor nu este corectat, utilizarea unui sistem
contaminat poate conduce la inacuratee, fraud sau luarea unor decizii eronate. De
asemenea, violarea integritii poate fi un prim pas al unui atac mpotriva confidenialitii
sau disponibilitii sistemului.
Pierderea disponibilitii - Dac un sistem informaional esenial nu este disponibil
utilizatorilor finali, misiunea organizaiei ar putea fi afectat. Scderea funcionalitii
sistemului i a productivitii acestuia pot rezulta n scderea timpului de producie, astfel
afectnd performanele organizaiei.
Pierderea confidenialitii - Confidenialitatea sistemului i a datelor acestuia se refer la
protecia informaiilor de accesri neautorizate. Accesul neautorizat, neanticipat i involuntar
poate rezulta n pierderea ncrederii publice sau acionarea n judecat a organizaiei.
Unele impacte pot fi cuantificate n scderea ncasrilor, costul reparaiilor necesare
sau nivelul necesar de efort depus pentru a corecta problemele aprute n urma atacului
informatic.

Pasul 7. Determinarea riscurilor


Scopul acestei etape este de a evalua nivelul de risc al sistemului informaional.
Determinarea riscului pentru o anumit pereche ameninare-vulnerabilitate poate fi exprimat
ca funcie de:
Probabilitatea de apariie a unei surse de ameninare
Magnitudinea impactului n cazul materializrii riscului
Adecvarea controalelor de securitate existente sau planificate a fi implementate pentru
reducerea sau eliminarea riscului

Matricea nivelului de risc


Determinarea final a riscului se face prin ponderarea probabilitilor asociate unei
ameninri cu impactul. Tabelul 2.4 reprezint o matrice 3x3, unde att probabilitatea ct i
impactul sunt ncadrate n 3 niveluri (mare, mediu i sczut). Probabilitatea asociat fiecrei
ameninri prezint urmtoarele nivele: 1.0 pentru o probabilitate mare, 0.5 pentru o
probabilitate medie, i 0.1 pentru una sczut. Valoarea asociat fiecrui nivel de impact este:
100 pentru nivel ridicat, 50 pentru nivel mediu i 10 pentru nivel sczut.

Tabel 2.4 Probabilitile de apariie a ameninrii


Probabilitatea de
apariie a ameninrii
Mare (1.0)
Medie (0.5)
Redus (0.1)

Sczut (10)
Sczut
10 x 1.0 = 0
Sczut
10 x 0.5 = 5
Sczut
10 x 0.1 = 1

Impact
Mediu (50)
Mediu
50 x 1.0 = 50
Mediu
50 x 0.5 = 25
Sczut
50 x 0.1 = 5

Ridicat (100)
Mare
100 x 1.0 = 100
Mediu
100 x 0.5 = 50
Sczut
100 x 0.1 = 10

Sursa: The risk management process, Southern Cross University, disponibil la:
http://scu.edu.au/risk_management/index.php/2

Pasul 8. Recomandri privind controlul


Scopul controalelor este de a reduce nivelul de risc al sistemului informaional la un
nivel de risc acceptabil. Urmtorii factori trebuie luai n considerare n recomandarea
controalelor i a solutilor alternative, pentru a minimiza sau elimina riscurile identificate:
Eficacitatea opiunilor recomandate (compatibilitatea sistemului)

Legislaie i reglementri
Politicile organizaionale
Impactul operaional
Siguran i credibilitate
Controalele recomandate sunt rezultatul procesului de evaluare al riscului i reprezint
intrri pentru procesul de diminuare a riscului, prin care controalele de securitate
(procedurale i tehnice) sunt evaluate, prioritizate i implementate.
Pentru a determina care dintre controalele propuse sunt adecvate implementrii ntr-o
anumit organizaie, este necesar o analiz cost-beneficiu, care va justifica costurile
implementrii controalelor prin reducerea nivelului de risc. De asemenea, trebuie luate n
considerare i impactul operaional, respective fezabilitatea implementrii controalelor.
Pasul 9. Documentarea rezultatelor
Odat cu ncheierea fazei de evaluare a riscului (sursele ameninrilor i
vulnerabilitile au fost identificate, riscurile au fost evaluate i au fost formulate recomandri
privind controalele), rezultatele ar trebui documentate ntr-un raport oficial.
Un raport de evaluare al riscurilor este un raport de management care ajut
managementul n adoptarea deciziilor privind politica, procedurile, bugetul i sistemul
operaional.

Capitolul 3. Diminuarea riscului


Diminuarea riscului, cel de-al doilea proces n cadrul managementului riscului,
implic prioritizarea, evaluarea i implementarea controalelor adecvate recomandate n urma
derulrii procesului de evaluare a riscului.
Deoarece eliminarea riscului este de obicei aproape imposibil, este responsabilitatea
managementului s foloseasc cea mai eficient metod din punct de vedere al costurilor, i
s implementeze controalele adecvate pentru a reduce riscul la un nivel acceptabil,
minimiznd impactul asupra resurselor organizaiei.
Reducerea riscului poate fi atins prin oricare din urmtoarele opiuni:
Asumarea riscului implic acceptarea potenialului risc i continuarea operrii sistemului
IT sau implementarea unor controale pentru a diminua riscul la un nivel acceptat;
Evitarea riscului realizabil prin eliminarea cauzei riscului i/sau a consecinelor (ex.
renunarea la anumite funcii ale sistemului acolo unde sunt identificate riscuri);
Limitarea riscului prin implementarea unor controale care minimizeaz impactul
materializrii unei ameninri (ex. folosirea unor controale de prevenire i detecie) ;
Planificarea riscului - Dezvoltarea unui plan care prioritizeaz, implementeaz i ntreine
controalele;

Cercetare i acceptare diminuarea riscului prin acceptarea vulnerabilitilor sau lipsurilor


i cercetarea controalelor necesare pentru corecia vulnerabilitilor;
Transferul riscului prin utilizarea altor opiuni care s compenseze pierderile nregistrate,
cum ar fi ncheierea unei asigurri.
Atunci cnd este necesar s fie luate msuri de control, urmtoarea regul este
aplicabil:
intete riscul cel mai mare i tinde ctre o reducere a riscului suficient de mare, la un cost
redus, cu impact minim asupra celorlalte obiective ale organizaiei.

Conform Figurii 3.1, urmtoarea metodologie de reducere a riscului descrie abordarea


implementrii controalelor:
Figura 3.1 Metodologia diminurii riscului

Sursa: Scalet, S., Death to Phishing, CSO, disponibil la:


http://www.csoonline.com/article/2119357/malware-cybercrime/death-tophishing.html?page=8

a) Prioritizarea aciunilor
n baza nivelurilor de risc prezentate n raportul de evaluare a riscurilor, aciunile din
implementare sunt prioritizate. n momentul alocrii resurselor, cea mai mare

prioritate ar trebui s fie acordat elementelor cu risc ncadrat n categoria foarte mare
sau mare. Aceste vulnerabiliti vor necesita corecii imediate.
b) Evaluarea opiunilor de controale recomandate
n cadrul acestui pas, sunt analizate fezabilitatea i eficiena controalelor recomandate.
Obiectivul este de a alege cea mai adecvat opiune de control pentru minimizarea
riscului.
c) Elaborarea unei analize cost-beneficiu
Pentru a sprijini echipa de management n asumarea unei decizii i n identificarea
unor contoale eficiente din punct de vedere al costurilor, se va realiza o analiz costbeneficiu.
d) Selectarea controalelor
n baza rezultatelor analizei cost-beneficiu, managementul va determina cele mai
eficiente controale n vederea reducerii risului organizaiei. Controalele selectate vor
mbina elemente de ordin tehnic, managerial i operaional pentru a asigura o
securitate adecvat sistemului informatonal.
e) Desemnarea responsabilitilor
Este identificat personalul adecvat (propriu sau extern) care deine expertiza i
calificarea necesar pentru a implementa controalele selectate.
f) Dezvoltarea unui plan de implementare
Planul ar trebui s conin cel puin informaii referitoare la: riscuri (vulnerabiliti/
ameninri) i nivelurile de risc asociate; controalele recomandate; prioritizarea
aciunilor; controalele selectate; lista persoanelor responsabile cu implementarea
controalelor; resursele necesare implementrii; data de ncepere a implementrii
proiectului, etc).
g) Implementarea efectiv a controalelor selectate
n funcie de situaiile specifice, controalele implementate pot diminua dar nu elimin
riscul (riscul rezidual nu poate fi eliminat).

Capitolul 4. Evaluare i estimare


n majoritatea organizaiilor, reeaua va fi lrgit i updatat n mod continuu,
componentele sale se vor schimba, iar aplicaiile vor fi nlocuite sau updatate la versiuni mai
noi. n plus, n timp, se vor nregistra schimbri de personal i modificri ale politicilor de

securitate. Aceste schimbri vor implica apariia unor noi riscuri, iar riscurile care au fost
eliminate anterior pot deveni din nou o preocupare. n acest sens, procesul de management al
riscului se deruleaz continuu i evolueaz.
Pentru a implementa un program de success n ceea ce privete managementul de risc,
trebuie s inem cont de anumite practici i de anumii factori cheie.
Procesul de identificare a riscurilor pentru sistemele IT ar trebui s fie implementat i
integrat n SDLC, nu pentru c aa ordon legislaia i reglementrile n vigoare ci pentru c
reprezint o bun practic i, mai presus de toate, susine obiectivele i misiunea organizaiei.
Ar trebui s existe un orar specific n privina identificrii i diminurii sau eliminrii
riscurilor ns, n acelai timp, procesul ar trebui s fie destul de flexibil pentru a permite
schimbri n sistemul IT, schimbri generate de noi tehnologii sau reglementri n domeniu.
Un program de management de risc de succes trebuie s se bazeze pe anumii factori
cheie:
a) implicarea managementului senior
b) suportul si implicarea activ a echipei de IT
c) competena echipei de evaluare i identificare a riscului - aceast echip trebuie s
aib capacitatea de a aplica metodologia specific
d) contientizarea i cooperarea membrilor comunitii, care trebuie s urmeze
procedurile i s se supun controalelor n vederea protejrii i ndeplinirii obiectivelor
organizaiei.
e) o evaluare continu a sistemului IT n vederea prevenirii anumitor riscuri.

Bibliografie
1. Bandyopadhyay, K., Mykytyn, P., A framework for integrated risk management in
information technology, Management Decision, Vol.37, Nr.5, 2006, disponibil la:
http://www.emeraldinsight.com/doi/abs/10.1108/00251749910274216

2. Boukouras, A., Rajabi, M., An Ordinal Game Theory Approach to the Analisys and
Selection of Partners in Public Private Partnership Projects, Journal of
Optimization
Theory
and
Application,
2015,
disponibil
la:
http://link.springer.com/article/10.1007%2Fs10957-015-0844-3
3. Egon, F., Corporate Information Security Governance in Swiss Private Banking,
2004,
pp.
45-47,
disponibil
la:
http://www.isaca.ch/files/DO7_Diplomarbeiten/Diplom_CorporateInfSecGovernance
_E.pdf
4. Elky, S., An Introduction to Information System Risk Management, Sans Institute
Reading Room Site, 2006, disponibil la: https://www.sans.org/readingroom/whitepapers/auditing/introduction-information-system-risk-management-1204
5. Mc Neil, A.J, Frey, R., Quantitative Risk Management Concept, Tehniques and
Tools, Princeton University Press, U.K., 2015
6. Risk Management Guide for Information Tehnology Systems, NIST, iulie 2002,
disponibil la http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf
7. Scalet,
S.,
Death
to
Phishing,
CSO,
disponibil
la:
http://www.csoonline.com/article/2119357/malware-cybercrime/death-tophishing.html?page=8
8. Stylusinc, The software development life cycle (SLDC) overview, disponibil la:
http://www.stylusinc.com/BI/it-outsourcing/the-software-development-life-cycle-sdlc/
9. Stoneburner, G., Goguen, A., Risk Management Guide for Information Tehnology
System, National Institute of Standards and Technology, U.S.A., 2002,
10. The risk management process, Southern Cross University, disponibil la:
http://scu.edu.au/risk_management/index.php/2

Anexe
1. Sistem Development Life Cycle

Sursa: http://www.stylusinc.com/BI/it-outsourcing/the-software-development-life-cyclesdlc/

2. ntrebri Chestionar

Care sunt utilizatorii valizi?


Care este misiunea organizaiei?
Care este rolul sistemului n cadrul procesului organizaional?
Ct de important este sistemul n cadrul procesului organizaional?
Care este accesibilitatea sistemului?
Ce informaii sunt necesare organizaiei?
Ce informaii sunt generate de/utilizate de/procesate de/arhivate de/oferite de sistem?
Ct de important este informaia pentru misiunea companie?
Care sunt etapele prin care trece informaia nainte de a ajune n forma final?
Ce tip de informaii sunt procesate i arhivate de ctre sistem (ex. financiare,
personale, cercetare, medicale etc.)?
Ce informaii utilizate n cadrul sistemului nu ar trebui fcute publice i cine are
dreptul s utilizeze informaiile?
Unde anume este procesat i arhivat informaia?
Ce tip de informaii sunt stocate de ctre sistem?
Care este impactul asupra organizaiei dac informaia este utilizat de ctre persoane
neautorizate?
Care sunt cerinele n privina valabilitii i integritii informaiilor?

Care este efectul asupra misiunii organizaiei dac sistemul sau informaiile nu sunt
fiabile?
Care este nivelul de toleran al companiei n privina nefuncionalitii sistemului?
Care sunt alternativele, n privina procesrii i a comunicrii, pe care le poate folosi
utilizatorul?
Este posibil ca o defeciune sau indisponibilitatea sistemului s cauzeze rni sau
deces?

Sursa: Boukouras, A., Rajabi, M., An Ordinal Game Theory Approach to the Analisys and
Selection of Partners in Public Private Partnership Projects, Journal of Optimization
Theory and Application, 2015, pp. 20-27

3. Sursa Ameninrilor

Sursa: Elky, S., An Introduction to Information System Risk Management, Sans Institute Reading Room Site,
2006, pp.2, disponibil la: https://www.sans.org/reading-room/whitepapers/auditing/introduction-informationsystem-risk-management-1204

4. Definirea Probabilitilor

Sursa: Boukouras, A., Rajabi, M., An Ordinal Game Theory Approach to the Analisys and
Selection of Partners in Public Private Partnership Projects, Journal of Optimization
Theory and Application, 2015, pp. 22

Вам также может понравиться