Securitate PDF

Compilat de Srinivas Kante Email: srinivaskante4u@gmail.
com
IIBF & NISM Adda
Examenul de certificat în
SECURITATE IT
( IIBF și alte examene)
Srinivas Kante B.Tech, CAIIB IT
Compilat de
Compilat de Srinivas Kante Email: srinivaskante4u@gmail.com
Despre examenul de certificat în SECURITATE IT
Examinarea certificatului IIBF
OBIECTIV
Obiectivul cursului este de a conștientiza angajații băncii cu privire la cerințele de securitate IT și implementarea
corectă a acestora pentru protejarea interesului organizațional. Acest curs a fost dezvoltat pe baza discuțiilor pe care un
comitet al IBA le-a avut cu privire la securitatea IT, pe baza Raportului Comitetului Goplakrishnan.
DIPLOMAȚĂ ÎN AUDIT A SISTEMULUI INFORMAȚIONAL (DISA)
Candidații care absolvă toate următoarele trei examene de certificat în cadrul programului revizuit vor primi o
„DIPLOMAȚĂ ÎN AUDIT SISTEMULUI INFORMATIC (DISA)” din mai 2017:
a) Examen de certificat în securitate IT (programa revizuită)
b) Examen de certificat în prevenirea infracțiunilor cibernetice și managementul fraudei (programa revizuită)
c) Examen de certificat în Bancher în Sistemul Informațional (Programa revizuită)
Candidații care obțin toate cele trei certificate de mai sus în cadrul unei programe revizuite vor trebui totuși să solicite
certificatul DISA plătind Rs.500/- plus taxe, după caz.
Pentru candidații care au absolvit deja una sau toate cele trei examene de mai sus în cadrul vechii programe, adică
înainte de mai 2017, trebuie să aplice și să aprobe examenul din programa revizuită pentru a deveni eligibili pentru
Certificatul DISA.
ELIGIBILITATE
i) Angajații unei bănci sau instituții financiare.
ii) Orice absolvent al unei universități recunoscute sau echivalentul acesteia.
OBIECTUL EXAMINĂRII
Securitate IT
CRITERII DE PASARE:
Notele minime pentru promovarea materiei sunt 50 din 100.
TAXE* : Detalii
Prima incercare
Ulterior fiecare
EXAMEN Pentru Membri Pentru Nemembri încercare
1.000 Rs/- * 1.500 Rs./-

1.000 Rs/- * *
MEDIUL DE EXAMINARE: 1.500 Rs/- *
Examenul se va desfășura numai în limba engleză.
MODEL DE EXAMINARE:
(i) Foaia de întrebări va conține 120 de întrebări cu răspunsuri multiple de tip obiectiv pentru 100 de puncte.
(ii) Examenul se va desfășura numai în modul online
(iii) NU va exista notare negativă pentru răspunsurile greșite.
DURATA EXAMINĂRII:
Durata examenului va fi de 2 ore.
CENTRE DE PERIODICITATE ȘI DE EXAMINARE:

a) Examinarea se va desfășura la datele pre-anunțate publicate pe site-ul web IIBF. Institutul efectuează examenul
semestrial, totuși periodicitatea examinării poate fi modificată în funcție de cerințele industriei bancare.
b) Lista centrelor de examinare va fi disponibilă pe site-ul web. (Institutul va desfășura examenul în acele centre în
care există 20 sau mai mulți candidați.)
PROCEDURA DE APLICARE LA EXAMEN
Cererea de examinare trebuie înregistrată online de pe site-ul web al Institutului www.iibf.org.in. Programul de
examinare și datele de înregistrare vor fi publicate pe site-ul IIBF.
DOVADĂ DE IDENTITATE
Cei care nu sunt membri care aplică pentru examenele/cursurile Institutului sunt obligați să atașeze/să trimită o copie a
oricăruia dintre următoarele documente care conțin Numele, Fotografia și Semnătura la momentul înregistrării cererii
de examen. Cererea fără același lucru poate fi respinsă.
1) Fotografie I / Card eliberat de Angajator sau 2) Card PAN sau 3) Permis de conducere sau
4) I / Cardul alegătorului electoral sau 5) Pașaport 6) Cardul Aadhaar
MATERIAL DE STUDIU / CURS

Institutul a dezvoltat un curs pentru a acoperi programa. Cursurile (cartea) pentru subiectul/subiectele vor fi disponibile
la punctele de vânzare ale editorilor. Vă rugăm să vizitați site-ul IIBF www.iibf.org.in sub meniul „Legat de examen”
pentru detalii despre cărți și adresa editorilor. Candidații sunt sfătuiți să folosească pe deplin cursul. Cu toate acestea,
deoarece domeniile bancare și financiare sunt dinamice, regulile și reglementările sunt martorii unor schimbări rapide.
Prin urmare, cursul nu ar trebui să fie considerat singura sursă de informații în timpul pregătirii pentru examene.
Candidații sunt sfătuiți să parcurgă din când în când actualizările publicate pe site-ul IIBF și să parcurgă Master
Circulares / Master Directions emise de RBI și publicații ale IIBF precum IIBF Vision, Bank Quest etc. Toate aceste
surse sunt importante din punct de vedere al examinării. De asemenea, candidații trebuie să viziteze site-urile web ale
organizațiilor precum RBI, SEBI, BIS, IRDAI, FEDAI etc.
parcurgând alte cărți și publicații care acoperă subiectul/examenul în cauză etc. De asemenea, pot fi adresate întrebări
bazate pe evoluțiile actuale legate de subiect/examen.
Data limită a liniilor directoare/Evoluții importante pentru examene
Institutul are o practică de a pune întrebări în fiecare examen cu privire la evoluțiile recente / orientările emise de
autoritățile de reglementare pentru a testa dacă candidații se mențin la curent cu evoluțiile actuale. Cu toate acestea, ar
putea exista modificări în evoluțiile/orientările de la data la care sunt pregătite lucrările cu întrebări și datele
examinărilor efective.
Pentru a aborda aceste probleme în mod eficient, s-a decis că:
(i) În ceea ce privește examinările care urmează să fie efectuate de Institut pentru perioada februarie – iulie a unui an
calendaristic, instrucțiunile/orientările emise de autoritățile de reglementare și evoluțiile importante din domeniul
bancar și financiar până la 31 decembrie vor fi luate în considerare numai în acest scop. de includere în foile de
întrebări”.
(ii) În ceea ce privește examinările care urmează să fie efectuate de Institut pentru perioada august-ianuarie a unui an
calendaristic, instrucțiunile/orientările emise de autoritățile de reglementare și evoluțiile importante din domeniul
bancar și financiar până la 30 iunie vor fi luate în considerare numai în acest scop. de includere în foile de întrebări.
Tabelul de mai jos clarifică în Data limită a liniilor

continuare situația. directoare / Important
Detalii
Evoluții pentru Evoluții pentru
Examinare/e Examinare/e
Pentru ca examenele sa fie 31 decembrie 2017
condus de
Institutul pentru perioada februarie 2018
până în iulie 2018
Pentru ca examenele să fie 30 iunie 2018 conduse de
Institutul pentru perioada august 2018 până la
ianuarie 2019
PROGRAMĂ
Modulul - A: Prezentare generală a securității IT
1. Introducere în securitatea informațiilor
2. Politica de securitate IT corporativă
3. Securitate organizațională
a. Evaluare a riscurilor
b. Clasificarea informațiilor
4. Guvernarea securității
a. Politici
b. Cadru
c. Roluri și responsabilități
d. Respectarea politicilor
e. Formare și conștientizare
f. Monitorizarea
5. Securitate fizică și de mediu
6. Securitate hardware/software
7. Securitate operațională
8. Standarde de securitate
Modulul - B: Controale de securitate IT

9. Clasificarea și controlul activelor
10. Controale de securitate fizică și de mediu
11. Controale de securitate hardware/software
• Aplicații software și sisteme de operare
• Baze de date
12. Rețele și dispozitive de calculatoare (tehnologii cu fir și fără fir)
• Soluții de securitate (IDS, IPS, Fire Wall, VPN etc.)
• Logic
• Criptografie
13. Dezvoltare și întreținere software
• Dezvoltare internă
• externalizarea
Modulul - C: Amenințări de securitate IT

14. Prezentare generală a amenințărilor de securitate
• Legat de rețea
• Internet / Aplicație
• Non tehnic / intern
• Inginerie sociala
• Spionaj și delapidare
• Terorismul cibernetic etc
15. Prezentare generală a malware-urilor computerizate
• Prezentare generală
• Politică
16. Detectarea și prevenirea malware-urilor computerizate
17. Gestionarea incidentelor
18. Sisteme tolerante la erori
19. Continuitatea afacerii și recuperarea în caz de dezastru

Modulul - D: Audit SI și conformitatea reglementărilor
20. Audit IS
a. Cadru
b. Politici
c. Cartă
d. Planificare
e. Metodologie
f. Constatări de audit și proceduri de închidere
21. Conformitatea cu reglementările
a. Prezentare generală
b. Identificarea conformităților aplicabile
c. Revizuirea conformității
INDEX
S.nr Cuprins Pagina nr

1 Introducere în securitatea informațiilor 9 până la 17
2 Politica de securitate IT corporativă 18 la 28
3 Securitate organizațională 29 la 36
4 Guvernarea securității 37 până la 42
5 Securitate hardware 43 până la 52
6 Securitate operațională 52 până la 54
7 Securitate software 54 până la 56
8 Testare software 56 până la 67
9 Standarde de securitate și bune practici 67 până la 72
10 Controale de rețea 73 până la 97
11 Gestionarea incidentelor 98 la 99
12 Continuitatea afacerii și recuperarea în caz de dezastru 100 până la 107
13 Auditul Sistemelor Informatice 108 până la 121
14 Organisme de reglementare financiară din India 122 până la 153
15 Legea IT din 2008 154 până la 156
16 Informații suplimentare 157 până la 198
17 Glosar 199 până la 206
INTRODUCERE ÎN SECURITATEA INFORMAȚIILOR
Securitatea informațiilor este un set de strategii de gestionare a proceselor, instrumentelor și

politicilor necesare pentru a preveni, detecta, documenta și contracara amenințările la adresa
informațiilor digitale și non-digitale. Responsabilitățile de securitate a informațiilor includ
stabilirea unui set de procese de afaceri care vor proteja activele informaționale, indiferent de
modul în care informațiile sunt formatate sau dacă sunt în tranzit, sunt procesate sau sunt în stare de
repaus în stocare.
Programele de securitate a informațiilor sunt construite în jurul obiectivelor de bază ale triadei
CIA : menținerea confidențialității , integrității și disponibilității sistemelor IT și a datelor de
afaceri. Aceste obiective asigură că informațiile sensibile sunt dezvăluite doar părților autorizate
(confidențialitate), împiedică modificarea neautorizată a datelor (integritate) și garantează că datele
pot fi accesate de către părțile autorizate atunci când sunt solicitate (disponibilitate).
Multe întreprinderi mari angajează un grup de securitate dedicat pentru implementarea și

menținerea programului de securitate a informațiilor al organizației. De obicei, acest grup este
condus de un ofițer șef de securitate a informațiilor. Grupul de securitate este în general responsabil
pentru gestionarea riscurilor , un proces prin care vulnerabilitățile și amenințările la adresa activelor
informaționale sunt evaluate în mod continuu, iar controalele de protecție adecvate sunt decise și
aplicate. Valoarea unei organizații constă în informațiile sale -- securitatea acesteia este critică
pentru operațiunile de afaceri, precum și pentru păstrarea credibilității și câștigarea încrederii
clienților.
Amenințările la adresa informațiilor sensibile și private au multe forme diferite, cum ar fi atacuri de
malware și phishing , furtul de identitate și ransomware . Pentru a descuraja atacatorii și a atenua
vulnerabilitățile în diferite puncte, mai multe controale de securitate sunt implementate și
coordonate ca parte a unei strategii de apărare în profunzime . Acest lucru ar trebui să minimizeze
impactul unui atac. Pentru a fi pregătiți pentru o încălcare a securității, grupurile de securitate ar
trebui să aibă un plan de răspuns la incident ( IRP ). Acest lucru ar trebui să le permită să limiteze și
să limiteze daunele, să elimine cauza și să aplice controale de apărare actualizate.
PILERS DE SECURITATE A INFORMAȚIILOR

Securitatea este o îngrijorare constantă când vine vorba de tehnologia informației . Furtul de date ,
piratarea , programele malware și o serie de alte amenințări sunt suficiente pentru a ține treaz orice
profesionist IT noaptea.
Securitatea informațiilor urmează trei principii generale:
• Confidențialitate : Aceasta înseamnă că informațiile sunt văzute sau utilizate numai de către
persoanele care sunt autorizate să le acceseze.
• Integritate : Aceasta înseamnă că orice modificări aduse informațiilor de către un utilizator
neautorizat sunt imposibile (sau cel puțin detectate), iar modificările efectuate de utilizatorii
autorizați sunt urmărite.
• Disponibilitate : Aceasta înseamnă că informațiile sunt accesibile atunci când utilizatorii
autorizați au nevoie de ele.
Asigurarea informațiilor (IA) se referă la pașii implicați în protejarea sistemelor informaționale,

cum ar fi sistemele și rețelele informatice. Există în mod obișnuit cinci termeni asociați cu definiția
asigurării informațiilor:
• Integritate
• Disponibilitate
• Autentificare
• Confidențialitate
• Nerepudierea
IA este un domeniu în sine. Poate fi considerată o specialitate a tehnologiei informației (IT),

deoarece un specialist IA trebuie să aibă o înțelegere aprofundată a IT și a modului în care
sistemele informaționale funcționează și sunt interconectate. Cu toate amenințările care sunt acum
comune în lumea IT, cum ar fi viruși, viermi, atacuri de phishing, ingineria socială, furtul de
identitate și multe altele, este necesar să se concentreze asupra protecției împotriva acestor
amenințări. IA este acel focus.
1. Confidențialitatea, în contextul sistemelor informatice, permite utilizatorilor autorizați să
acceseze date sensibile și protejate. Mecanisme specifice asigură confidențialitatea și protejează
datele împotriva intrușilor dăunători.
Confidențialitatea este unul dintre cei cinci piloni ai asigurării informațiilor (IA). Celelalte patru
sunt autentificarea, disponibilitatea, integritatea și nonrepudierea.
Informațiile sau datele sensibile trebuie dezvăluite numai utilizatorilor autorizați. În IA,
confidențialitatea este impusă într-un sistem de clasificare. De exemplu, un guvern sau un muncitor
militar american trebuie să obțină un anumit nivel de autorizare, în funcție de cerințele de date ale
unei poziții, cum ar fi, clasificate, secrete sau secrete. Cei cu autorizații secrete nu pot accesa
informații de top secret.
Cele mai bune practici utilizate pentru a asigura confidențialitatea sunt următoarele:
Un proces de autentificare, care asigură că utilizatorilor autorizați li se atribuie o identificare și

parole confidențiale ale utilizatorului. Un alt tip de autentificare este biometria.
Metode de securitate bazate pe roluri pot fi folosite pentru a asigura autorizarea utilizatorului
sau a vizualizatorului. De exemplu, nivelurile de acces la date pot fi atribuite personalului
departamentului specificat.
Controalele accesului asigură că acțiunile utilizatorului rămân în rolurile lor. De exemplu,

dacă un utilizator este autorizat să citească, dar nu să scrie date, pot fi integrate controale de sistem
definite.
1. Integritatea, în contextul sistemelor informatice, se referă la metodele de asigurare a faptului că

datele sunt reale, exacte și protejate de modificările neautorizate ale utilizatorului. Integritatea este
unul dintre cei cinci piloni ai asigurării informațiilor (IA). Celelalte patru sunt autentificarea,
disponibilitatea, confidențialitatea și nonrepudierea.
Menținerea integrității datelor este o cerință de securitate a informațiilor. Integritatea este o

componentă majoră a IA, deoarece utilizatorii trebuie să poată avea încredere în informații. Datele
care nu sunt de încredere sunt lipsite de integritate. Datele stocate trebuie să rămână neschimbate în
cadrul unui sistem informatic (IS), precum și în timpul transportului de date.
Evenimente precum eroziunea stocării, erorile și datele intenționate sau deteriorarea sistemului pot
crea modificări ale datelor. De exemplu, hackerii pot provoca daune prin infiltrarea sistemelor cu
programe malware, inclusiv cai troieni, care depășesc sistemele informatice, precum și viermi și
viruși. Un angajat poate crea daune companiei prin introducerea intenționată a datelor false.
Măsurile de verificare a integrității datelor includ sume de control și utilizarea comparației datelor
3 .Disponibilitatea, în contextul unui sistem informatic, se referă la capacitatea unui utilizator de a
accesa informații sau resurse într-o locație specificată și în formatul corect. Disponibilitatea este
unul dintre cei cinci piloni ai asigurării informațiilor (IA). Celelalte patru sunt integritatea,
autentificarea, confidențialitatea și non-repudierea.
Atunci când un sistem nu funcționează în mod regulat, disponibilitatea informațiilor este afectată și
are un impact semnificativ asupra utilizatorilor. În plus, atunci când datele nu sunt sigure și ușor
disponibile, securitatea informațiilor este afectată, adică autorizațiile de securitate top secret. Un alt
factor care afectează disponibilitatea este timpul. Dacă un sistem informatic nu poate furniza
informații în mod eficient, atunci disponibilitatea este compromisă.
Disponibilitatea datelor trebuie asigurată prin stocare, care poate fi locală sau la o unitate în afara
amplasamentului. În cazul unei instalații în afara amplasamentului, un plan stabilit de continuitate a
activității ar trebui să precizeze disponibilitatea acestor date atunci când datele la fața locului nu
sunt disponibile. În orice moment, informațiile trebuie să fie disponibile celor cu autorizație.
Triada
CIA
CONFIDENȚIALITATE
Confidențialitatea împiedică dezvăluirea

neautorizată a informațiilor.
-
INTEGRITATE
asigurați-vă că
datele nu pot
manieră.
r DISPONIBILITATE
Informațiile ar trebui să fie

ușor disponibile pentru
utilizatorii autorizați.
4 Nerepudierea este o metodă de garantare a transmiterii mesajelor între părți prin

semnătură digitală și/sau criptare. Este unul dintre cei cinci piloni ai asigurării
informațiilor (AI). Celelalte patru sunt disponibilitate, integritate, confidențialitate și
autentificare.
Nerepudierea este adesea folosită pentru contractele digitale, semnăturile și mesajele de e-

mail.
Prin utilizarea unui hash de date, se poate obține dovada datelor de identificare autentice și
a originii datelor. Alături de semnăturile digitale, cheile publice pot fi o problemă atunci
când vine vorba de nerepudiere dacă destinatarul mesajului și-a expus, cu bună știință sau
fără, cheia criptată sau secretă. .
5. În contextul sistemelor informatice, autentificarea este un proces care asigură și confirmă

identitatea unui utilizator. Autentificarea este unul dintre cei cinci piloni ai asigurării informațiilor
(IA). Celelalte patru sunt integritatea, disponibilitatea, confidențialitatea și non-repudierea.
Autentificarea începe atunci când un utilizator încearcă să acceseze informații. În primul rând,
utilizatorul trebuie să își dovedească drepturile de acces și identitatea. Când se conectează la un
computer, utilizatorii introduc de obicei nume de utilizator și parole în scopuri de autentificare.
Această combinație de autentificare, care trebuie atribuită fiecărui utilizator, autentifică accesul. Cu
toate acestea, acest tip de autentificare poate fi ocolit de hackeri.
O formă mai bună de autentificare, biometria, depinde de prezența utilizatorului și de machiajul
biologic (adică, retina sau amprentele digitale). Această tehnologie face mai dificilă pătrunderea
hackerilor în sistemele informatice.

Metoda de autentificare Public Key Infrastructure (PKI) folosește certificate digitale pentru a
dovedi identitatea unui utilizator. Există și alte instrumente de autentificare, cum ar fi carduri
de cheie și jetoane USB. Una dintre cele mai mari amenințări de autentificare apare cu e-mailul,
unde autenticitatea este adesea dificil de verificat. De exemplu, e-mailurile nesecurizate par
adesea legitime.
Siguranță fizică
Securitatea fizică descrie măsurile concepute pentru a asigura protecția fizică a activelor IT,
cum ar fi instalațiile, echipamentele, personalul, resursele și alte proprietăți împotriva daunelor
și accesului fizic neautorizat. Sunt luate măsuri de securitate fizică pentru a proteja aceste
bunuri de amenințări fizice, inclusiv furt, vandalism, incendiu și dezastre naturale.
Securitatea fizică este adesea prima preocupare în instalațiile cu concentrare mare a activelor,
în special cea utilizată în sistemele critice pentru procesele de afaceri. Securitatea fizică este
deosebit de importantă pentru resursele IT, deoarece funcționarea lor corectă necesită ca
activele hardware și infrastructura pe care rulează să fie ținute departe de orice ar putea
împiedica funcționarea lor. Aceasta include manipularea personalului neautorizat și evenimente
neprevăzute, cum ar fi accidente și dezastre naturale.
Există două faze de securitate fizică:

• Descurajare: metode și măsuri menite să descurajeze atacatorii și intrușii sau să prevină

evenimentele naturale și accidentele să afecteze bunurile protejate. Metoda simplă pentru
aceasta este prin utilizarea barierelor fizice și a semnelor. Semnele servesc ca un avertisment
pentru orice intrus că acțiunile lor vor aduce vătămări fizice sau urmărire penală. Barierele
fizice sunt menite să împiedice accesul în întregime sau pur și simplu să ofere protecție
împotriva factorilor externi precum furtunile sau accidentele rutiere.
• Detectare: Permite personalului de securitate să detecteze și să localizeze potențiali intruși
folosind echipamente de supraveghere cum ar fi camere, senzori de mișcare, lumini de
securitate și personal cum ar fi paznicii și câinele de pază
Securitatea fizică se referă la măsurile preventive utilizate pentru a împiedica intrușii să

acceseze fizic locația. Indicând echipamente fizice sau electronice care protejează aspecte
tangibile ale site-ului, securitatea fizică este eficientă în oprirea infractorilor nedoriți sau a
vizitatorilor neautorizați. Soluțiile de securitate fizică, cum ar fi gestionarea vizitatorilor,
protejează vizitatorii neautorizați. Nu poți fi niciodată prea sigur în a te asigura că celor care
intră li se acordă permisiunile corespunzătoare pentru a face acest lucru. Vizitatorii neautorizați
ar putea căuta să extragă datele companiei, să facă rău angajaților sau chiar să fure
echipamente precum computere și monitoare.
Securitatea fizică permite stabilirea de bariere oriunde este nevoie pentru a se asigura că numai
cei cu autorizație pot intra. Măsurile suplimentare de securitate fizică includ:
• Seifuri – Construcția lor robustă oferă protecție fără limite, fie că este vorba despre obiecte
de valoare sau informații precum documente și unități de stocare a datelor. Seifurile au
capabilitățile de a rezista la daune fizice provocate de potențiali intruși pentru a păstra
conținutul în siguranță. Pătrunderea într-un seif este atât de dificilă încât acționează ca un
factor de descurajare împotriva unui posibil furt.
• CCTV – Televiziune cu circuit închis (CCTV) permite monitorizarea și înregistrarea în
majoritatea locațiilor din unitatea dumneavoastră. Utile în identificarea celor care pătrund în
timp ce descurajează potențialii invadatori, supravegherea video și CCTV sunt eficiente și
unele dintre cele mai comune măsuri de securitate fizică. CCTV reduce, de asemenea, costurile
de securitate, deoarece permite mai puține persoane să monitorizeze mai mult din instalație,
spre deosebire de numirea de paznici la un post.
• Alarme – În cazul intrării neautorizate, alarmele semnalează autoritățile și asigură
răspunsurile adecvate cu partea neinvitată. Alarmele reduc nevoile de personal și măresc
timpul de răspuns prin eliminarea nevoii de a avea o persoană care să contacteze forțele de
ordine.
Securitate logică
Numai pe internet există aproximativ 1,2 milioane de terabytes de date. Cu atât de multe
informații disponibile pentru oricine are acces la internet, expansiunea noastră digitală a făcut
ca lumea să se micșoreze din cauza interconectării noastre. Cu toate acestea, lumea mică
rezultată nu denotă că totul trebuie împărtășit. Securitatea logică se referă la garanțiile
existente pentru a proteja accesul la sistemul de stocare a datelor în sine. Este folosit o dată în
interiorul șantierului și îngreunează accesul celor fără anumite permisiuni la sistemele cărora
nu le aparțin. Dacă cineva ar trece de securitatea fizică, securitatea logică asigură că nu poate
intra în sistemele informatice fără acreditări pentru a vă proteja rețeaua de intruziuni.
Exemple de soluții eficiente de securitate logică includ:
• Profiluri de utilizator – Furnizarea persoanelor autorizate de acces la conturi la sistem

facilitează urmărirea persoanelor care accesează ce și când. Rețelele partajate monitorizează
cine modifică documentele și înregistrează utilizatorii care se conectează ulterior pentru
referință dacă se suspectează fraudă.
• Parole – În timp ce angajații au acces la sediu, doriți totuși să vă asigurați securitatea în
sistemul dumneavoastră. Parolele sunt modalitatea ideală de a preveni părțile nedorite Compiled
by Srinivas Kante Email: srinivaskante4u@gmail.com

a intra în. Parolele puternice împiedică hackerii să intre și să perturbe integritatea datelor dvs.
• Biometrie – Inclusiv scanări ale retinei, analiza amprentelor digitale și recunoașterea
vocală, biometria folosește fiziologia ca mijloc de identificare.
Politica de securitate IT corporativă
Progresele tehnologice semnificative au schimbat modul în care facem afaceri. Adică,

internetul, e-mailul și mesajele text au înlocuit practic faxurile, scrisorile și telexurile în lumea
corporativă. Internetul este folosit pentru a obține informații și a comunica eficient cu clienții,
asociații de afaceri și partenerii.
În timp ce utilizarea internetului vine cu numeroase avantaje, cum ar fi viteza de comunicare și

o creștere a profitului, conține și câteva dezavantaje care pot împiedica serios productivitatea și
creșterea afacerii. De exemplu, personalul poate folosi internetul ca o distragere a atenției
pentru a-și examina conturile de Facebook, Twitter și Instagram, de a face cumpărături de pe
Amazon sau eBay, de a verifica cele mai recente statistici sportive, de a schimba e-mailuri
personale cu colegii, prietenii și așa mai departe. Aceste activități nu numai că sporesc riscul
de apariție a programelor malware, ci și scad productivitatea și veniturile angajaților.
Prin urmare, elaborarea unei politici corporative de securitate IT va ajuta la atenuarea

consecințelor negative asociate cu utilizarea internetului – și în special a e-mailului.
„Piulițele și șuruburile” unei politici de securitate IT
Vreau să încep prin a spune că o abordare de tip cookie-cutter pentru dezvoltarea unei politici
de securitate IT nu există. Fiecare organizație diferă în practicile și protocoalele sale de afaceri,
așa că o singură politică de securitate IT nu se va potrivi nevoilor fiecărei organizații. O
politică de securitate IT ar trebui să fie un document personalizat care să reprezinte cu
acuratețe un anumit mediu de afaceri și să răspundă în mod specific nevoilor acestuia. Nu vă
modelați politica de securitate IT exact pe politicile de securitate IT ale Google sau Apple,
deoarece ceea ce funcționează pentru ei ar putea să nu funcționeze pentru dvs.
O politică de securitate IT este în esență o strategie (plan) scrisă care acoperă implementarea
metodelor, tehnologiilor și conceptelor de securitate a informațiilor. Această politică oferă linii
directoare generale pentru procedurile de securitate ale companiei, fără a preciza cu precizie
cum vor fi protejate datele. Managerii IT le oferă o oarecare libertate de a decide care
dispozitive electronice, software și metode ar fi cele mai bune pentru a implementa liniile
directoare ale politicii. O politică de securitate IT nu ar trebui să precizeze în mod explicit ce
furnizori și tehnologii ar trebui să fie utilizate. Scopul de bază este de a stabili reguli de bază și
parametri utilizați pentru a elabora apoi practici mai specifice de securitate a datelor.
Politica ar trebui să cuprindă toate datele sale critice și sistemele electronice – inclusiv
internetul, e-mailul, rețelele de computere și așa mai departe. În plus, trei puncte vitale trebuie
luate în considerare atunci când se elaborează o politică de securitate IT corporativă:
• confidențialitatea informațiilor sensibile critice pentru misiune
• disponibilitatea acestor informații
• protecția informațiilor împotriva distrugerii (gândiți-vă la viruși, viermi, troieni), abuz

intern și abuz.
Cele mai importante 3 motive pentru o politică de securitate IT corporativă
O politică de securitate IT oferă o rampă de lansare pentru alte proceduri de securitate IT, o
bază pentru aplicarea consecventă și un ghid de referință stabil pentru încălcările de securitate
IT atunci când apar. În loc să aruncați această politică pe raft pentru a colecta praf, utilizați-o
pentru a vă asigura că datele dvs. corporative rămân în siguranță și pentru a aplica sancțiuni
corespunzătoare atunci când nu sunt. Mai jos sunt trei moduri suplimentare prin care o politică
de securitate IT se poate dovedi benefică:
1. Răspunderea juridică corporativă – Când o politică de securitate IT prevede în mod

explicit
• cum și când să utilizați e-mailul, internetul, dispozitivele electronice și rețelele de

computere
• cum ar trebui tratate datele corporative sensibile
• și utilizarea corectă a parolelor și a criptării,

amenințarea dvs. de expunere la programe malware și scurgeri de date confidențiale va scădea
semnificativ.
E-mailurile – personale și corporative – vor face inevitabil o organizație vulnerabilă la atacuri

de tip phishing, viruși și alte programe rău intenționate. Angajații care fac schimb de e-mailuri
în cadrul sau în afara companiei pot include glume rasiale și sexiste, conținut sexual explicit și
alte materiale care pot fi considerate ofensatoare de către destinatarii acestor e-mailuri. Această
activitate deschide compania către răspunderi legale masive în cazul în care angajații depun
procese pentru că se simt hărțuiți sau jigniți de aceste e-mailuri.
O politică de securitate IT (și aplicarea acesteia) va elimina infractorii și va fi o apărare strânsă

în instanța de judecată, deoarece compania poate demonstra că a făcut tot ce i-a stat în putere
pentru a descuraja e-mailurile ofensive și pentru a rezolva toate problemele conexe.
2. Terți – Când persoane fizice și companii (adică vânzători, auditori, clienți, investitori etc.)
se asociază cu dvs., probabil că vor dori să știe dacă aveți o politică de securitate IT stabilită
înainte de a-și împărtăși informațiile confidențiale, cum ar fi extrasele bancare, numere de
securitate socială, nume, adrese și alte informații specifice identității.
De exemplu, o corporație de compensare oferă tot felul de servicii de procesare și programare

financiară pentru companii de asigurări, bănci și chiar agenții guvernamentale. Desigur, au o
politică strictă de securitate IT pentru a se asigura că niciuna dintre acele înregistrări financiare
nu a fost vreodată supusă atacurilor de tip phishing.
3. Conformitatea cu legislația guvernamentală și locală – În cele din urmă, companiile

creează politici de securitate IT pentru a îndeplini standardele și reglementările legilor
guvernamentale privind protecția informațiilor electronice.
Într-o notă care nu are nicio legătură, dacă politica dvs. de securitate IT conține o secțiune
despre monitorizarea e-mailurilor corporative și personale ale angajaților, informați-i clar pe
angajații că IT va monitoriza toate e-mailurile de intrare și de ieșire. Dacă angajații nu știu că
e-mailurile lor sunt monitorizate și apoi intră sub control pentru un e-mail suspect, ei pot
depune un proces împotriva companiei pentru încălcarea vieții private.
Pentru a proteja compania împotriva acestui tip de litigii, informați-le cu privire la politicile
dvs. de securitate IT și e-mail prin sesiuni de informare și instruire. Acest lucru va pune pe
umerii lor responsabilitatea conformității și va reduce riscul unei activități lipsite de etică.
Majoritatea planurilor complete de securitate IT ar include următoarele nouă subiecte de

politică:
1. Politica de utilizare acceptabilă
Deoarece utilizarea necorespunzătoare a sistemelor corporative expune

compania la riscuri, este important să specificați exact ce este permis și ce este
interzis. Scopul acestei politici este de a detalia utilizarea acceptabilă a
resurselor de tehnologia informației corporative pentru protecția tuturor părților
implicate.
Sfera de aplicare a acestei politici include orice utilizare a resurselor IT

corporative, inclusiv, dar fără a se limita la, sistemele informatice, e-mailul,
rețeaua corporativă și conexiunea la Internet corporativă.
De exemplu, politica de utilizare acceptabilă a Annese subliniază lucruri

precum utilizarea e-mailului, confidențialitatea, rețelele sociale și navigarea pe
web, utilizarea personală și modul de raportare a incidentelor de securitate.
Politica dvs. de utilizare acceptabilă ar trebui să fie singura politică pe care toată
lumea din organizația dvs. o recunoaște prin semnătură pe care a citit-o și a
înțeles-o.
2. Politica privind datele confidențiale
Datele confidențiale sunt de obicei datele care dețin cea mai mare valoare pentru o companie.
Adesea, datele confidențiale sunt valoroase și pentru alții și, prin urmare, pot prezenta un risc
mai mare decât datele generale ale companiei. Din aceste motive, este o bună practică să dictați
standarde de securitate care se referă în mod specific la datele confidențiale.
Această politică ar detalia modul în care trebuie tratate datele confidențiale și exemple de ceea
ce organizația dvs. consideră confidențial.
3. Politica de e-mail
E-mailul este o componentă esențială a comunicării în afaceri; cu toate acestea, prezintă

provocări datorită potențialului său de a introduce amenințări de securitate în rețea. E-mailul
poate avea, de asemenea, un efect asupra răspunderii companiei prin furnizarea unei evidențe
scrise a comunicărilor. Politica dvs. de e-mail ar detalia regulile de utilizare ale organizației
dvs. pentru sistemul de e-mail.
Această politică va ajuta compania să reducă riscul unui incident de securitate

legat de e-mail, să promoveze o bună comunicare de afaceri atât intern, cât și
extern și să asigure aplicarea consecventă și profesională a principiilor
companiei de e-mail.
Sfera de aplicare a acestei politici include sistemul de e-mail al companiei în

întregime, inclusiv aplicații de e-mail desktop și/sau web, aplicații pe partea de
server, relee de e-mail și hardware asociat. Acesta acoperă toată poșta
electronică trimisă din sistem, precum și orice cont de e-mail extern accesat din
rețeaua companiei.
4. Politica dispozitivelor mobile
O forță de muncă mai mobilă este o forță de muncă mai flexibilă și mai
productivă. Din acest motiv, utilizarea dispozitivelor mobile în afaceri este în
creștere și, pe măsură ce aceste dispozitive devin instrumente vitale pentru a
desfășura afaceri, pe ele sunt stocate tot mai multe date sensibile și, astfel, riscul
asociat utilizării lor crește.
Această politică acoperă orice dispozitiv mobil capabil să intre în contact cu

datele companiilor dvs.
5. Politica de răspuns la incident
Un incident de securitate poate lua mai multe forme: un atacator rău intenționat care obține
acces la rețea, un virus sau alt program malware care infectează computerele sau chiar un
laptop furat care conține date confidențiale. O politică bine gândită de răspuns la incident este
esențială pentru recuperarea cu succes după un incident de date.
Această politică acoperă toate incidentele care pot afecta securitatea și integritatea activelor
informaționale ale companiei dvs. și prezintă pașii de urmat în cazul în care apare un astfel de
incident.
6. Politica de securitate a rețelei
Toată lumea are nevoie de o infrastructură de rețea sigură pentru a proteja integritatea datelor
corporative și pentru a reduce riscul unui incident de securitate. Scopul unei politici specifice
de securitate a infrastructurii de rețea este de a stabili liniile directoare tehnice pentru
securitatea IT și de a comunica controalele necesare pentru o infrastructură de rețea securizată.
Această politică poate include proceduri specifice referitoare la parolele dispozitivului,

jurnalele, firewall-urile, hardware-ul în rețea și/sau testele de securitate.
7. Politica parolelor
Cel mai simplu punct de intrare pentru a vă construi politica de securitate, o politică de parole
este primul pas pentru a le permite angajaților să vă protejeze compania de atacurile
cibernetice. (Annese împărtășește propria noastră politică privind parolele ca parte a șablonului
pentru a începe aici.)
Parolele sunt prima linie de protecție pentru conturile de utilizator. O parolă prost aleasă poate
duce la compromiterea întregii rețele corporative a organizației dvs. Această politică s-ar aplica
oricărei persoane cărora i se oferă un cont conectat la rețeaua sau sistemele dvs. corporative,
inclusiv: angajați, oaspeți, contractori, parteneri, furnizori etc.
8. Politica de securitate fizică
Scopul acestei politici este de a proteja sistemele de informații fizice ale companiei
dumneavoastră prin stabilirea de standarde pentru operațiuni securizate. Pentru a vă securiza
datele companiei, trebuie să vă gândiți la securitatea resurselor fizice de tehnologie a
informației (IT) ale companiei pentru a vă asigura că acestea sunt protejate de riscurile
standard.
Această politică s-ar aplica dispozitivelor de rețea deținute de companie sau

furnizate de companie, precum și oricărei persoane care lucrează sau vizitează
un birou corporativ.
9. Politica de acces pentru oaspeți și rețea fără fir
Fiecare organizație ar trebui să aibă o politică wireless care ar trebui probabil să includă
cerințele de acces pentru oaspeți. Accesul wireless se poate face în siguranță dacă se iau
anumite măsuri pentru a atenua riscurile cunoscute.
Accesul oaspeților la rețeaua companiei este adesea necesar pentru clienții, consultanții sau
vânzătorii care vizitează birourile companiei. Acest lucru poate lua pur și simplu forma unui
acces la Internet de ieșire sau oaspetele poate solicita acces la resurse specifice din rețeaua
companiei. Prin urmare, accesul oaspeților la rețeaua companiei trebuie să fie strict controlat.
Această politică ar sublinia pașii pe care compania dorește să-i facă pentru a-și
asigura infrastructura wireless. Aceste politici ar acoperi pe oricine accesează
rețeaua printr-o conexiune wireless, inclusiv oaspeții.
Organizare Char! pentru Guvernarea IS
Comitetul de securitate a informațiilor
Rolul comitetului de securitate a informațiilor este de a elabora strategii și politici pentru protecția
tuturor activelor băncii (inclusiv informații, aplicații, infrastructură și Compiled by Srinivas Kante Email:
srinivaskante4u@gmail.com
oameni). Comitetul va oferi, de asemenea, îndrumări și direcții cu privire la Implicațiile de
securitate ale planurilor de continuitate a activității și de recuperare în caz de dezastru. Dezvoltarea
și facilitarea implementării politicilor, standardelor și procedurilor de securitate a informațiilor
pentru a se asigura că toate riscurile identificate sunt gestionate în cadrul apetitului pentru risc al
băncii.
Creați o structură de securitate a informațiilor și de gestionare a riscurilor care să acopere întreaga
bancă, cu roluri și responsabilități clar definite. Creați și urmați un proces de evaluare a riscurilor
care este consecvent în întreaga bancă pentru a identifica, evalua riscurile cheie și aproba măsurile
de control și strategiile de atenuare. Monitorizează în mod regulat procesele de securitate și
management al riscurilor și acțiunile corective pentru a asigura conformitatea cu cerințele de
reglementare. Asigurați-vă că echipa de securitate a informațiilor are calificarea adecvată și
personalul adecvat. Prezentați în mod regulat rapoarte Consiliului și solicitați feedback cu privire
la procesele de management al securității informațiilor.
Șef – Management integrat al riscurilor (HIRM)
Șeful Managementului Integrat al Riscului va fi un oficial de nivel superior cu gradul

CGM/GM/DGM. HIRM este responsabil pentru toate funcțiile de management al riscului din
bancă, cum ar fi riscul de credit, riscul de piață și riscul operațional. Securitatea informațiilor va fi
una dintre cele mai critice componente ale riscului operațional de care trebuie să se îngrijească
HIRM. El este cel mai senior executiv în funcția de securitate a informațiilor din bancă și oferă
conducerea și sprijinul necesar pentru aceasta în întreaga bancă, cu sprijinul și angajamentul deplin
din partea Consiliului.
Responsabilități (în domeniul guvernanței securității informațiilor):

Guvernanța securității informațiilor
Politica și strategia de securitate a informațiilor
Evaluarea, managementul și monitorizarea riscurilor de securitate a informațiilor
Aspecte de securitate și implicații ale planificării continuității afacerii în bancă.
Alocarea resurselor adecvate pentru Managementul Securității Informaționale
Ofițerul șef pentru securitatea informațiilor (CISO)*
În funcție de dimensiunea băncii și de amploarea operațiunilor acesteia, un oficial de nivel

suficient de înalt cu rangul de GM/DGM/AGM trebuie desemnat ca responsabil șef pentru
securitatea informațiilor (CISO) responsabil pentru articularea și aplicarea politicilor pe care o
bancă. folosește pentru a-și proteja activele informaționale în afară de coordonarea problemelor
legate de securitatea informațiilor/implementarea în cadrul organizației, precum și a agențiilor
externe relevante.
CISO trebuie să raporteze direct șefului funcției de management integrat al riscurilor (HIRM) și nu
ar trebui să aibă o relație de raportare directă cu CIO. Rolul CISO se întinde atât pe dimensiunile
strategice, cât și pe cele operaționale și este responsabil pentru toate sarcinile administrative și
controlul legate de Securitatea Informației și raportează către Proprietarul acestei funcții, HIRM.
Responsabilitati:
Politica și strategia de securitate a informațiilor – Intrări și îmbunătățiri

Stabiliți linii directoare și măsuri de securitate pentru a proteja datele și sistemele. Evaluarea,
evaluarea, evaluarea, evaluarea, managementul, monitorizarea și raportarea la securitatea
informațiilor, riscuri, amenințări, vulnerabilități – în mod continuu Monitorizarea indicatorilor
cheie de obiective și indicatorilor cheie de performanță ai Programului de securitate a informațiilor
Stabilirea și diseminarea regulilor aplicabile Continuitatea activității și planificarea recuperării în
caz de dezastru – Intrări și îmbunătățiri de securitate Supraveghea
Instruire de conștientizare privind securitatea informațiilor Centrul de operațiuni de securitate și
managementul incidentelor Business Case pentru investiții și cheltuieli în securitatea informațiilor
Menținerea poziției de securitate și a profilului băncii la nivelurile așteptate Colaborare și
comunicare activă cu unitățile de afaceri și operaționale. Colectarea informațiilor de securitate
interne și externe. Stabilirea unei structuri organizaționale de securitate cu roluri și responsabilități
bine concepute. Respectarea cerințelor de reglementare privind Securitatea Informației.
Facilitarea investigațiilor în fraudele IT și măsuri de atenuare
Manager de risc pentru securitatea informațiilor (ISRM)
ISRM deține ciclul de viață al managementului riscului în ceea ce privește securitatea

informațiilor. El asistă CISO prin descărcarea următoarelor.
Evaluarea riscurilor de securitate a informațiilor
Analiza și evaluarea riscurilor de securitate a informațiilor
Atenuarea riscurilor de securitate a informațiilor
Identificarea și atribuirea controalelor.
Managementul riscului de securitate a informațiilor
Respectarea Ghidurilor de management al riscului de securitate a informațiilor – Monitorizare
externă și internă Implementarea politicii de securitate a informațiilor
Manager de conștientizare a securității informațiilor (ISAM)
ISAM este responsabil pentru creșterea nivelurilor de conștientizare a securității informațiilor și

pentru eforturile de a crea un mediu propice și o cultură de conformitate în întreaga bancă. Se
așteaptă să se țină la curent cu cele mai recente evoluții în domeniul Standardelor de Securitate
Informațională și al celor mai bune practici, astfel încât să poată fi luate măsuri proactive pentru
adoptarea acestora, ori de câte ori este posibil și aplicabil în bancă, cât mai curând. Este un prieten,
filosof și ghid al întregii bănci, în ceea ce privește educația și conștientizarea în domeniul
Securității Informaționale. Politica de securitate a informațiilor – Intrări și îmbunătățiri
Măsurarea și monitorizarea eficacității implementării politicii de securitate a informațiilor.
Educație, conștientizare și promovare a inițiativelor de securitate a informațiilor în cadrul băncii.
Instruire intensivă de diferite tipuri și pentru diferite niveluri privind Securitatea Informației
Promovarea educației și conștientizării clienților cu privire la securitatea informațiilor prin canale,
instrumente și intervenții adecvate.
Diseminarea proactivă a inițiativelor, mecanismelor și bunelor practici ale politicii de securitate a
informațiilor
– o bază de resurse de tutoriale online, demonstrații, chestionare și întrebări frecvente pe Intranet
pentru acces ușor în cadrul băncii.
Centrul de operațiuni de securitate și managementul incidentelor (SOCIM)
Directorul SOCIM este responsabil pentru supravegherea eficientă a Centrului de operațiuni de

securitate și a capabilităților de gestionare a incidentelor pentru bancă în ansamblu. Poziția și
statutul de securitate sunt demonstrate de acest funcționar.
Responsabilitati:
Proprietar al Centrului de operațiuni de securitate la nivelul întregii bănci (SOC)
Proprietar al managementului incidentelor la nivel de bancă.

Responsabil pentru crearea, instruirea și modernizarea echipelor de răspuns la incidente din cadrul
băncii la diferite niveluri.
Supravegherea continuă a infrastructurii IT a băncii pentru a se proteja împotriva încălcărilor și
incidentelor de securitate a informațiilor: IT și non-IT.
Responsabil cu monitorizarea și revizuirea jurnalelor de securitate ale aplicațiilor, sistemelor de
operare, bazelor de date, rețelelor etc.
Demonstrând robustețea și îmbunătățirea atât de necesare în mediul de conformitate cu securitatea
informațiilor și pregătirea pentru a face față eventualităților.

Fiind la curent cu schimbările rapide ale tehnologiei și procesului de afaceri pentru a face ca SOC
să fie la înălțimea cerințelor tot mai mari din interior și din exterior.
Testare regulată de penetrare, evaluarea vulnerabilităților și legătura cu CERT local.
Responsabil pentru colectarea, agregarea, corelarea, analiza și sinteza informațiilor legate de
incidentele de securitate pentru a învăța lecții eficiente și pentru a încorpora schimbările în politici
și proceduri în mod corespunzător în mod continuu.
Securitate organizațională
Politica de securitate este o definiție a ceea ce înseamnă a fi sigur pentru un sistem , organizație
sau altă entitate. Pentru o organizație, abordează constrângerile asupra comportamentului
membrilor săi, precum și constrângerile impuse adversarilor prin mecanisme precum uși,
încuietori, chei și pereți. Pentru sisteme, politica de securitate abordează constrângerile asupra
funcțiilor și fluxul dintre acestea, constrângerile privind accesul de către sisteme externe și
adversari, inclusiv programe și accesul la date de către oameni.
Politica organizațională
O politică de securitate este de așteptat să facă multe lucruri. În primul rând, ar trebui să protejeze
oamenii și informațiile, precum și să stabilească regulile pentru comportamentul așteptat al
utilizatorilor, administratorilor de sistem, personalului de conducere și de securitate. De asemenea,
ar trebui să autorizeze personalul relevant să monitorizeze, să cerceteze, să investigheze, să
definească și să autorizeze consecințele încălcărilor, pe lângă definirea poziției de bază a
companiei cu privire la securitate. Acest lucru poate ajuta la minimizarea riscurilor și la urmărirea
conformității cu reglementările corespunzătoare.
Acest lucru este în regulă în teorie, dar după cum au demonstrat cazuri recente recente, politicile
scrise nu înseamnă întotdeauna că oamenii le urmează
Politica de securitate a informațiilor (ISP) este un set de reguli adoptate de o organizație pentru a
se asigura că toți utilizatorii sau rețelele structurii IT din domeniul organizației respectă
prescripțiile privind securitatea datelor stocate digital în limitele în care organizația își întinde
autoritatea.
Un ISP guvernează protecția informațiilor, care este unul dintre multele active pe care trebuie să le
protejeze o corporație. Prezenta scriere va discuta unele dintre cele mai importante aspecte pe care
o persoană ar trebui să le ia în considerare atunci când are în vedere dezvoltarea unui ISP. Punând
la lucru argumentele logice ale raționalizării, s-ar putea spune că o politică poate fi atât de largă pe
cât își doresc creatorii: practic, totul de la A la Z în ceea ce privește securitatea IT și chiar mai
mult. Din acest motiv, aici se pune accent pe câteva elemente cheie, dar ar trebui să țineți cont de
libertatea pe care o au organizațiile de gândire atunci când își creează propriile linii directoare.
2 Elemente ale politicii de securitate a informațiilor
2.1 Scop
Instituțiile creează furnizori de servicii de internet din mai multe motive:
• Pentru a stabili o abordare generală a securității informațiilor

• Pentru a detecta și a preveni compromisul securității informațiilor, cum ar fi utilizarea
greșită a datelor, rețelelor, sistemelor informatice și aplicațiilor.
• Pentru a proteja reputația companiei în ceea ce privește responsabilitățile sale etice și
legale.
• Să respecte drepturile clienților; O modalitate de a atinge acest obiectiv este furnizarea de

mecanisme eficiente de răspuns la plângeri și întrebări privind neconformitățile reale sau
percepute cu politica.
2.2 Domeniul de aplicare
ISP-ul ar trebui să se adreseze tuturor datelor, programelor, sistemelor, facilităților, altor

infrastructuri tehnologice, utilizatorilor tehnologiei și terților dintr-o anumită organizație, fără
excepție.
2.3 Obiectivele de securitate a informațiilor

O organizație care se străduiește să compună un ISP funcțional trebuie să aibă obiective bine
definite privind securitatea și strategia asupra cărora managementul a ajuns la un acord. Orice
disonanțe existente în acest context pot face ca proiectul politicii de securitate a informațiilor să fie
disfuncțional. Cel mai important lucru pe care un profesionist în securitate ar trebui să-l amintească
este că cunoașterea practicilor de management al securității i-ar permite să le încorporeze în
documentele pe care i-a fost încredințat să le redacteze și aceasta este o garanție pentru
completitudine, calitate și funcționalitate.
Simplificarea limbajului politicilor este un lucru care poate atenua diferențele și poate garanta
consensul în rândul personalului de conducere. În consecință, expresiile ambigue trebuie evitate.
Atenție, de asemenea, la sensul corect al termenilor sau cuvintelor uzuale. De exemplu, „trebuie”
exprimă negociabilitatea, în timp ce „trebuie” denotă un anumit nivel de discreție. În mod ideal,
politica ar trebui formulată pe scurt la obiect. Redundanța formulării politicii (de exemplu,
repetarea inutilă în scris) ar trebui evitată, deoarece ar face documentele lungi și desincronizate, cu
ilizibilitate care îngreunează evoluția. În cele din urmă, tone de detalii pot împiedica conformitatea
completă la nivel de politică.
Deci, modul în care managementul vede securitatea IT pare să fie unul dintre primii pași atunci
când o persoană intenționează să aplice noi reguli în acest departament. În plus, un profesionist în
securitate ar trebui să se asigure că ISP-ul are o gravitate instituțională egală ca și alte politici
adoptate în cadrul corporației. În cazurile în care o organizație are o structură considerabilă,
politicile pot diferi și, prin urmare, pot fi separate pentru a defini tranzacțiile în subsetul vizat al
acestei organizații.
Securitatea informațiilor este considerată a proteja trei obiective principale:
• Confidențialitate – datele și activele informaționale trebuie să fie limitate la

persoanele autorizate să acceseze și să nu fie dezvăluite altora;
• Integritate – menținerea datelor intacte, complete și exacte și a sistemelor IT
operaționale;
•Disponibilitate – un obiectiv care indică faptul că informațiile sau sistemul sunt

la dispoziția utilizatorilor autorizați atunci când este necesar.
Donn Parker, unul dintre pionierii în domeniul securității IT, a extins această paradigmă triplă,
sugerând și „autenticitate” și „utilitate”.
Încredere în nticlitate Integritate

Calculator
-- Securitate ___________________________eu eu
+ Autenticitate + Utilitate
Ava ilubi I it y
2.4 Politica de autoritate și control al accesului
De obicei, o politică de securitate are un model ierarhic. Înseamnă că personalul inferior este, de
obicei, obligat să nu împărtășească cantitatea mică de informații pe care o deține decât dacă este
autorizat în mod explicit. În schimb, un manager superior poate avea suficientă autoritate pentru a
lua o decizie ce date pot fi partajate și cu cine, ceea ce înseamnă că acestea nu sunt legate de
aceiași termeni de politică de securitate a informațiilor. Deci, logica cere ca ISP-ul să abordeze
fiecare poziție de bază din organizație cu specificații care să clarifice statutul lor de autoritate.
Rafinarea politicii are loc concomitent cu definirea controlului administrativ sau, cu alte cuvinte,
autoritatea pe care o au oamenii din organizație. În esență, este o delegare a controlului bazată pe
ierarhie, în care cineva poate avea autoritate asupra propriei lucrări, managerul de proiect are
autoritate asupra fișierelor de proiect aparținând unui grup în care este numit, iar administratorul de
sistem are autoritate numai asupra fișierelor de sistem - o structură care amintește de doctrina
separării puterilor. Evident, un utilizator poate avea „nevoia de a cunoaște” pentru un anumit tip de
informații. Prin urmare, datele trebuie să aibă un atribut de granularitate suficient pentru a permite
accesul autorizat corespunzător. Aceasta este linia subțire de găsire a echilibrului delicat între
permiterea accesului celor care trebuie să folosească datele ca parte a muncii lor și refuzul acestora
unor entități neautorizate.
Accesul la rețeaua și serverele companiei, indiferent dacă este sau nu în sensul fizic al cuvântului,
ar trebui să se facă prin login-uri unice care necesită autentificare fie sub formă de parole, date
biometrice, cărți de identitate sau jetoane etc. Monitorizarea pe toate sistemele trebuie
implementată pentru a înregistra încercările de conectare (atât cele reușite, cât și eșecurile) și data
și ora exactă de conectare și deconectare.
Apropo de evoluție la punctul anterior – pe măsură ce programul de securitate IT se maturizează,

politica poate necesita actualizare. Deși acest lucru nu va echivala neapărat cu îmbunătățirea
securității, este totuși o recomandare sensibilă.
2.5 Clasificarea datelor

Datele pot avea o valoare diferită. Gradările în indicele valoric pot impune separare și
regimuri/proceduri specifice de manipulare pentru fiecare fel. Prin urmare, un sistem de clasificare
a informațiilor poate reuși să acorde atenție protecției datelor care au o importanță semnificativă
pentru organizație și să lase deoparte informații nesemnificative care altfel ar suprasolicita
resursele organizației. Politica de clasificare a datelor poate aranja întregul set de informații după
cum urmează:
1. Clasa de risc ridicat – datele protejate de legislația statală și federală (Legea privind
protecția datelor, HIPAA, FERPA), precum și cele financiare, de salarizare și de personal
(cerințele de confidențialitate) sunt incluse aici.
2. Clasă confidențială – datele din această clasă nu se bucură de privilegiul de a fi sub aripa
legii, dar proprietarul datelor consideră că acestea ar trebui protejate împotriva dezvăluirii
neautorizate.
3. Clasă Publică – Aceste informații pot fi distribuite gratuit.
Proprietarii de date ar trebui să stabilească atât clasificarea datelor, cât și măsurile exacte pe care
trebuie să le ia un custode de date pentru a păstra integritatea în conformitate cu acel nivel.
2.6 Suport de date și operațiuni

În această parte am putea găsi clauze care stipulează:
. Reglementarea mecanismelor generale de sistem responsabile cu protecția datelor

• Salvarea datelor
• Mișcarea datelor
2.7 Sesiuni de conștientizare a securității
Partajarea politicilor de securitate IT cu personalul este un pas critic. A-i face să citească și să
semneze pentru a recunoaște un document nu înseamnă neapărat că sunt familiarizați și înțeleg
noile politici. O sesiune de instruire ar implica angajații într-o atitudine pozitivă față de securitatea
informațiilor, ceea ce va asigura că aceștia obțin o noțiune despre procedurile și mecanismele
existente pentru a proteja datele, de exemplu, nivelurile de confidențialitate și problemele de
sensibilitate a datelor. O astfel de formare de conștientizare ar trebui să abordeze o gamă largă de
subiecte vitale: cum să colectați/utilizați/ștergeți datele, menținerea calității datelor, gestionarea
înregistrărilor, confidențialitatea, confidențialitatea, utilizarea adecvată a sistemelor IT, utilizarea
corectă a rețelelor sociale etc. Un mic test la sfârșit este poate o idee bună.
2.8 Responsabilitățile, Drepturile și Îndatoririle Personalului

Considerațiile generale în această direcție se îndreaptă către responsabilitatea persoanelor
desemnate să efectueze implementarea, educarea, răspunsul la incident, revizuirea accesului
utilizatorilor și actualizările periodice ale unui ISP.
Prevenirea furtului, know-how-ul în informații și secretele industriale de care ar putea beneficia

concurenții sunt printre cele mai invocate motive pentru care o afacere ar putea dori să angajeze un
ISP pentru a-și apăra activele digitale și drepturile intelectuale.
2.9 Trimitere la legislația relevantă

1. Legislație
[Organizația] trebuie să respecte următoarea legislație, dar nu poate fi limitată la
domeniul de aplicare al acestei liste:
• Legea privind utilizarea abuzivă a computerelor (1990)

• Legea privind protecția datelor (1998)
• Ordinul privind protecția datelor (prelucrarea datelor cu caracter personal
sensibile) (2000)
• Legea privind drepturile de autor, modelele și brevetele (1988)
• Legea privind utilizarea abuzivă a computerelor (1990)
• Legea privind sănătatea și securitatea în muncă (1974)
• Telecomunicațiile (practica comercială legală) (interceptarea
• Comunicații) Regulamente (2000)
• Legea defăimării (1996)
• Legea economiei digitale (2010)
• Legea drepturilor omului (1998)
• Legea privind reglementarea competențelor de investigare (2000)
• Legea privind publicațiile obscene (1959)
• Legea privind libertatea de informare (2000)
• Legea privind sănătatea și asistența socială (2001)
2.10 Alte elemente pe care un ISP le poate include:

Procedura de protecție împotriva virușilor, Procedura de detectare a intruziunilor, Procedura de lucru la distanță,
Orientări tehnice, Audit, Cerințe pentru angajați, Consecințe pentru neconformitate, Acțiuni disciplinare, Angajații
concediați, Securitatea fizică a IT, Referințe la documente justificative și așa mai departe.
SECTORUL BANCAR
Rezerva Bank of India a emis noi îndrumări în aprilie 2011 pentru bănci pentru a reduce
riscurile utilizării tehnologiei informației în operațiunile bancare. Orientările RBI sunt rezultatul
recomandărilor Grupului de lucru privind securitatea informațiilor, banca electronică,
managementul riscului tehnologic și frauda cibernetică. Grupul de lucru a fost format sub
președinția lui G. Gopalakrishna, directorul executiv al RBI în aprilie 2010.
Îndrumarea este în mare măsură determinată de nevoia de a atenua amenințările cibernetice care
apar din adoptarea tot mai mare a IT de către băncile comerciale din India.
Recomandările sunt făcute în nouă domenii largi, inclusiv:

1. Guvernanța IT: accentuează responsabilitatea de gestionare a riscurilor IT în consiliul de

administrație și conducerea executivă a unei bănci. Accentul include crearea unei structuri
organizaționale și a unui proces pentru a se asigura că securitatea IT a unei bănci susține și extinde
strategiile și obiectivele de afaceri.
2. Securitatea informațiilor: menținerea unui cadru care să ghideze dezvoltarea unui program
cuprinzător de securitate a informațiilor, care include formarea unei funcții separate de securitate a
informațiilor care să se concentreze exclusiv pe securitatea informațiilor și managementul
riscurilor, distinct de activitățile unui departament de tehnologie a informației. Aceste linii
directoare specifică faptul că responsabilul șef cu securitatea informațiilor trebuie să raporteze
direct șefului managementului riscurilor și nu ar trebui să aibă o relație de raportare directă cu
responsabilul cu informațiile șef.
3. Operațiuni IT: capabilități organizaționale specializate care oferă valoare clienților, inclusiv
managementul serviciilor IT, managementul infrastructurii, managementul ciclului de viață al
aplicațiilor și cadrul de risc pentru operațiunile IT.
4. Outsourcing de servicii IT: plasează responsabilitatea finală pentru operațiunile de
externalizare și gestionarea riscului inerent în astfel de relații în consiliul de administrație și
conducerea superioară. Accentul include selecția eficientă a furnizorului de servicii, monitorizarea
și controlul activităților externalizate și evaluarea și managementul riscurilor.
5. Auditul securității informațiilor: necesitatea băncilor de a reevalua procesele de audit SI și
de a se asigura că acestea oferă o viziune independentă și obiectivă asupra măsurii în care riscurile
sunt gestionate. Acest subiect se concentrează pe definirea rolurilor și responsabilităților părților
interesate din auditul SI și pe planificarea și execuția auditului.
6. Frauda cibernetică: definește necesitatea unui cadru la nivel de industrie privind guvernarea
fraudei, cu accent deosebit pe combaterea fraudelor bazate pe canale electronice. Accentul include
crearea unei structuri organizaționale pentru managementul riscului de fraudă și a unui comitet
special pentru monitorizarea fraudei cu valoare mare.
7. Planificarea continuității afacerii : se concentrează pe politici, standarde și proceduri pentru
a asigura continuitatea, reluarea și recuperarea proceselor critice de afaceri. De asemenea, acest
subiect pune accent pe implementarea unui cadru pentru a minimiza consecințele operaționale,
financiare, juridice, reputaționale și alte consecințe materiale care decurg dintr-un astfel de
dezastru.
8. Educația clienților: necesitatea de a implementa un cadru și programe de conștientizare a
consumatorilor cu privire la o varietate de probleme legate de fraudă.
9. Probleme juridice: definește necesitatea de a pune în aplicare procese eficiente pentru a se
asigura că riscurile juridice care decurg din legile cibernetice sunt identificate și abordate la bănci.
De asemenea, se concentrează pe consultarea consiliului de administrație cu departamentul juridic
cu privire la pașii de atenuare a riscurilor de afaceri în cadrul băncii.
Guvernarea securității
Guvernanța securității este mijlocul prin care controlați și direcționați abordarea organizației
dumneavoastră cu privire la securitate. Când este făcută bine, guvernarea securității va
coordona eficient activitățile de securitate ale organizației dumneavoastră. Permite fluxul de
informații și decizii de securitate în jurul organizației dvs.
Așa cum securitatea este responsabilitatea tuturor din cadrul unei organizații, luarea deciziilor
de securitate poate avea loc la toate nivelurile . Pentru a realiza acest lucru, conducerea
superioară a unei organizații ar trebui să utilizeze guvernanța securității pentru a stabili tipurile
de riscuri de securitate pe care sunt pregătiți să le asume personalul și pe cele pe care nu sunt.
Funcția de securitate și guvernanță IT include asigurarea, stabilirea și aplicarea politicilor,
standardelor și procedurilor de securitate. Managerii de securitate IT monitorizează continuu
toate componentele infrastructurii IT pentru amenințări de conformitate și securitate și iau
măsurile de remediere corespunzătoare. Ei efectuează, de asemenea, analize și evaluări ale
riscurilor IT și apoi se asigură că există soluții pentru a atenua riscurile. Un cadru de
guvernanță stabilit pentru a gestiona toate activitățile legate de guvernanța, riscul și
conformitatea IT (IT-GRC) le permite profesioniștilor în securitate IT să gestioneze guvernanța
IT, politica IT, riscul IT, conformitatea IT, auditul IT și incidentele într-o manieră integrată.
Guvernanța securității întreprinderii este strategia unei companii pentru reducerea riscului
de acces neautorizat la sistemele și datele tehnologice ale informațiilor.
Activitățile de guvernare a securității întreprinderii implică dezvoltarea, instituționalizarea,

evaluarea și îmbunătățirea politicilor https://searchcio.techtarget.com/definition/enterprise-risk-
managementde securitate și managementul riscurilor întreprinderii ( ERM ) ale unei
organizații. Guvernarea securității întreprinderii include determinarea modului în care diferite
unități de afaceri, personal, directori și personal ar trebui să lucreze împreună pentru a proteja
activele digitale ale unei organizații, pentru a asigura prevenirea pierderii de date și pentru a
proteja reputația publică a organizației.
Activitățile de guvernare a securității întreprinderii ar trebui să fie în concordanță cu cerințele

de conformitate , cultura și politicile de management ale organizației. Dezvoltarea și susținerea
guvernanței securității întreprinderii implică adesea efectuarea de teste de analiză a
amenințărilor, vulnerabilității și riscurilor care sunt specifice industriei companiei.
Guvernanța securității întreprinderii este strategia unei companii pentru a reduce șansele ca
activele fizice deținute de companie să poată fi furate sau deteriorate. În acest context,
guvernarea securității întreprinderii include bariere fizice, încuietori, garduri și sisteme de
răspuns la incendiu, precum și iluminat, sisteme de detectare a intruziunilor, alarme și camere.
SECURITATE FIZICĂ ȘI DE MEDIU
Este în general acceptat că, atunci când vine vorba de protejarea resurselor informaționale din
perspectivă fizică (adică în cazul în care protejăm bunuri tangibile pe care cineva le poate
atinge, lovi, fura, arunca etc.), numele jocului trebuie să fie despre a convinge făptuitorul că
costul, timpul și riscul descoperirii implicate în încercarea de acces neautorizat la informații
sau echipamente depășesc valoarea câștigurilor astfel realizate.
Securitatea fizică nu este un fenomen modern - există pentru a descuraja sau împiedica
persoanele neautorizate să intre într-o unitate fizică sau să fure ceva de valoare percepută.
Siguranța personalului nu trebuie trecută cu vederea în acest sens.
Puține s-au schimbat de-a lungul secolelor când vine vorba de protejarea proprietății, cu
uși/cufere încuiate, agenți de securitate înarmați, capcane etc.
Considerațiile de securitate fizică (la toate nivelurile de la corporativ la personal) ar trebui să

includă protecția împotriva efracției, furtului, vandalismului, vederii și, potențial, terorismului,
în funcție de locația dvs. și de ceea ce vă interesează! Cel mai bun în securitatea software-ului
nu valorează prea mult dacă cineva pleacă cu computerul sub braț!
În plus, amenințările pentru mediu includ incendii, inundații, dezastre naturale și contaminarea
din alimente/băuturi vărsate.
Următoarele oferă o scurtă prezentare generală a unora dintre opțiunile disponibile pentru
securizarea fizică și protejarea echipamentului și a datelor.
Asigurați-vă echipamentul informatic. (control preventiv)

Acest concept este, evident, unul dintre cele mai ușor de înțeles din lumea securității IT, dar
realizarea acestui lucru poate fi descurajantă. Cu toate acestea, problema fundamentală nu este
atât protejarea valorii intrinseci a computerului, ci CE INFORMAȚII SUNT STOCATE PE
ACEL COMPUTER SAU SUNT ACCESIBILE DE LA EL?
Puteți cumpăra oricând un kit nou și, probabil, cu o performanță semnificativ îmbunătățită
decât cea pe care ați avut-o înainte – OK, reducerea de asigurare fără daune ar putea avea un
pic de lovitura – dar pierderea unei mașini de înaltă performanță este puțin în comparație cu
pierderea datele valoroase de pe el sau, mai rău, agravate de pierderea confidențialității datelor
respective.
Pierderea informațiilor, în special a informațiilor despre clienți poate, poate duce, de

asemenea, la prejudicii reputației, litigii, costuri de recuperare/recreare a datelor... ce-i mai
spune.
Deci, în analiza dvs. de risc (dacă aveți una) pentru protejarea informațiilor, stivuiți evaluarea
impactului în raport cu datele, nu cu mașina.
Acestea fiind spuse, există măsuri sensibile de protecție fizică pe care le puteți lua:
· Păstrați dispozitivele neportabile (PC-uri, imprimante) în spații care pot fi încuiate

· Păstrați întotdeauna dispozitivele portabile (laptop-uri, telefoane inteligente,

tablete).
rază de protecție atunci când sunteți în mișcare
· Închideți echipamentele portabile în dulapuri peste noapte - nu le lăsați niciodată

la vedere
în orele de tăcere.
· Dacă aveți informații prețioase pe dispozitiv, faceți-le în mod regulat copii de

rezervă și stocați
copie de rezervă în siguranță
· Dacă este posibil, scoateți hard disk-ul și păstrați-l separat de dispozitiv
· Cu siguranță nu lăsați cheile USB introduse prea mult timp - sunt atât de mici
în zilele noastre s-ar putea să uiți că sunt acolo
· Utilizați o formă de criptare a punctelor finale pe dispozitivul dvs. care împiedică

apariția datelor
exportate
· Dacă utilizați o autentificare cu simbol, păstrați computerul/dispozitivul și

simbolul separat - nu
scrieți codul PIN al simbolului și păstrați-l împreună cu simbolul
· Nu lăsați echipamentele de calcul în mașină, încuiate sau nu - chiar dacă nu sunt

vizibile,
acesta ar fi un bonus major pentru ceea ce altfel ar fi un hoț de mașini obișnuit!
· Folosiți cabluri de blocare sigure acolo unde nu este disponibilă altă stocare sigură.
Țineți echipamentele de calcul departe de pericolele pentru mediu. (control preventiv)

Echipamentele de calcul, în special dispozitivele mobile, nu sunt doar amenințate de intenții
rău intenționate – ele suferă din când în când accidente, la fel ca multe dintre bunurile noastre!
Unele dintre controalele, cum ar fi realizarea de copii de siguranță ale datelor, eliminarea hard
disk-urilor, criptarea datelor etc. menționate în articolul anterior, sunt de asemenea relevante
aici, dar următoarele merită menționate:
· Transportați întotdeauna un laptop într-o geantă căptușită pentru laptop sau un

dispozitiv mai mic (de exemplu, tabletă
sau telefon inteligent) în carcasa sa de protecție - ambele vor merge mai bine dacă vor fi
scăpate.
· Când călătoriți cu un taxi, mai ales noaptea când partea din spate a cabinei este
întunecată sau
dacă dormiți într-un tren, țineți brațul sau piciorul prin cureaua genții pentru laptop (de
preferință blocată). În acest fel, dacă este smuls, măcar vei fi smuls cu el... și este mai puțin
probabil să-l lași în taxi din greșeală. (Se întâmplă!)
· Țineți băuturile departe de dispozitiv.
· Dacă utilizați o cameră de server, asigurați-vă cea mai adecvată prevenire/detecție

a incendiilor
sistemele sunt implementate – sprinklerele pe bază de apă pot salva clădirea, dar nu vor face
favoruri echipamentelor de calcul sau mediilor asociate.
Alarme sonore. (control descurajator)

Dispozitivele sonore pot fi montate pe carcasa computerului dvs. (sus), fie pe interior, fie pe
exterior, care, atunci când sunt deranjate, vor emite o sirenă puternică care va alerta pe oricine
la îndemână că ceva este furat. Nu va preveni furtul, dar ar trebui să descurajeze (sau cel puțin
să-l facă de rușine) pe răufăcător.
Dezavantajul acestora este că, în opinia scriitorului, ele pot suna spontan ca alarme false, ceea
ce poate duce în cel mai bun caz la iritare sau în cel mai rău caz ignorarea acesteia și nicio
măsură.
Sisteme de marcare. (control detectiv)

Echipamentul informatic care este marcat indelebil (și posibil invizibil) cu detalii adecvate,
cum ar fi un cod poștal, este destul de ușor și ieftin. Marcarea poate fi efectuată în diverse
moduri – sub formă de cleme metalice care se fixează cu un adeziv epoxidic puternic, printr-un
compus de gravare sau pur și simplu folosind un stilou de marcare UV.
Asociat cu aceasta, ar trebui să păstrați o înregistrare separată a numărului de serie al

producătorului echipamentului.
Se blochează unitatea de disc și portul USB. (control preventiv)

Pentru a vă proteja unitățile de utilizare greșită, există o gamă largă de soluții hardware care le
vor împiedica deloc să fie folosite fără cheie. Unele sunt mai puternice decât altele, iar unele
dintre ele au încuietori jalnice care pot fi forțate ușor cu o agrafă, dar dacă alegi una bună
poate fi extrem de eficientă.
Politica clară a biroului și a ecranului (control preventiv)

Un birou clar asigură că atunci când nu vă aflați la birou (în special în afara orelor de lucru)
documentele sensibile pe hârtie sunt blocate corespunzător și protejate împotriva accesului sau
copierii neautorizate. Amenințările variază de la cele de zi cu zi (de exemplu,
vizionarea/eliminarea de către terți, cum ar fi contractorii de curățenie) la cele dramatice (de
exemplu, explozie, suflarea ferestrelor și distribuirea documentelor în tot districtul).
Deși nu este un control fizic, strâns asociată cu acest concept este utilizarea parolelor de
economizor de ecran - întotdeauna, chiar și atunci când sunteți acasă, utilizați un timeout bazat
pe o perioadă scurtă de inactivitate a tastaturii - și asigurați-vă că poziționați monitorul în așa
fel încât pentru a preveni vizionarea ocazională sau „surfingul pe umăr”.
Când părăsiți biroul pentru o perioadă scurtă, acordați-vă timp pentru a ieși din și/sau a bloca
orice activitate sensibilă pe care o puteți face în cazul în care persoane „neautorizate” se
apropie de zona de lucru în timpul absenței dumneavoastră.
Nu uitați, de asemenea, când părăsiți sălile de ședințe, să ștergeți tablourile albe de orice
informații care nu ar trebui dezvăluite spectatorilor neautorizați.
Securitatea spațiilor (control preventiv și detectiv)

Securitatea spațiilor poate fi atât de complexă sau simplă, de costisitoare sau economică pe cât
doriți și destul de des eficacitatea poate fi indistinguită una de cealaltă.
Deci, să începem cu controale „simple” și „economice”:
· Încuietori la uși și ferestre (cu chei sub control adecvat)
· Ecusoane de identitate care trebuie purtate în orice moment
· Vizitatorii să fie găzduiți, însoțiți în orice moment... ei bine, aproape întotdeauna...

și
check-in și ieșit din incintă
· Păstrați o carte a vizitatorilor cu detalii despre nume, dată, cine este vizitat (sau
cine este
hosting), timpul de intrare/ieșire și, dacă este cazul, înmatricularea vehiculului. (NB. O carte
de vizitatori poate fi, de asemenea, esențială în cazul unei evacuări de urgență pentru a se
asigura că toți oamenii din incintă sunt luați în considerare)
· Educați personalul cu privire la securitatea incintelor – fără „adăpostire”;

provocarea străinilor etc
– și explicați motivul din spatele acestor reguli, de exemplu, poate fi pentru propria lor
siguranță.
O protecție mai sofisticată a spațiilor (ceea ce de obicei înseamnă mai scump) poate fi realizată
și cu:
· Sisteme electronice de recunoaștere a insignelor care deschid ușile și înregistrează

cine a fost
unde... dar asigurați-vă că nu setați sensibilitatea cititorului de insignă atât de mare încât să se
activeze pur și simplu când un purtător de insignă trece pe lângă!
· Dispozitivele „blocarea datelor” care necesită introducerea unui cod PIN – dar
codurile trebuie să fie
modificate periodic pentru a rămâne în vigoare
· CCTV – păstrați în siguranță un ciclu rezonabil de benzi, cum ar fi până la 2

săptămâni
· Senzori de mișcare care activează alarme sau lumini
· Bariere cu fascicul laser la interior sau la perimetru
Securitate hardware
Securitatea hardware este protecția împotriva vulnerabilităților care vine sub forma unui
dispozitiv fizic, mai degrabă decât sub forma unui software instalat pe hardware-ul unui sistem
informatic.
Securitatea hardware se poate referi la un dispozitiv utilizat pentru a scana un sistem sau
pentru a monitoriza traficul de rețea. Exemplele comune includ firewall-uri hardware și
servere proxy. Exemple mai puțin obișnuite includ modulele de securitate hardware ( HSM ),
care furnizează chei criptografice pentru funcții critice, cum ar fi criptarea , decriptarea și
autentificarea pentru diferite sisteme. Sistemele hardware pot oferi o securitate mai robustă
decât este capabilă software-ul și pot adăuga, de asemenea, un nivel suplimentar de securitate
pentru sistemele importante.
Termenul de securitate hardware se referă și la protecția sistemelor fizice împotriva

daunelor. Atacurile de distrugere a echipamentelor , de exemplu, se concentrează asupra
dispozitivelor de calcul și a dispozitivelor în rețea care nu sunt informatice, cum ar fi numărul
tot mai mare de dispozitive conectate în medii M2M sau IoT (Internet of Things). Aceste
medii aduc conectivitate și comunicații la un număr mare de dispozitive hardware care trebuie
protejate fie prin securitate bazată pe hardware, fie prin software.
Pentru a evalua securitatea unui dispozitiv hardware, este necesar să se ia în considerare

vulnerabilitățile existente din fabricarea acestuia, precum și alte surse potențiale, cum ar fi
codul de rulare și I/O de date ale dispozitivului într-o rețea. Deși orice dispozitiv ar trebui
protejat dacă se conectează chiar și indirect la internet, strictețea acestei protecție ar trebui să
fie în conformitate cu nevoia. Un sistem care controlează culoarea și intensitatea luminilor în
LED-ul Wi-Fi pentru o locuință, de exemplu, poate să nu necesite multă securitate.
Serverele utilizate în mod obișnuit sunt
Server web:
Un server web este un sistem care furnizează conținut sau servicii utilizatorilor finali prin
internet. Un server web constă dintr-un server fizic, sistem de operare pentru server (OS) și
software utilizat pentru a facilita comunicarea HTTP.
Un server web este cunoscut și ca server de internet

Cea mai simplă definiție este că un server web rulează un site web returnând fișiere HTML
printr-o conexiune HTTP. Este posibil ca această definiție să fi fost adevărată în primele zile ale
internetului, dar linia dintre site-uri web, aplicații web și servicii web s-a estompat etc. De
exemplu, un server care livrează un document XML către un alt dispozitiv poate fi un server
web. O definiție mai bună ar putea fi aceea că un server web este orice server de internet care
răspunde la solicitările HTTP pentru a furniza conținut și servicii.
Server de e-mail:
Un server de e-mail (uneori denumit și un server de e-mail) este un server care gestionează și
livrează e-mailul printr-o rețea, de obicei prin Internet. Un server de e-mail poate primi e-mailuri
de la computerele client și le poate livra altor servere de e-mail. Un server de e-mail poate livra,
de asemenea, e-mail-uri către computerele client. Un computer client este, de obicei, computerul
pe care îți citești e-mailurile, de exemplu computerul de acasă sau de la birou. De asemenea, un
telefon mobil avansat sau Smartphone, cu capabilități de e-mail, poate fi privit ca un computer
client în aceste circumstanțe.
Server de e-mail
Rapoarte și diagrame
Server de fișiere: serverul de fișiere (sau serverul de fișiere) este un computer atașat la o rețea
care oferă o locație pentru accesul la disc partajat , adică stocarea partajată a fișierelor
computerului (cum ar fi text, imagine, sunet, video) care pot fi accesate de stațiile de lucru care
sunt capabili să ajungă la computerul care partajează accesul printr-o rețea de calculatoare.
Termenul server evidențiază rolul mașinii în schema client-server , unde clienții sunt stațiile de
lucru care utilizează stocarea. Este obișnuit ca un server de fișiere să nu efectueze sarcini de
calcul și să nu execute programe în numele clienților săi. Este conceput în primul rând pentru a
permite stocarea și preluarea datelor în timp ce calculul este efectuat de stațiile de lucru.
Serverele de fișiere se găsesc de obicei în școli și birouri, unde utilizatorii folosesc o rețea LAN
pentru a-și conecta computerele client.
Server de imprimare:
Un server de imprimare este un computer care poate procesa lucrări legate de imprimare pe o rețea
de computere. Serverele de imprimare sunt conectate la o rețea de computere pentru a satisface
nevoia de lucrări de imprimare într-o rețea care poate conține mai multe imprimante. Un server de
imprimare permite, de obicei, utilizatorilor dintr-o rețea de calculatoare să efectueze o lucrare de
imprimare fără a fi nevoie să mute fișiere pe computerul conectat direct la imprimantă. Cunoscut și
ca server de imprimantă sau imprimantă de rețea, (deși aceasta din urmă este de fapt una dintre
proprietățile server de imprimare).
Server de rețea
Un server de rețea este un computer conceput să acționeze ca depozit central și să ajute la

furnizarea de diverse resurse, cum ar fi accesul hardware, spațiul pe disc, accesul la imprimantă etc.
către alte computere din rețea.
Este posibil ca un server de rețea să nu difere de o stație de lucru din punct de vedere hardware, dar
funcționalitatea pe care o realizează îl diferențiază în mod clar de alte stații de lucru. Serverele de
rețea ajută la simplificarea diferitelor sarcini pentru administratorii de sistem, inclusiv cele centrate
pe management.
Orice actualizări de configurare sau de securitate pot fi aplicate unui server de rețea în loc să fie
transferate individual la diferite computere conectate la rețea.
Factori care influențează alegerea utilizării unui server de rețea:
• Numărul de utilizatori în rețea.

• Clasificarea rețelei utilizate.
• Planuri de creștere a afacerii, dacă există.
Caracteristici ale serverelor de rețea:
• Calculatoarele sunt prevăzute cu mai multă memorie și capacitate de stocare și, de asemenea,
sunt configurate pentru a face procesări suplimentare pentru a gestiona diferitele solicitări ale
clienților.
• Mașinile sunt de obicei computere personale cu performanțe ridicate, cu hard disk-uri fiabile și
rapide, procesoare puternice și cantități mari de memorie RAM disponibilă.
• Poate acționa și ca unitate centrală de stocare a fișierelor. Acest lucru poate împiedica stocarea
datelor în diferite stații de lucru din rețea.
• Autentificarea și controlul utilizatorului pot fi setate pe o altă stație de lucru folosind un server
de rețea.
• Măsurile de control al securității pot fi mai convenabile de gestionat folosind un server de
rețea.
• Serverul de rețea este, de asemenea, capabil să ruleze un intranet.
• Unele dintre exemplele comune de servere de rețea sunt serverele FTP și serverele web.
Server de baze de date

Termenul server de baze de date se poate referi atât la hardware, cât și la software utilizat pentru a
rula o bază de date, în funcție de context. Ca software, un server de baze de date este partea de
back-end a unei baze de date
aplicație, după modelul tradițional client-server. Această porțiune de back-end este uneori numită
instanță. Se poate referi și la computerul fizic utilizat pentru a găzdui baza de date. Când este
menționat în acest context, serverul de baze de date este de obicei un computer dedicat de ultimă
generație care găzduiește baza de date.
Rețineți că serverul bazei de date este independent de arhitectura bazei de date. Baze de date
relaționale, fișiere plate, baze de date non-relaționale: toate aceste arhitecturi pot fi găzduite pe
servere de baze de date.
Modem
Un modem este un dispozitiv de rețea care atât modulează, cât și demodulează semnalele
purtătoare analogice (numite unde sinusoidale) pentru codificarea și decodificarea informațiilor
digitale pentru procesare. Modemurile îndeplinesc ambele aceste sarcini simultan și, din acest
motiv, termenul modem este o combinație de „modula” și „demodulează”.
Repetitor
Un repetor este un dispozitiv de rețea care retransmite un semnal recepționat cu mai multă putere
și către o limită de rețea geografică sau topologică extinsă decât ceea ce ar fi capabil cu semnalul
original.
Intrerupator
Un comutator, în contextul rețelei, este un dispozitiv de mare viteză care primește pachetele de
date primite și le redirecționează către destinația lor într-o rețea locală (LAN). Un comutator LAN
operează la nivelul de legătură de date (Layer 2) sau la nivelul de rețea al modelului OSI și, ca
atare, poate suporta toate tipurile de protocoale de pachete.
Poarta de acces
În rețelele de calculatoare și telecomunicațiile, un gateway este o componentă care face parte din
două rețele, care utilizează protocoale diferite. Gateway-ul va traduce un protocol în celălalt. Un
router este un caz special de gateway.
Gateway-urile, numite și convertoare de protocol, pot funcționa la orice nivel de rețea. Activitățile
unui gateway sunt mai complexe decât cele ale routerului sau comutatorului, deoarece comunică
folosind mai mult de un protocol.
Atât computerele utilizatorilor de internet , cât și computerele care deservesc pagini utilizatorilor
sunt noduri gazdă . Nodurile care conectează rețelele dintre acestea sunt gateway-uri . Acestea
sunt noduri gateway:
• calculatoarele care controlează traficul dintre rețelele companiei
• computerele utilizate de furnizorii de servicii de internet (ISP) pentru a conecta utilizatorii
la internet
VSAT (Terminal cu deschidere foarte mică)
VSAT (Very Small Aperture Terminal) este un sistem de comunicații prin satelit care servește
utilizatorilor casnici și de afaceri. Un utilizator final VSAT are nevoie de o cutie care să facă
interfață între computerul utilizatorului și o antenă exterioară cu un transceiver . Transponderul
primește sau trimite un semnal către un transponder satelit pe cer. Satelitul trimite și primește
semnale de la un computer al stației terestre care acționează ca un hub pentru sistem. Fiecare
utilizator final este interconectat cu stația hub prin satelit într-o topologie în stea. Pentru ca un
utilizator final să comunice cu altul, fiecare transmisie trebuie să meargă mai întâi la stația hub
care o retransmite prin satelit către VSAT-ul celuilalt utilizator final. VSAT gestionează semnalele
de date, voce și video.
VSAT este folosit atât de utilizatorii casnici care se înscriu la un serviciu mare, cum ar fi DirecPC,
cât și de companiile private care operează sau închiriază propriile sisteme VSAT. VSAT oferă o
serie de avantaje față de alternativele terestre. Pentru aplicațiile private, companiile pot avea
control total asupra propriului sistem de comunicații fără a depinde de alte companii. Utilizatorii
de afaceri și cei casnici beneficiază, de asemenea, de recepție cu viteză mai mare decât dacă
folosesc serviciul telefonic obișnuit sau ISDN .
SOFTWARE & SECURITATE OPERAȚIONALĂ
SECURITATE OPERAȚIONALĂ
Securitatea operațională (OPSEC), cunoscută și sub denumirea de securitate procedurală, este
un proces de gestionare a riscurilor care încurajează managerii să vadă operațiunile din
perspectiva unui adversar pentru a proteja informațiile sensibile împotriva căderii în mâini
greșite.
Deși folosit inițial de armată , OPSEC devine popular și în sectorul privat. Lucrurile care intră
sub umbrela OPSEC includ monitorizarea comportamentelor și obiceiurilor pe site-urile de
rețele sociale , precum și descurajarea angajaților de a partaja acreditările de conectare prin e-
mail sau mesaj text.
CEI CINCI ETAPE ALE SECURITATII OPERAȚIONALE
Procesele implicate în securitatea operațională pot fi clasificate în cinci pași:
1. Identificați datele dvs. sensibile , inclusiv cercetarea produsului, proprietatea intelectuală,

situațiile financiare, informațiile despre clienți și informații despre angajați. Acestea vor fi
datele de care veți avea nevoie pentru a vă concentra resursele asupra protejării.
1. Identificați posibilele amenințări. Pentru fiecare categorie de informații pe care o
considerați sensibilă, ar trebui să identificați ce tipuri de amenințări sunt prezente. Deși ar
trebui să fiți atenți la terți care încearcă să vă fure informațiile, ar trebui să fiți atenți și la
amenințările interne, cum ar fi angajații neglijenți și lucrătorii nemulțumiți.
2. Analizați găurile de securitate și alte vulnerabilități. Evaluați-vă garanțiile actuale și
determinați care există, dacă există, lacune sau puncte slabe care pot fi exploatate pentru a
obține acces la datele dvs. sensibile.
3. Evaluați nivelul de risc asociat cu fiecare vulnerabilitate. Clasați-vă vulnerabilitățile
utilizând factori precum probabilitatea ca un atac să se producă, amploarea daunelor pe care
le-ați suferi și cantitatea de muncă și timpul de care aveți nevoie pentru a vă recupera. Cu cât
un atac este mai probabil și mai dăunător, cu atât mai mult ar trebui să acordați prioritate
diminuării riscului asociat.
4. Luați contramăsuri. Ultimul pas al securității operaționale este crearea și implementarea
unui plan pentru eliminarea amenințărilor și atenuarea riscurilor. Aceasta ar putea include
actualizarea hardware-ului, crearea de noi politici privind datele sensibile sau instruirea
angajaților cu privire la practicile de securitate și politicile companiei. Contramăsurile ar trebui
să fie directe și simple. Angajații ar trebui să poată implementa măsurile necesare din partea
lor cu sau fără pregătire suplimentară.
BUNE PRACTICI PENTRU SECURITATEA OPERAȚIONALĂ
Urmați aceste bune practici pentru a implementa un program de securitate operațional robust
și cuprinzător:
• Implementați procese precise de management al schimbărilor pe care angajații dvs. ar

trebui să le urmeze atunci când sunt efectuate modificări în rețea. Toate modificările ar trebui
să fie înregistrate și controlate, astfel încât să poată fi monitorizate și auditate.
• Restricționați accesul la dispozitivele din rețea folosind autentificarea AAA . În armată
și alte entități guvernamentale, o bază de „necesitate de a cunoaște” este adesea folosită ca
regulă generală în ceea ce privește accesul și partajarea informațiilor.
• Oferiți angajaților dvs. accesul minim necesar pentru a-și îndeplini sarcinile. Practicați
principiul cel mai mic privilegiu .
• Implementați controlul dublu. Asigurați-vă că cei care lucrează în rețeaua dvs. nu sunt
aceleași persoane responsabile cu securitatea .
Securitate software
Securitatea software este o idee implementată pentru a proteja software-ul împotriva atacurilor rău
intenționate și a altor riscuri ale hackerilor, astfel încât software-ul să continue să funcționeze
corect sub astfel de riscuri potențiale. Securitatea este necesară pentru a oferi integritate,
autentificare și disponibilitate.
Orice compromis asupra integrității, autentificării și disponibilității face ca un software să nu fie
sigur. Sistemele software pot fi atacate pentru a fura informații, pentru a monitoriza conținutul,
pentru a introduce vulnerabilități și pentru a deteriora comportamentul software-ului. Programele
malware pot provoca DoS (denial of service) sau pot prăbuși sistemul în sine.
Buffer overflow, stack overflow, injectarea de comandă și injecțiile SQL sunt cele mai frecvente
atacuri asupra software-ului.
Atacurile buffer și stack overflow suprascrie conținutul heap-ului sau, respectiv, stivei prin
scrierea de octeți suplimentari.
Injecția de comandă poate fi realizată pe codul software atunci când comenzile de sistem sunt
utilizate în mod predominant. Noile comenzi de sistem sunt atașate comenzilor existente prin
atacul rău intenționat. Uneori, comanda de sistem poate opri serviciile și poate cauza DoS.
Injecțiile SQL folosesc cod SQL rău intenționat pentru a prelua sau modifica informații importante
de pe serverele de baze de date. Injecțiile SQL pot fi folosite pentru a ocoli datele de conectare.
Uneori, injecțiile SQL preiau informații importante dintr-o bază de date sau șterg toate datele
importante dintr-o bază de date.
Singura modalitate de a evita astfel de atacuri este practicarea unor tehnici bune de programare.
Securitatea la nivel de sistem poate fi asigurată folosind firewall-uri mai bune. Utilizarea detectării
și prevenirii intruziunilor poate ajuta, de asemenea, la oprirea atacatorilor de la accesul ușor la
sistem
Software-ul poate fi clasificat ca
1.Software de sistem
Software-ul de sistem este o platformă compusă din programe și servicii ale sistemului de operare
(OS), inclusiv setări și preferințe, biblioteci de fișiere și funcții utilizate pentru aplicațiile de
sistem. Software-ul de sistem include și drivere de dispozitiv care rulează hardware și periferice de
bază ale computerului.
Software-ul de sistem este rulat de sistemul de operare, comparativ cu utilizatorii finali. Deoarece
software-ul de sistem rulează în fundal la un nivel de bază, este considerat software de nivel
scăzut.
Exemplele de bază de software de sistem includ:
• Software utilitar
• Servere de sistem
• Drivere de dispozitiv
• Sistem de operare (OS)
• Sisteme Windows/interfață grafică cu utilizatorul (GUI).
2.Software de aplicație
Aplicația software este un program sau un grup de programe conceput pentru utilizatorii finali.
Aceste programe sunt împărțite în două clase: software de sistem și software de aplicație. În timp
ce software-ul de sistem constă din programe de nivel scăzut care interacționează cu computerele
la un nivel de bază, software-ul de aplicație se află deasupra software-ului de sistem și include
aplicații precum programe de bază de date, procesoare de text și foi de calcul. Aplicația software
poate fi inclusă cu software-ul de sistem sau publicat singur.
Aplicația software poate fi denumită pur și simplu o aplicație.
Diferite tipuri de aplicații software includ:
• Suite de aplicații: are mai multe aplicații combinate. Funcțiile, caracteristicile și interfețele de
utilizator conexe interacționează între ele.
• Software pentru întreprinderi: se adresează nevoilor unei organizații și fluxului de date într-un
mediu distribuit imens
• Software de infrastructură pentru întreprinderi: oferă capabilitățile necesare pentru a susține
sistemele software de întreprindere
• Software pentru lucrători în informații: abordează nevoile individuale necesare pentru a
gestiona și a crea informații pentru proiecte individuale din cadrul departamentelor
• Software de acces la conținut: Folosit pentru a accesa conținut și răspunde dorinței de conținut
digital publicat și de divertisment
• Software educațional: furnizează conținut destinat utilizării de către studenți
• Software de dezvoltare media: se adresează nevoilor individuale de a genera și tipări medii
electronice pentru ca alții să le consume
Testare software
Testarea software-ului este o investigație efectuată pentru a oferi părților interesate informații
despre calitatea produsului sau serviciului software testat.[1] Testarea software-ului poate oferi, de
asemenea, o vedere obiectivă, independentă a software-ului, pentru a permite afacerii să aprecieze
și să înțeleagă riscurile implementării software-ului. Tehnicile de testare includ procesul de
executare a unui program sau a unei aplicații cu intenția de a găsi erori software (erori sau alte
defecte) și de a verifica dacă produsul software este adecvat pentru utilizare.
Testarea software-ului implică execuția unei componente software sau a unei componente de
sistem pentru a evalua una sau mai multe proprietăți de interes. În general, aceste proprietăți indică
măsura în care componenta sau sistemul testat
• îndeplinește cerințele care i-au ghidat proiectarea și dezvoltarea,
• răspunde corect la toate tipurile de intrări,
• își îndeplinește funcțiile într-un timp acceptabil,
• este suficient de utilizabil,
• poate fi instalat și rulat în mediile destinate și
• atinge rezultatul general pe care îl doresc părțile interesate.
Deoarece numărul de teste posibile chiar și pentru componentele software simple este practic
infinit, toate testele software utilizează o strategie pentru a selecta teste care sunt fezabile pentru
timpul și resursele disponibile. Ca rezultat, testarea software-ului de obicei (dar nu exclusiv)
încearcă să execute un program sau o aplicație cu intenția de a găsi erori software (erori sau alte
defecte). Sarcina de a testa este un proces iterativ, deoarece atunci când o eroare este remediată,
poate lumina alte erori mai profunde sau poate chiar crea altele noi.
Testarea software-ului poate oferi utilizatorilor sau sponsorilor informații obiective și

independente despre calitatea software-ului și riscul eșecului acestuia.
Testarea software-ului poate fi efectuată imediat ce software-ul executabil (chiar dacă este parțial
complet) există. Abordarea generală a dezvoltării software determină adesea când și cum se
efectuează testarea. De exemplu, într-un proces în etape, majoritatea testărilor au loc după ce
cerințele de sistem au fost definite și apoi implementate în programe testabile. În schimb, în cadrul
unei abordări agile, cerințele, programarea și testarea sunt adesea efectuate simultan.
Abordarea cutiei
Metodele de testare a software-ului sunt în mod tradițional împărțite în testare cutie albă și testare
cutie neagră. Aceste două abordări sunt folosite pentru a descrie punctul de vedere pe care îl are
testatorul atunci când proiectează cazuri de testare.
Testarea cutiei albe

Testarea cutie albă (cunoscută și sub denumirea de testare cutie transparentă, testare cutie de sticlă,
testare cutie transparentă și testare structurală, prin vizualizarea codului sursă) testează structurile
interne sau funcționarea unui program, spre deosebire de funcționalitatea expusă utilizatorului
final. În testarea cutie albă, o perspectivă internă a sistemului, precum și abilitățile de programare,
sunt folosite pentru a proiecta cazuri de testare. Testerul alege intrări pentru a exercita căile prin
cod și pentru a determina ieșirile corespunzătoare. Acest lucru este analog cu testarea nodurilor
dintr-un circuit, de exemplu testarea în circuit (ICT).
În timp ce testarea cutie albă poate fi aplicată la nivel de unitate , integrare și sistem ale procesului
de testare a software-ului, de obicei se face la nivel de unitate. Poate testa căi în interiorul unei
unități, căi între unități în timpul integrării și între subsisteme în timpul unui test la nivel de sistem.
Deși această metodă de proiectare a testelor poate descoperi multe erori sau probleme, este posibil
să nu detecteze părți neimplementate ale specificației sau cerințele lipsă.
Tehnicile utilizate în testarea cutiei albe includ:
• Testare API – testarea aplicației folosind API-uri publice și private (interfețe de
programare a aplicațiilor)
• Acoperire de cod – crearea de teste pentru a satisface unele criterii de acoperire a codului
(de exemplu, proiectantul de teste poate crea teste pentru a determina ca toate instrucțiunile
din program să fie executate cel puțin o dată)
• Metode de injectare a erorilor – introducerea intenționată a defecțiunilor pentru a măsura
eficacitatea strategiilor de testare
• Metode de testare a mutațiilor
• Metode de testare statică
Instrumentele de acoperire a codului pot evalua caracterul complet al unei suite de teste care a fost
creată cu orice metodă, inclusiv cu testarea cutie neagră. Acest lucru permite echipei de software
să examineze părți ale unui sistem care sunt rar testate și se asigură că au fost testate cele mai
importante puncte de funcționare . Acoperirea codului ca valoare software poate fi raportată ca
procent pentru:
• Acoperirea funcției, care raportează asupra funcțiilor executate
• Acoperire declarație, care raportează asupra numărului de linii executate pentru a
finaliza testul
• Acoperire de decizie, care raportează dacă a fost executată atât ramura Adevărat, cât
și cea Falsă a unui anumit test
Acoperirea 100% a instrucțiunilor asigură că toate căile sau ramurile de cod (în ceea ce
privește fluxul de control ) sunt executate cel puțin o dată. Acest lucru este util pentru a
asigura funcționalitatea corectă, dar nu suficient, deoarece același cod poate procesa diferite
intrări corect sau incorect.
Testare cutie neagră
Cutie neagră
Diagrama cutie neagră

Testarea cutie neagră tratează software-ul ca pe o „cutie neagră”, examinând funcționalitatea
fără nicio cunoaștere a implementării interne, fără a vedea codul sursă. Testerii sunt conștienți
doar de ceea ce ar trebui să facă software-ul, nu de cum o face. [15] Metodele de testare cutie
neagră includ: partiționarea echivalenței , analiza valorii la limită , toate perechile
testare , tabele de tranziție de stări , testare tabel de decizie , testare fuzz , testare bazată pe
modele , testare de caz de utilizare , testare exploratorie și testare bazată pe specificații.
Testarea bazată pe specificații are ca scop testarea funcționalității software-ului în
conformitate cu cerințele aplicabile. [16] Acest nivel de testare necesită de obicei furnizarea
de cazuri de testare amănunțite testatorului, care apoi poate verifica pur și simplu că,
pentru o intrare dată, valoarea de ieșire (sau comportamentul), fie „este” fie „nu este”
aceeași cu valoarea așteptată specificată în cazul de testare. Cazurile de testare sunt
construite în jurul specificațiilor și cerințelor, adică ceea ce ar trebui să facă aplicația.
Utilizează descrieri externe ale software-ului, inclusiv specificații, cerințe și design pentru
a obține cazuri de testare. Aceste teste pot fi funcționale sau nefuncționale , deși de obicei
funcționale.
Testarea bazată pe specificații poate fi necesară pentru a asigura funcționalitatea corectă,
dar este insuficientă pentru a proteja împotriva situațiilor complexe sau cu risc ridicat.
Un avantaj al tehnicii cutiei negre este că nu sunt necesare cunoștințe de programare.
Indiferent de prejudecățile pe care programatorii le-ar fi avut, testerul probabil are un set
diferit și poate sublinia diferite zone de funcționalitate. Pe de altă parte, s-a spus că testarea
cutiei negre este „ca o plimbare într-un labirint întunecat fără lanternă”. Deoarece nu
examinează codul sursă, există situații în care un tester scrie multe cazuri de testare pentru
a verifica ceva care ar fi putut fi testat de un singur caz de testare sau lasă unele părți ale
programului netestate.
Această metodă de testare poate fi aplicată la toate nivelurile de testare software: unitate ,
integrare , sistem și acceptare . De obicei, cuprinde majoritatea testărilor, dacă nu toate, la
niveluri superioare, dar poate domina și testarea unitară.
Testare vizuală
Scopul testării vizuale este de a oferi dezvoltatorilor capacitatea de a examina ceea ce s-a
întâmplat în momentul eșecului software-ului prin prezentarea datelor în așa fel încât
dezvoltatorul să poată găsi cu ușurință informațiile de care are nevoie, iar informațiile sunt
exprimate clar. .
La baza testării vizuale se află ideea că a arăta cuiva o problemă (sau un eșec al testului),
mai degrabă decât doar o descriere, crește foarte mult claritatea și înțelegerea. Testarea
vizuală necesită, prin urmare, înregistrarea întregului proces de testare – captarea tot ceea
ce se întâmplă pe sistemul de testare în format video. Ieșirea videoclipurilor este
completată de intrarea în timp real a testerului prin intermediul webcam-ului imagine în
imagine și comentarii audio de la microfoane.
Testarea vizuală oferă o serie de avantaje. Calitatea comunicării este crescută drastic
deoarece testerii pot arăta problema (și evenimentele care au dus la aceasta)
dezvoltatorului, în loc să o descrie, iar nevoia de a replica eșecurile testelor va înceta să
mai existe în multe cazuri. Dezvoltatorul va avea toate dovezile de care are nevoie cu
privire la un eșec al testului și se poate concentra în schimb asupra cauzei defecțiunii și
asupra modului în care ar trebui să fie remediată.
Testarea vizuală este deosebit de potrivită pentru mediile care implementează metode agile
în dezvoltarea software-ului, deoarece metodele agile necesită o comunicare mai mare între
testeri și dezvoltatori și colaborare în cadrul echipelor mici.
Testarea ad-hoc și testarea exploratorie sunt metodologii importante pentru verificarea
integrității software-ului, deoarece necesită mai puțin timp de pregătire pentru implementare, în
timp ce erorile importante pot fi găsite rapid. În testarea ad-hoc, în care testarea are loc într-un
mod improvizat, compilat de Srinivas Kante E-mail: srinivaskante4u@gmail.com
În mod improvizat, capacitatea unui instrument de testare de a înregistra vizual tot ceea ce
se întâmplă pe un sistem devine foarte importantă pentru a documenta pașii luați pentru a
descoperi eroarea.
Testarea vizuală adună recunoaștere în ceea ce privește acceptarea clienților și testarea de
utilizare , deoarece testul poate fi utilizat de multe persoane implicate în procesul de
dezvoltare. Pentru client, devine ușor să furnizeze rapoarte detaliate despre erori și
feedback, iar pentru utilizatorii de programe, testarea vizuală poate înregistra acțiunile
utilizatorului pe ecran, precum și vocea și imaginea acestora, pentru a oferi o imagine
completă la momentul defecțiunii software pentru dezvoltatori.
Testarea cutie gri

Testarea cu caseta gri (ortografia americană: testarea cu caseta gri) implică cunoașterea
structurilor interne de date și a algoritmilor în scopul de a proiecta teste în timp ce se
execută acele teste la nivel de utilizator sau cutie neagră. Testerul nu trebuie să aibă acces
deplin la codul sursă al software-ului. Manipularea datelor de intrare și formatarea ieșirii
nu se califică drept cutie gri, deoarece intrarea și ieșirea se află în mod clar în afara „cutiei
negre” pe care o numim sistemul testat. Această distincție este deosebit de importantă
atunci când se efectuează teste de integrare între două module de cod scrise de doi
dezvoltatori diferiți, unde doar interfețele sunt expuse pentru test.
Cu toate acestea, testele care necesită modificarea unui depozit de date back-end, cum ar fi
o bază de date sau un fișier jurnal, se califică drept case gri, deoarece utilizatorul nu ar
putea în mod normal să schimbe depozitul de date în operațiunile normale de producție.
Testarea cu casetă gri poate include, de asemenea , inginerie inversă pentru a determina, de
exemplu, valorile limită sau mesajele de eroare.
Cunoscând conceptele de bază ale modului în care funcționează software-ul, testerul face
alegeri de testare mai bine informate în timp ce testează software-ul din exterior. În mod
obișnuit, unui tester cu casete gri i se va permite să creeze un mediu de testare izolat cu
activități precum seeding-ul unei baze de date . Testerul poate observa starea produsului
testat după ce a efectuat anumite acțiuni, cum ar fi executarea instrucțiunilor SQL în baza
de date și apoi executarea de interogări pentru a se asigura că modificările așteptate au fost
reflectate. Testarea Grey-box implementează scenarii de testare inteligente, bazate pe
informații limitate. Acest lucru se va aplica în special pentru gestionarea tipului de date,
gestionarea excepțiilor și așa mai departe.
Niveluri de testare
În general, există patru niveluri recunoscute de teste: testarea unitară, testarea integrării,
testarea interfeței componentelor și testarea sistemului. Testele sunt frecvent grupate după
locul în care sunt adăugate în procesul de dezvoltare a software-ului sau după nivelul de
specificitate al testului. Principalele niveluri în timpul procesului de dezvoltare, așa cum
sunt definite de ghidul SWEBOK , sunt testarea unitară, integrarea și testarea sistemului,
care se distinge prin ținta testului fără a implica un model de proces specific. Alte niveluri
de testare sunt clasificate în funcție de obiectivul de testare.
Există două niveluri diferite de teste din perspectiva clienților: testare de nivel scăzut
(LLT) și testare de nivel înalt (HLT). LLT este un grup de teste pentru componente de
nivel diferit ale aplicației software sau ale produsului. HLT este un grup de teste pentru
întreaga aplicație software sau produs.
Testarea unitară
Testarea unitară se referă la teste care verifică funcționalitatea unei anumite secțiuni de
cod, de obicei la nivel de funcție. Într-un mediu orientat pe obiecte, aceasta este de obicei
la nivel de clasă, iar testele unitare minime includ constructorii și destructorii. [23]
Aceste tipuri de teste sunt de obicei scrise de dezvoltatori în timp ce lucrează la cod (stil
cutie albă), pentru a se asigura că funcția specifică funcționează conform așteptărilor. O
funcție poate avea mai multe teste, pentru a prinde cazuri de colț sau alte ramuri în cod.
Testarea unitară în sine nu poate verifica funcționalitatea unei piese de software, ci mai
degrabă este folosită pentru a se asigura că blocurile de bază ale software-ului funcționează
independent unele de altele.
Testarea unitară este un proces de dezvoltare software care implică o aplicare sincronizată
a unui spectru larg de strategii de prevenire și detectare a defectelor pentru a reduce
riscurile, timpul și costurile de dezvoltare a software-ului. Este realizat de către
dezvoltatorul de software sau inginerul în timpul fazei de construcție a ciclului de viață al
dezvoltării software. Testarea unitară urmărește eliminarea erorilor de construcție înainte
ca codul să fie promovat la testare suplimentară; această strategie are scopul de a crește
calitatea software-ului rezultat, precum și eficiența procesului general de dezvoltare.
În funcție de așteptările organizației în ceea ce privește dezvoltarea software-ului, testarea
unitară poate include analiza statică a codului , analiza fluxului de date , analiza valorilor,
revizuirea codului de la egal la egal, analiza acoperirii codului și alte practici de testare a
software-ului.
Testarea integrării
Testarea de integrare este orice tip de testare software care urmărește să verifice interfețele
dintre componente în raport cu un design software. Componentele software pot fi integrate
într-un mod iterativ sau toate împreună ("big bang"). În mod normal, prima este
considerată o practică mai bună, deoarece permite ca problemele de interfață să fie
localizate mai rapid și rezolvate.
Testarea integrării funcționează pentru a expune defectele interfețelor și a interacțiunii
dintre componentele integrate (module). Grupuri din ce în ce mai mari de componente
software testate corespunzătoare elementelor de proiectare arhitecturală sunt integrate și
testate până când software-ul funcționează ca un sistem.
Testarea interfeței componentelor
Practica testării interfeței componentelor poate fi utilizată pentru a verifica gestionarea
datelor transmise între diferite unități sau componente ale subsistemului, dincolo de
testarea completă a integrării între acele unități. [ Datele transmise pot fi considerate
„pachete de mesaje”, iar intervalul sau tipurile de date pot fi verificate, pentru datele
generate de la o unitate, și testate pentru validitate înainte de a fi transmise într-o altă
unitate. O opțiune pentru testarea interfeței este de a păstra un fișier jurnal separat al
elementelor de date transmise, adesea cu un marcaj de timp înregistrat pentru a permite
analiza a mii de cazuri de date transmise între unități timp de zile sau săptămâni. Testele
pot include verificarea gestionării unor valori extreme de date, în timp ce alte variabile de
interfață sunt transmise ca valori normale. [ Valorile neobișnuite ale datelor dintr-o
interfață pot ajuta la explicarea performanței neașteptate în următoarea unitate. Testarea
interfeței componentelor este o variație a testării cutie neagră , [ cu accent pe valorile
datelor dincolo de acțiunile asociate unei componente ale subsistemului.
Testarea sistemului
Testarea sistemului testează un sistem complet integrat pentru a verifica dacă sistemul
îndeplinește cerințele acestuia. De exemplu, un test de sistem poate implica testarea unei
interfețe de conectare, apoi crearea și editarea unei intrări, plus trimiterea sau imprimarea
rezultatelor, urmată de procesarea sau ștergerea rezumatului (sau arhivare) a intrărilor, apoi
deconectare.
Testarea de acceptare operațională
Acceptarea operațională este utilizată pentru a conduce pregătirea operațională (pre-
lansare) a unui produs, serviciu sau sistem ca parte a unui sistem de management al
calității . OAT este un tip comun de testare software nefuncțională, utilizat în principal în
proiecte de dezvoltare și întreținere software . Acest tip de testare se concentrează pe
pregătirea operațională a sistemului pentru a fi susținut sau pentru a deveni parte a
mediului de producție. Prin urmare, este cunoscută și ca testare de pregătire operațională
(ORT) sau testare de pregătire și asigurare a operațiunilor (OR&A). Testarea funcțională în
cadrul OAT este limitată la acele teste care sunt necesare pentru a verifica aspectele
nefuncționale ale sistemului.
În plus, testarea software-ului ar trebui să se asigure că portabilitatea sistemului, precum și
funcționarea conform așteptărilor, nu deteriorează sau corupă parțial mediul său de operare
sau determină ca alte procese din acel mediu să devină inoperante.
Testarea de acceptare
Testarea de acceptare poate însemna unul dintre două lucruri:
1. Un test de fum este utilizat ca test de acceptare a construcției înainte de testarea
ulterioară, de exemplu, înainte de integrare sau regresie .
1. Testarea de acceptare efectuată de client, adesea în mediul de laborator pe propriul
hardware, este cunoscută sub numele de testare de acceptare a utilizatorului (UAT).
Testarea de acceptare poate fi efectuată ca parte a procesului de transfer între oricare
două faze de dezvoltare.
Testarea alfa
Testarea Alpha este testarea operațională simulată sau reală de către potențiali utilizatori/clienți
sau o echipă de testare independentă de pe site-ul dezvoltatorilor. Testarea alfa este adesea
folosită pentru software-ul disponibil ca o formă de testare internă de acceptare înainte ca
software-ul să treacă la testarea beta. [
Testare beta
Testarea beta vine după testarea alfa și poate fi considerată o formă de testare de acceptare a
utilizării externe. Versiunile software-ului, cunoscute sub denumirea de versiuni beta , sunt
lansate unui public limitat în afara echipei de programare cunoscute sub numele de testeri beta.
Software-ul este lansat pentru grupuri de oameni, astfel încât testele ulterioare pot asigura că
produsul are câteva defecte sau erori . Versiunile beta pot fi puse la dispoziția publicului
deschis pentru a crește câmpul de feedback la un număr maxim de viitori utilizatori și pentru a
oferi valoare mai devreme, pentru o perioadă de timp extinsă sau chiar nedeterminată
Testare de dezvoltare
Testarea de dezvoltare este un proces de dezvoltare a software-ului care implică aplicarea
sincronizată a unui spectru larg de strategii de prevenire și detectare a defectelor, pentru a se

compila de Srinivas Kante E-mail: srinivaskante4u@gmail.com
reduce riscurile de dezvoltare a software-ului, timpul și costurile. Este realizat de către

dezvoltatorul de software sau inginerul în timpul fazei de construcție a ciclului de viață al
dezvoltării software. Testarea de dezvoltare are ca scop eliminarea erorilor de construcție
înainte ca codul să fie promovat la alte teste; această strategie are scopul de a crește calitatea
software-ului rezultat, precum și eficiența procesului general de dezvoltare.
În funcție de așteptările organizației în ceea ce privește dezvoltarea software-ului, testarea de
dezvoltare poate include analiza static a codului , analiza fluxului de date, analiza valorilor,
revizuirea codului de la egal la egal, testarea unitară, analiza acoperirii codului, trasabilitatea și
alte practici de testare a software-ului.
Testare A/B
Testarea A/B este o metodă de desfășurare a unui experiment controlat pentru a determina dacă
o modificare propusă este mai eficientă decât abordarea actuală. Clienții sunt direcționați fie
către o versiune actuală (control) a unei caracteristici, fie către o versiune modificată
(tratament), iar datele sunt colectate pentru a determina care versiune este mai bună pentru a
obține rezultatul dorit.
Testare concomitentă
În testarea concomitentă, accentul se pune pe performanță în timp ce rulează continuu cu
intrare normală și în condiții de funcționare normale, spre deosebire de testarea la stres sau
testarea fuzz. Scurgerile de memorie, precum și defecțiunile de bază sunt mai ușor de găsit cu
această metodă.
Testare de conformitate sau testare de tip
În testarea software-ului, testarea conformității verifică dacă un produs funcționează conform
standardelor specificate. Compilatorii, de exemplu, sunt testați pe larg pentru a determina dacă
îndeplinesc standardul recunoscut pentru limba respectivă.
Cloud Computing
Cloud computing este utilizarea diferitelor servicii, cum ar fi platforme de dezvoltare software,
servere, stocare și software, pe internet, adesea denumite „nori”.
În general, există trei caracteristici de cloud computing care sunt comune tuturor furnizorilor
de cloud computing:
1. Back-end-ul aplicației (în special hardware) este complet gestionat de un furnizor de
cloud.
2. Un utilizator plătește doar pentru serviciile utilizate (memorie, timp de procesare și lățime
de bandă etc.).
3. Serviciile sunt scalabile
Multe progrese în cloud computing sunt strâns legate de virtualizare. Capacitatea de a plăti la
cerere și de a scala rapid este în mare parte rezultatul faptului că furnizorii de cloud computing
sunt capabili să reunească resurse care pot fi împărțite între mai mulți clienți.
Este obișnuit să se clasifice serviciile de cloud computing ca infrastructură ca serviciu (IaaS),

platformă ca serviciu (PaaS) sau software ca serviciu (SaaS).
Unii consideră că cloud computing este un cuvânt la modă suprautilizat, care a fost
disproporționat de către departamentele de marketing ale companiilor mari de software. Un
argument comun al criticilor este că cloud computing nu poate avea succes, deoarece înseamnă
că organizațiile trebuie să piardă controlul Compiled by Srinivas Kante Email: srinivaskante4u@gmail.com
datele lor, cum ar fi un furnizor de e-mail care stochează date în mai multe locații din întreaga
lume. O companie mare reglementată, cum ar fi o bancă, ar putea fi obligată să stocheze date
în Statele Unite. Deși aceasta nu este o problemă de netrecut, ea demonstrează tipul de
problemă pe care unele companii le pot avea cu cloud computing.
Susținătorii cloud computing-ului subliniază că acesta este o nouă paradigmă în dezvoltarea de
software, în care organizațiile mai mici au acces la procesele de stocare a energiei de procesare
și procese de afaceri care erau cândva disponibile doar pentru întreprinderile mari.
Denumirea de cloud computing provine de la utilizarea tradițională a cloud-ului pentru a
reprezenta internetul – sau o rețea largă (WAN) – în diagrame de rețea sau diagrame de flux.
Securitatea cloud computing se referă la setul de proceduri, procese și standarde concepute

pentru a oferi asigurare a securității informațiilor într-un mediu de cloud computing.
Securitatea cloud computing abordează atât problemele de securitate fizică, cât și logică în
toate modelele de servicii diferite de software, platformă și infrastructură. De asemenea,
abordează modul în care sunt furnizate aceste servicii (model de livrare public, privat sau
hibrid).
Securitatea în cloud cuprinde o gamă largă de constrângeri de securitate din perspectiva
utilizatorului final și a furnizorului de cloud, unde utilizatorul final va fi preocupat în primul
rând de politica de securitate a furnizorului, de cum și unde sunt stocate datele lor și cine are
acces la acele date. Pentru un furnizor de cloud, pe de altă parte, problemele de securitate a
computerelor în cloud pot varia de la securitatea fizică a infrastructurii și mecanismul de
control al accesului la activele cloud, până la execuția și întreținerea politicii de securitate.
Securitatea în cloud este importantă, deoarece este probabil cel mai mare motiv pentru care
organizațiile se tem de cloud.
Cloud Security Alliance (CSA), o organizație nonprofit de specialiști din industrie, a dezvoltat
un grup de linii directoare și cadre pentru implementarea și impunerea securității într-un mediu
de operare cloud.
Cloud public: în cloud public, infrastructura de calcul este găzduită de furnizorul de cloud la
sediul furnizorului. Clientul nu are vizibilitate și control asupra locului în care este găzduită
infrastructura de calcul. Infrastructura de calcul este partajată între orice organizație.
Cloud privat: infrastructura de calcul este dedicată unei anumite organizații și nu este
partajată cu alte organizații. Unii experți consideră că cloud-urile private nu sunt exemple reale
de cloud computing. Norurile private sunt mai scumpe și mai sigure în comparație cu norii
publici.
Norurile private sunt de două tipuri: cloud-uri private on-premise și cloud-uri private
găzduite extern. Cloudurile private găzduite extern sunt, de asemenea, utilizate exclusiv de o
organizație, dar sunt găzduite de o terță parte specializată în infrastructura cloud. Norurile
private găzduite extern sunt mai ieftine decât cele private on-premise.
Cloud hibrid: organizațiile pot găzdui aplicații critice pe cloud-uri private și aplicații cu
probleme de securitate relativ mai reduse în cloud-ul public. Utilizarea atât a cloud-urilor
private, cât și a celor publice împreună se numește cloud hibrid.
Cloudul comunitar implică partajarea infrastructurii de calcul între organizațiile aceleiași

comunități. De exemplu, toate organizațiile guvernamentale din statul California pot partaja
infrastructura de calcul în cloud pentru a gestiona datele referitoare la cetățenii care locuiesc în
California.
2. Clasificare pe baza serviciului prestat
În funcție de serviciile oferite, norii sunt clasificați în următoarele moduri:
Infrastructura ca serviciu (IaaS) presupune oferirea de servicii legate de hardware folosind

principiile cloud computing. Acestea ar putea include un fel de servicii de stocare (bază de date
sau stocare pe disc) sau servere virtuale. Furnizorii de top care oferă Infrastructură ca serviciu
sunt Amazon EC2, Amazon S3, Rackspace Cloud Servers și Flexiscale.
Platform as a Service (PaaS) presupune oferirea unei platforme de dezvoltare pe cloud.

Platformele furnizate de diferiți furnizori nu sunt de obicei compatibile. Jucătorii tipici din
PaaS sunt Google Application Engine, Microsoft Azure și Salesforce.com force.com.
Software-ul ca serviciu (SaaS) include o ofertă completă de software pe cloud. Utilizatorii pot
accesa
o aplicație software găzduită de furnizorul cloud pe bază de plată pe utilizare. Acesta este un
sector bine stabilit. Pionierul în acest domeniu a fost oferta Salesforce.com în spațiul online
Customer Relationship Management (CRM). Alte exemple sunt furnizorii de e-mail online
precum Googles Gmail și Hotmailul Microsoft, Google Docs și versiunea online de birou a
Microsoft numită BPOS (Business Productivity Online Standard Suite).
Provocările cloud computing
Provocările cloud computing au existat întotdeauna. Companiile sunt din ce în ce mai

conștiente de valoarea de afaceri pe care o aduce cloud computing și fac pași către tranziția
către cloud. Unele dintre cele mai importante provocări sunt următoarele.
Securitate și confidențialitate: principala provocare pentru cloud computing este modul în

care abordează preocupările de securitate și confidențialitate ale companiilor care se gândesc
să o adopte. Faptul că datele valoroase ale întreprinderii vor locui în afara paravanului de
protecție corporativă ridică îngrijorări serioase. Hackingul și diversele atacuri la infrastructura
cloud ar afecta mai mulți clienți chiar dacă un singur site este atacat. Aceste riscuri pot fi
atenuate prin utilizarea aplicațiilor de securitate, a sistemelor de fișiere criptate, a software-ului
pentru pierderea datelor și a achiziționării de hardware de securitate pentru a urmări
comportamentul neobișnuit pe servere.
Disponibilitate și scalabilitate: este dificil de evaluat costurile implicate din cauza naturii la
cerere a serviciilor. Bugetarea și evaluarea costurilor vor fi foarte dificile, cu excepția cazului
în care furnizorul are de oferit niște repere bune și comparabile. Acordurile de nivel de serviciu
(SLA) ale furnizorului nu sunt adecvate pentru a garanta disponibilitatea și scalabilitatea.
Companiile vor fi reticente să treacă la cloud fără o garanție puternică a calității serviciilor.
Interoperabilitate și portabilitate: companiile ar trebui să aibă pârghia de a migra în și din

cloud și de a schimba furnizorii oricând doresc și nu ar trebui să existe o perioadă de blocare.
Serviciile de cloud computing ar trebui să aibă capacitatea de a se integra fără probleme cu IT-
ul local.
Fiabilitate și disponibilitate : furnizorii de cloud încă nu au un serviciu non-stop; acest lucru

duce la întreruperi frecvente. Este important să monitorizați serviciul furnizat folosind
instrumente interne sau terțe. Este vital să existe planuri pentru a supraveghea utilizarea, SLA-
urile, performanța, robustețea și dependența de afaceri a acestor servicii.
Costul performanței și lățimii de bandă: companiile pot economisi bani pe hardware, dar
trebuie să cheltuiască mai mult pentru lățimea de bandă. Acest lucru poate fi un cost scăzut
pentru aplicațiile mai mici, dar poate fi semnificativ ridicat pentru aplicațiile cu consum mare
de date. Furnizarea de date intensive și complexe prin rețea necesită o lățime de bandă
suficientă. Din această cauză, multe companii așteaptă un cost redus înainte de a trece la cloud.
Toate aceste provocări nu ar trebui să fie considerate blocaje în căutarea cloud computingului.
Este destul de important să se acorde o atenție serioasă acestor probleme și posibilelor căi de
ieșire înainte de a adopta tehnologia.
Viitorul tehnologiei cloud în India

În februarie 2017, gigantul tehnologic din SUA Oracle a prezis că, întrucât se așteaptă ca
cloud-ul pentru întreprinderi să devină cel mai sigur loc pentru procesarea IT, cu aproape 60%
organizații IT care își vor muta managementul sistemelor în cloud în 2017, India va fi printre
principalii beneficiari ai cloud-ului. tehnica de calcul.
Cheltuielile guvernamentale crescute pentru tehnologiile digitale, împreună cu cererea crescută

din partea sectorului privat, continuă să fie un impuls extraordinar pentru industria cloud. Nu
numai firmele mari, cloud-ul va stimula inovarea în afacerile mici în 2017, iar Inteligența
Artificială (AI) va deveni o realitate, a spus Oracle. Gartner a prezis că doar în India, piața
cloud va ajunge la peste 3 miliarde de dolari până în 2017 - o creștere de aproape cinci ori față
de 2012.
India Inc a promis R4,5 lakh crore pentru Digital India, care poate crea locuri de muncă pentru
aproximativ 18 lakh de oameni. Un număr bun dintre ei vor fi în cloud computing. Odată cu
lansarea a 100 de orașe inteligente, a 500 de orașe întinerite și a numeroase proiecte pentru a
crea hub-uri industriale, o coloană vertebrală virtuală puternică, care este posibilă cu
tehnologia cloud, este o necesitate critică pentru a duce procesul de dezvoltare la următorul
nivel.
STANDARDE DE SECURITATE ȘI BUNE PRACTICI

Standardul de bune practici pentru securitatea informațiilor, publicat de Forumul pentru
securitatea informațiilor (ISF), este un ghid cuprinzător, practic și axat pe afaceri pentru
identificarea și gestionarea riscurilor de securitate a informațiilor în organizații și lanțurile lor
de aprovizionare.
Cea mai recentă ediție este 2016, o actualizare a ediției din 2014.
Standardul din 2011 este cea mai semnificativă actualizare a standardului timp de patru ani.
Include „subiecte fierbinți” de securitate a informațiilor, cum ar fi dispozitivele de consum,
infrastructura critică, atacurile de criminalitate cibernetică, echipamente de birou, foi de calcul
și baze de date și cloud computing.
Standardul din 2011 este aliniat cu cerințele pentru un sistem de management al securității
informațiilor (ISMS) stabilite în standardele din seria ISO/IEC 27000 și oferă o acoperire mai
largă și mai profundă a subiectelor de control ISO/IEC 27002 , precum și cloud computing,
scurgeri de informații , dispozitivele de consum și guvernarea securității.
Pe lângă faptul că oferă un instrument pentru a permite certificarea ISO 27001, standardul
2011 oferă o acoperire completă a subiectelor COBIT v4 și oferă o aliniere substanțială cu alte
standarde și legislații relevante, cum ar fi PCI DSS și Sarbanes Oxley Act , pentru a permite și
conformitatea cu aceste standarde. .
Standardul este utilizat de către Chief Information Security Officers (CISO), managerii de
securitate a informațiilor, managerii de afaceri, managerii IT, auditorii interni și externi,
furnizorii de servicii IT din organizații de toate dimensiunile.
Standardul 2011 este disponibil gratuit membrilor ISF. Non-membrii pot cumpăra o copie a
standardului direct de la ISF.
Standarde de guvernare IT și bune practici
• Familia ISO/IEC 27000 de sisteme de management al securității informațiilor - Acest

document oferă o privire de ansamblu asupra familiei ISO/IEC 27000 de sisteme de
management al securității informațiilor, care constă din standarde și linii directoare
interdependente, deja publicate sau în curs de dezvoltare, și conține o serie de aspecte
structurale semnificative. componente.
• ISO 27001 - Acest document oferă standardele ISO ale cerințelor pentru stabilirea,
implementarea, menținerea și îmbunătățirea continuă a unui sistem de management al
securității informațiilor în contextul organizației.
• ISO 27002 - Acest document prezintă codul de practică pentru controalele securității
informațiilor.
• Standardul britanic 7799 Partea 3 - Acest set de linii directoare este publicat de BSI Group
pentru managementul riscului de securitate a informațiilor.
• COBIT - Obiectivele de control pentru tehnologia informației și tehnologia conexe

(COBIT) este publicată de Consiliul de Standarde al Asociației de Audit și Control al
Sistemelor Informaționale (ISACA) care oferă un cadru de control pentru guvernanța și
managementul IT-ului întreprinderii.
• Criterii comune (cunoscute și ca ISO/IEC 15408) - Acest set de criterii de evaluare este
dezvoltat și aliniat cu organizațiile naționale de standarde de securitate din Australia, Canada,
Franța, Germania, Japonia, Țările de Jos, Noua Zeelandă, Spania, Marea Britanie și SUA.
• ITIL (sau seria ISO/IEC 20000) - Acest document prezintă o colecție de bune practici în
managementul serviciilor IT (ITSM) și se concentrează pe procesele de servicii ale IT și ia în
considerare rolul central al utilizatorului.
• Specificația standardului național de securitate a informațiilor - Această pagină web

introduce o colecție de standarde naționale de securitate a informațiilor formulate de Comitetul
tehnic pentru standardele naționale de securitate a informațiilor. Aceste standarde includ
managementul securității informațiilor, evaluarea securității informațiilor, autentificarea și
autorizarea etc.
Clasificarea și controlul activelor
Securitatea informațiilor este păstrarea CIA a activelor unei organizații. Nivelul de asigurare a
securității cerut este determinat de tipul activului și valoarea acestuia.
Informația este un activ de afaceri care adaugă valoare unei organizații. Clasificarea activelor
identifică tipul de activ informațional pe baza valorii, sensibilității și gradului de asigurare
cerut. Acest lucru ne permite să elaborăm controale adecvate.
Următoarele concepte sunt aplicabile activelor informaționale:
• Criterii de clasificare — Activele informaționale sunt, în general, clasificate în funcție de

valoarea, vechimea, durata de viață utilă și asocierea personalului pe baza cerințelor de
confidențialitate.
• Proprietar — proprietarul informațiilor este responsabil pentru protecția acestora.

Proprietarul joacă rolul de a determina nivelul de clasificare, revizuirea periodică și delegarea.
• Custode - Un custode este cel delegat de proprietar pentru a păstra informațiile. Rolul unui
custode include backup și restaurarea informațiilor și menținerea înregistrărilor.
• Utilizator — Un utilizator este persoana care utilizează informațiile. Un utilizator poate fi

un angajat, un
operator sau oricare al treilea...
Controlul echipamentelor hardware de către
1.identificarea
2.Înregistrare
3 clasificarea
4.1 controlul inventarului
5.Monitorizare
Recodificarea echipamentului hardware de către
Cod de bare
Un cod de bare (de asemenea, un cod de bare) este o reprezentare optică, care poate fi citită de
mașină , a datelor; datele descriu de obicei ceva despre obiectul care poartă codul de bare.
Codurile de bare tradiționale

reprezintă sistematic datele prin variarea lățimilor și distanțelor liniilor paralele și pot fi
denumite liniare sau unidimensionale (1D). Ulterior, au fost dezvoltate variante bidimensionale
(2D), folosind dreptunghiuri, puncte, hexagoane și alte modele geometrice, numite coduri
matrice sau coduri de bare 2D , deși nu folosesc bare ca atare. Inițial, codurile de bare erau
scanate doar de scanere optice speciale numite cititoare de coduri de bare . Mai târziu,
software-ul de aplicație a devenit disponibil pentru dispozitivele care puteau citi imagini, cum
ar fi smartphone-urile cu camere.
O utilizare timpurie a unui tip de cod de bare într-un context industrial a fost sponsorizată de
Asociația Căilor Ferate Americane la sfârșitul anilor 1960. Dezvoltată de General Telephone
and Electronics (GTE) și numită KarTrak ACI (Automatic Car Identification), această schemă
presupunea plasarea dungi colorate în diferite combinații pe plăci de oțel care erau fixate pe
părțile laterale ale materialului rulant feroviar. Au fost folosite două plăcuțe pe mașină, câte
una pe fiecare parte, cu aranjamentul dungilor colorate care codifică informații precum
proprietatea, tipul de echipament și numărul de identificare. Plăcuțele au fost citite de un
scaner de lângă cale, situat, de exemplu, la intrarea într-o curte de clasificare, în timp ce
mașina trecea pe lângă. Proiectul a fost abandonat după aproximativ zece ani, deoarece
sistemul s-a dovedit nefiabil după utilizare pe termen lung
Circuit RFID
RFID sau Radio Frequency Identification System este un sistem de identificare bazat pe
tehnologie care ajută la identificarea obiectelor doar prin intermediul etichetelor atașate
acestora, fără a necesita nicio lumină de vedere între etichete și cititorul de etichete. Tot ce este
nevoie este comunicarea radio între etichetă și cititor
Managementul activelor IT
Managementul activelor IT (ITAM) este „un set de practici de afaceri care încorporează
active IT în toate unitățile de afaceri din cadrul organizației. Se alătură responsabilităților
financiare, de inventar, contractuale și de gestionare a riscurilor pentru a gestiona ciclul
general de viață al acestor active, inclusiv luarea deciziilor tactice și strategice”. Activele
includ toate elementele de software și hardware care se găsesc în mediul de afaceri.
Gestionarea activelor IT este uneori denumită managementul inventarului IT, deoarece implică
de obicei colectarea de informații detaliate despre inventarul hardware și software, care sunt
apoi utilizate pentru a lua decizii cu privire la achiziții și la modul în care sunt utilizate
activele. A avea un inventar precis al activelor IT ajută companiile să-și folosească activele
mai eficient și să evite achizițiile inutile de active prin reutilizarea resurselor existente.
Managementul activelor IT permite, de asemenea, organizațiilor să reducă costurile riscurilor
legate de construirea, în neștire, de noi proiecte IT pe baze de infrastructură învechite (sau
necunoscute).
Gestionarea activelor IT este eficientă folosind metadate și înregistrări electronice pentru a
urmări și clasifica activele organizației. Metadatele sunt descrierea activului fizic sau digital și
a oricăror informații de sprijin care sunt necesare pentru a informa deciziile de gestionare a
activelor. Adâncimea metadatelor poate varia în funcție de nevoile organizației.
Controale de rețea
Securitatea rețelei este un termen general care descrie politicile și procedurile implementate de
un administrator de rețea pentru a evita și a ține evidența accesului neautorizat, exploatării,
modificării sau refuzării rețelei și a resurselor rețelei.
Aceasta înseamnă că o securitate a rețelei bine implementată blochează virușii, programele
malware, hackerii etc. de la accesarea sau modificarea informațiilor securizate.
Primul nivel de securitate a rețelei este impus printr-un mecanism de nume de utilizator/parolă,
care permite accesul numai utilizatorilor autentificați cu privilegii personalizate. Atunci când
un utilizator este autentificat și i se acordă acces la sistem specific, paravanul de protecție
configurat impune politicile de rețea, adică serviciile de utilizator accesibile.
Cu toate acestea, firewall-urile nu detectează și opresc întotdeauna virușii sau programele

malware dăunătoare, ceea ce poate duce la pierderea datelor. Este implementat un software
antivirus sau un sistem de prevenire a intruziunilor (IPS) pentru a preveni intrarea virusului
și/sau a programelor malware dăunătoare în rețea.
Securitatea rețelei este uneori confundată cu securitatea informațiilor, care are un domeniu de
aplicare diferit și se referă la integritatea datelor de toate formele, tipărite sau electronice.
Unele dintre cele mai frecvent utilizate dispozitive de rețea sunt

Modem
Un modem este un dispozitiv de rețea care atât modulează, cât și demodulează semnalele
purtătoare analogice (numite unde sinusoidale) pentru codificarea și decodificarea
informațiilor digitale pentru procesare. Modemurile îndeplinesc ambele aceste sarcini simultan
și, din acest motiv, termenul modem este o combinație de „modula” și „demodulează”.
Repetitor
Un repetor este un dispozitiv de rețea care retransmite un semnal recepționat cu mai multă
putere și către o limită de rețea geografică sau topologică extinsă decât ceea ce ar fi capabil cu
semnalul original.
Intrerupator
Un comutator, în contextul rețelei, este un dispozitiv de mare viteză care primește pachetele de
date primite și le redirecționează către destinația lor într-o rețea locală (LAN). Un comutator
LAN operează la nivelul de legătură de date (Layer 2) sau la nivelul de rețea al modelului OSI
și, ca atare, poate suporta toate tipurile de protocoale de pachete.
Hub
Un hub, numit și hub de rețea, este un punct de conectare comun pentru dispozitivele dintr-o
rețea . Hub-urile sunt dispozitive utilizate în mod obișnuit pentru a conecta segmente ale unei
rețele LAN . Hub-ul conține mai multe porturi . Când un pachet ajunge la un port, acesta este
copiat în celelalte porturi, astfel încât toate segmentele LAN-ului să poată vedea toate
pachetele
Poarta de acces
În rețelele de calculatoare și telecomunicațiile, un gateway este o componentă care face parte
din două rețele, care utilizează protocoale diferite. Gateway-ul va traduce un protocol în
celălalt. Un router este un caz special de gateway.
Gateway-urile, numite și convertoare de protocol, pot funcționa la orice nivel de rețea.
Activitățile unui gateway sunt mai complexe decât cele ale routerului sau comutatorului,
deoarece comunică folosind mai mult de un protocol.
Atât computerele utilizatorilor de internet , cât și computerele care deservesc pagini

utilizatorilor sunt noduri gazdă . Nodurile care conectează rețelele dintre acestea sunt
gateway-uri . Acestea sunt noduri gateway:
• calculatoarele care controlează traficul dintre rețelele companiei
• computerele utilizate de furnizorii de servicii de internet (ISP) pentru a conecta
utilizatorii la internet
•
Rețea de calculatoare | Straturi ale modelului OSI
OSI înseamnă Open Systems Interconnection . A fost dezvoltat de ISO – „ Organizația
Internațională de Standardizare ”, în anul 1974. Este o arhitectură cu 7 straturi, fiecare strat
având o funcționalitate specifică de realizat. Toate aceste 7 straturi lucrează în colaborare
pentru a transmite datele de la o persoană la alta pe tot globul.
1. Stratul fizic (Stratul 1):

Cel mai de jos strat al modelului de referință OSI este stratul fizic. Este responsabil pentru
conexiunea fizică reală dintre dispozitive. Stratul fizic conține informații în Compiled by Srinivas
Kante Email: srinivaskante4u@gmail.com
forma de biți. Este responsabil pentru conexiunea fizică reală dintre dispozitive. Când primește
date, acest strat va primi semnalul primit și îl va converti în 0 și 1 și le va trimite la stratul Data
Link, care va pune din nou cadrul împreună.
Funcțiile stratului fizic sunt:
1. Sincronizarea biților: stratul fizic asigură sincronizarea biților prin furnizarea

unui ceas. Acest ceas controlează atât emițătorul, cât și receptorul, oferind astfel
sincronizare la nivel de biți.
2. Controlul ratei de biți: Stratul fizic definește și rata de transmisie, adică numărul
de biți trimiși pe secundă.
3. Topologii fizice: Stratul fizic specifică modul în care diferitele dispozitive/noduri
sunt aranjate într-o rețea, adică topologia magistrală, stea sau plasă.
4. Modul de transmisie: Stratul fizic definește și modul în care datele circulă între
cele două dispozitive conectate. Diferitele moduri de transmisie posibile sunt: Simplex,
half-duplex și full-duplex.
* Hub-ul, Repeatorul, Modemul, Cablurile sunt dispozitive de nivel fizic.
** Stratul de rețea, Stratul de legătură de date și Stratul fizic sunt cunoscute și ca Straturi
inferioare sau Straturi hardware.
2. Strat de legătură de date (DLL) (Layer 2):

Stratul de legătură de date este responsabil pentru livrarea mesajului de la nod la nod.
Funcția principală a acestui strat este de a se asigura că transferul de date este fără erori de
la un nod la altul, peste nivelul fizic. Când un pachet ajunge într-o rețea, este
responsabilitatea DLL să-l transmită gazdei folosind adresa MAC.
Stratul de legătură de date este împărțit în două substraturi:
1. Controlul legăturii logice (LLC)
2. Control acces media (MAC)
Pachetul primit de la stratul de rețea este împărțit în continuare în cadre în funcție de
dimensiunea cadrului NIC (Placă de interfață de rețea). DLL încapsulează, de asemenea,
adresa MAC a expeditorului și a destinatarului în antet.
Adresa MAC a receptorului este obținută prin plasarea unei solicitări ARP (Address
Resolution Protocol) pe fir care cere „Cine are acea adresă IP?” iar gazda de destinație va
răspunde cu adresa sa MAC.
Funcțiile stratului de legătură de date sunt:

3. Încadrarea: încadrarea este o funcție a stratului de legătură de date. Oferă o
modalitate pentru un expeditor de a transmite un set de biți care sunt semnificativi
pentru receptor. Acest lucru poate fi realizat prin atașarea unor modele speciale de
biți la începutul și la sfârșitul cadrului.
4. Adresare fizică: După crearea cadrelor, stratul de legătură de date adaugă adrese
fizice (adresa MAC) ale expeditorului și/sau receptorului în antetul fiecărui cadru.
5. Controlul erorilor: Stratul de legătură de date oferă mecanismul de control al
erorilor prin care detectează și retransmite cadrele deteriorate sau pierdute.
6. Controlul fluxului: Rata de date trebuie să fie constantă pe ambele părți, altfel
datele pot fi corupte, astfel, controlul fluxului coordonează acea cantitate de date care
poate fi trimisă înainte de a primi confirmarea.
7. Controlul accesului: Când un singur canal de comunicație este partajat de mai
multe dispozitive, sub-stratul MAC al stratului de legătură de date ajută la
determinarea dispozitivului care are controlul asupra canalului la un moment dat.
* Pachetul din stratul de legătură de date este denumit cadru .
** Stratul Data Link este gestionat de NIC (Network Interface Card) și driverele de dispozitiv
ale mașinilor gazdă.
*** Switch & Bridge sunt dispozitive Data Link Layer.
3. Stratul de rețea (Layer 3):

Stratul de rețea funcționează pentru transmiterea datelor de la o gazdă la alta situată în
rețele diferite. De asemenea, se ocupă de rutarea pachetelor, adică de selectarea celei mai
scurte căi pentru transmiterea pachetului, din numărul de rute disponibile. Adresa IP a
expeditorului și a destinatarului sunt plasate în antet după stratul de rețea.
Funcțiile stratului de rețea sunt:
1. Rutare: protocoalele stratului de rețea determină care rută este potrivită de la
sursă la destinație. Această funcție a stratului de rețea este cunoscută sub numele de
rutare.
2. Adresare logică: Pentru a identifica fiecare dispozitiv pe internet în mod unic,
stratul de rețea definește o schemă de adresare. Adresa IP a expeditorului și a
destinatarului sunt plasate în antet după stratul de rețea. O astfel de adresă distinge
fiecare dispozitiv în mod unic și universal.
* Segmentul din stratul de rețea este denumit Pachet.
** Stratul de rețea este implementat de dispozitive de rețea, cum ar fi routerele.
4. Stratul de transport (Stratul 4):

Stratul de transport oferă servicii la nivelul aplicației și preia servicii de la nivelul de rețea.
Datele din stratul de transport sunt denumite Segmente . Este responsabil pentru livrarea
de la capăt la capăt a mesajului complet. Stratul de transport oferă, de asemenea,
confirmarea transmisiei cu succes a datelor și retransmite datele dacă se găsește o eroare.
• De partea expeditorului:
Stratul de transport primește datele formatate de la straturile superioare, efectuează
Segmentarea și, de asemenea, implementează controlul fluxului și erorilor pentru a asigura
o transmitere adecvată a datelor. De asemenea, adaugă numărul portului Sursă și
Destinație în antetul său și transmite datele segmentate către Stratul de rețea.
Notă: Expeditorul trebuie să cunoască numărul portului asociat cu aplicația destinatarului.
În general, acest număr de port de destinație este configurat, fie implicit, fie manual. De
exemplu, atunci când o aplicație web face o solicitare către un server web, de obicei
folosește numărul portului 80, deoarece acesta este portul implicit alocat aplicațiilor web.
Multe aplicații au portul implicit alocat.
• De partea receptorului:
Transport Layer citește numărul portului din antetul său și transmite datele pe care le-a
primit la aplicația respectivă. De asemenea, efectuează secvențierea și reasamblarea datelor
segmentate.
Funcțiile stratului de transport sunt:

1. Segmentare și reasamblare: Acest strat acceptă mesajul din stratul (sesiune),

descompune mesajul în unități mai mici. Fiecare dintre segmentele produse are
asociat un antet. Stratul de transport de la stația de destinație reasambla mesajul.
1. Adresarea punctului de serviciu: Pentru a livra mesajul la procesul corect, antetul
stratului de transport include un tip de adresă numită adresă punct de serviciu sau
adresă port. Astfel, prin specificarea acestei adrese, stratul de transport se asigură că
mesajul este livrat la procesul corect.
Serviciile oferite de stratul de transport:
1. Serviciu orientat spre conexiune: este un proces în trei faze care include
– Stabilirea conexiunii
- Transfer de date
– Încetarea/deconectarea
În acest tip de transmisie, dispozitivul receptor trimite o confirmare, înapoi la sursă,
după ce un pachet sau un grup de pachete este primit. Acest tip de transmisie este
fiabil și sigur.
1. Serviciu fără conexiune: este un proces într-o fază și include transferul de date. În
acest tip de transmisie, receptorul nu confirmă primirea unui pachet. Această
abordare permite o comunicare mult mai rapidă între dispozitive. Serviciul orientat
spre conexiune este mai fiabil decât Serviciul fără conexiune.
1 Datele din Stratul de transport sunt numite Segmente .
2 * Stratul de transport este operat de sistemul de operare. Este o parte a sistemului de operare
și comunică cu Stratul de aplicație prin apeluri de sistem.
Stratul de transport este numit modelul Heart of OSI .
5. Strat de sesiune (Stratul 5):

Acest nivel este responsabil pentru stabilirea conexiunii, întreținerea sesiunilor,
autentificare și, de asemenea, asigură securitatea.
Funcțiile stratului de sesiune sunt:
1. Stabilirea, întreținerea și terminarea sesiunii: stratul permite celor două procese
să stabilească, să utilizeze și să încheie o conexiune.
2. Sincronizare: Acest strat permite unui proces să adauge puncte de control care
sunt considerate puncte de sincronizare în date. Aceste puncte de sincronizare ajută la
identificarea erorii, astfel încât datele să fie resincronizate corect, iar capetele
mesajelor să nu fie tăiate prematur și să fie evitată pierderea datelor.
3. Controler de dialog: stratul de sesiune determină ce dispozitiv va comunica primul
și cantitatea de date care va fi trimisă.
**Toate cele 3 straturi de mai sus sunt integrate ca un singur strat în modelul TCP/IP ca „Strat
de aplicație”.
**Implementarea celor 3 straturi de mai sus se face chiar de aplicația de rețea. Acestea sunt
cunoscute și sub denumirea de Straturi superioare sau Straturi software .
SCENARIU:
Să luăm în considerare un scenariu în care un utilizator dorește să trimită un mesaj prin
intermediul unei aplicații Messenger care rulează în browserul său. „Messenger” aici
acționează ca stratul de aplicație care oferă utilizatorului o interfață pentru a crea datele.
Acest mesaj sau așa numitul Date este comprimat, criptat (dacă există date securizate) și
convertit în biți (0 și 1), astfel încât să poată fi transmis.
6. Stratul de prezentare (Stratul 6):
Stratul de prezentare se mai numește și stratul de traducere. Datele din stratul de aplicație
sunt extrase aici și manipulate conform formatului necesar pentru a fi transmise prin rețea.
Funcțiile stratului de prezentare sunt:

1. Traducere: De exemplu, de la ASCII la EBCDIC.
2. Criptare/Decriptare: Criptarea datelor traduce datele într-o altă formă sau cod.
Datele criptate sunt cunoscute ca text cifrat, iar datele decriptate sunt cunoscute ca
text simplu. O valoare cheie este utilizată atât pentru criptarea, cât și pentru
decriptarea datelor.
3. Compresie: Reduce numărul de biți care trebuie să fie transmiși în rețea.
7. Stratul de aplicare (Stratul 7):

În partea de sus a stivei de straturi ale modelului de referință OSI, găsim stratul de
aplicație care este implementat de aplicațiile de rețea. Aceste aplicații produc datele, care
trebuie să fie transferate prin rețea. Acest strat servește și ca fereastră pentru serviciile
aplicației pentru a accesa rețeaua și pentru afișarea informațiilor primite către utilizator.
Ex: Aplicație – Browsere, Skype Messenger etc.
** Stratul de aplicație este numit și Strat de desktop.
Funcțiile stratului Aplicație sunt:

1. Terminal virtual de rețea
1. FTAM-Acces și gestionarea transferului de fișiere
2. Servicii de corespondență
3. Servicii de director
Modelul OSI acționează ca un model de referință și nu este implementat în Internet din
cauza invenției sale târzii. Modelul curent utilizat este modelul TCP/IP.
Securitate pe straturi diferite

Internet Protocol Security (IPsec)

Securitatea protocolului Internet (IPsec) este un set de protocoale care asigură securitatea
protocolului Internet. Poate folosi criptografie pentru a oferi securitate. IPsec poate fi utilizat
pentru configurarea rețelelor private virtuale (VPN) într-o manieră sigură.
Cunoscut și ca IP Security.
IPsec implică două servicii de securitate:
• Antet de autentificare (AH): Acesta autentifică expeditorul și descoperă orice modificări ale
datelor în timpul transmiterii.
• Încărcătura utilă de securitate încapsulată (ESP): Aceasta nu numai că realizează
autentificarea expeditorului, ci și criptează datele trimise.
Există două moduri de IPsec:
• Modul tunel: Acest lucru va lua întregul pachet IP pentru a forma o comunicare securizată
între două locuri sau gateway-uri.
• Mod de transport: Acesta încapsulează doar sarcina utilă IP (nu întregul pachet IP ca în
modul tunel) pentru a asigura un canal de comunicare securizat.
Comutarea etichetelor multiprotocol (MPLS)
Multiprotocol Label Switching (MPLS) este un mecanism utilizat în infrastructurile de rețele de
calculatoare pentru a accelera timpul necesar unui pachet de date pentru a trece de la un nod la
altul. Permite rețelelor de calculatoare să fie mai rapide și mai ușor de gestionat prin utilizarea
etichetelor de cale scurtă în loc de adrese lungi de rețea pentru rutarea pachetelor de rețea.
MPLS implementează și utilizează în primul rând etichete pentru luarea deciziilor de rutare.
Mecanismul de comutare bazat pe etichete permite pachetelor de rețea să circule pe orice

protocol. MPLS funcționează prin atribuirea unei etichete sau un identificator unic fiecărui
pachet de rețea. Eticheta constă din informațiile din tabelul de rutare, cum ar fi adresa IP de
destinație, lățimea de bandă și alți factori, precum și IP-ul sursă și informații despre socket.
Routerul se poate referi doar la etichetă pentru a lua decizia de rutare, mai degrabă decât să se
uite în pachet. MPLS acceptă IP, modul de transfer asincron (ATM), frame relay, rețele optice
sincrone (SONET) și rețele bazate pe Ethernet. MPLS este conceput pentru a fi utilizat atât în
rețelele cu comutare de pachete, cât și în rețelele cu comutație de circuite.
IDS
Înseamnă „Sistem de detectare a intruziunilor”. Un IDS monitorizează traficul de rețea pentru
activități suspecte. Poate fi compus din hardware , software sau o combinație a celor două. IDSe-
urile sunt similare cu firewall-urile , dar sunt concepute pentru a monitoriza traficul care a intrat
într-o rețea, mai degrabă decât să împiedice accesul complet la o rețea. Acest lucru permite IDSe-
urilor să detecteze atacurile care provin din interiorul unei rețele.
Un sistem de detectare a intrusilor poate fi configurat fie pentru o rețea, fie pentru un anumit
dispozitiv. Un sistem de detectare a intruziunilor în rețea (NIDS) monitorizează traficul de intrare
și de ieșire, precum și transferurile de date între sistemele dintr-o rețea. NIDS-urile sunt adesea
răspândite în mai multe puncte diferite ale unei rețele pentru a vă asigura că nu există lacune în
care traficul poate fi nemonitorizat.
Un IDS configurat pentru un singur dispozitiv se numește sistem de detectare a intruziunilor

gazdă sau HIDS. Monitorizează o singură gazdă pentru modele anormale de trafic. De exemplu,
poate căuta viruși sau programe malware cunoscute atât în traficul de intrare, cât și în cel de
ieșire. Unele HIDS verifică chiar pachetele pentru fișiere de sistem importante pentru a se asigura
că nu sunt modificate sau șterse.
Atât ID-urile de rețea, cât și cele de gazdă sunt concepute pentru a detecta intruziunile și a suna o
alertă. Această alertă poate fi trimisă unui administrator de rețea sau poate fi procesată de un
sistem automat. Un sistem care gestionează automat alertele de intruziune se numește IDS reactiv
sau sistem de prevenire a intruziunilor (IPS).
Firewall
Un firewall este un software folosit pentru a menține securitatea unei rețele private. Firewall-urile
blochează accesul neautorizat la sau din rețelele private și sunt adesea folosite pentru a împiedica
utilizatorii web neautorizați sau software-ul ilicit să obțină acces la rețelele private conectate la
Internet. Un firewall poate fi implementat folosind hardware, software sau o combinație a
ambelor.
Un firewall este recunoscut ca prima linie de apărare în securizarea informațiilor sensibile. Pentru
o mai bună siguranță, datele pot fi criptate.
Firewall-urile folosesc, în general, două sau mai multe dintre următoarele metode:
• Filtrarea pachetelor: firewall-urile filtrează pachetele care încearcă să intre sau să părăsească
o rețea și fie le acceptă, fie le resping, în funcție de setul predefinit de reguli de filtrare.
• Gateway de aplicație: Tehnica de gateway de aplicație folosește metode de securitate aplicate
anumitor aplicații, cum ar fi serverele Telnet și File Transfer Protocol.
• Gateway la nivel de circuit: Un gateway la nivel de circuit aplică aceste metode atunci când se
stabilește o conexiune precum Protocolul de control al transmisiei și pachetele încep să se
deplaseze.
• Servere proxy: serverele proxy pot masca adresele de rețea reale și pot intercepta fiecare
mesaj care intră sau iese dintr-o rețea.
• Inspecție cu stare sau filtrare dinamică a pachetelor: Această metodă compară nu doar
informațiile din antet, ci și cele mai importante părți de date de intrare și de ieșire ale unui pachet.
Acestea sunt apoi comparate cu o bază de date de informații de încredere pentru potrivirile
caracteristice. Aceasta determină dacă informațiile sunt autorizate să traverseze firewall-ul în
rețea.
Amenințare
O amenințare, în contextul securității computerului, se referă la orice lucru care are potențialul
de a provoca daune grave unui sistem informatic. O amenințare este ceva care se poate
întâmpla sau nu, dar are potențialul de a provoca daune grave. Amenințările pot duce la atacuri
asupra sistemelor informatice, rețelelor și altele.
Amenințările sunt potențialele ca vulnerabilitățile să se transforme în atacuri asupra sistemelor
informatice, rețelelor și altele. Acestea pot pune în pericol sistemele de calculatoare ale
persoanelor și computerele de afaceri, astfel încât vulnerabilitățile trebuie remediate, astfel
încât atacatorii să nu se infiltreze în sistem și să nu provoace daune.
Amenințările pot include totul, de la viruși, troieni, uși din spate până la atacuri directe ale
hackerilor. Adesea, termenul de amenințare combinată este mai precis, deoarece majoritatea
amenințărilor implică mai multe exploatări. De exemplu, un hacker poate folosi un atac de tip
phishing pentru a obține informații despre o rețea și a pătrunde într-o rețea.
O amenințare și o vulnerabilitate nu sunt una și aceeași. O amenințare este o persoană sau un

eveniment care are potențialul de a afecta o resursă valoroasă într-un mod negativ. O
vulnerabilitate este acea calitate a unei resurse sau a mediului ei care permite realizarea
amenințării. Un jefuitor de bănci înarmat este un exemplu de amenințare. Un casier de bancă
este un exemplu de resursă valoroasă care poate fi vulnerabilă în timpul unui jaf de bancă.
Sticla antiglonț între tâlhar și casier îi interzice tâlharului să-l împuște pe casier. Amenințarea
rămâne prezentă, dar unul dintre efectele sale nocive (o împușcătură) a fost atenuat de un
mecanism de protecție (sticlă).
În securitatea sistemului și a rețelei, amenințările rămân prezente, dar sunt atenuate prin
utilizarea adecvată a caracteristicilor și procedurilor de securitate. Atenuarea este orice efort de
a preveni amenințarea să aibă un impact negativ sau de a limita daunele acolo unde prevenirea
totală nu este posibilă sau de a îmbunătăți viteza sau eficacitatea efortului de recuperare.
Sistemele hardware și software și datele pe care le procesează pot fi vulnerabile la o mare
varietate de amenințări. Selecția caracteristicilor și procedurilor de securitate trebuie să se
bazeze nu numai pe obiective generale de securitate, ci și pe vulnerabilitățile specifice ale
sistemului în cauză, în lumina amenințărilor la care este expus sistemul. Este posibilă
supraprotejare, ceea ce doar irosește resurse și deranjează utilizatorii.
După cum puteți vedea, există o relație între amenințări și vulnerabilități. Uneori este mai ușor
să examinați fiecare potențială amenințare și să determinați în ce măsură sunteți vulnerabil (de
exemplu, incendiu, inundație, cutremur). În alte cazuri, este mai ușor să căutați potențiale
vulnerabilități fără a avea în vedere nicio amenințare specială (de exemplu, montarea
necorespunzătoare a echipamentului, defecțiunea media, eroarea de introducere a datelor).
Pentru a ajunge la o evaluare completă a riscurilor, ambele perspective trebuie examinate.
Amenințările și vulnerabilitățile sunt amestecate în lista următoare și pot fi denumite în mod
colectiv potențiale „preocupări de securitate”.
Pentru ușurință în discuție și utilizare, preocupările pot fi împărțite în patru categorii.
Preocupările de mediu includ evenimente nedorite specifice locului, cum ar fi fulgerele, praful
și activarea sprinklerelor. Preocupările fizice includ acțiuni nedorite ale personalului specifice
locației, fie intenționate, fie neintenționate, cum ar fi furtul, vandalismul și pericolele de
împiedicare. Preocupările legate de asistența pe amplasament includ aspecte de bază ale site-
ului, cum ar fi energia electrică, serviciul telefonic și controlul climatului. Aceste trei categorii
de preocupări nu sunt, în general, rezolvabile ca parte a proiectării și administrării sistemului -
ele sunt abordate mai adecvat ca parte a proiectării și întreținerii instalației, cuprinzând astfel
toate sistemele prezente.
Ultima categorie, Preocupări tehnice, include situații insidioase specifice sistemului, cum ar fi
funcționarea necorespunzătoare a sistemului, software rău intenționat și atingerea liniilor.
Amenințările reale sunt puține: Compilat de Srinivas Kante Email: srinivaskante4u@gmail.com

utilizatori neinstruiți și nelegiuiți și calamități ale sistemului. Este mult mai util să explorați
numeroasele căi (vulnerabilități) deschise acestor utilizatori și evenimente și să luați în
considerare modalități de a preveni aceste apariții și/sau de a asigura o recuperare rapidă.
Următoarea listă este menită să fie utilizată ca punct de plecare în orice evaluare a riscurilor
IT. Fiecare problemă potențială trebuie evaluată pentru un anumit site sau sistem pentru a
determina măsura în care se aplică. Probabilitatea apariției acestuia, împreună cu impactul
proiectat al evenimentului și costul atenuării adecvate, generează o listă prioritizată de
preocupări de securitate care ar trebui abordate.
Mediu (apariții nedorite specifice locului)
• Foc
• Potop
• Tsunami
• Cutremur
• Erupții vulcanice
• Fulger
• Vreme rea
• Fum
• Praf
• Insecte
• rozătoare
• Fumi chimici
• Activarea sprinklerului
• Scurgeri de apă - ruperea conductei, gaură în acoperiș, condens
• Explozie - conductă de gaz în apropiere, uzină chimică, fermă de rezervoare, depozit de
muniție
• Vibrații - cale ferată în apropiere, trafic cu avioane, șantier
• Interferențe electromagnetice - sugerate de recepția radio slabă sau de afișajele stației de
lucru agitate
• Descărcare electrostatică - sugerată prin „scântei” obiectelor legate la pământ
Fizice (acțiuni nedorite ale personalului specifice locului)
• Acces neautorizat la facilitate
• Furt
• Vandalism
• Sabotaj
• Extorcare
• Terorism / Amenințare cu bombă
• Labor Unrest - angajați și contractori de sprijin
• Război / Tulburări civile
• Transport necorespunzător - echipament scăpat, scufundat, expus la intemperii sau radiat
în timpul tranzitului
• Montare/Depozitare necorespunzătoare - echipament expus la lovituri, lovituri sau
intemperii
• Stropire/Păcare - materiale periculoase permise lângă echipamente (de exemplu, alimente,
lichide)
• Magneți / Instrumente magnetice - pot șterge datele sau pot deteriora echipamentele
sensibile
• Coliziune - stivuitor, auto, avion, scaun cu rotile

• Pericole de deplasare / Căderi - echipamentul prezintă pericole pentru personal
• Pericole de incendiu - materiale inflamabile depozitate în apropiere
Site-Support (aspecte de bază ale site-ului)
• Pana de curent
• Temperaturi extreme/instabile
• Umiditate extremă / instabilă
• Mediu nesigur - impropriu ocupației umane
• Inaccesibilitatea instalației - intrare blocată
• Incapacitatea de a întrerupe puterea - în timpul incendiului, inundației etc.
• Zgomot electric / pământ defectuos - sugerat de lumini pâlpâitoare sau de afișaje agitate
ale stației de lucru
• Întreținere necorespunzătoare - asistență necalificată sau întreținere preventivă întârziată
• Indisponibilitatea personalului - incapacitatea de a contacta operațiunile sau personalul de
asistență
• Eșec la telefon - incapacitatea de a contacta site-ul din exterior, incapacitatea de a apela,
serviciul complet indisponibil
• Suprimare inadecvată a incendiilor - apă, spumă, PKP, halon
• Eliminare inadecvată a gunoiului - date sensibile eliberate într-o manieră neautorizată
Tehnic (situații insidioase specifice sistemului)
• Procedură necorespunzătoare / inadecvată - evenimente previzibile care nu sunt susținute
de documentație și instruire complete și exacte
• Operare necorespunzătoare - operarea echipamentelor peste capacitate sau în afara
constrângerilor producătorului
• Configurație hardware necorespunzătoare - hardware prescris configurat în alt mod decât
cel prescris în timpul instalării
• Configurare software necorespunzătoare - software prescris configurat în alt mod decât cel
prescris în timpul instalării
• Hardware/Modificare neautorizată - adăugarea de hardware diferit de cea prescrisă sau
efectuarea de modificări hardware neautorizate
• Software/Modificare neautorizată - adăugarea unui software diferit de cel prescris sau
efectuarea modificărilor software neautorizate
• Duplicare neautorizată de software - crearea de copii ale software-ului licențiat care nu
sunt acoperite de o licență valabilă
• Acces logic neautorizat - obținerea utilizării unui sistem pentru care nu a fost autorizat
accesul (spre deosebire de obținerea accesului fizic la hardware)
• Abatere (depășirea autorizațiilor) - dobândirea utilizării unui sistem în exces față de cel
care a fost autorizat
• Utilizare neautorizată / Depășirea licenței - utilizarea resurselor de sistem autorizate în
scopuri neautorizate (cv, buletin bisericesc, e-mail sau navigare pe internet care nu au legătură
cu locul de muncă) sau depășirea unui acord de licență pentru utilizator
• Supra sau Sub-clasificare - etichetarea unei resurse la un nivel mai mare sau mai mic de
sensibilitate decât este adecvat
• Software rău intenționat - software al cărui scop este de a degrada performanța sistemului,
de a modifica sau de a distruge date, de a fura resurse sau de a submina securitatea în orice
mod
• Hardware Error / Failure [funcționalitate] - hardware care încetează să ofere

serviciile/resursele dorite de utilizator
• Hardware Error / Failure [securitate] - hardware care nu mai oferă serviciile/resursele de
securitate dorite
• Software Error / Failure [funcționalitate] - software care încetează să ofere
serviciile/resursele dorite de utilizator
• Software Error / Failure [securitate] - software care nu mai oferă serviciile/resursele de
securitate dorite
• Media Failure - suport de stocare care nu mai reține informațiile stocate într-un mod
recuperabil/intact
• Data Remanence - suport de stocare care reține informațiile stocate într-o manieră
recuperabilă/intactă mai mult decât se dorește (eșecul ștergerii totale)
• Object Reuse - un sistem care furnizează utilizatorului un obiect de stocare (de exemplu,
memorie sau spațiu pe disc) care conține informații utile aparținând altui utilizator
• Eșec/supraîncărcare de comunicații - o facilitate de comunicații care încetează să furnizeze
serviciul sau nu poate furniza serviciul la capacitatea solicitată
• Eroare de comunicații - o facilitate de comunicații care oferă servicii incorecte
• Eroare de introducere a datelor - un sistem care acceptă date eronate ca fiind legitime
• Modificare/Ștergere accidentală a software-ului - ștergerea sau, în alt mod,
indisponibilitatea software-ului necesar
• Modificare/Ștergere accidentală a datelor - ștergerea sau, în alt mod, indisponibilitatea
datelor necesare
• Dezvăluirea accidentală a datelor - dezvăluirea din greșeală a datelor sensibile unui
utilizator neautorizat
• Repudie - participarea la un proces sau tranzacție, dar apoi neagă să fi făcut acest lucru
• Masquerading - participarea la un proces sau tranzacție, dar dându-se drept alt utilizator
• Redarea mesajelor - înregistrarea unei transmisii legitime pentru retransmitere mai târziu,
în încercarea de a obține privilegii neautorizate
• Inundarea mesajelor - generarea unei cantități excesiv de mare de transmisii în încercarea
de a face un sistem sau serviciu indisponibil din cauza supraîncărcării
• Line Tapping - conectarea la o facilitate de comunicații într-un mod neautorizat în
încercarea de a culege informații utile
• Emanații electronice - emisii nocive purtătoare de informații asociate cu toate
echipamentele electronice (prevenite de echipamente sau de ecranare TEMPEST)
• Geo-locație - un sistem care dezvăluie din neatenție locația fizică curentă a unui utilizator
Amenințări cibernetice
Urmărirea cibernetică:
Urcarea cibernetică este o practică criminală în care o persoană folosește internetul pentru a
hărțui sau a amenința în mod sistematic pe cineva. Această infracțiune poate fi săvârșită prin e-
mail, rețele sociale, camere de chat, clienți de mesagerie instantanee și orice alt mediu online.
De asemenea, poate apărea și urmărirea cibernetică
în combinație cu forma mai tradițională de urmărire, în care infractorul hărțuiește victima

offline. Nu există o abordare juridică unificată a urmăririi cibernetice, dar multe guverne au
făcut aceste practici pedepsite prin lege.
Urcarea cibernetică este uneori denumită urmărire pe Internet, urmărire electronică sau
urmărire online
NUMELE DE DOMENIU:
Adresa IP :
Internetul este o rețea de calculatoare. Fiecare computer din rețeaua menționată are propria sa
entitate și prezență distinctă. Acesta este motivul pentru care fiecărui computer i se atribuie o
adresă electronică distinctă numită adresă de protocol Internet sau, pe scurt, adresă IP. Această
adresă IP este dată de valori numerice precum 202.54.15.75. Adresa IP este la fel ca orice
număr de telefon care identifică un anumit computer de pe Internet.
Numele domeniului :
Deoarece nu este posibil să reținem fiecare valoare numerică a unei adrese IP, sistemul de
nume de domenii a evoluat. Numele de domenii de internet, în limbajul unui om obișnuit, sunt
folosite ca un alias ușor de reținut, care indică o anumită adresă IP. Scopul dominant al
numelui de domeniu este pur și simplu acela de a oferi o metodă ușoară de a reține adresa
electronică a altuia. Este un nume unic folosit pentru a identifica, printre altele, un anumit site
Web. Astfel, un nume de domeniu tipic ar fi http://www.iibf.org
Componentele unui nume de domeniu:
Orice nume de domeniu este format din două componente, și anume numele de domeniu de
nivel superior (TLD) și un nume de domeniu de nivel al doilea. Astfel, în exemplul menționat,
http://www.iibf.org , „.org” ar fi numele de domeniu de nivel superior, în timp ce „iibf” ar fi
numele de domeniu de nivel al doilea.
Categorii de nume de domeniu de nivel superior (TLD-uri)
Ca și în prezent, există două categorii de nume de domenii de nivel superior. În prima categorie
intră numele de domenii .com, .net, .org, .edu. Când a început sistemul de înregistrare a
numelor de domenii, normele erau ca numele .com să fie dat organizațiilor comerciale, în timp
ce altele precum .org, .net, .gov și .edu să fie atribuite organizațiilor necomerciale, furnizorii de
rețele, agențiile guvernamentale și, respectiv, instituțiile de învățământ. Cu toate acestea, odată
cu trecerea timpului, din cauza volumelor sporite de înregistrări de nume de domeniu, normele
menționate au fost abandonate și astăzi oricine poate, fără nicio restricție de niciun fel, să
înregistreze orice nume de domeniu.
A doua categorie de nume de domenii de nivel superior este TLD-urile de cod de țară notate cu
un cod de țară de două litere. De exemplu, numele de domeniu de nivel superior pentru India
este .in. Responsabilitatea pentru atribuirea acestora este dată în fiecare țară unui registrator de
nume de domeniu de țară specificată. În India, TLD.in este înregistrat de NCST la Bombay.
Numele de domenii au fost înregistrate inițial doar de Network Solutions, care avea monopolul
unic pentru a înregistra TLD-urile menționate. Acest monopol al soluțiilor de rețea a continuat
mulți ani și abia în 1999, Internet Corporation a atribuit nume și numere.

(ICANN) a permis altor registratori acreditați să înregistreze nume de domenii. Astăzi există
peste 100 de registratori cu care se poate înregistra un TLD.
Caracteristica unică a numelor de domenii este că numele de domenii menționate sunt date pe
baza „primul venit, primul servit”. Această caracteristică a numelor de domenii dă naștere la
numeroase probleme juridice și dispute. Astfel, lucrul important în înregistrarea numelor de
domenii este viteza. Pentru a lua un exemplu, numele de domeniu www.microsoft.org era
disponibil și a fost înregistrat de Amit Mehrotra cu mult înainte ca Microsoft Corporation să se
gândească la asta. Acest lucru a dus la numeroase probleme juridice gâdilatoare. Microsoft
Corporation, deși deține marca comercială Microsoft, nu a putut obține numele de domeniu
www.microsoft.org din cauza criteriilor „primul venit, primul servit” de înregistrare a numelui
de domeniu.
Nume de domeniu diferite de mărcile comerciale:
Pentru a spune simplu, numele de domeniu sunt într-adevăr diferite de mărcile comerciale.
Deși este posibil ca aceeași marcă să fie înregistrată de persoane diferite în diferite categorii și
linii de afaceri diferite, este posibil să se înregistreze un singur nume de domeniu
corespunzător unei astfel de mărci comerciale. Acest aspect al numelor de domenii a dus la
numeroase probleme juridice.
Squatting cibernetic:
O altă problemă juridică în jurul numelor de domenii este cea a Cybersquatting.

Cybersquatting este practica prin care o persoană sau o entitate juridică înregistrează marca
comercială, denumirea comercială sau marca de serviciu a altei persoane ca nume propriu de
domeniu, în scopul de a păstra aceasta și apoi de a vinde același nume de domeniu celeilalte
persoane. pentru o primă și o contraprestație valoroasă. Cibersquatterii își rezervă nume de
domenii ale mărcilor importante în speranța de a câștiga milioane rapid.
Tendințele recente legate de abordarea cybersquatterilor
Istoria internetului a arătat că, în timp ce unii jucători corporativi au fost dispuși și într-adevăr
au scos bani pentru a-și recupera numele de domenii legitime, tendința recentă este mai
degrabă să ia de coarne pe cei cibernetici și să-i lupte prin procese legale. Instanțele din
întreaga lume, inclusiv din India, au fost proactive și au acordat ordonanțe pentru a opri
ocupanții cibernetici să își opereze site-urile web.
Cel mai recent remediu eficient împotriva Cybersquatting-ului
Cea mai recentă gură de aer proaspăt în lupta împotriva cybersquatting-ului a fost Politica
uniformă de soluționare a litigiilor privind numele de domeniu, care a fost aprobată în mod
corespunzător de ICANN. În conformitate cu Politica de soluționare a litigiilor privind numele
de domeniu menționată, este adoptată o procedură sumară pentru a soluționa plângerea
oricărui reclamant referitoare la orice nume de domeniu la plata taxelor de procesare. Această
politică este în vigoare de la sfârșitul anului trecut .
Conform politicii menționate, companiile indiene încep, de asemenea, să-și recupereze

numele de domenii legitime. Numele de domeniu www.theeconomictimes.com și
www.timesofindia.com a fost recâștigat conform politicii menționate. Două succese recente
pentru companiile indiene în cadrul politicii menționate includ recâștigarea numelor de
domenii www.tata.org și www.philipsindia.com de către TATA și, respectiv, Philips India.
Extorcare cibernetică
Ciberextorcarea este o infracțiune care implică un atac sau amenințarea unui atac cuplată cu o
cerere de bani sau un alt răspuns în schimbul opririi sau remedierii atacului .
Extorcarea cibernetică poate apărea în multe forme diferite, dar, în cel mai simplu mod, este
atunci când cineva online amenință cu un fel de rău, dacă nu îi îndeplinești cerințele.
De exemplu, criminalul cibernetic poate folosi „ransomware” pentru a vă cripta datele, ceea ce
înseamnă că nu vă puteți citi datele fără cheia de criptare – iar criminalul cibernetic va reține
această cheie până la efectuarea plății.
Astăzi, atacurile distribuite de refuzare a serviciului (DDoS) sunt painea și untul

extorsionatorilor cibernetici. Acesta este un atac în care...
Un hacker copleșește serverul unei ținte cu trafic rău intenționat. De obicei, atacatorul va folosi
o rețea botnet (adică o rețea de computere infectate) pentru a genera un flux de trafic pe server.
Traficul trimite mai multe solicitări de conectare decât poate gestiona un server. Sau, botnet-ul
trimite țintei cantități uriașe de date pentru a-și folosi lățimea de bandă .
Site-ul țintei este închis. Credeți sau nu, unii oameni plătesc estorcatorii pentru a reduce la
tăcere site-urile care nu le plac. Închiderea unui site mic sau menținerea unei mici organizații
offline timp de o săptămână poate costa până la 10000/-
Dacă o afacere nu îndeplinește cerințele extortionistului, hackerul ar putea menține site-ul

offline suficient de mult pentru a rula afacerea în pământ. Sau, hackerul poate să acceseze de la
distanță panourile de control și să înceapă să ștergă fișierele necesare pentru a menține site-ul
sau afacerea în funcțiune.
Deci, ce riscă să fie „ținut ostatic” de atacatorii cibernetici?
Oricare dintre dvs.…
Site-uri web.
Sisteme informatice.
Severs.
Atacatorii vor înceta și vor renunța doar când cererile lor vor fi îndeplinite. Deoarece
majoritatea întreprinderilor mici funcționează cu ajutorul computerelor, extorcarea cibernetică
este o problemă în creștere.
Razboi cibernetic
Războiul cibernetic este orice conflict virtual inițiat ca un atac motivat politic asupra
computerelor și sistemelor informaționale ale unui inamic. Desfășurate prin internet, aceste
atacuri dezactivează financiar și

sisteme organizaționale prin furtul sau modificarea datelor clasificate pentru a submina
rețelele, site-urile web și serviciile.
Războiul cibernetic este cunoscut și ca război cibernetic sau război cibernetic.
Războiul cibernetic implică următoarele metode de atac:

• Sabotaj: sistemele informatice militare și financiare sunt expuse riscului de a întrerupe
operațiunile și echipamentele normale, cum ar fi infrastructurile de comunicații, combustibil,
energie și transport.
• Spionaj și/sau încălcări ale securității: Aceste metode ilegale de exploatare sunt folosite
pentru a dezactiva rețele, software-ul, computerele sau internetul pentru a fura sau obține
informații clasificate de la instituții sau persoane rivale în scopul câștigurilor militare, politice
sau financiare.
Terorism cibernetic
Un atac premeditat împotriva unui sistem informatic, a datelor informatice, a programelor și
a altor informații cu unicul scop de violență împotriva agenților clandestini și a grupurilor
subnaționale. Scopul principal din spatele terorismului cibernetic este de a provoca vătămări și
distrugeri.
Terorismul cibernetic poate fi explicat ca terorism pe internet. Odată cu apariția internetului,
indivizii și grupurile folosesc abuziv anonimatul pentru a amenința persoane, anumite grupuri,
religii, etnii sau credințe. Terorismul cibernetic poate fi clasificat în trei mari categorii:
• Simplu: Acesta constă în atacuri de bază, inclusiv hacking-ul unui sistem individual.
• Avansat: Acestea sunt atacuri mai sofisticate și pot implica piratarea mai multor sisteme
și/sau rețele.
• Complex: Acestea sunt atacuri coordonate care pot avea un impact pe scară largă și pot
folosi instrumente sofisticate
ATACURI SOFTWARE de către
Virus
Un virus este un tip de software rău intenționat (malware) format din bucăți mici de cod
atașate unor programe legitime. Când rulează acel program, virusul rulează.
Virușii sunt programe rău intenționate care se răspândesc în fișierele computerului fără
cunoștințele utilizatorului. Cele mai răspândite infecții cu virusuri se răspândesc prin
atașamentele mesajelor de e-mail care se activează atunci când sunt deschise. Cercul vicios al
unui virus se perpetuează pe măsură ce e-mailurile infectate sunt redirecționate către mai mulți
utilizatori. Virușii se răspândesc și prin medii partajate, cum ar fi unitățile Universal Serial Bus
(USB).
Creați inițial ca farse, virușii sunt responsabili pentru distrugerea pe scară largă și
semnificativă a sistemului informatic și a fișierelor. Instalarea software-ului antivirus ajută la
prevenirea, blocarea sau eliminarea virușilor instalați anterior
Vierme
Un vierme este un tip de software rău intenționat (malware) care se reproduce în timp ce se
deplasează pe computere, lăsând copii ale lui în memoria fiecărui computer aflat în cale.
Un vierme localizează vulnerabilitatea unui computer și se răspândește în rețeaua sa conectată

ca o infecție, în timp ce caută în permanență noi vulnerabilități. La fel ca virușii, viermii
provin adesea din atașamentele de e-mail care par a fi de la expeditori de încredere. Viermii se
răspândesc apoi la contactele unui utilizator prin contul său de e-mail și agenda.
Unii viermi se răspândesc și apoi nu fac nimic în timp ce ei provoacă rău. În astfel de cazuri,
codul viermelui este cunoscut ca sarcină utilă.
Software rău intenționat (malware)

Software-ul rău intenționat, cunoscut în mod obișnuit ca malware, este orice software care
dăunează unui sistem informatic. Programele malware pot fi sub formă de viermi, viruși,
troieni, spyware, adware și rootkit-uri etc., care fură date protejate, șterg documente sau
adaugă software neaprobat de un utilizator.
Malware este un software conceput pentru a dăuna computerului și utilizatorului. Unele forme
de malware „spionează” traficul de internet al utilizatorilor. Exemplele includ spyware și
adware. Spyware-ul monitorizează locația unui utilizator și, dacă este activat, poate captura
informații sensibile, de exemplu, numere de card de credit, promovând furtul de identitate.
Adware-ul achiziționează, de asemenea, informații despre utilizator, care sunt partajate cu
agenții de publicitate și apoi integrate cu anunțuri pop-up nedorite, declanșate.
Viermii și virușii se comportă diferit, deoarece pot prolifera rapid și pot submina un întreg
sistem informatic. De asemenea, aceștia pot efectua activități neplăcute de pe computerul unui
utilizator fără știrea acestuia. În urma unui virus sau vierme, un sistem informatic poate suferi
daune semnificative.
Anti-malware ar trebui să determine dacă există amenințări prin scanarea unui computer și
eliminarea acestora, dacă este găsită. Prevenirea este mai bună decât acțiunea corectivă după
infecție. Deși programele anti-virus ar trebui să fie activate și actualizate în mod continuu,
anumite tipuri de amenințări, cum ar fi programele spion, adesea își fac loc într-un sistem
informatic.
În orice moment, ar trebui să existe un firewall pentru securitate suplimentară. Mai multe surse
de protecție compatibile sunt încurajate ca asigurare suplimentară împotriva programelor
malware.
Adware
Adware este un software de calculator gratuit care conține reclame comerciale. Programele
adware includ jocuri, bare de instrumente desktop sau utilitare. În mod obișnuit, adware-ul
este bazat pe web și colectează date ale browserului web pentru a viza reclame, în special
ferestre pop-up.
Adware este, de asemenea, cunoscut sub numele de freeware și pitchware.
Adware-ul este clasificat după cum urmează:
• Legitim: reclame gratuite sau de probă sponsorizate de produse

• Spyware: Urmărește preferințele site-ului utilizatorului și compromite confidențialitatea

Adware-ul poate părea inofensiv și oferă utilizatorilor software de afaceri legitim, dar apoi
lansează programe spion care colectează date de căutare din browser pentru reclame specifice
utilizatorului.
Dezinstalarea adware-ului necesită, în general, software anti-adware. Sunt disponibile o

varietate de versiuni gratuite și plătite, dar adware-ul licențiat este cel mai fiabil, agresiv și
recomandat. Software-ul anti-adware este, de asemenea, inclus în pachetele de scanare
antivirus.
Cal troian
Un cal troian este un program aparent benign care, atunci când este activat, dăunează unui
sistem informatic.
Un cal troian este cunoscut și ca virus troian sau troian.
Calul troian este numit după darul aparent al păcii oferit de Grecia antică troienilor, când un
cal uriaș de lemn era umplut în secret cu războinici greci. După ce troienii au permis calului să
intre în marele lor oraș, războinicii greci au ieșit din cal au câștigat controlul asupra orașului
Troia.
Următoarele sunt tipuri de cai troieni:
• Backdoor Troian : deschide o ușă din spate pentru ca un utilizator să acceseze sistemul
unei victime mai târziu
• Descărcător : Acest troian descarcă software rău intenționat și dăunează victimei
sistem informatic.
• Infostealer : Acest troian încearcă să fure informații de pe computerul victimei.
• Remote Access Trojan (RAT ): Acesta poate fi ascuns în jocuri sau alte programe de o
varietate mai mică și poate oferi atacatorului controlul computerului victimei.
• Troian de trimitere a datelor : Acesta oferă făptuitorului informații sensibile, cum ar fi
parole sau alte informații programate pentru a fi deturnate.
• Troian distructiv : Acesta distruge fișierele victimei.
• Troian proxy : Ca server proxy, acesta permite atacatorului să deturneze computerul
victimei și să desfășoare activități ilegale de pe computerul victimei.
Spyware
Spyware este un software de infiltrare care monitorizează în secret utilizatorii nebănuiți.
Acesta poate permite unui hacker să obțină informații sensibile, cum ar fi parole, de la
computerul utilizatorului. Programele spion exploatează vulnerabilitățile utilizatorilor și ale
aplicațiilor și sunt adesea atașate la descărcări gratuite de software online sau la link-uri pe
care utilizatorii le fac clic.
Partajarea de fișiere peer-to-peer (P2P) a crescut proliferarea programelor spyware și
ramificațiile acestuia.
Aplicațiile anti-spyware localizează și elimină programele spion și sunt recomandate ca linie
de apărare preventivă împotriva infiltrațiilor și deteriorării.
Software-ul antivirus elimină virușii de pe computer, dar scanările antivirus nu detectează
întotdeauna programele spion. Programele spyware și modulele cookie sunt similare, dar
programul spyware desfășoară activitate de infiltrare în mod continuu până când este eliminat
de anumite instrumente anti-spyware.
Utilizatorii ar trebui să ia următoarele măsuri de precauție pentru a preveni atacurile spyware:
• Mențineți actualizări și corecții antivirus și anti-spyware.

• Descărcați numai de pe site-uri cunoscute și de renume.

• Utilizați un firewall pentru securitate sporită
Internet Bot
Un bot de internet, în sensul său cel mai generic, este un software care realizează o sarcină
automată prin Internet. Mai precis, un bot este o aplicație automatizată folosită pentru a efectua
sarcini simple și repetitive care ar fi consumatoare de timp, banale sau imposibil de realizat
pentru un om.
Boții pot fi folosiți pentru sarcini productive, dar sunt folosiți frecvent și în scopuri rău
intenționate.
Termenul „bot” provine de la robot. Un bot de internet poate fi cunoscut și ca robot web sau
robot WWW.
Unul dintre cele mai bune exemple de robot bun este un păianjen al motorului de căutare.
Astfel de roboți caută pe Web și indexează pagini noi pentru un motor de căutare. Alte
exemple includ boții de chat și chatterbot originali.
Boții rău intenționați sunt de obicei amenințări combinate care apar ca parte virus/vierme,
parțial bot și sunt utilizați în cazul furtului de identitate sau pentru a lansa atacuri de denial of
service. Acest lucru este predominant în special într-o rețea bot, care este o grupare de
computere care sunt toate infectate cu un bot rău intenționat. Alte utilizări ilegale, sau cel puțin
discutabile, implică roboți care recoltează adrese de e-mail pentru spam, răzuiesc conținut sau
manipulează comentariile/voturile de pe site-uri care permit feedbackul utilizatorilor.
Rootkit
Un rootkit este un software folosit de un hacker pentru a obține acces constant la nivel de
administrator la un computer sau o rețea. Un rootkit este de obicei instalat printr-o parolă furată
sau prin exploatarea vulnerabilităților unui sistem fără consimțământul sau știrea victimei.
Rootkit-urile vizează în primul rând aplicațiile în modul utilizator, dar se concentrează și pe
hypervisorul computerului, kernel-ul sau chiar firmware-ul. Rootkiturile pot dezactiva sau
distruge complet software-ul anti-malware instalat într-un computer infectat, făcând astfel un
atac de rootkit dificil de urmărit și eliminat. Când este făcută bine, intruziunea poate fi ascunsă
cu grijă, astfel încât nici administratorii de sistem să nu fie conștienți de ea.
Rootkiturile pot fi, de asemenea, prezentate ca un troian sau chiar ca un fișier ascuns împreună
cu un fișier aparent inofensiv. Aceasta poate fi o aplicație grafică sau chiar o prostie distribuită
prin e-mail. Când victima face clic pe program sau pe grafic, rootkit-urile sunt instalate pe
sistemul lor fără știrea lor.
Unele dintre efectele rootkit-urilor sunt adesea:
• Oferiți atacatorului acces complet din spate, permițându-i să falsifice sau să fure
documente.
• Ascundeți alte programe malware, în special keyloggers. Keylogger-urile pot fi apoi
folosite pentru a accesa și a fura datele sensibile ale victimei.
• Permiteți atacatorului să folosească mașina infectată ca un computer zombi pentru a
declanșa atacuri asupra altora
Falsificarea
Falsificarea, în general, este o practică frauduloasă sau rău intenționată în care comunicarea
este trimisă dintr-o sursă necunoscută deghizată ca o sursă cunoscută de destinatar. Spoofing-ul
este cel mai răspândit în mecanismele de comunicare cărora le lipsește un nivel ridicat de
securitate.
Falsificarea e-mailului este una dintre cele mai cunoscute falsificări. Deoarece SMTP-ul de
bază nu oferă autentificare, este simplu să falsificați și să vă uzurpați identitatea e-mailurilor.
E-mailurile falsificate pot solicita informații personale și pot părea a fi de la un expeditor
cunoscut. Astfel de e-mailuri solicită destinatarului să răspundă cu un număr de cont pentru
verificare. Spooferul de e-mail folosește apoi acest număr de cont în scopuri de furt de
identitate, cum ar fi accesarea contului bancar al victimei, modificarea detaliilor de contact și
așa mai departe.
Atacatorul (sau spooferul) știe că, dacă destinatarul primește un e-mail falsificat care pare a fi
de la o sursă cunoscută, este probabil să fie deschis și să ia măsuri. Deci, un e-mail falsificat
poate conține și amenințări suplimentare, cum ar fi troieni sau alți viruși. Aceste programe pot
provoca daune semnificative ale computerului prin declanșarea unor activități neașteptate,
acces la distanță, ștergerea fișierelor și multe altele.
Gestionarea incidentelor
Un incident este un eveniment care ar putea duce la pierderea sau întreruperea operațiunilor,
serviciilor sau funcțiilor unei organizații. Managementul incidentelor (IcM) este un termen care
descrie activitățile unei organizații pentru a identifica, analiza și corecta pericolele pentru a
preveni o reapariție viitoare. Aceste incidente din cadrul unei organizații structurate sunt tratate
în mod normal fie de o echipă de răspuns la incident (IRT), de o echipă de gestionare a
incidentelor (IMT) sau de sistemul de comandă a incidentelor (ICS). Fără un management
eficient al incidentelor, un incident poate perturba operațiunile de afaceri, securitatea
informațiilor, sistemele IT, angajații, clienții sau alte funcții vitale de afaceri.
Un incident este un eveniment care ar putea duce la pierderea sau întreruperea operațiunilor,
serviciilor sau funcțiilor unei organizații. Managementul incidentelor (IcM) este un termen care
descrie activitățile unei organizații pentru a identifica, analiza și corecta pericolele pentru a
preveni o reapariție viitoare. Dacă nu este gestionat, un incident se poate transforma într-o
urgență, o criză sau un dezastru. Managementul incidentelor este, așadar, procesul de limitare a
potențialei perturbări cauzate de un astfel de eveniment, urmat de o revenire la activitățile ca de
obicei. Fără un management eficient al incidentelor, un incident poate perturba operațiunile de
afaceri, securitatea informațiilor, sistemele IT, angajații, clienții sau alte funcții vitale de
afaceri. [1]
Managementul incidentelor fizice
Managementul incidentelor este considerat a fi mult mai mult decât o simplă analiză a
amenințărilor și pericolelor percepute la adresa și organizației pentru a determina riscul ca acel
eveniment să se producă și, prin urmare, capacitatea organizației respective de a desfășura
activități ca de obicei în timpul incidentului. O parte importantă a procesului de gestionare a
riscurilor și a planificării rezilienței afacerii, gestionarea incidentelor este o activitate fizică în
timp real.
Planificarea care s-a întâmplat pentru a formula răspunsul la un incident - fie un dezastru, o
urgență, o criză sau un accident - a fost făcută astfel încât să poată avea loc o reziliență efectivă
a afacerii pentru a asigura pierderi sau daune minime, indiferent dacă este vorba de active
corporale sau necorporale. a acelei organizaţii. Gestionarea fizică eficientă a incidentului -
utilizarea cât mai bună a timpului și a resurselor disponibile și înțelegerea modului de a obține
mai multe resurse din afara organizației atunci când este necesar printr-o legătură clară și în
timp util - asigurați-vă că planul este implementat.
National Fire Protection Association afirmă că managementul incidentelor poate fi descris ca:
„[un]n IMS [sistem de management al incidentelor] este „combinația de facilități, echipamente,
personal, proceduri și comunicații care funcționează în cadrul unei structuri organizaționale
comune, concepute pentru a ajuta la managementul resurselor în timpul incidentelor”.
Gestionarea incidentelor fizice este răspunsul în timp real care poate dura ore, zile sau mai
mult. Biroul de Cabinet al Regatului Unit a elaborat Ghidul Național de Recuperare (NRG),
care se adresează respondenților locali, ca parte a implementării Actului Civil Contingencies
din 2004 (CCA). Acesta descrie răspunsul după cum urmează: „Răspunsul cuprinde acțiunile
întreprinse pentru a face față efectelor imediate ale unei urgențe. În multe scenarii, este
probabil să fie relativ scurt și să dureze câteva ore sau zile – implementarea rapidă a
aranjamentelor de colaborare, coordonare și comunicare este, prin urmare, vitală. Răspunsul
cuprinde efortul de a face față nu numai efectelor directe ale situației de urgență în sine (de
exemplu stingerea incendiilor, salvarea persoanelor), ci și efectelor indirecte (de exemplu,
perturbarea, interesul mass-media)”.
Organizația Internațională pentru Standardizare (ISO), care este cel mai mare dezvoltator de
standarde internaționale din lume, menționează, de asemenea, în descrierea documentului ISO
31000 :2009 privind managementul riscurilor, principiile și liniile directoare, că „Folosirea ISO
31000 poate ajuta organizațiile să crească probabilitatea atingerea obiectivelor, îmbunătățirea
identificării oportunităților și amenințărilor și alocarea și utilizarea eficientă a resurselor pentru
tratarea riscurilor”. [7] Acest lucru arată din nou importanța nu doar a unei bune planificări, ci și
a alocării eficiente a resurselor pentru a trata riscul.
Managementul incidentelor de securitate informatică
Astăzi, un rol important îl joacă o echipă de răspuns la incidente de securitate informatică
(CSIRT), din cauza creșterii criminalității pe internet și este un exemplu comun de incident cu
care se confruntă companiile din țările dezvoltate din întreaga lume. De exemplu, dacă o
organizație descoperă că un intrus a obținut acces neautorizat la un sistem informatic, CSIRT
va analiza situația, va determina amploarea compromisului și va lua măsuri
corective.Criminalistica informatică este o sarcină inclusă în acest proces. În prezent, peste
jumătate din tentativele de hacking din lume asupra corporațiilor transnaționale (TNC) au loc
în America de Nord (57%). 23% dintre încercări au loc în Europa. A avea o echipă completă de
răspuns la incidente de securitate informatică este esențială pentru asigurarea unui mediu sigur
pentru orice organizație și devine o parte critică a designului general al multor echipe moderne
de rețea.
Continuitatea afacerii și recuperare în caz de dezastru (BCDR)
Continuitatea afacerii și recuperarea în caz de dezastru (BCDR) sunt practici strâns legate care
descriu pregătirea unei organizații pentru riscuri neprevăzute pentru continuarea operațiunilor
Tendința de a combina continuitatea afacerii și recuperarea în caz de dezastru într-un singur

termen a rezultat dintr-o recunoaștere tot mai mare a faptului că directorii de afaceri și de
tehnologie trebuie să colaboreze strâns în loc să dezvolte planuri izolat.
Care este diferența dintre continuitatea afacerii și recuperarea în caz de dezastru?
Continuitatea afacerii este mai proactivă și se referă în general la procesele și procedurile pe

care o organizație trebuie să le implementeze pentru a se asigura că funcțiile esențiale pentru
misiune pot continua în timpul și după un dezastru. BC implică o planificare mai cuprinzătoare
orientată către provocări pe termen lung pentru succesul unei organizații.
Recuperarea în caz de dezastru este mai reactivă și cuprinde pași specifici pe care o organizație
trebuie să ia pentru a relua operațiunile în urma unui incident. Acțiunile de recuperare în caz de
dezastru au loc după incident, iar timpii de răspuns pot varia de la secunde la zile.
BC se concentrează de obicei pe organizație ca întreg, în timp ce DR se concentrează pe

infrastructura tehnologică. Recuperarea în caz de dezastru este o parte a planificării
continuității afacerii și se concentrează pe accesarea cu ușurință a datelor în urma unui
dezastru. BC include acest element, dar ia în considerare și managementul riscurilor și alte
planuri de care o organizație are nevoie pentru a rămâne pe linia de plutire în timpul unui
eveniment.
Există asemănări între continuitatea afacerii și recuperarea în caz de dezastru. Amândoi iau în
considerare diverse evenimente neplanificate, de la atacuri cibernetice la erori umane până la
un dezastru natural. De asemenea, au scopul de a face afacerea să funcționeze cât mai aproape
de normal, în special în ceea ce privește aplicațiile critice. În multe cazuri, aceeași echipă va fi
implicată atât cu BC, cât și cu DR în cadrul unei organizații.
Importanța BCDR
Pe măsură ce amenințările cibernetice cresc și scade toleranța pentru timpul de nefuncționare,

continuitatea afacerii și recuperarea în caz de dezastru câștigă importanță. Aceste practici
permit unei organizații să se redreseze după ce apar probleme, reduc riscul pierderii de date și
daune reputației și îmbunătățesc operațiunile, reducând în același timp șansele de urgență.
Profesioniștii BCDR pot ajuta o organizație și angajații săi să obțină reziliență. Dezvoltarea
unei strategii este un proces complex care necesită cercetare și analiză, inclusiv efectuarea unei
analize de impact asupra afacerii ( BIA ) și a unei analize de risc , precum și dezvoltarea
planurilor BCDR, teste, exerciții și instruire.

Planurile oferă, de asemenea, informații precum listele de contacte ale angajaților, listele de
contacte în caz de urgență, listele de furnizori, instrucțiuni pentru efectuarea testelor, liste de
echipamente și diagrame tehnice ale sistemelor și rețelelor.
Expertul BCDR Paul Kirvan observă alte câteva motive pentru importanța continuității afacerii
și a planificării recuperării în caz de dezastru:
• Rezultatele BIA identifică oportunități de îmbunătățire a proceselor și modalități în

care organizația poate utiliza mai bine tehnologia;
• Informațiile din plan servesc ca sursă alternativă de documentare;
• Planul oferă o singură sursă de informații cheie de contact; și
• Planul servește ca document de referință pentru utilizarea în planificarea și

proiectarea produselor, proiectarea și livrarea serviciilor și alte activități.
O organizație ar trebui să depună eforturi pentru îmbunătățirea continuă, condusă de procesul

BCDR.
De ce aveți nevoie într-un plan de continuitate a afacerii și de recuperare în caz de

dezastru
Planurile BC și DR au liste de contacte actualizate, atât ale angajaților, cât și ale părților
interesate externe, și proceduri specifice pentru modul de răspuns la anumite situații.
Mai exact, potrivit lui Kirvan, un plan de continuitate a afacerii ( BCP ) conține informații de
contact; proceduri de management al schimbării; orientări despre cum și când să utilizați
planul; proceduri pas cu pas; și un program de revizuire, testare și actualizare. Un plan de
recuperare în caz de dezastru ( DRP ) conține un rezumat al pașilor cheie de acțiune și
informații de contact, responsabilitățile definite ale echipei DR, liniile directoare pentru
momentul în care trebuie utilizat planul, declarația de politică DR, obiectivele planului,
răspunsul la incident și pașii de recuperare, instrumente de autentificare. , riscurile geografice
și istoricul planului.
Planurile bune de continuitate a afacerii și de recuperare în caz de dezastru sunt clare cu privire
la diferitele niveluri de risc pentru organizație; oferiți pași bine definiți și acționați pentru
reziliență și recuperare; proteja angajații, facilitățile și marca organizației; include un plan de
comunicare; și sunt cuprinzătoare în detalierea acțiunilor de la început până la sfârșit.
O politică BCDR este un pas inițial important. Politica stabilește baza procesului și acoperă de
obicei domeniul de aplicare al sistemului de management al continuității afacerii, de care

angajații sunt responsabili pentru acesta și activitățile efectuate, cum ar fi dezvoltarea planului
și afacerile Compilat de Srinivas Kante E-mail: srinivaskante4u@gmail.com
analiza impactului. Aspectul de politică este adesea trecut cu vederea, dar este un element
important de audit al continuității afacerii.
Dezvoltarea BCP și a planului de recuperare în caz de dezastru începe de obicei prin adunarea
membrilor echipei BCDR și efectuarea unei analize de risc și BIA. Organizația identifică cele
mai critice aspecte ale afacerii și cât de repede și în ce măsură trebuie să ruleze după un
incident. După ce organizația scrie procedurile pas cu pas, documentele trebuie testate,
revizuite și actualizate în mod constant.
Deși anumite aspecte ale procesului vor implica membri selecționați ai organizației, este
important ca toată lumea să înțeleagă planul și să fie inclus la un moment dat. Un test al
planului BCDR, de exemplu, este o modalitate bună de a încorpora întreaga organizație.
Rolul analizei de risc, al analizei impactului asupra afacerii și al strategiilor BCDR
Determinarea riscurilor interne și externe este importantă pentru continuitatea afacerii și

procesul de recuperare în caz de dezastru. Analiza riscurilor identifică riscurile și
probabilitatea ca acestea să apară, precum și potențialele daune pe care le-ar putea provoca.
Aceste date sunt utilizate împreună cu rezultatele analizei impactului asupra afacerii.
BIA identifică funcțiile esențiale pentru misiune pe care o organizație trebuie să le mențină sau
să le restabilească în urma unui incident și resursele necesare pentru a susține acele funcții.
Este important să obțineți sprijin managerial în realizarea unui BIA, având în vedere
intensitatea procesului. BIA este o modalitate prin care o organizație poate afla despre ea însăși
și detaliază oportunitățile de îmbunătățire.
O organizație folosește analiza de risc și analiza impactului asupra afacerii pentru a determina
continuitatea afacerii și strategiile de recuperare în caz de dezastru și răspunsurile adecvate.
Fiecare strategie este transformată într-o serie de acțiuni care vor ajuta la realizarea recuperării
operaționale, cum ar fi replicarea datelor, trecerea la un serviciu bazat pe cloud, activarea
rutelor alternative de rețea și lucrul de la distanță.
Managementul schimbării și testarea BCDR
Managementul schimbării supraveghează ajustările la sisteme, rețele, infrastructură și

documente. Acesta abordează situații similare cu planificarea și testarea BCDR, astfel încât o
organizație poate decide să includă continuitatea afacerii și recuperarea în caz de dezastru în
procesul de management al schimbărilor.
Procesul de management al schimbării conține șase activități majore, potrivit lui Kirvan:
1. Identificați o potențială schimbare;
1. analiza cererea de modificare;
2. evaluează schimbarea;
3. planificați schimbarea;
4. implementează schimbarea; și
5. revizuiți și închideți procesul de schimbare.
Întreținerea este un element important. O organizație își îmbunătățește rezistența atunci când
își actualizează planurile BC și DR, apoi le testează continuu.
Cu toate acestea, testarea necesită timp, finanțare, sprijin managerial și participarea angajaților.
Procesul de testare include, de asemenea, planificarea pretestării, instruirea participanților la
test și raportarea testului.
Testele pot varia de la simple la complexe. O revizuire a planului implică o discuție detaliată și
o examinare a documentului, cu ochii pe ceea ce lipsește sau care este problematic. Un test de
masă reunește participanții pentru a parcurge pașii planului, de asemenea, căutând informațiile
lipsă și erorile. Un test de simulare marchează o derulare completă a planului, folosind sisteme
de rezervă și site-uri de recuperare.
Tendințele, standardele și furnizorii de planificare pentru continuitatea activității și recuperarea

în caz de dezastru
BCDR nu mai este doar pentru întreprinderi. Utilizarea cloudului -- recuperarea în caz de
dezastru ca serviciu ( DRaaS ) -- face DR mai accesibilă pentru organizațiile mai mici. Un
furnizor puternic DRaaS poate oferi infrastructură și expertiză în planificarea BCDR. O
organizație trebuie să fie atentă atunci când își selectează furnizorul DRaaS pentru a se asigura
că își îndeplinește nevoile.
Standardele continuă să fie o tendință emergentă, multe fiind dezvoltate în ultimii ani de la
organizații precum Organizația Internațională pentru Standardizare ( ISO ) și Comisia
Electrotehnică Internațională ( IEC ):
• ISO 22301:2012: Sisteme de management al continuității afacerii -- Cerințe
• ISO 22313:2012: Sisteme de management al continuității afacerii -- Ghid

• ISO 22320:2011: Managementul urgențelor -- Cerințe pentru răspunsul la incident
• ISO/IEC 27031:2011: Tehnologia informației -- Tehnici de securitate -- Linii

directoare pentru pregătirea tehnologiei informației și comunicațiilor pentru continuitatea
afacerii
• ISO/IEC 24762:2008: Tehnologia informației -- Tehnici de securitate -- Orientări

pentru serviciile de recuperare în caz de dezastru din tehnologia informației și
comunicațiilor
• ISO 31000: Managementul riscurilor
• Autoritatea de Reglementare a Industriei Financiare 4370: Continuitatea activității

pentru sectorul bancar și financiar
• National Fire Protection Association 1600: Managementul situațiilor de urgență și

continuitatea activității
• Institutul Național de Standarde și Tehnologie Publicație Specială 800-34:

Planificarea de urgență IT
• Societatea Americană pentru Securitate Industrială (ASIS) SPC.1-2009: Ghid privind

rezistența organizațională
• ASIS SPC.4-2012: Sisteme de management al rezilienței organizaționale

Continuitatea afacerii și
planificarea recuperării în caz de dezastru
STRAT DE
INFRASTRUCTUR
Ă
Continuita
A STRATURILE DE
tea afacerii
MANAGEMENT
Afaceri
UN STRAT DE POLITICĂ
Continuita
Politici și te
Strategii
Managementul
riscurilor
Planuri de continuitate a
afacerii
Validare și testare
Procesul de recuperare a tehnologiei

informației Dezastru
Recupera
re
Site alternativ
Backup de date și replicare offsite
Servere Depozit
sounErEEcaST •TIGATON
are
Software-ul BCDR ajută, de asemenea, o organizație să-și construiască planurile de continuitate a activității și de
recuperare în caz de dezastru, facilitând analizele de impact asupra afacerii sau furnizând șabloane de plan. Unele
produse au o funcție automată de notificare de urgență, în timp ce altele permit instruirea.
Furnizorii cheie de pe piață includ eBRP Solutions Network, Everbridge, IBM, Strategic BCP și Sungard
Availability Services. Prețurile variază de la sute de dolari la sute de mii de dolari.
O altă opțiune este de a externaliza nevoile BCDR ale organizației către o firmă de consultanță care poate oferi
evaluări, planificare de dezvoltare și întreținere și instruire. Este de sarcina afacerii să își analizeze nevoile înainte
de a selecta o firmă BCDR, găzduind astfel de informații precum ce dorește să externalizeze, ce servicii așteaptă
de la furnizor, riscurile unui acord de externalizare și cât plănuiește să cheltuiască.
Auditul Sistemelor Informatice
Un audit al sistemului informatic (IS) sau un audit al tehnologiei informației (IT) este o
examinare a controalelor din cadrul infrastructurii tehnologiei informației a unei entități.
Aceste revizuiri pot fi efectuate împreună cu un audit al situațiilor financiare, audit intern sau
altă formă de misiune de atestare. Este procesul de colectare și evaluare a dovezilor privind
sistemele informaționale, practicile și operațiunile unei organizații. Evaluarea dovezilor
obținute poate asigura dacă sistemele informaționale ale organizației protejează activele,
mențin integritatea datelor și funcționează eficient și eficient pentru a atinge scopurile sau
obiectivele organizației.
Un audit IS nu este în întregime similar cu un audit al situațiilor financiare. O evaluare a

controalelor interne poate sau nu să aibă loc într-un audit IS. Încrederea pe controalele interne
este o caracteristică unică a unui audit financiar. O evaluare a controalelor interne este
necesară într-un audit financiar, pentru a permite auditorului să se bazeze pe controalele
interne și, prin urmare, pentru a reduce substanțial volumul de teste necesare pentru a forma o
opinie cu privire la situațiile financiare ale companiei. Un audit IS, pe de altă parte, tinde să se
concentreze pe determinarea riscurilor care sunt relevante pentru activele informaționale și pe
evaluarea controalelor pentru a reduce sau atenua aceste riscuri. Un audit IT poate lua forma
unei „evaluări generale de control” sau a unei „evaluări a controlului specific”. În ceea ce
privește protecția activelor informaționale, un scop al unui audit IS este de a revizui și evalua
disponibilitatea, confidențialitatea și integritatea sistemului informațional al unei organizații,
răspunzând la următoarele întrebări:
1. Sistemele computerizate ale organizației vor fi disponibile pentru afacere în orice

moment când este necesar? (Disponibilitate)
2. Informațiile din sisteme vor fi dezvăluite numai utilizatorilor autorizați?
(Confidentialitate)
3. Informațiile furnizate de sistem vor fi întotdeauna exacte, de încredere și la timp?
(Integritate).
Efectuarea unui audit IS acoperă mai multe fațete ale funcțiilor financiare și organizaționale
ale clienților noștri. Diagrama din dreapta vă oferă o imagine de ansamblu asupra fluxului de
audit al sistemelor informaționale: de la situațiile financiare la mediul de control și platformele
sistemelor informaționale.
Metodologia Auditului Sistemelor Informaţionale

Metodologia noastră a fost dezvoltată în conformitate cu Standardele Internaționale de Audit al
Sistemelor Informaționale, de exemplu Standardele și Ghidurile de Audit al Sistemelor
Informaționale ISACA și Standardul COSO Sabarne Oxley. Punctul de început al acestei
metodologii este realizarea activităților de planificare care sunt orientate spre integrarea unei
abordări de audit bazate pe risc în auditul IS.
FAZA 1: Planificarea auditului
În această fază planificăm acoperirea sistemului informațional pentru a respecta obiectivele de
audit specificate de Client și pentru a asigura conformitatea cu toate Legile și Standardele
Profesionale. Primul lucru este de a obține de la Client o Cartă de Audit care să detalieze
scopul auditului, responsabilitatea managementului, autoritatea și responsabilitatea funcției de
Audit al Sistemelor Informaționale, după cum urmează:
1. Responsabilitate: Carta de audit ar trebui să definească misiunea, scopurile,

scopurile și obiectivele auditului sistemului informațional. În această etapă definim, de
asemenea, Indicatorii Cheie de Performanță și un proces de Evaluare de Audit;
2. Autoritate: Carta de audit ar trebui să specifice în mod clar Autoritatea atribuită

auditorilor sistemelor informaționale în legătură cu activitatea de evaluare a riscurilor
care va fi efectuată, dreptul de acces la informațiile clientului, sfera de aplicare și/sau
limitările sferei de aplicare, funcțiile clientului la fi auditat și așteptările auditatului; și
3. Responsabilitate: Carta de audit ar trebui să definească în mod clar liniile de
raportare, evaluările, evaluarea conformității și acțiunile convenite.
Carta de audit ar trebui să fie aprobată și agreată de un nivel corespunzător din cadrul
Organizației Clientului.
Consultați șablonul pentru o carte de audit/scrisoare de angajament aici.
În plus față de Carta de audit, ar trebui să putem obține o declarație scrisă („Scrisoare de
reprezentare”) din partea conducerii clientului, care confirmă:
1. Responsabilitatea acestora pentru proiectarea și implementarea sistemelor de

control intern care afectează sistemele și procesele IT
2. Disponibilitatea acestora de a dezvălui auditorului sistemelor informaționale
cunoștințele lor cu privire la neregulile și/sau actele ilegale care le afectează
organizația referitoare la conducere și angajații cu roluri semnificative în cadrul
departamentului de audit intern.
3. Disponibilitatea lor de a dezvălui auditorului IS rezultatele oricărei evaluări a
riscului conform căreia s-ar fi putut produce o denaturare semnificativă
Vedeți un șablon pentru o scrisoare de reprezentare aici.
FAZA 2 – Evaluarea riscurilor și analiza procesului de afaceri
Riscul este posibilitatea producerii unui act sau eveniment care ar avea un efect negativ asupra
organizației și sistemelor sale informaționale. Riscul poate fi, de asemenea, potențialul ca o
anumită amenințare să exploateze vulnerabilitățile unui activ sau grup de active pentru a cauza
pierderea sau deteriorarea activelor. Este de obicei măsurată printr-o combinație de efect și
probabilitatea de apariție.
Tot mai multe organizații trec la o abordare de audit bazată pe risc, care poate fi adaptată
pentru a dezvolta și îmbunătăți procesul de audit continuu. Această abordare este utilizată
pentru a evalua riscul și pentru a sprijini decizia auditorului SI de a face fie teste de
conformitate, fie teste de fond. Într-o abordare de audit bazată pe risc, auditorii SI nu se
bazează doar pe risc. De asemenea, se bazează pe controale interne și operaționale, precum și
pe cunoștințele despre organizație. Acest tip de decizie de evaluare a riscului poate ajuta la
corelarea analizei cost/beneficiu a controlului cu riscul cunoscut, permițând alegeri practice.
Procesul de cuantificare a riscului se numește evaluarea riscului. Evaluarea riscurilor este utilă
în luarea unor decizii precum:
1. Zona/funcția de afaceri care urmează să fie auditată

2. Natura, amploarea și momentul procedurilor de audit
3. Cantitatea de resurse care trebuie alocată unui audit
Trebuie luate în considerare următoarele tipuri de riscuri:
Riscul inerent: Riscul inerent este susceptibilitatea unei zone de audit la erori care ar putea fi
semnificative, individual sau în combinație cu alte erori, presupunând că nu au existat
controale interne aferente. În evaluarea riscului inerent, auditorul SI trebuie să ia în
considerare atât controalele IS generale, cât și cele detaliate. Acest lucru nu se aplică
circumstanțelor în care misiunea auditorului SI este legată doar de controale IS pervazive. Un
control IS pervaziv sunt controale generale care sunt concepute pentru a gestiona și monitoriza
mediul IS și, prin urmare, afectează toate activitățile legate de IS. Unele dintre controalele IS
omniprezente pe care un auditor le poate lua în considerare includ:
• Integritatea managementului SI și a experienței și cunoștințelor în managementul SI

• Schimbări în managementul IS
• Presiuni asupra managementului IS care îi poate predispune să ascundă sau să
denatureze informații (de exemplu, depășiri mari de proiecte critice pentru afaceri și
activitate de hackeri)
• Natura activității și sistemelor organizației (de exemplu, planurile pentru comerțul
electronic, complexitatea sistemelor și lipsa sistemelor integrate)
• Factori care afectează industria organizației în ansamblu (de exemplu, schimbări în
tehnologie și disponibilitatea personalului IS)
• Nivelul influenței terților asupra controlului sistemelor auditate (de exemplu, din
cauza integrării lanțului de aprovizionare, a proceselor IS externalizate, a asociațiilor
comerciale în comun și a accesului direct al clienților)
• Constatări de la și data auditurilor anterioare
Un control IS detaliat este un control asupra achiziției, implementării, livrării și suportului
sistemelor și serviciilor IS. Auditorul SI trebuie să ia în considerare, la nivelul adecvat
domeniului de audit în cauză:
• Constatările și data auditurilor anterioare în acest domeniu

• Complexitatea sistemelor implicate
• Nivelul de intervenție manuală necesar
• Susceptibilitatea la pierderea sau deturnarea activelor controlate de sistem (de
exemplu, inventar și salarizare)
• Probabilitatea de activitate atinge vârfuri în anumite momente ale perioadei de audit
• Activități în afara rutinei de zi cu zi a prelucrării IS (de exemplu, utilizarea utilităților
sistemului de operare pentru a modifica datele)
• Integritatea, experiența și abilitățile conducerii și ale personalului implicat în
aplicarea controalelor IS
Riscul de control: Riscul de control este riscul ca o eroare care ar putea apărea într-o zonă de
audit și care ar putea fi semnificativă, individual sau în combinație cu alte erori, să nu fie
prevenită sau detectată și corectată în timp util de către sistemul de control intern. . De
exemplu, riscul de control asociat cu revizuirile manuale ale jurnalelor computerului poate fi
mare, deoarece activitățile care necesită investigare sunt adesea ratate cu ușurință din cauza
volumului de informații înregistrate. Riscul de control asociat cu procedurile computerizate de
validare a datelor este de obicei scăzut deoarece procesele sunt aplicate în mod consecvent.
Auditorul SI trebuie să evalueze riscul de control ca fiind ridicat, cu excepția cazului în care
controalele interne relevante sunt:
• Identificat
• Evaluat ca eficient
• Testat și dovedit că funcționează corespunzător
Riscul de detectare: Riscul de detectare este riscul ca procedurile de fond ale auditorului SI să
nu detecteze o eroare care ar putea fi semnificativă, individual sau în combinație cu alte erori.
Pentru a determina nivelul de testare de fond necesar, auditorul SI trebuie să ia în considerare
ambele:
• Evaluarea riscului inerent

• Concluzia la care sa ajuns cu privire la riscul de control în urma testării de
conformitate
Cu cât evaluarea riscului inerent și de control este mai mare, cu atât auditorul SI ar trebui să
obțină în mod normal mai multe probe de audit din efectuarea procedurilor de audit de fond.
Abordarea noastră de audit a sistemelor informaționale bazată pe risc
O abordare bazată pe risc a unui audit al sistemelor informaționale ne va permite să dezvoltăm

un plan global și eficient de audit IS, care va lua în considerare toate potențialele deficiențe
și/sau absența controalelor și va determina dacă acest lucru ar putea duce la o deficiență
semnificativă sau o slăbiciune semnificativă.
Pentru a efectua o evaluare eficientă a riscurilor, va trebui să înțelegem mediul de afaceri și
operațiunile clientului. De obicei, prima fază în realizarea unui audit IS bazat pe risc este de a
obține o înțelegere a Universului de audit. În înțelegerea Universului de Audit, efectuăm
următoarele:
• Identificați zonele în care riscul este inacceptabil de mare

• Identificați sistemele de control critice care abordează riscurile inerente ridicate
• Evaluează incertitudinea care există în legătură cu sistemele critice de control
În efectuarea analizei procesului de afaceri:
• Obține o înțelegere a proceselor de afaceri ale clientului

• Harta mediul de control intern
• Identificați zonele cu puncte slabe de control
Chatul din dreapta rezumă faza de analiză a procesului de afaceri.
Șablonul xxx vă va oferi un ghid pentru a documenta subprocesele de afaceri ale organizațiilor
identificate în timpul fazei de analiză a riscului. Pentru fiecare dintre sub-procese, identificăm
o listă de Ce ar putea merge greșit (WCGW). Acest WCGW reprezintă amenințarea existentă
asupra unui anumit proces. Un singur proces ar avea mai multe WCGW. Pentru fiecare dintre
WCGW-urile identificate în faza anterioară, vom determina Activitățile cheie din acel proces.
Pentru fiecare activitate cheie:
1. Vom identifica Controalele Sistemelor Informaționale
1. Pentru fiecare dintre controalele identificate, vom evalua impactul/efectul lipsei
acelui control (pe un rating de 1 - 5, cu 5 indicând cel mai mare impact), vom
determina apoi probabilitatea apariției amenințării ( tot pe un rating de 1 - 5 cu 5
reprezentând cea mai mare probabilitate).
<< Descrieți aici metodologia specifică de evaluare a riscurilor >>
FAZA 3 – Efectuarea lucrărilor de audit
În realizarea lucrărilor de audit, standardele de audit ale sistemelor informaționale ne cer să

asigurăm supraveghere, să colectăm probe de audit și să ne documentăm activitatea de audit.
Atingem acest obiectiv prin:
• Stabilirea unui proces de evaluare internă în care munca unei persoane este revizuită
de o altă persoană, de preferință o persoană mai în vârstă.
• Obținem dovezi suficiente, de încredere și relevante pentru a fi obținute prin inspecție,
observare, anchetă, confirmare și recalculare a calculelor
• Ne documentăm munca prin descrierea activității de audit efectuate și a probelor de
audit adunate pentru a susține constatările auditorilor.
Pe baza evaluării noastre de risc și pe baza identificării zonelor riscante, mergem mai departe
pentru a dezvolta un plan de audit și un program de audit. Planul de audit va detalia natura,
obiectivele, calendarul și amploarea resurselor necesare auditului.
Consultați șablonul pentru un exemplu de plan de audit.
Pe baza testelor de conformitate efectuate în faza anterioară, dezvoltăm un program de audit

care detaliază natura, momentul și amploarea procedurilor de audit. În Planul de Audit se pot
face diverse Teste de Control și Revizuiri. Acestea sunt subdivizate în:
1. Controale generale/pervazive
1. Controale specifice
Chatul de mai jos în stânga arată testele de revizuire a controlului care pot fi efectuate în cele
două teste de control de mai sus.
Obiective de control pentru tehnologia informației și aferente (COBIT)

Obiectivele de control pentru tehnologia informației și aferente (COBIT) este un set de bune
practici (cadru) pentru managementul informațiilor (IT) creat de Asociația de Audit și Control
al Sistemelor Informaționale (ISACA) și Institutul de Guvernare IT (ITGI) în 1992.
COBIT oferă managerilor, auditorilor și utilizatorilor IT un set de măsuri, indicatori, procese și
bune practici general acceptate pentru a-i ajuta în maximizarea beneficiilor obținute prin
utilizarea tehnologiei informației și dezvoltarea unei guvernanțe și control IT adecvate într-o
companie.
PROCESELE COBIT IT DEFINITE ÎN CADRUL CELOR PATRU DOMENII
BUSI ECTIVE
GUVERNANȚA FT
Ml moritcf the procme Pul defire 4 turaimgu It plan

M2 mcin irderml -cwtrnl adoqunc P02 defirn theinlormakonarcheecrc
M3 cbinin independleni oasuramf Mi proridofor PDJ determine hhe bechmologie m dircerion
idirperidont nudi P04 definește ergamtaon și relauerehip IT
PC'S minnge ihe R irmemkrem
PCe5 Eerrmunicaie mrinjemned inlimmn si chreekiem
POT mnnee uman tebuce
POe eraaic cespbarewth eqiernd iteuitomain
P09 assereks
PO1C mnage peejeei
Trage mrngecalry
ION
I&
ION
051 052 defireand manage serwce levek mansg=
DS3 05a ihedparty sevces marine perlormance and
D55 DS6 capacify eneule corruots serice
057 DSE enule ay-eme iecurity iderfy and allocoi cos
039 educam and wai LeH aris arid adike cudlfm
0S10 mannge the congu ancn nanage pobee and
DSII irwcidene manag= Jana monnge locilies
Al 1 k5a iiy nubomaind xcliom
512 mansge operains Toate nequfe și maininin appleamot bomwaie
0513 A13 aequire ene maninin iechrelogsinfrairucture
AM deeeop ard mnirea in piccedure
AIE imainl nevoie de ntetedit nhemn
AIB rnamage chkgm
COBIT ajută la satisfacerea nevoilor multiple ale managementului prin reducerea decalajelor
dintre riscurile de afaceri, nevoile de control și problemele tehnice. Acesta oferă un cadru de
bune practici pentru gestionarea resurselor IT și prezintă activitățile de control al
managementului într-o structură gestionabilă și logică.

Acest cadru va ajuta la optimizarea investițiilor în informații tehnologice și va oferi o măsură
de referință adecvată.
Cadrul cuprinde un set de 34 de obiective de control la nivel înalt, câte unul pentru fiecare
dintre procesele IT enumerate în cadru. Acestea sunt apoi grupate în patru domenii: planificare
și organizare, achiziție și implementare, livrare și suport și monitorizare. Această structură
acoperă toate aspectele procesării și stocării informațiilor și tehnologia care o susține. Prin
abordarea acestor 34 de obiective de control la nivel înalt, ne vom asigura că este asigurat un
sistem de control adecvat pentru mediul IT. O reprezentare schematică a cadrului este
prezentată mai jos.
Vom aplica cadrul COBIT în planificarea, executarea și raportarea rezultatelor auditului. Acest
lucru ne va permite să revizuim controalele generale asociate problemelor de guvernanță IT.
Analiza noastră va acoperi următoarele domenii;
• Planificarea și organizarea resurselor informaționale;
• Planificarea si achizitia sistemelor si modelul de crestere in stadii a sistemelor

informatice;
• Furnizarea și suportul IS/IT, inclusiv facilități, operațiuni, utilizare și acces;
• Monitorizarea proceselor din jurul sistemelor informatice;
• Nivelul de eficacitate, eficiență, confidențialitate, integritate, disponibilitate,

conformitate și fiabilitate asociate cu informațiile deținute; și
• Nivelul de utilizare a resurselor IT disponibile în mediul SI, inclusiv oamenii,
sistemele de aplicație de interfață, tehnologie, facilități și date.
Obiectivele de control de mai sus vor fi corelate cu obiectivele de control al afacerii pentru a
aplica proceduri specifice de audit care vor oferi informații despre controalele construite în
aplicație, indicând zonele de îmbunătățire pe care trebuie să ne concentrăm asupra realizării.
Revizuirea controlului aplicației
O revizuire a controlului aplicației va oferi managementului o asigurare rezonabilă că
tranzacțiile sunt procesate conform intenției și că informațiile din sistem sunt exacte, complete
și la timp. O examinare a comenzilor aplicației va verifica dacă:
• Controlează eficacitatea și eficiența

• Securitatea aplicațiilor
• Dacă aplicația funcționează conform așteptărilor
O revizuire a controalelor aplicației va acoperi o evaluare a ciclului de viață al tranzacției de la
originea, pregătirea, intrarea, transmiterea, procesarea și ieșirea datelor, după cum urmează:
1. Controalele de origine a datelor sunt controale stabilite pentru a pregăti și a autoriza
introducerea datelor într-o aplicație. Evaluarea va implica o revizuire a designului și
stocării documentului sursă, a procedurilor și manualelor utilizatorului, a formularelor
cu scop special, a codurilor de identificare a tranzacțiilor, a indicilor de referință
încrucișată și a documentelor alternative, acolo unde este cazul. De asemenea, va
implica o revizuire a procedurilor de autorizare și separarea sarcinilor în procesul de

captare a datelor.
1. Controalele de pregătire a intrărilor sunt controale referitoare la numerotarea
tranzacțiilor, numerotarea seriei loturilor, procesarea, analiza jurnalelor și o revizuire a
documentelor de transmitere și de livrare
2. Controalele transmisiei implică verificarea și echilibrarea loturilor, programele de
procesare, revizuirea mesajelor de eroare, monitorizarea corecțiilor și securitatea
tranzacțiilor
3. Controalele de prelucrare asigură integritatea datelor pe măsură ce acestea trec
prin faza de procesare, inclusiv controale relaționale ale bazelor de date, stocare și
regăsire a datelor
4. Procedurile de control al ieșirilor implică proceduri referitoare la distribuirea
rapoartelor, reconcilierea, procesarea erorilor de ieșire, păstrarea înregistrărilor.
Utilizarea tehnicilor de audit asistate de computer (CAATS) în realizarea unui audit IS
Standardele de audit al sistemelor informaționale ne cer ca, pe parcursul unui audit, auditorul
SI să obțină dovezi suficiente, fiabile și relevante pentru a atinge obiectivele auditului.
Constatările și concluziile auditului trebuie să fie susținute de analiza și interpretarea adecvată
a acestor probe. CAAT-urile sunt utile în atingerea acestui obiectiv.
Tehnicile de audit asistate de calculator (CAAT) sunt instrumente importante pentru auditorul
SI în efectuarea auditurilor. Acestea includ multe tipuri de instrumente și tehnici, cum ar fi
software-ul de audit generalizat, software-ul utilitar, datele de testare, urmărirea și maparea
software-ului de aplicație și sisteme expert de audit. Pentru noi, CAAT-urile noastre includ
software-ul de analiză a datelor ACL și setul de instrumente de audit al sistemelor
informaționale (ISAT).
CAAT-urile pot fi utilizate în realizarea diferitelor proceduri de audit, inclusiv:
• Teste ale detaliilor tranzacțiilor și soldurilor (Teste de fond)

• Proceduri de revizuire analitică
• Teste de conformitate ale controalelor generale IS
• Teste de conformitate ale controalelor aplicației IS
CAAT-urile pot produce o mare parte din probele de audit dezvoltate cu privire la auditurile SI
și, în consecință, auditorul SI trebuie să planifice cu atenție și să dea dovadă de grija
profesională cuvenită în utilizarea CAAT-urilor. pentru aplicarea CAAT-urilor selectate sunt:
• Stabiliți obiectivele de audit ale CAAT-urilor
• Determinați accesibilitatea și disponibilitatea facilităților, programelor/sistemului și

datelor IS ale organizației
• Definiți procedurile care trebuie întreprinse (de exemplu, eșantionare statistică,
recalculare, confirmare etc.)
• Definiți cerințele de ieșire
• Determinați cerințele de resurse, de exemplu, personalul, CAAT-urile, mediul de

procesare (facilitățile SI ale organizației sau instalațiile SI de auditare)
• Obține acces la facilitățile IS ale clienților, programe/sistem și date, inclusiv definițiile
fișierelor
• Documentați CAAT-urile care trebuie utilizate, inclusiv obiective, diagrame de flux
de nivel înalt și instrucțiuni de rulare
• Faceți aranjamentele adecvate cu auditatul și asigurați-vă că:
1. Fișierele de date, cum ar fi fișierele detaliate ale tranzacțiilor, sunt păstrate și puse
la dispoziție înainte de începerea auditului.
2. Ați obținut drepturi suficiente la facilitățile, programele/sistemul și datele
clientului IS
3. Testele au fost programate corespunzător pentru a minimiza efectul asupra
mediului de producție al organizației.
4. Efectul că modificările aduse programelor/sistemului de producție au fost luate în
considerare în mod corespunzător.
Consultați șablonul aici pentru exemple de teste pe care le puteți efectua cu ACL
FAZA 4: Raportare
La efectuarea testului de audit, Auditorul Sistemelor Informaționale este obligat să elaboreze și
un raport corespunzător care să comunice rezultatele auditului SI. Un raport de audit IS ar
trebui:
1. Identificați o organizație, destinatarii vizați și orice restricții privind circulația

2. Precizați domeniul de aplicare, obiectivele, perioada de acoperire, natura,
calendarul și extinderea activității de audit
3. Prezentați constatările, concluziile, recomandările și orice rezerve, calificări și
limitări
4. Furnizați probe de audit
Grupul de audit al Sistemelor Informaționale (IS) evaluează sistemele critice, arhitectura

tehnologică și procesele Universității pentru a se asigura că activele informaționale sunt
protejate, fiabile, disponibile și conforme cu politicile și procedurile Universității, precum și cu
legile și reglementările aplicabile. Subliniem importanța atenuării riscurilor de securitate în
timpul acoperirii auditului nostru asupra aplicațiilor, sistemelor de operare și de rețea ale
Universității. Prin auditurile noastre integrate și de guvernanță IT, evaluăm impactul
tehnologiei informației asupra proceselor Universității și abilităților acesteia de a-și atinge
scopurile și obiectivele. Evaluările noastre sunt obiective și profesionale, utilizând cadrul
COBIT (Control Objectives for Information and related Technology), un standard internațional
pentru bunele practici de control IT.
ISA oferă următoarele servicii de audit:

• Guvernanța IT - Auditurile de guvernanță IT includ analize ale responsabilității fiduciare

a organizației în satisfacerea calității serviciilor de livrare IT, aliniind în același timp la
obiectivele de afaceri și stabilind un sistem adecvat de controale interne.
• Sisteme informatice - Auditurile sistemelor informatice se concentrează pe controalele de
securitate ale securității fizice și logice a serverului, inclusiv controlul modificărilor,
administrarea conturilor de server, înregistrarea și monitorizarea sistemului, gestionarea
incidentelor, backup-ul sistemului și recuperarea în caz de dezastru.
• Audituri integrate - Auditurile integrate includ revizuiri ale operațiunilor de afaceri și
dependența acestora de sistemele automate pentru a sprijini procesul de afaceri. Considerăm
tehnologia informației și procesele financiare și operaționale ca fiind dependente reciproc
pentru stabilirea unui mediu de control eficient și eficient. Din perspectiva tehnologiei, auditul
se concentrează pe controalele aplicațiilor, administrarea accesului utilizatorilor, controlul
modificărilor aplicației și backup și recuperare pentru a asigura fiabilitatea, integritatea și
disponibilitatea datelor.
• Autoevaluări de control - Autoevaluările de control sunt concepute pentru departamentul
care gestionează și operează un mediu tehnologic. Aceste instrumente de autoevaluare pot fi
utilizate pentru a identifica potențiale zone de slăbiciune a controlului în managementul
mediului tehnologic.
• Conformitate - Auditurile de conformitate includ politicile și procedurile universitare,
industria cardurilor de plată (PCI), Legea privind portabilitatea și responsabilitatea asigurărilor
de sănătate (HIPAA) , Legea privind drepturile și confidențialitatea la educația familiei
(FERPA) și orice alte legi și reglementări aplicabile.
Organisme de reglementare financiară din India
În India, sistemul financiar este reglementat cu ajutorul autorităților independente de

reglementare, asociate cu domeniul asigurărilor, bancar, pieței de mărfuri și pieței de capital și,
de asemenea, domeniul fondurilor de pensii. Pe de altă parte, guvernul indian este cunoscut și
pentru că joacă un rol semnificativ în controlul domeniului securității financiare și, de
asemenea, influențează rolurile acestor autorități de reglementare menționate. Trebuie să fiți la
curent cu organismele de reglementare și despre funcțiile acestora, înainte de un ultim cuvânt.
Cel mai proeminent dintre toate este RBI sau Reserve Bank of India. Să ne uităm în detaliu
despre diferitele organisme de reglementare financiară din India.
RBI – Băncile de rezervă din India:
Reserve Bank of India: Reserve Bank of India este instituția monetară de vârf a Indiei. Este
numită și banca centrală a țării.
(ame I 5 4ppzeem 4 (62953)) 8) V,2=§/ S<ESBANE3

Rezerva Bank of India a fost înființată la 1 aprilie 1935 în
în conformitate cu prevederile Reserve Bank of India Act, 1934. Oficiul Central al
Reserve Bank a fost inițial înființată în Calcutta, dar a fost mutată definitiv în
Mumbai în 1937. Biroul Central este locul unde stă guvernatorul și unde sunt politicile
formulate. Deși inițial proprietate privată, de la naționalizare în 1949, Rezervația
Banca este deținută în totalitate de Guvernul Indiei.
Biroul Central este locul unde stă guvernatorul și este locul unde sunt formulate politicile. Deși
inițial deținută privată, de la naționalizare în 1949, Reserve Bank este deținută în totalitate de
Guvernul Indiei.
SEBI – Securities and Exchange Board of India:
În afară de RBI, SEBI formează și o parte majoră în cadrul

organismului financiar al Indiei. Acesta este un organism de
reglementare asociat cu piețele de securitate din teritoriul indian. Înființată în anul 1988, Legea
SEBI a intrat în vigoare în anul 1992, la 12 aprilie. Consiliul este format dintr-un președinte,
membri cu normă întreagă, un secretar comun, un membru desemnat, un guvernator adjunct al
RBI, un secretar al ministerului afacerilor corporative și, de asemenea, un membru cu jumătate
de normă. Există trei grupuri, care se încadrează în această categorie, și acestea sunt
investitorii, emitenții de valori mobiliare și intermediarii de piață.
PFRDA – Autoritatea de Reglementare și Dezvoltare a Fondului de Pensii:
Fondul de pensii de reglementare este o autoritate legată de pensii,

care a fost înființată în anul 2003 de guvernul indian. Este autorizat de Ministerul Finanțelor și
ajută la promovarea securității veniturilor bătrâneții prin reglementarea și dezvoltarea
fondurilor de pensii. Pe de altă parte, acest grup poate contribui și la protejarea ratei dobânzii
abonaților, asociată cu schemele de bani de pensii, împreună cu aspectele conexe. PFRDA
este, de asemenea, responsabilă pentru numirea diferitelor alte agenții intermediare, cum ar fi
administratorii de fonduri de pensii, CRA, NPS Trustee Bank și altele.
FMC – Forward Markets Commission:
Vard Markets Commie

În afară de organismele financiare menționate mai sus, FMC joacă,
de asemenea, un rol major. Este autoritatea principală de reglementare a mărfurilor (MCX,
NCDEX, NMCE, UCX etc.) Compiled by Srinivas Kante Email: srinivaskante4u@gmail.com
piața la termen din India. Conform celui mai recent flux de știri, a reglementat suma de Rs. 17
trilioane, în cadrul tranzacțiilor cu mărfuri. Sediul central este situat în Mumbai, iar agenția de
reglementare financiară lucrează în colaborare cu Ministerul de Finanțe. Președintele FMC
lucrează împreună cu membrii aceleiași organizații pentru a îndeplini scopurile cerute. Scopul
principal al acestui organism este acela de a consilia guvernul central cu privire la chestiunile
Legii Contractelor Forward din 1952.
IRDA – Autoritatea de Reglementare și Dezvoltare a Asigurărilor:
, este mai bine să menționăm numele IRDA sau i autoritatea de

reglementare și dezvoltare, ca parte majoră a organismului financiar. Această companie
urmează să reglementeze organismul statutar apex, care va reglementa și, în același timp, va
dezvolta industria asigurărilor. Acesta cuprindea actul parlamentar indian și a fost adoptat în
mod corespunzător de guvernul indian. Sediul acestui grup este în Hyderabad și a fost mutat de
la Delhi la Hyderabad. Acestea sunt câteva dintre cele mai bune puncte posibile, asupra cărora
vă puteți concentra, în timp ce aveți de-a face cu organismele financiare din India.
Rezerva Bank of India a emis noi îndrumări în aprilie 2011 pentru bănci pentru a reduce
riscurile utilizării tehnologiei informației în operațiunile bancare. Orientările RBI sunt
rezultatul recomandărilor Grupului de lucru privind securitatea informațiilor, banca
electronică, managementul riscului tehnologic și frauda cibernetică. Grupul de lucru a fost
format sub președinția lui G. Gopalakrishna, directorul executiv al RBI în aprilie 2010.
Îndrumarea este în mare măsură determinată de nevoia de a atenua amenințările cibernetice
care apar din adoptarea tot mai mare a IT de către băncile comerciale din India.
Recomandările sunt făcute în nouă domenii largi, inclusiv:
1. Guvernanța IT: accentuează responsabilitatea de gestionare a riscurilor IT în consiliul de

administrație și conducerea executivă a unei bănci. Accentul include crearea unei structuri
organizaționale și a unui proces pentru a se asigura că securitatea IT a unei bănci susține și
extinde strategiile și obiectivele de afaceri.
2. Securitatea informațiilor: menținerea unui cadru care să ghideze dezvoltarea unui program
cuprinzător de securitate a informațiilor, care include formarea unei funcții separate de
securitate a informațiilor care să se concentreze exclusiv pe securitatea informațiilor și
managementul riscurilor, distinct de activitățile unui departament de tehnologie a informației.
Aceste linii directoare specifică faptul că responsabilul șef cu securitatea informațiilor trebuie
să raporteze direct șefului managementului riscurilor și nu ar trebui să aibă o relație de
raportare directă cu responsabilul cu informațiile șef.
3. Operațiuni IT: capabilități organizaționale specializate care oferă valoare clienților,
inclusiv managementul serviciilor IT, managementul infrastructurii, managementul ciclului de
viață al aplicațiilor și cadrul de risc pentru operațiunile IT.
4. Outsourcing de servicii IT: plasează responsabilitatea finală pentru operațiunile de

externalizare și gestionarea riscului inerent în astfel de relații în consiliul de administrație și
conducerea superioară. Accentul include selecția eficientă a furnizorului de servicii,

monitorizarea și controlul activităților externalizate și evaluarea și managementul riscurilor.
5. Auditul securității informațiilor: necesitatea băncilor de a reevalua procesele de audit SI și
de a se asigura că acestea oferă o viziune independentă și obiectivă asupra măsurii în care
riscurile sunt gestionate. Acest subiect se concentrează pe definirea rolurilor și
responsabilităților părților interesate din auditul SI și pe planificarea și execuția auditului.
6. Frauda cibernetică: definește necesitatea unui cadru la nivel de industrie privind
guvernarea fraudei, cu accent deosebit pe combaterea fraudelor bazate pe canale electronice.
Accentul include crearea unei structuri organizaționale pentru managementul riscului de fraudă
și a unui comitet special pentru monitorizarea fraudei cu valoare mare.
7. Planificarea continuității afacerii : se concentrează pe politici, standarde și proceduri
pentru a asigura continuitatea, reluarea și recuperarea proceselor critice de afaceri. De
asemenea, acest subiect pune accent pe implementarea unui cadru pentru a minimiza
consecințele operaționale, financiare, juridice, reputaționale și alte consecințe materiale care
decurg dintr-un astfel de dezastru.
8. Educația clienților: necesitatea de a implementa un cadru și programe de conștientizare a
consumatorilor cu privire la o varietate de probleme legate de fraudă.
9. Probleme juridice: definește necesitatea de a pune în aplicare procese eficiente pentru a se
asigura că riscurile juridice care decurg din legile cibernetice sunt identificate și abordate la
bănci. De asemenea, se concentrează pe consultarea consiliului de administrație cu
departamentul juridic cu privire la pașii de atenuare a riscurilor de afaceri în cadrul băncii.
Fundal :
Tehnologia a devenit parte a tuturor categoriilor sociale și în toate sectoarele de afaceri, și cu
atât mai mult în domeniul bancar. A existat o utilizare masivă a tehnologiei în multe domenii
ale afacerilor bancare din India, atât din punct de vedere al activelor, cât și al pasivelor din
bilanțul unei bănci. Canalele de livrare au crescut enorm opțiunile oferite clientului pentru a
efectua tranzacții cu ușurință și comoditate. Diverse sisteme de plată și decontare angro și cu
amănuntul au permis mijloace mai rapide de deplasare a banilor pentru a deconta fonduri între
bănci și clienți, facilitând o rotație îmbunătățită a tranzacțiilor comerciale și financiare. Băncile
au început proiecte noi, cum ar fi depozitarea de date, managementul relațiilor cu clienții și
inițiativele de incluziune financiară, pentru a inova și a elabora strategii pentru viitor și pentru
a extinde raza de acțiune a serviciilor bancare.
Dependența de tehnologie este de așa natură încât afacerea bancară nu poate fi gândită în mod
izolat fără tehnologie, așa a fost răspândirea amprentelor tehnologice în peisajul bancar
comercial din India. Evoluțiile din IT au adus, de asemenea, un întreg set de provocări cu care
trebuie să le faceți față. Dependența de tehnologie a condus la diverse provocări și probleme,
cum ar fi schimbări frecvente sau învechirea, multiplicitatea și complexitatea sistemelor,
diferite tipuri de controale pentru diferite tipuri de tehnologii/sisteme, alinierea adecvată la
obiectivele de afaceri și cerințele legale/de reglementare, dependența de furnizori din cauza la
externalizarea serviciilor IT, riscul de concentrare legat de furnizor, segregarea sarcinilor,
amenințările externe care duc la fraude/crimă cibernetică, impact mai mare din cauza actelor
intenționate sau neintenționate ale angajaților interni, noi tehnici de inginerie socială folosite
pentru a obține acreditări confidențiale, necesitatea proceselor de guvernare să gestioneze în
mod adecvat tehnologia și securitatea informațiilor, necesitatea de apreciere a legilor
cibernetice și a impactului acestora și să asigure continuitatea proceselor de afaceri în cazul
unor exigențe majore.
Riscurile tehnologice nu numai că au un impact direct asupra unei bănci ca riscuri
operaționale, dar pot, de asemenea, exacerba alte riscuri, cum ar fi riscurile de credit și
riscurile de piață. Având în vedere dependența tot mai mare a clienților de canalele electronice
de livrare pentru a efectua tranzacții, orice probleme legate de securitate au potențialul de a
submina încrederea publicului în utilizarea canalelor de e-banking și de a conduce la riscuri de
reputație pentru bănci. Implementarea inadecvată a tehnologiei poate induce, de asemenea, risc
strategic în ceea ce privește luarea deciziilor strategice bazate pe date/informații inexacte.
Riscul de conformitate este, de asemenea, un rezultat în cazul nerespectării oricăror cerințe de
reglementare sau legale care decurg din utilizarea IT. Aceste probleme au în cele din urmă
potențialul de a afecta siguranța și soliditatea unei bănci și, în cazuri extreme, pot duce la crize
sistemice.
Având în vedere mediul în schimbare a amenințărilor și cele mai recente standarde
internaționale, s-a considerat că este nevoie de îmbunătățirea liniilor directoare RBI referitoare
la guvernanța IT, măsurile de securitate a informațiilor pentru a combate frauda cibernetică, pe
lângă sporirea asigurării independente cu privire la eficacitatea controalelor IT. . Pentru a lua
în considerare aceste aspecte și aspectele conexe, RBI a anunțat în aprilie 2010 înființarea unui
grup de lucru pentru securitatea informațiilor, banca electronică, managementul riscului
tehnologic și combaterea fraudei cibernetice. Grupul a fost înființat sub președinția directorului
executiv Shri.G.Gopalakrishna.
Grupul a aprofundat în diferite probleme care decurg din utilizarea tehnologiei informației în
bănci și și-a făcut recomandări în nouă domenii largi. Aceste domenii sunt guvernanța IT,
securitatea informațiilor, auditul IS, operațiunile IT, externalizarea serviciilor IT, frauda
cibernetică, planificarea continuității afacerii, programele de conștientizare a clienților și
problemele juridice.
Recomandările majore ale grupului de lucru
Grupul a considerat că recomandările nu sunt „uniforme” și punerea în aplicare a acestor
recomandări trebuie să se bazeze pe natura și domeniul de aplicare a activităților angajate de
bănci și pe mediul tehnologic predominant în bancă și pe sprijinul oferit de către bănci.
tehnologie la procesele de afaceri.
Despre guvernarea IT:
• Băncile trebuie să formuleze un document de strategie/plan IT aprobat de Consiliu.
Trebuie elaborată o politică IT pentru gestionarea regulată a funcțiilor IT și să se asigure că
există și sunt implementate documentația detaliată în ceea ce privește procedurile și liniile
directoare. Planul strategic și politica trebuie revizuite anual.
• S-a simțit nevoia de a crea un comitet de strategie IT exclusiv la nivel de consiliu, cu
minim doi directori ca membri, dintre care unul ar trebui să fie un director independent. Toți
membrii Comitetului de strategie IT ar trebui să fie competenți din punct de vedere tehnic, în
timp ce cel puțin un membru ar trebui să aibă o experiență substanțială în gestionarea/dirijarea
inițiativelor tehnologice.
• S-a simțit nevoia ca poziția de CIO în bănci, să fie jucătorul cheie în afaceri și să joace un
rol în funcția executivă de luare a deciziilor. Rolul cheie al CIO ar fi să acționeze ca proprietar
al funcției IT și să permită alinierea afacerii și tehnologiei.
• Trebuie creat comitetul de conducere IT cu reprezentanți din diferite funcții IT, HR,
juridic și funcții de afaceri, după caz. Rolul Comitetului de Coordonare IT ar fi acela de a
asista conducerea executivă în implementarea strategiei IT aprobată de Consiliu.
• Comitetul de conducere IT ar trebui să evalueze dacă structura de guvernanță IT
încurajează responsabilitatea, este eficientă și transparentă, are obiective și acțiuni bine definite
și responsabilități clare pentru fiecare nivel al organizației.
• Structura organizatorică pentru IT ar trebui să fie proporțională cu dimensiunea,
amploarea și natura activităților de afaceri desfășurate de bancă și suportul subiacent oferit de
sistemele de informare pentru funcțiile de afaceri.
• Domeniile de interes cheie ale guvernanței IT care trebuie luate în considerare includ
alinierea strategică, livrarea valorii, managementul riscurilor, managementul resurselor și
managementul performanței.
• Cerințele pentru resursele instruite cu seturile de abilități necesare pentru funcția IT
trebuie să fie înțelese și evaluate în mod corespunzător. Ar trebui efectuată o evaluare
periodică a cerințelor de formare pentru resursele umane pentru a se asigura că sunt disponibile
resurse umane suficiente, competente și capabile.
• Consiliul trebuie să cunoască în mod adecvat resursele IT și infrastructura disponibilă

pentru a îndeplini obiectivele strategice de afaceri necesare și să se asigure că există un proces
de înregistrare a resurselor disponibile/ potențial disponibile pentru bancă.
• Performanța funcției IT ar trebui monitorizată pentru a asigura livrarea la timp și în limita
bugetului, cu funcționalitate adecvată și cu beneficiile preconizate.
• Băncile trebuie să stabilească și să mențină un model de informații de întreprindere pentru
a permite dezvoltarea de aplicații și activități de sprijinire a deciziilor, în concordanță cu
strategia IT. Modelul ar trebui să faciliteze crearea, utilizarea și partajarea optime a
informațiilor de către o companie, într-un mod care să mențină integritatea și să fie flexibil,
funcțional, rentabil, oportun, sigur și rezistent la eșec.
• Există, de asemenea, necesitatea menținerii unui „dicționar de date al întreprinderii” care
încorporează regulile de sintaxă a datelor ale organizației. Acest lucru ar trebui să permită
partajarea datelor între aplicații și sisteme, să promoveze o înțelegere comună a datelor între
utilizatorii IT și de afaceri și să prevină crearea elementelor de date incompatibile.
• Trebuie să existe proceduri de evaluare a integrării și interoperabilității proceselor IT
complexe, cum ar fi managementul problemelor, schimbărilor și configurației, în funcție de
gradul de pârghie tehnologică dintr-o bancă.
• Trebuie implementat un cadru adecvat de management al programului și al proiectelor
pentru gestionarea tuturor proiectelor IT, care să asigure prioritizarea și coordonarea corectă.
• Pentru gestionarea riscurilor de proiect, proiectelor IT ar trebui să se aplice o abordare
consecventă și definită formal de management al programului și al proiectelor, care să permită
participarea adecvată a părților interesate și monitorizarea riscurilor și progresului proiectului.
• Pentru proiectele majore, evaluarea formală a riscurilor de proiect trebuie efectuată și
gestionată în mod continuu
• Politica de gestionare a riscurilor la nivelul întregii bănci sau politica de risc operațional
trebuie să includă riscuri legate de IT, iar Comitetul de management al riscurilor ar trebui să le
revizuiască și să le actualizeze periodic (cel puțin anual).
• Funcția IT trebuie să susțină un sistem de informare de management robust și cuprinzător
în ceea ce privește diferitele funcții de afaceri, conform nevoilor afacerii și în coordonare cu
personalul de afaceri, astfel încât să ofere input pentru luarea eficientă a deciziilor de către
conducere.
• Componentele cadrelor de control IT bine-cunoscute, cum ar fi COBIT, aplicabile
mediului tehnologic al fiecărei bănci, pot fi luate în considerare pentru implementare în etape,
oferind un set standardizat de termeni și definiții care sunt interpretate în mod obișnuit de către
toate părțile interesate.
• Practicile eficiente de control IT și monitorizarea acestora sunt necesare pentru a evita
defecțiunile controlului intern și a supravegherii, pentru a crește eficiența, a utiliza resursele în
mod optim și a crește eficacitatea proceselor IT.
• Informațiile privind proiectele IT majore care au un impact semnificativ asupra profilului
de risc și strategiei băncii trebuie raportate la nivelurile adecvate de management și sunt
supuse periodic unei analize strategice și cost/recompense adecvate.
• Trebuie create comitete de conducere la nivel de proiect pentru a-și asuma
responsabilitatea pentru execuția planului de proiect, atingerea rezultatelor și finalizarea
proiectului.
• Un tablou de punctaj echilibrat IT poate fi luat în considerare pentru implementare, cu
aprobarea părților interesate cheie, pentru a măsura performanța IT pe diferite dimensiuni, cum
ar fi aspectele financiare,
satisfacția clienților, eficacitatea procesului, capacitatea viitoare și pentru evaluarea
performanței managementului IT.
• Băncile pot lua în considerare, de asemenea, evaluarea nivelului lor de maturitate IT, pe
baza unor standarde internaționale bine cunoscute, elaborarea unui plan de acțiune și
implementarea planului pentru a atinge nivelul țintă de maturitate.
• Un forum din India, sub egida IDRBT, asemănător Consorțiului pentru Tehnologia
Serviciilor Financiare din SUA, poate lucra în colaborare pentru a rezolva problemele și
provocările comune, precum și pentru a iniția noi tehnologii care beneficiază toate băncile.
• Un forum exclusiv pentru CIO și oficialii IT superiori ai băncilor, sub egida IDRBT, poate
fi încurajat pentru a permite schimbul de experiențe și a discuta probleme de relevanță
contemporană în beneficiul industriei în ansamblu.
Despre securitatea informațiilor:
• Rolul major al Consiliului de Administrație/Super Management ar trebui să implice
aprobarea politicilor de securitate a informațiilor, stabilirea proceselor/funcțiilor
organizaționale necesare pentru securitatea informațiilor și furnizarea resurselor necesare.
• Fiecare bancă trebuie să creeze o funcție separată de securitate a informațiilor pentru a se
concentra exclusiv pe managementul securității informațiilor. Organizarea funcției de
securitate a informațiilor ar trebui să fie proporțională cu natura și dimensiunea activităților
unei bănci și cu amploarea pârghiei IT și a canalelor de livrare electronică. Funcția ar trebui să
dispună de resurse adecvate în ceea ce privește numărul de personal, gama și nivelul de
aptitudini ale acestora, precum și instrumentele sau tehnicile.
• Un funcționar de nivel suficient de înalt cu rangul de GM/DGM/AGM trebuie desemnat
ca Chief Information Security Officer (CISO) responsabil pentru articularea și aplicarea
politicilor pe care o bancă le folosește pentru a-și proteja activele informaționale, în afară de
coordonarea securității informațiilor legate de probleme / implementare în cadrul organizației
precum și agenții externe relevante. CISO trebuie să raporteze direct șefului funcției de
management al riscurilor și nu ar trebui să aibă o relație de raportare directă cu CIO.
• Trebuie să existe o politică de securitate a informațiilor aprobată de consiliu și să fie
revizuită cel puțin o dată pe an. Cadrul de politici ar trebui să ia în considerare, printre altele,
aspecte precum:alinierea la obiectivele de afaceri; obiectivele, domeniul de aplicare,
proprietatea și responsabilitatea politicii; structura organizatorica de securitate a informatiilor;
rolurile și responsabilitățile în materie de securitate a informațiilor; excepții; seturile de
cunoștințe și abilități necesare; formare periodică și educație profesională continuă; evaluarea
conformității și măsurile penale pentru nerespectarea politicilor.
• Evaluarea riscurilor este competența de bază a managementului securității informațiilor
pentru o bancă. Evaluarea riscului trebuie să identifice, pentru fiecare activ din domeniul său
de aplicare, combinațiile de amenințare/vulnerabilitate care au probabilitatea de a afecta
confidențialitatea, disponibilitatea sau integritatea acelui activ - din punct de vedere al afacerii,
conformității și/sau contractuală.
• Descrierile postului, inclusiv rolurile și responsabilitățile, contractele de angajare și
recunoașterile privind conștientizarea politicilor din partea personalului cresc responsabilitatea
pentru securitate. Conducerea poate comunica rolurile și responsabilitățile de securitate
generale și specifice pentru toți angajații pe baza fișelor postului lor. Conducerea trebuie să se
aștepte ca toți angajații, ofițerii și contractanții să respecte politicile de securitate a
informațiilor și/sau de utilizare acceptabilă și să protejeze activele instituției, inclusiv
informațiile.
• Dovezile digitale trebuie considerate ca fiind similare cu orice altă formă de probă legală.
Trebuie să facă față provocărilor aduse integrității sale, manipularea sa trebuie urmărită și
documentată cu atenție și trebuie să fie autentificată corespunzător de către personalul în
cauză. Trebuie să existe o politică în acest sens.
• Menținerea unui inventar detaliat al activelor informaționale și clasificarea
informațiilor/datelor se numără printre componentele cheie ale managementului securității
informațiilor.
• Băncile trebuie să acorde autorizație pentru accesul la activele informaționale numai acolo
unde există o nevoie de afaceri valabilă și numai pentru o perioadă de timp determinată pentru
care este necesar accesul.
• Personalul cu privilegii ridicate de acces la sistem ar trebui supravegheat îndeaproape.
• Securitatea informațiilor trebuie să fie luată în considerare în toate etapele ciclului de viață
al unui activ informațional (cum ar fi hardware, software), care include de obicei: planificare și
proiectare; achizitie si implementare; întreținere și suport; și eliminarea astfel încât să se
minimizeze expunerea la vulnerabilități.
• Băncile ar trebui să aibă un proces în vigoare pentru a verifica informațiile despre cererea
de angajare pentru toți angajații noi. Sensibilitatea unui anumit loc de muncă sau a unui nivel
de acces poate justifica verificarea suplimentară a antecedentelor și a creditului.
• Băncile ar trebui să implementeze controale fizice și de mediu adecvate, luând în
considerare amenințările și pe baza locației geografice unice a entității, configurația clădirii,
entitățile învecinate etc.
• Există o nevoie vitală de programe inițiale și continue de instruire/conștientizare privind
securitatea informațiilor pentru angajați și personalul furnizorului. De asemenea, ar trebui să
existe un mecanism de urmărire periodică a eficacității programelor de formare printr-un
proces de evaluare conceput pentru a testa înțelegerea politicilor relevante.
• Trebuie să existe un proces robust de gestionare a incidentelor pentru a menține
capacitatea de a gestiona incidentele în cadrul unei întreprinderi, pentru a permite limitarea
expunerilor și pentru a realiza recuperarea într-o perioadă de timp specificată. Incidentele pot
include aspecte legate de utilizarea greșită a activelor de calcul, dezvăluirea de informații sau
evenimente care amenință continuarea proceselor de afaceri.
• O bancă trebuie să aibă mecanisme clare de responsabilitate și planuri de comunicare
(pentru escaladare și raportare către Consiliu și conducerea superioară și comunicarea cu
clienții, acolo unde este cazul) pentru a limita impactul incidentelor de securitate a
informațiilor. Instituțiile ar trebui, de asemenea, să notifice în mod proactiv
CERT-In/IDRBT/RBI cu privire la incidentele majore de securitate cibernetică.
• Ar trebui să existe standarde/proceduri documentate pentru administrarea unui sistem de
aplicații, care sunt aprobate de proprietarul aplicației și menținute la zi. Accesul la aplicație ar
trebui să se bazeze pe principiul cel mai mic privilegiu și „nevoia de a ști”, proporțional cu
responsabilitățile postului. Trebuie aplicată o segregare adecvată a sarcinilor.
• Fiecare aplicație care afectează informații critice/sensibile, de ex. care afectează aspectele
financiare, ale clienților, de control, de gestionare a riscurilor, de reglementare și statutare,
trebuie să prevadă trasee de audit detaliate/capacitate de înregistrare cu detalii precum id-ul
tranzacției, data, ora, id-ul inițiatorului, id-ul autorizatorului, acțiunile întreprinse de un anumit
ID de utilizator etc. Trebuie să fie disponibile și alte detalii, cum ar fi adresa IP de înregistrare
a computerului client, identitatea terminalului sau locația. Trebuie luate în considerare alertele
cu privire la utilizarea aceluiași aparat atât pentru tranzacțiile producătorului, cât și a celor de
verificare. Jurnalele/alertele/rapoartele de excepție cu privire la sisteme ar trebui analizate și
orice probleme trebuie remediate cel mai devreme.
• Traseele de audit ar trebui să satisfacă cerințele de afaceri ale unei bănci, în afară de
cerințele legale și de reglementare. De asemenea, ar trebui să faciliteze desfășurarea auditului,
servind drept dovezi criminalistice atunci când este necesar și să asiste la soluționarea litigiilor,
inclusiv în scopuri de nerepudiere. Părțile de audit ar trebui să fie securizate pentru a asigura
integritatea informațiilor capturate și păstrarea dovezilor.
• Băncile pot obține declarații de integritate a aplicației în scris de la furnizorii de sisteme de
aplicații, oferind un nivel rezonabil de asigurare cu privire la faptul că aplicația nu conține
programe malware în momentul vânzării, fără erori evidente și fără canale secrete din cod (din
versiunea aplicației în curs de livrare, precum și orice versiuni/modificări ulterioare efectuate).
• Trebuie să existe măsuri de securitate a datelor. Băncile trebuie să definească și să

implementeze proceduri pentru a asigura integritatea și coerența tuturor datelor critice stocate
în formă electronică, cum ar fi bazele de date, depozitele de date și arhivele de date.
• Actualizările directe ale bazei de date nu ar trebui permise decât în timpul exigențelor, în
cazul unei nevoi reale de afaceri și după autorizarea corespunzătoare conform politicii
relevante
• Orice modificare a unui sistem/date de aplicație trebuie să fie justificată de nevoile reale de
afaceri și de aprobări susținute de documentație și supuse unui proces robust de gestionare a
modificărilor.
• Pentru toate aplicațiile critice, fie codul sursă trebuie să fie primit de la furnizor, fie un
acord de escrow software trebuie să fie în vigoare cu o terță parte pentru a asigura
disponibilitatea codului sursă în cazul în care vânzătorul iese din afacere. Trebuie să se asigure
că actualizările de produse și remedierea programelor sunt incluse și în acordul de escrow.
• Transferul de date de la un proces la altul sau de la o aplicație la alta, în special în ceea ce
privește aplicațiile critice sau financiare, nu ar trebui să aibă nicio intervenție manuală pentru a
preveni orice modificare neautorizată. Procesul trebuie să fie automatizat și integrat
corespunzător prin metodologia „Straight Through Processing” cu un mecanism de
autentificare și piste de audit adecvate.
• În cazul în care datele referitoare la operațiunile din India sunt stocate și/sau procesate în
străinătate, de exemplu, de către bănci străine, trebuie să existe controale adecvate, cum ar fi
segregarea datelor și controale stricte de acces bazate pe „nevoia de a cunoaște” și controale
robuste ale schimbării. Banca ar trebui să fie în măsură să demonstreze în mod adecvat același
lucru autorității de reglementare. Accesul autorităților de reglementare la astfel de
date/înregistrări și alte informații relevante nu ar trebui să fie împiedicat în niciun fel, iar RBI
ar avea dreptul de a determina efectuarea unei inspecții a centrului de procesare/centrul de date
și a registrelor și a conturilor acestuia de către unul sau mai mulți dintre funcționarii săi. sau
angajați sau alte persoane.
• Trebuie efectuate teste robuste de securitate a sistemului.
• Arhitectura de aplicații cu mai multe niveluri trebuie implementată pentru sistemele de e-
banking critice, cum ar fi internet banking, care diferențiază controlul sesiunii, logica
prezentării, validarea de intrare pe partea serverului, logica de afaceri și accesul la baze de
date.
• O bancă trebuie să aibă o politică de migrare documentată care să specifice un proces
sistematic pentru migrarea datelor și pentru a asigura integritatea, completitudinea și coerența
datelor. Trebuie obținute aprobări explicite de la utilizatori/proprietari de aplicații după fiecare
etapă de migrare și, de asemenea, după finalizarea procesului de migrare. Traseele de audit
trebuie să fie disponibile pentru a documenta conversia, inclusiv mapările și transformările
datelor.
• Băncile trebuie să efectueze diligența necesară cu privire la noile tehnologii/sisteme,
deoarece pot introduce expuneri suplimentare la riscuri.
• Orice produse comerciale noi introduse, împreună cu sistemele informaționale subiacente,
trebuie să fie evaluate ca parte a unui proces formal de aprobare a produsului care
încorporează, printre altele, aspecte legate de securitate și îndeplinirea prescripțiilor legale și de
reglementare relevante.
• Tehnicile criptografice trebuie utilizate pentru a controla accesul la date/informații critice
și sensibile în tranzit și stocare. Băncile ar trebui să selecteze doar algoritmi de criptare care
sunt standarde internaționale bine stabilite și care au fost supuși unui control riguros de către o
comunitate internațională de criptografi sau aprobați de organisme profesionale autorizate,
furnizori de securitate reputați sau agenții guvernamentale.
• În mod normal, este de așteptat un minim de criptare SSL de 128 de biți. Progresele
constante în hardware-ul computerelor, criptoanaliza și tehnicile distribuite de forță brută pot
induce utilizarea periodică a cheilor de lungimi mai mari. Este de așteptat ca băncile să
evalueze în mod corespunzător cerințele de securitate asociate cu sistemele lor bancare prin
internet și cu alte sisteme relevante și să adopte o soluție de criptare proporțională cu gradul de
confidențialitate și integritate necesar.

• Băncile trebuie să scaneze frecvent vulnerabilitățile și să abordeze defectele descoperite în
mod proactiv pentru a evita probabilitatea ca sistemele lor computerizate să fie compromise.
Instrumentele automate de scanare a vulnerabilităților trebuie utilizate periodic împotriva
tuturor sistemelor din rețelele lor.
• Băncile trebuie să dispună de procese de monitorizare pentru a identifica evenimentele
suspecte și modelele de comportament neobișnuite care ar putea afecta securitatea activelor IT.
Puterea controalelor de monitorizare ar trebui să se bazeze pe criticitatea unui activ IT. O
bancă ar trebui să stabilească o alocare clară a responsabilității pentru mecanismul de
monitorizare regulat, iar instrumentele și procesele în acest sens trebuie să fie proporționale cu
nivelul de monitorizare necesar.
• Funcțiile critice, de exemplu cele legate de financiar, de reglementare și juridic, MIS și
managementul riscurilor, trebuie să fie realizate prin sisteme de aplicații adecvate și nu manual
sau într-o manieră semi-automatizată prin foi de calcul care prezintă riscuri legate de
integritatea și fiabilitatea datelor. Utilizarea foilor de calcul în acest sens ar trebui să fie
restricționată și ar trebui înlocuită cu aplicații IT adecvate în mod treptat într-un interval de
timp determinat.
• Trebuie să existe un proces robust pentru „controlul eficient al malware”. Controalele
tipice pentru protejarea împotriva codului rău intenționat folosesc combinații stratificate de
tehnologie, politici și proceduri și instruire. Controalele sunt de natură preventivă și
detectivă/corectivă.
• Stabilirea unei strategii robuste de protecție a rețelei și a securității stratificate bazate pe
principiul apărării în profunzime este o necesitate absolută pentru bănci.
• Ar trebui să existe aranjamente pentru monitorizarea și raportarea stării de securitate a
informațiilor din organizație, care să fie documentate, convenite cu managementul de vârf și
efectuate în mod regulat. Valorile legate de securitate pot fi utilizate pentru a măsura
implementarea politicii de securitate.
• Având în vedere multitudinea de dispozitive și sisteme, băncile ar trebui să implementeze
instrumente automate adecvate pentru agregarea și consolidarea jurnalelor de la mai multe
mașini/sisteme și pentru corelarea și analiza jurnalelor.
• Procesele de securitate și audit ale furnizorilor/furnizorilor de servicii critice trebuie să fie
evaluate în mod regulat, deoarece controalele ineficiente ale terților pot slăbi capacitatea unei
bănci de a-și atinge obiectivele de control.
• Băncile comerciale ar trebui să implementeze cele mai bune practici ale sistemului de
management al securității informațiilor (ISMS) bazate pe ISO 27001 pentru funcțiile lor critice.
În plus, băncile pot lua în considerare și alte cadre reputate de securitate/control IT.
• Trebuie inițiate controale puternice împotriva oricărei facilitati de acces la distanță.
Conducerea ar trebui să stabilească politici de restricționare a accesului de la distanță și să fie
la curent cu toate dispozitivele de acces la distanță atașate sistemelor băncii. Aceste dispozitive
ar trebui să fie strict controlate.
• Evenimentele care declanșează implementarea unui plan de continuitate a afacerii pot avea
implicații de securitate. Evaluările riscurilor ar trebui să ia în considerare riscurile în schimbare
care apar în scenariile de continuitate a afacerii și diferitele posturi de securitate care ar putea
trebui stabilite.
• Asigurarea securității informațiilor trebuie să fie obținută prin exerciții periodice de testare
a pătrunderii, audituri și evaluări ale vulnerabilităților. Lucrarea de asigurare trebuie efectuată
de experți/auditori independenți și instruiți corespunzător în securitatea informațiilor. Punctele
forte și punctele slabe ale aplicațiilor critice bazate pe internet, ale altor sisteme și rețele critice
trebuie realizate înainte de fiecare implementare inițială și cel puțin anual după aceea. Orice
constatări trebuie raportate și monitorizate folosind o metodologie sistematică de remediere a
auditului sau de urmărire a conformității.
• Furnizarea de diverse canale bancare electronice, cum ar fi ATM/carduri de debit/internet
banking/telefonic banking ar trebui să fie emisă numai la opțiunea clienților, pe baza unei
cereri electronice specifice scrise sau autentificate, împreună cu o confirmare pozitivă a
termenilor și condițiilor din partea clientului. Un client nu trebuie obligat să opteze pentru
servicii în acest sens. Băncile ar trebui să ofere clienților informații clare despre riscurile și
beneficiile utilizării serviciilor de livrare prin e-banking, pentru a le permite clienților să decidă
cu privire la alegerea unor astfel de servicii.
• Având în vedere proliferarea atacurilor cibernetice și a potențialelor consecințe ale
acestora, băncile ar trebui să implementeze autentificarea cu doi factori pentru activități critice,
cum ar fi transferurile de fonduri și modificarea detaliilor legate de clienți prin intermediul
facilitatii de internet banking.
• Implementarea metodologiilor adecvate de autentificare ar trebui să se bazeze pe o
evaluare a riscului prezentat de sistemele de internet banking ale instituției. Riscul ar trebui
evaluat în funcție de tipul de client (de exemplu, retail sau corporativ/comercial); capabilitățile
tranzacționale ale clienților (de exemplu, plata facturii, transferul de fonduri), sensibilitatea
informațiilor despre clienți care sunt comunicate băncii și volumul tranzacțiilor implicate.
• Deși nu folosirea criptosistemului asimetric și a funcției hash este o sursă de risc juridic,
băncile, cel puțin, trebuie să implementeze autentificarea dinamică cu doi factori prin
combinația ID utilizator/parolă și al doilea factor cum ar fi (a) OTP/codul de acces dinamic
prin diverse moduri, cum ar fi SMS-uri prin telefoane mobile sau token hardware sau (b) o
semnătură digitală, printr-un card/token care conține un certificat digital și cheia privată
asociată (de preferință pentru clienții corporativi).
• Pentru a spori securitatea procesării online, procedurile de confirmare ale canalului
secundar (cum ar fi telefonia, SMS-urile, e-mailul etc.) ar trebui aplicate în ceea ce privește
tranzacțiile peste valorile prestabilite, crearea de noi legături de cont, înregistrarea detaliilor
beneficiarului terților, modificarea detaliilor contului sau revizuirea limitelor de transfer de
fonduri. În conceperea acestor caracteristici de securitate, banca ar trebui să țină cont de
eficacitatea acestora și de preferințele diferite ale clienților pentru o protecție suplimentară
online.
• Pe baza protocoalelor de autentificare reciprocă, clienții ar putea, de asemenea, autentifica
site-ul web al băncii prin mecanisme de securitate, cum ar fi mesaje/imagini de asigurare
personală, schimbul de coduri de securitate pentru răspuns la provocare și/sau verificarea
certificatelor de server SSL (Secure Sockets Layer). În ultima vreme, certificatele Extended
Validation Secure Sockets Layer (EV-SSL) sunt din ce în ce mai folosite. Cu toate acestea,
trebuie remarcat faptul că SSL nu oferă securitate de criptare end-to-end la nivelul aplicației, ci
este conceput doar pentru a cripta datele în tranzit la nivelul de transport al rețelei.
• Trebuie implementat un proces de monitorizare sau supraveghere a tranzacțiilor bazat pe
riscuri. Băncile pot lua în considerare modele dinamice de scoring și procese aferente pentru a
declanșa sau a alerta tranzacții care nu sunt normale pentru a îmbunătăți capacitatea de
prevenire/detecție. Studiul modelelor de comportament ale tranzacțiilor clienților și oprirea
tranzacțiilor neregulate sau obținerea unei confirmări prealabile de la clienți pentru tranzacțiile
aberante pot fi încorporate ca parte a procesului.
• Cardurile bazate pe cip găzduiesc date pe microcipuri în loc de benzi magnetice, ceea ce
face ca datele să fie mai dificil de furat și cardurile mai dificil de reprodus. Se recomandă ca
RBI să ia în considerare trecerea la carduri bazate pe cip împreună cu necesitatea modernizarii
infrastructurii necesare, cum ar fi ATM-urile/terminalele POS în acest sens, într-o manieră
treptată.
• Pentru tranzacțiile cu cardul de debit/credit la terminalele POS, un sistem de autorizare
bazat pe PIN trebuie să fie implementat (fără nicio buclă) în locul sistemului existent bazat pe
semnătură, iar terminalele POS fără PIN trebuie retrase în etape. .
• Având în vedere că problemele de control, securitate și juridice privind cloud computing
sunt încă în evoluție, o bancă trebuie să fie precaută și să efectueze diligența necesară pentru a
evalua riscurile în mod cuprinzător înainte de a lua în considerare cloud computing.
• Trebuie să existe un forum de CISO care să poată interacționa periodic și să împărtășească
experiențe cu privire la orice amenințări la securitatea informațiilor. Se raportează că un forum
CISO este deja funcțional în cadrul IDRBT. Forumul poate, printre alte funcții, să încerce să
împărtășească bune practici, să identifice orice probleme specifice de securitate a informațiilor
și să le semnaleze părților interesate adecvate, cum ar fi autoritatea de reglementare, IBA etc.
• Este nevoie de un sistem de schimb de informații asemănător cu funcțiile îndeplinite de

FS-ISAC (Agenția de Partajare a Informațiilor pentru Servicii Financiare) în SUA. IDRBT ca
sub-CERT al sistemului bancar poate funcționa ca un punct nodal pentru schimbul de
informații.
• Acreditarea și includerea calificărilor/certificărilor de audit de securitate și a furnizorilor
de audit de securitate pot fi luate în considerare la un nivel mai larg de către Guvernul
Indiei/CERT-In sau de către IDRBT pentru sectorul bancar.
• Pentru a reduce timpul, costul și complexitatea asigurării software și pentru a asigura
securitatea, sustenabilitatea și rezistența acesteia și pentru a crește eficacitatea metodelor
utilizate de industria bancară pentru asigurarea software-ului, o inițiativă similară cu FSTC
Software Assurance Initiative (SAI) în SUA poate fi luat în considerare în India, eventual sub
egida IDRBT împreună cu diverse părți interesate.
• Este nevoie ca IBA, IDRBT și instituții de renume precum DSCI să colaboreze și să
dezvolte cadre de securitate și metodologii și proceduri detaliate de implementare în beneficiul
sectorului bancar, pe baza aspectelor legate de securitatea informațiilor acoperite în acest
raport.
• Există o nevoie din ce în ce mai mare de cercetări detaliate specifice în domeniul
securității tehnologiei bancare și de a scoate la iveală produse bancare inovatoare și sigure în
colaborare cu organisme academice de renume precum IIT-urile. IDRBT își poate extinde
activitățile/inițiativele în acest sens.
• Având în vedere natura problemei securității cibernetice, trebuie să existe implicare la un
nivel mai larg la nivel național și internațional, cu guvernul, agențiile de aplicare a legii,
diferite asociații industriale și instituții academice.
• RBI poate lua în considerare crearea unui Comitet permanent multidisciplinar pentru
securitatea informațiilor, cu reprezentare a diverșilor părți interesate, pentru a lua în
considerare noile evoluții legate de securitate și, de asemenea, evoluțiile legale și, pe baza
acestora, să ofere recomandări pentru actualizarea adecvată a ghidurilor în mod periodic.
• Eforturi de colaborare pot fi depuse și de organisme reputate precum IDRBT, IIBF și
DSCI coordonate de IBA pentru a crea cursuri de certificare indigene personalizate pentru a
certifica cunoștințe și aptitudini specifice în domeniile IT/securității informațiilor pentru
diferite categorii de personal bancar la nivel operațional și managerial, astfel încât crearea unui
grup mare și divers de talente necesare în cadrul sistemului bancar.
Despre operațiunile IT:
• Consiliul de administrație și conducerea superioară ar trebui să supravegheze
implementarea unui mediu de operațiuni IT sigur și solid. Politicile și procedurile definite ca
parte a operațiunilor IT ar trebui să sprijine scopurile și obiectivele unei bănci, precum și să
respecte cerințele statutare și de reglementare.
• Operațiunile IT includ servicii de afaceri care sunt disponibile clienților interni sau externi
ai organizației folosind IT ca componentă de livrare a serviciilor. Instanțele includ Mobile
Banking și Internet Banking. Operațiunile IT includ, de asemenea, componente IT care sunt
utilizate pentru a sprijini operațiunile IT, care pot fi aplicații de birou de service, instrumente
de ticketing, instrumente de gestionare a evenimentelor etc. Băncile pot lua în considerare
includerea mediului de testare, mediu de asigurare a calității și orice alt astfel de mediu în afară
de mediul de producție în domeniul de aplicare al Operațiunilor IT.
• Băncile ar trebui să își analizeze mediul de operare IT, inclusiv tehnologia, resursele
umane și procesele implementate pentru a identifica amenințările și vulnerabilitățile și pentru a
efectua o evaluare periodică a riscurilor. Ca parte a identificării și evaluării riscurilor, băncile
ar trebui să identifice evenimente sau activități care ar putea perturba operațiunile sau ar putea
afecta negativ reputația sau câștigurile și să evalueze conformitatea cu cerințele de
reglementare. Băncile ar trebui să definească diferite atribute pentru fiecare componentă de
risc, cum ar fi probabilitatea de apariție, impactul financiar etc. Aceste atribute, împreună cu
procesul de afaceri implicat, ar trebui să fie utilizate pentru a prioritiza acțiunile de atenuare a
riscurilor și cadrul de control.
• Strategia IT ca cadru ar trebui să ofere feedback operațiunilor IT cu privire la serviciile

care vor fi susținute, procesele lor de afaceri subiacente, prioritizarea acestor servicii etc. Un
cadru de strategie IT bine definit va ajuta operațiunile IT în sprijinirea serviciilor IT, așa cum
este cerut de afacere și definite în SLA.
• Evaluarea Serviciilor este mecanismul care poate fi luat în considerare de bănci pentru a
cuantifica serviciile care sunt disponibile clienților săi (interni/externi) și susținute de
operațiunile IT în termeni financiari. Evaluarea serviciului va ajuta Funcția de operare IT să
prezinte implicarea funcției în sprijinirea activității de bază a băncilor.
• Procesul de management al cererii oferă linii directoare care pot fi utilizate de bănci pentru
a înțelege procesele de afaceri suportate de operațiunile IT pentru a identifica, analiza și
codifica modelele de activități de afaceri (PBA) pentru a oferi o bază suficientă pentru cerințele
de capacitate.
• Componentele care ar trebui luate în considerare atunci când se proiectează un nou
serviciu IT sau se efectuează o modificare a serviciului IT existent includ procesele de afaceri,
acordurile de nivel de servicii, infrastructura IT, mediul IT etc.
• De-a lungul anilor, infrastructura IT din bănci a crescut și s-a dezvoltat și este posibil să nu
existe o imagine clară a tuturor serviciilor IT furnizate în prezent și a consumatorilor pentru
fiecare serviciu. Pentru a stabili un peisaj IT precis, se recomandă definirea, producerea și
întreținerea unui Catalog de servicii IT. Catalogul de servicii poate fi considerat un depozit
care oferă informații despre toate serviciile IT susținute de cadrul Operațiunilor IT.
• Băncile trebuie să instituie un proces de management al nivelului de servicii pentru
planificarea, coordonarea și elaborarea, acordul, monitorizarea și raportarea atributelor
serviciilor utilizate pentru măsurarea calității serviciului. Cadrul trebuie să includă linii
directoare pentru revizuirea continuă a realizărilor serviciilor pentru a se asigura că calitatea
serviciului necesară și justificabilă din punct de vedere al costurilor este menținută și
îmbunătățită treptat. Cadrul de management al nivelului de servicii definit de bănci ar trebui să
aibă, de asemenea, linii directoare definite pentru înregistrare și gestionare, inclusiv
escaladarea reclamațiilor și complimentelor.
• Este necesar un proces de management al capacității pentru a se asigura că există o
capacitate IT justificabilă din punct de vedere al costurilor pentru serviciile IT și se potrivește
cu cerințele actuale și viitoare ale afacerii, așa cum sunt identificate în Acordul privind nivelul
de servicii. Băncile care adoptă procesul de management al capacității ar trebui să se asigure că
cadrul cuprinde toate domeniile legate de tehnologie, adică hardware, software, resurse umane,
facilități etc.
• Disponibilitatea și fiabilitatea serviciilor IT pot influența direct satisfacția clienților și
reputația băncilor. Managementul disponibilității este esențial pentru a ne asigura că IT oferă
nivelul corect de servicii cerut de companie pentru a-și îndeplini obiectivele de afaceri. Când
definesc țintele de disponibilitate pentru un serviciu de afaceri, băncile ar trebui să ia în
considerare identificarea funcției vitale de afaceri (VBF).
• Atributele care pot fi utilizate de bănci pentru a raporta disponibilitatea serviciilor IT
includ disponibilitatea (în procente), Timpul mediu între incidente de serviciu, Timpul mediu
între defecțiuni și Timpul mediu până la reparare.
• Implementarea cadrului de management al activelor și configurației de servicii are
implicații legate de costuri și resurse și, prin urmare, trebuie să existe discuții strategice cu
privire la prioritățile care trebuie abordate.
• Băncile trebuie să implementeze un proces de „management al schimbării” pentru
gestionarea oricăror schimbări în tehnologie și procese, pentru a se asigura că modificările sunt
înregistrate, evaluate, autorizate, prioritizate, planificate, testate, implementate, documentate și
revizuite într-o manieră și mediu controlat.
• Faza de operațiuni, ca parte a ciclului de viață de management al serviciilor, este
responsabilă de executarea și realizarea proceselor care optimizează costul calității serviciilor.
Ca parte a organizației, este responsabilă pentru a permite afacerii să-și atingă obiectivele. Ca
parte a tehnologiei, este responsabil pentru funcționarea eficientă a componentelor care sprijină
serviciile de afaceri. Diferitele aspecte pe care băncile trebuie să le ia în considerare includ
managementul evenimentelor, managementul incidentelor, managementul problemelor și

managementul accesului.
Despre externalizarea IT:
• Consiliul și conducerea superioară sunt responsabile în ultimă instanță pentru operațiunile
externalizate și pentru gestionarea riscurilor inerente unor astfel de relații de externalizare.
Responsabilitățile pentru due diligence, supravegherea și gestionarea externalizării și
responsabilitatea pentru toate deciziile de externalizare continuă să revină băncii, Consiliului și
conducerii superioare.
• Băncile trebuie să evalueze gradul de „materialitate” inerent funcțiilor externalizate. Dacă
un aranjament de externalizare este „material” sau nu pentru contextul de afaceri este o
judecată calitativă și poate fi determinată pe baza criticității serviciului, procesului sau
tehnologiei față de obiectivele generale de afaceri. În cazul în care o bancă se bazează pe
angajați terți pentru a îndeplini funcții bancare cheie, cum ar fi procesarea cererilor etc., în mod
continuu, o astfel de externalizare poate fi, de asemenea, interpretată ca „materială”, indiferent
dacă personalul se află sau nu în sediul Băncii.
• Externalizarea proceselor nefinanciare, cum ar fi operațiunile tehnologice, este „materială”
și, dacă este perturbată, are potențialul de a avea un impact semnificativ asupra operațiunilor de
afaceri, reputației și stabilității unei bănci.
• Evaluarea riscurilor trebuie efectuată înainte de încheierea unui acord de externalizare și
revizuită periodic în lumina schimbărilor cunoscute și așteptate, ca parte a procesului de
planificare strategică sau de revizuire.
• Băncile ar trebui să evalueze procesele gestionate de furnizori sau relațiile specifice cu
furnizorii, deoarece acestea se referă la sistemele și tehnologia informației. Toate sistemele și
operațiunile de informații externalizate pot face obiectul managementului riscului și politicilor
de securitate și confidențialitate care îndeplinesc standardele proprii ale unei bănci și orice
cerințe externe.
• În timpul negocierii/reînnoirii unui acord de externalizare, trebuie efectuată diligența
corespunzătoare pentru a evalua capacitatea furnizorului de servicii tehnologice de a respecta
obligațiile din contractul de externalizare. Due diligence ar trebui să implice o evaluare a
tuturor informațiilor despre furnizorul de servicii, inclusiv a factorilor calitativi, cantitativi,
financiari, operaționali și reputaționali.
• Băncilor trebuie să li se solicite să raporteze autorităților de reglementare în cazul în care
amploarea și natura funcțiilor externalizate sunt semnificative sau este implicată un schimb
extins de date între locații geografice, ca parte a externalizării tehnologiei/proceselor.
• Termenii și condițiile care guvernează contractul dintre bancă și furnizorul de servicii ar
trebui să fie definite cu atenție în acorduri scrise și verificate de consilierul juridic al băncii în
ceea ce privește efectul lor juridic și caracterul executoriu.
• Băncile ar trebui să se asigure că contractul scoate în evidență natura relației juridice dintre
părți (agent, principal sau de altă natură) și abordează riscurile și strategiile de atenuare
identificate în etapele de evaluare a riscurilor și de due diligence. Contractele ar trebui să
definească în mod clar rolurile și responsabilitățile părților la contract și să includă clauze de
despăgubire adecvate. Orice considerație de „limitare a răspunderii” încorporată de furnizorul
de servicii ar trebui să fie evaluată în consultare cu departamentul juridic.
• În cazul relațiilor cu mai mulți furnizori de servicii în care doi sau mai mulți furnizori de
servicii colaborează pentru a oferi o soluție completă pentru instituția financiară, banca
rămâne responsabil pentru înțelegerea și monitorizarea mediului de control al tuturor

furnizorilor de servicii care au acces la sistemele, înregistrările sau resursele băncii.
• Băncile ar trebui să stabilească o structură de management și control al externalizării,
bazată pe natura, domeniul de aplicare, complexitatea și riscul inerent activității externalizate.
• Conducerea ar trebui să includă SLA-uri în contractele de externalizare pentru a conveni și
a stabili responsabilitatea pentru așteptările de performanță. SLA-urile trebuie să formalizeze
clar criteriile de performanță pentru a măsura calitatea și cantitatea nivelurilor de servicii.
Pentru operațiunile tehnologice externalizate, metrici specifice pot fi definite în jurul
disponibilității serviciilor, continuității afacerii și securității tranzacțiilor, pentru a măsura
serviciile prestate de organizația furnizorului extern.
• Băncile ar trebui să evalueze caracterul adecvat al mediului de control intern oferit de
furnizorul de servicii. Ar trebui să se acorde atenție cuvenită implementării de către furnizorul
de servicii a diferitelor aspecte, cum ar fi politicile de securitate a informațiilor și
conștientizarea angajaților cu privire la acestea, controale logice de acces, securitate și
controale fizice și de mediu, controale pentru manipularea datelor etc.
• Externalizarea nu ar trebui să împiedice sau să interfereze cu capacitatea băncii sau a
autorității de reglementare de a-și îndeplini funcțiile și obiectivele de supraveghere. Ca
practică, instituțiile ar trebui să efectueze revizuiri de implementare înainte și după
externalizare. O instituție ar trebui, de asemenea, să își revizuiască aranjamentele de
externalizare periodic (cel puțin anual) pentru a se asigura că politicile și procedurile sale de
gestionare a riscului de externalizare, precum și aceste orientări, sunt respectate efectiv.
• O instituție ar trebui, cel puțin o dată pe an, să revizuiască starea financiară și operațională
a furnizorului de servicii pentru a evalua capacitatea acestuia de a-și îndeplini în continuare
obligațiile de externalizare.
• Băncile ar trebui, de asemenea, să solicite periodic audituri independente și evaluări ale
experților privind mediul de securitate și control al furnizorului de servicii.
• Băncile ar trebui să se asigure că pregătirea lor pentru continuitatea activității nu este
compromisă din cauza externalizării.
• Băncile trebuie să ia măsuri eficiente pentru a se asigura că riscurile legate de
confidențialitate și securitatea datelor sunt atenuate în mod adecvat.
• În cazul externalizării operațiunilor tehnologice, băncile ar trebui să le supună controlului
îmbunătățit și riguros de gestionare a schimbărilor și monitorizare, deoarece responsabilitatea
și responsabilitatea finală revin băncii.
• Băncile, în timp ce întocmesc un plan de urgență viabil, trebuie să ia în considerare
disponibilitatea furnizorilor de servicii alternativi sau posibilitatea de a aduce activitatea
externalizată înapoi în casă în caz de urgență (de exemplu, când numărul de furnizori pentru un
anumit serviciu este extrem de limitat). și costurile, timpul și resursele care ar fi implicate și
fiți pregătiți să luați măsuri rapide, dacă este justificat.
• Angajarea furnizorilor de servicii din mai multe zone geografice expune organizația la
riscul de țară – motive economice, sociale și politice din țară care pot afecta negativ afacerile și
operațiunile băncii. Băncile ar trebui să evalueze în mod proactiv un astfel de risc ca parte a
procesului de due diligence și să dezvolte controale adecvate de atenuare și, după caz, o
strategie de ieșire eficientă.
• Tehnologiile emergente, cum ar fi găzduirea centrelor de date, aplicațiile ca serviciu și
cloud computing au dat naștere unor jurisdicții legale unice pentru date și reglementări
transfrontaliere. Băncile ar trebui să clarifice jurisdicția pentru datele lor și reglementările
aplicabile la începutul unui acord de externalizare. Aceste informații ar trebui revizuite
periodic și în cazul unor modificări semnificative efectuate de furnizorul de servicii.
• Băncile ar trebui să se asigure că calitatea și disponibilitatea serviciilor bancare pentru
clienți nu sunt afectate negativ din cauza acordurilor de externalizare încheiate de bancă.
Băncile au nevoie Compiled by Srinivas Kante Email: srinivaskante4u@gmail.com
să instituie un mecanism robust de soluționare a plângerilor, care să nu fie compromis în niciun

fel din cauza externalizării.
• IBA poate facilita schimbul de date necesare între bănci pentru a menține informațiile de
punctaj pentru furnizorii de servicii existenți/noi, care pot include orice fraudă sau deficiențe
operaționale majore comise de furnizorii de servicii.
• Cadrele detaliate de evaluare și monitorizare a furnizorilor de servicii și cele mai bune
practici din context bancar pot fi explorate de IBA în colaborare cu instituții precum DSCI și
IDRBT.
La auditul IS:
• Pentru a-și îndeplini responsabilitatea de a asigura o funcție de audit independentă cu
resurse suficiente pentru a asigura o acoperire IT adecvată, consiliul de administrație sau
comitetul său de audit ar trebui să asigure o funcție de audit intern capabilă să evalueze în mod
adecvat controalele IT.
• Băncile ar trebui să permită o componență adecvată a comitetului de audit pentru a
gestiona complexitatea supravegherii auditului SI. Un membru desemnat al Comitetului de
Audit trebuie să posede cunoștințele relevante despre sistemele informaționale, controalele SI
și problemele de audit. Membrul desemnat trebuie să aibă, de asemenea, competențe relevante
pentru a înțelege impactul final al deficiențelor identificate în cadrul controlului intern IT de
către funcția de audit IS. Consiliul sau membrii Comitetului de Audit ar trebui să caute
instruire pentru a umple orice lacune în cunoștințele legate de riscurile și controalele IT.
• Comitetul de Audit ar trebui să aloce timp adecvat și suficient constatărilor auditului SI
identificate în timpul auditurilor SI, iar membrii Comitetului de Audit ar trebui să revizuiască
problemele critice evidențiate și să ofere îndrumări adecvate conducerii băncii.
• Băncile ar trebui să aibă o funcție separată de Audit SI în cadrul departamentului de Audit
Intern condus de un șef de audit SI, asumându-și responsabilitatea și responsabilitatea funcției
de audit SI, raportând către directorul executiv al auditului (CAE) sau șefului auditului intern.
În cazul în care banca utilizează resurse externe pentru efectuarea auditului SI în domeniile în
care abilitățile sunt lipsite în cadrul băncii, responsabilitatea și responsabilitatea pentru astfel de
audituri SI externe rămân în continuare la șeful de audit SI și la CAE.
• Auditorii IS trebuie să acționeze independent de conducerea băncii. În toate aspectele
legate de audit, auditul IS trebuie să fie independent de auditat atât ca atitudine, cât și ca aspect.
Auditorii IS trebuie să fie competenți profesional, să aibă abilitățile, cunoștințele, pregătirea și
experiența relevantă pentru a efectua un audit. Auditorii IS trebuie să dea dovadă de grijă
profesională cuvenită, care include respectarea standardelor profesionale de audit în efectuarea
auditului.
• Băncile pot decide să externalizeze execuția unor segmente ale planului de audit către
furnizori externi de servicii profesionale, conform strategiei generale de audit decisă în
coordonare cu CAE și Comitetul de Audit. Lucrarea externalizată va fi limitată la executarea
auditurilor identificate în planul de audit. Băncile trebuie să se asigure că proprietatea și
responsabilitatea generală a auditului SI, inclusiv procesul de planificare a auditului, evaluarea
riscurilor și urmărirea conformității, rămân în cadrul băncii. Asistența externă poate fi obținută
inițial pentru a pune în aplicare procesele necesare în acest sens, dacă este necesar.
• O Carta de Audit / Politica de Audit este un document care ghideaza si directioneaza
activitatile functiei de Audit Intern. Auditul IS, fiind parte integrantă a funcției de Audit Intern,
ar trebui, de asemenea, să fie guvernat de aceeași Carta de Audit / Politică de Audit. Politica de
audit ar trebui să fie documentată astfel încât să conțină o descriere clară a mandatului,
scopului, autorității și responsabilității sale (a membrilor/oficialilor relevanți în ceea ce privește
auditul SI, adică auditorii SI, managementul auditului și comitetul de audit) și principiile de
funcționare relevante. Documentul trebuie aprobat de Consiliul de Administrație.
• Politica/Carta de audit IS ar trebui să fie supusă unei revizuiri anuale pentru a asigura
relevanța și eficacitatea continuă.
• Auditorul SI ar trebui să ia în considerare stabilirea unui proces de asigurare a calității (de
exemplu, interviuri, anchete de satisfacție a clienților, anchete de performanță a sarcinilor etc.)
pentru a înțelege nevoile și așteptările auditatului relevante pentru funcția de audit SI. Aceste
nevoi ar trebui evaluate în raport cu politica în vederea îmbunătățirii serviciului sau a
modificării furnizării serviciilor sau carta de audit, după caz.
• Băncile trebuie să efectueze planificarea auditului IS folosind abordarea de audit bazată pe
risc. Abordarea implică aspecte precum metodologia de evaluare a riscului IT, definirea
Universului de audit IS, stabilirea domeniului și planificarea activităților de audit, execuție și
urmărire.
• Universul de audit IS poate fi construit în jurul celor patru tipuri de resurse IT și diferite
procese IT, cum ar fi sisteme de aplicații, informații sau date, infrastructură (tehnologie și
facilități precum hardware, sisteme de operare, sisteme de gestionare a bazelor de date, rețele,
multimedia etc., și mediu care le găzduiește și le susține care să permită procesarea aplicațiilor)
și oamenii (personal intern sau externalizat necesar pentru planificarea, organizarea,
achiziționarea, implementarea, sprijinirea, monitorizarea și evaluarea sistemelor și serviciilor
informaționale).
• Auditorul IS trebuie să definească, să adopte și să urmeze o metodologie adecvată de
evaluare a riscurilor. Un program de audit SI bazat pe riscuri de succes se poate baza pe un
sistem eficient de notare la care se ajunge prin luarea în considerare a tuturor factorilor de risc
relevanți. Băncile ar trebui să elaboreze orientări scrise cu privire la utilizarea instrumentelor
de evaluare a riscului și a factorilor de risc și să revizuiască aceste orientări împreună cu
Comitetul de Audit sau Consiliul de Administrație. Orientările legate de evaluarea riscurilor
vor varia pentru băncile individuale, în funcție de dimensiunea, complexitatea, domeniul de
activitate, diversitatea geografică și diferitele tehnologii/sisteme utilizate.
• Planul de audit al SI (fie separat, fie ca parte a planului general de audit intern) ar trebui să
fie un document oficial, aprobat în mod corespunzător de Comitetul de Audit inițial și în timpul
oricăror modificări majore ulterioare. Planul de audit ar trebui să fie pregătit astfel încât să fie
în conformitate cu cerințele externe de reglementare/legale corespunzătoare, în plus față de
standardele de audit IS bine-cunoscute.
• Șeful auditului SI este responsabil pentru Planul anual de audit SI care este pregătit pe
baza documentului de definire și a evaluării riscurilor. Planul de audit acoperă în mod obișnuit
strategia generală de audit, domeniile de audit vizate, detaliile obiectivelor de control
identificate în etapa de definire a domeniului, dimensiunile eșantionului, frecvența auditului pe
baza evaluării riscurilor, natura și amploarea auditului și identificarea resurselor de audit IT.
Trebuie prezentat periodic Comitetului de Audit și conducerii superioare un raport privind
starea auditurilor SI planificate față de cele reale și orice modificări ale planului anual de audit
SI.
• Guvernanța IT, aspectele legate de guvernanța securității informațiilor, controalele
generale critice ale IT, cum ar fi controalele și procesele centrelor de date și
aplicațiile/sistemele de afaceri critice care au implicații financiare/de conformitate, inclusiv
sistemele de raportare MIS și de reglementare și punctele de acces ale clienților (cum ar fi
canalele de livrare) trebuie supuse Auditul IS (sau auditul integrat) cel puțin o dată pe an (sau
mai frecvent, dacă este justificat de evaluarea riscului).
• Auditurile IS ar trebui să acopere, de asemenea, sucursale, cu accent pe sucursale mari și
mijlocii, în domenii critice cum ar fi controalele parolelor, controlul ID-urilor de utilizator,
securitatea sistemului de operare, controale anti-malware, controale maker-checker, segregarea
sarcinilor, rotația personalului, securitate, revizuire a rapoartelor de excepție/piste de audit,
politica și testarea BCP etc.
• Auditurile detaliate de control al aplicațiilor înainte de implementare și auditurile de
migrare a datelor cu privire la sistemele critice trebuie supuse unui audit extern independent.
• Băncile trebuie, de asemenea, să efectueze un audit detaliat de control al aplicațiilor post-
implementare. În plus, băncile ar trebui să includă, de asemenea, audituri de control al
aplicațiilor într-o manieră bazată pe risc, ca parte a planurilor obișnuite de audit intern/audit SI,
cu accent pe integritatea datelor (printre alți factori). Auditorii interni generali cu cunoștințele
funcționale necesare trebuie să fie implicați împreună cu auditorii IS în exercițiul pentru a oferi
expertiza în domeniu necesară.
• Auditorii IS ar trebui să revizuiască periodic rezultatele proceselor de control intern și să

analizeze datele financiare sau operaționale pentru orice impact asupra evaluării riscurilor sau a
punctajului. În consecință, diferitelor unități auditate ar trebui să li se solicite să țină auditorii la
curent cu toate schimbările majore în departamente sau funcții, cum ar fi introducerea unui nou
produs, implementarea unui nou sistem, conversiile aplicațiilor, schimbări semnificative în
organizație sau personal, noi reglementări. și cerințele legale, incidente de securitate etc.
• Auditorii IS trebuie să cunoască în mod rezonabil diferiții factori de risc de fraudă și ar
trebui să evalueze riscul de apariție a neregulilor legate de domeniul auditat. Auditorul IS ar
trebui să ia în considerare, de asemenea, evaluările vulnerabilității la fraudă efectuate de grupul
de management al riscului de fraudă, identificând în același timp factorii de risc de fraudă ca
parte a procesului de evaluare și audit al riscului IT.
• Băncile ar trebui să ia în considerare utilizarea acceleratoarelor de testare – instrumente și
tehnici care ajută la sprijinirea procedurilor pe care auditorii SI le vor efectua – pentru a crește
eficiența și eficacitatea auditului.
• Auditorii trebuie să îmbunătățească utilizarea CAAT-urilor, care pot fi utilizate eficient în
domenii precum detectarea scurgerilor de venituri, evaluarea impactului deficiențelor de
control, monitorizarea tranzacțiilor clienților conform cerințelor AML și, în general, în
domeniile în care sunt raportate un volum și o valoare mare de tranzacții. Pentru a permite
utilizarea CAAT-urilor, trebuie furnizate drepturi de acces „numai în citire” adecvate.
• Băncile pot lua în considerare, ori de câte ori este posibil, o abordare de audit continuă
pentru sistemele critice, care implică efectuarea de control și evaluări ale riscurilor pe o bază
mai frecventă prin utilizarea adecvată a tehnologiei.
• Consiliul (sau Comitetul de Audit) ar trebui să fie informat cu privire la decizia conducerii
superioare cu privire la toate observațiile și recomandările semnificative. Atunci când auditorii
SI consideră că banca a acceptat un nivel de risc rezidual care este inadecvat pentru aceasta, ar
trebui să discute problema cu funcția de audit intern și cu conducerea superioară. În cazul în
care auditorii SI nu sunt de acord cu decizia privind riscul rezidual acceptată de bancă, auditorii
SI și conducerea superioară ar trebui să raporteze problema Consiliului (sau Comitetului de
audit) pentru rezolvare.
• Serviciile furnizate de o terță parte sunt relevante pentru sfera auditului IS al unei bănci
atunci când aceste servicii și controalele din cadrul acestora fac parte din sistemele de
informații ale băncii. Acestea trebuie să fie evaluate în mod adecvat ca parte a procesului de
audit IS.
• Pentru a oferi asigurare conducerii și autorităților de reglementare, băncile sunt obligate să
efectueze o asigurare a calității, cel puțin o dată la trei ani, a auditului intern al băncilor,
inclusiv a funcției de audit IS, pentru a valida abordarea și practicile adoptate de acestea în
îndeplinirea responsabilităților lor. conform prevederilor Politicii de audit.
• Guvernul Indiei poate lua în considerare acreditarea și includerea calificărilor/certificărilor
de audit IS și a furnizorilor/firmelor de audit IS.
Despre frauda cibernetică:
• Majoritatea fraudelor cibernetice cu amănuntul și fraudelor bancare electronice ar avea o
valoare mai mică de 1 milion de lei și, prin urmare, ar putea să nu atragă atenția necesară din
partea Comitetului Special al Consiliului. Deoarece aceste fraude sunt în număr mare și au
potențialul de a atinge proporții mari, se recomandă ca Comitetul Special al Consiliului să fie
informat separat cu privire la acest lucru pentru a-i ține la cunoștință despre proporțiile fraudei
și despre măsurile luate de bancă pentru a atenua. lor. Comitetul Special ar trebui să
monitorizeze în mod specific progresul măsurilor de atenuare luate de bancă în cazul fraudelor
electronice și eficacitatea acestora în limitarea numerelor și valorilor fraudei.
• Activitățile de prevenire a fraudei, monitorizare, investigare, raportare și sensibilizare ar
trebui să fie deținute și efectuate de un grup independent de gestionare a riscului de fraudă din
bancă. Grupul ar trebui să aibă personal adecvat și condus de un funcționar superior al băncii,
nu sub rangul de Director General/DGM.
• Consiliile de examinare a fraudei ar trebui să fie înființate de grupul de management al
riscului de fraudă cu diferite grupuri de afaceri din bancă. Consiliul ar trebui să fie format din
șeful afacerii, șeful departamentului de management al riscului de fraudă, șeful operațiunilor
care sprijină acea funcție de afaceri și șeful tehnologiei informației care sprijină acea funcție de
afaceri. Consiliile ar trebui să se întrunească cel puțin în fiecare trimestru pentru a analiza
tendințele de fraudă și măsurile preventive luate care sunt specifice funcției/grupului de afaceri
respectiv.
• Băncile trebuie să urmeze diferite practici de prevenire a fraudei. Acestea includ evaluări
ale vulnerabilității fraudelor (pentru funcțiile de afaceri și, de asemenea, canalele de livrare),
revizuirea noilor produse și procese, stabilirea limitelor de pierdere prin fraudă, analiza
cauzelor principale pentru cazurile reale de fraudă de peste 10 lakhs, revizuirea cazurilor în
care există un modus operandi unic. implicat, asigurarea unor măsuri adecvate de securitate a
datelor/informațiilor, respectarea procedurilor KYC și Know your angajat/furnizor, asigurarea
unei securități fizice adecvate, partajarea celor mai bune practici de prevenire a fraudei și
crearea de conștientizare a fraudei în rândul personalului și clienților.
• Niciun produs sau proces nou nu ar trebui introdus sau modificat într-o bancă fără
aprobarea grupurilor de control, cum ar fi grupurile de management al riscului de conformitate,
audit și fraudă. Produsul sau procesul trebuie analizat pentru vulnerabilitățile de fraudă și
limitele de pierdere prin fraudă să fie impuse oriunde sunt observate vulnerabilități.
• Băncile au început să partajeze liste negative/frauduloase de conturi prin CIBIL Detect.
Băncile ar trebui să înceapă să împărtășească și detaliile angajaților care i-au înșelat, astfel
încât să nu fie angajați de alte bănci/instituții financiare.
• Capacitatea de detectare rapidă a fraudei ar permite unei bănci să reducă pierderile și ar
servi, de asemenea, ca un factor de descurajare pentru fraudatori. Diverse cerințe importante
recomandate în acest sens includ înființarea unui grup de monitorizare a tranzacțiilor în cadrul
grupului de management al riscului de fraudă, mecanisme de generare de alerte și remediere,
ID de e-mail dedicat și număr de telefon pentru raportarea fraudelor suspectate, cumpărături
misterioase și recenzii.
• Băncile ar trebui să înființeze o unitate de monitorizare a tranzacțiilor în cadrul grupului de
management al riscului de fraudă. Echipa de monitorizare a tranzacțiilor ar trebui să fie
responsabilă de monitorizarea diferitelor tipuri de tranzacții, în special de monitorizarea
zonelor potențiale de fraudă, prin intermediul cărora pot fi declanșate alarme timpurii. Această
unitate trebuie să aibă experiența de a analiza tranzacțiile pentru a detecta tendințele de fraudă.
Această unitate ar trebui să lucreze împreună cu echipa de depozitare și analiză a datelor din
cadrul băncilor pentru extragerea datelor, filtrarea și igienizarea pentru analiza tranzacțiilor
pentru a determina tendințele de fraudă. Băncile ar trebui să pună în aplicare sisteme automate
de detectare a fraudelor bazate pe algoritmi statistici avansați și tehnici de detectare a fraudelor.
• Este larg acceptat faptul că investigarea fraudelor este o funcție specializată. Astfel, grupul
de management al riscului de fraudă ar trebui să urmeze o formare continuă pentru a-și
îmbunătăți abilitățile și competențele.
• Pe lângă categoriile de fraudă care trebuie raportate conform Circularei principale RBI
privind fraudele din 2 iulie 2010, se recomandă ca acestea să includă și fraudele pe canalele
electronice și variantele de carduri de plastic utilizate de bănci și clienții acestora pentru
încheie tranzacții financiare.
• Sa observat că există o lipsă de uniformitate în ceea ce privește cantitatea de fraudă care
trebuie raportată către RBI. Unele bănci raportează pierderea netă ca valoare a fraudei (adică
suma fraudei minus recuperarea), în timp ce altele raportează suma brută. Unii nu raportează o
fraudă dacă întreaga sumă este recuperată. În cazul fraudelor cu cardul de credit, unele bănci
urmează practica de a raporta fraudele fără creditul de rambursare primit, în timp ce altele
raportează valoarea tranzacțiilor inițiale. Pentru a depăși o astfel de inconsecvență, se
recomandă o regulă uniformă de raportare a sumelor implicate în fraude.
• O mențiune specială trebuie făcută pentru fraudele comise de comercianții coluzivi care
folosesc carduri descarcate/furate la terminalele punctelor de vânzare (POS) oferite de bănci și
apoi fug cu banii înainte ca rambursarea să fie primită la tranzacție. Multe bănci nu raportează
astfel de cazuri afirmând că băncile care au emis cardurile sunt cele afectate. Cu toate acestea,
în aceste cazuri, comercianții provoacă pierderi nejustificate băncii prin sifonarea creditului
acordat. Prin urmare, astfel de cazuri ar trebui raportate ca fraude.
• S-a observat că într-un scenariu de rețea de bancomate partajată, atunci când cardul unei
bănci este folosit pentru a comite o fraudă prin ATM-ul altei bănci, există o lipsă de claritate cu
privire la cine ar trebui să raporteze o astfel de fraudă către RBI. Banca care achiziționează
tranzacția este cea care trebuie să raporteze frauda. Banca achizitoare trebuie să solicite ajutorul
băncii emitente pentru recuperarea banilor.
• Conștientizarea angajaților este crucială pentru prevenirea fraudei. Formarea privind
practicile de prevenire a fraudei ar trebui să fie oferită de grupul de gestionare a riscului de
fraudă la diferite forumuri.
• O modalitate pozitivă de a crea conștientizarea angajaților este de a recompensa angajații
care au depășit obligația și au prevenit fraudele. Detaliile despre angajații care primesc astfel de
premii pot fi publicate în buletinele informative privind fraudele.
• În cazul fraudelor online, deoarece jurisdicția nu este clară, există o ambiguitate cu privire
la locul în care ar trebui depusă plângerea poliției, iar clienții/băncile trebuie să facă transfer
între diferite unități de poliție din punctul de jurisdicție. Celulele criminalității informatice nu
sunt prezente în toate părțile țării. Problema de a avea o celulă separată care să lucreze la
fraudele bancare în fiecare departament de poliție de stat, autorizată să înregistreze plângeri de
la bănci și să facă investigații în acest sens, trebuie abordată cu departamentele de poliție
respective.
• Pentru a îmbunătăți abilitățile de investigare ale personalului din grupul de gestionare a
riscului de fraudă, băncile poate înființa un institut de formare pentru investigațiile
criminalistice financiare sub egida IBA.
• Experiența de control/prevenire a fraudelor în bănci ar trebui împărtășită între bănci în
mod regulat. Forumul permanent oferit de Asociația Băncilor Indiene (IBA) poate fi folosit
pentru a împărtăși cele mai bune practici și pentru a consolida în continuare controalele interne
în băncile respective.
• În fiecare stat, trebuie înființat un Comitet de evaluare a criminalității financiare pentru
fraude, în conformitate cu Comitetul de securitate care a fost înființat de RBI pentru a analiza
problemele de securitate din bănci cu autoritățile de aplicare a legii. Comitetul poate
supraveghea crearea de conștientizare de către bănci în rândul agențiilor de aplicare a legii cu
privire la noile tipuri de fraudă, în special fraudele bazate pe tehnologie.
• Este nevoie de aranjamente multilaterale între bănci pentru a face față fraudelor bancare
online. Lipsa unui astfel de acord între bănci poate forța un client să interacționeze cu diferite
bănci/organizații atunci când sunt implicate mai multe bănci. IBA ar putea ajuta la facilitarea
unui astfel de mecanism.
Despre planificarea continuității activității (BCP):
• Consiliul de administrație al unei bănci are responsabilitatea finală și supravegherea asupra
planificării continuității activității unei bănci și trebuie să aprobe politica de continuitate a
activității băncii. Conducerea superioară a unei bănci este responsabilă de supravegherea
procesului de planificare a continuității afacerii, care, printre altele, include determinarea
modului în care instituția va gestiona și controla riscurile identificate, prioritizarea funcțiilor
critice de afaceri, alocarea de personal cu cunoștințe și resurse financiare suficiente pentru
implementarea BCP.
• Un funcționar superior trebuie desemnat ca șef al funcției BCP.
• Deoarece banca electronică are funcții care sunt răspândite în mai mult de un departament,
este necesar ca fiecare departament să își înțeleagă rolul în plan și
sprijinul necesar pentru menținerea planului. În caz de dezastru, fiecare departament trebuie să
fie pregătit pentru procesul de recuperare care vizează protecția funcțiilor critice. În acest scop,
o înființare precum Comitetul BCP este însărcinată cu implementarea BCP într-o eventualitate
și se așteaptă ca toate departamentele să își îndeplinească rolurile respective într-o manieră
coordonată. Prin urmare, trebuie instituit un Comitet de management al crizelor/BCP format
din oficiali superiori din diferite departamente, cum ar fi HR, IT, Juridic, funcții de afaceri și
securitatea informațiilor.
• Trebuie să existe un număr adecvat de echipe pentru gestionarea diferitelor aspecte ale
BCP la nivel de birou central, precum și la nivel individual de birou zonal/ de control și la
nivel de sucursală.
• Băncile ar trebui să ia în considerare diverse metodologii și standarde BCP, cum ar fi BS
25999, ca intrări pentru cadrul lor BCP.
• Eșecul sistemelor critice sau întreruperea proceselor vitale de afaceri ar putea împiedica
recuperarea la timp a operațiunilor. Băncile trebuie să înțeleagă pe deplin vulnerabilitățile
asociate cu interrelațiile dintre diferite sisteme, departamente și procese de afaceri. Aceste
vulnerabilități ar trebui încorporate în analiza impactului asupra afacerii, care analizează
corelația dintre componentele sistemului și serviciile pe care le oferă.
• Aspectul de oameni ar trebui să fie o parte integrantă a unui BCP. De prea multe ori,
planurile sunt axate pe probleme tehnice, prin urmare se sugerează să fie încorporată o
secțiune separată referitoare la oameni, inclusiv detalii privind bunăstarea personalului,
consiliere, considerente privind relocarea etc.
• Planificarea pandemiei trebuie să fie încorporată ca parte a cadrului BCP al băncilor.
• Băncile trebuie să testeze în mod regulat BCP pentru a se asigura că sunt actualizate și
eficiente. Testarea BCP ar trebui să includă toate aspectele și elementele constitutive ale
băncii, adică oamenii, procesele și resursele (inclusiv tehnologia).
• Băncile ar trebui să-și implice auditorii interni (inclusiv auditorii SI) pentru a audita
eficacitatea BCP și testarea periodică a acestuia, ca parte a activității lor de audit intern, iar
constatările/recomandările lor în acest sens ar trebui să fie încorporate în raportul lor către
Consiliul de administrație și conducerea superioară. .
• Băncile ar trebui să ia în considerare planificarea unui exercițiu BCP împreună cu terții
critici pentru a obține un nivel rezonabil de asigurare în asigurarea continuității în ceea ce
privește procesele minime necesare preidentificate în timpul exigențelor.
• Băncile ar trebui să efectueze testul DR/BCP fără deplasarea personalului băncii la locul
DR. Acest lucru va ajuta la testarea gradului de pregătire a personalului alternativ de la locația
DR.
• Planurile de continuitate a afacerii ar trebui menținute prin revizuiri și actualizări anuale,
pentru a asigura eficacitatea lor continuă.
• Băncile ar trebui, de asemenea, să ia în considerare efectuarea unui exercițiu BCP
neplanificat, în care doar un set restrâns de oameni și un anumit personal identificat ar putea fi
conștienți de exercițiu și nu personalul de la podea/de afaceri.
• Au fost furnizate diverse cerințe detaliate referitoare la aspectele procedurale,
infrastructurale și legate de HR ale BCP, astfel încât băncile să poată îmbunătăți procesele
BCP și să genereze cele mai bune rezultate.
• Există multe aplicații și servicii în sistemul bancar care sunt extrem de critice în natură și,
prin urmare, necesită o disponibilitate ridicată și toleranță la erori pentru a fi luate în
considerare la proiectarea și implementarea soluției. Acest aspect este de luat în considerare în
special la proiectarea și implementarea soluției de data center și a soluției de rețea corporativă.
• Arhitecturile soluțiilor DC și DR nu sunt identice pentru toate aplicațiile și serviciile. În
general, se observă că aplicațiile și serviciile critice, și anume soluțiile de retail, corporative, de
finanțare comercială și de afaceri guvernamentale, precum și canalele de livrare au aceleași
configurații DR, în timp ce aplicațiile surround sau de interfață nu au suport DR. Băncile vor
trebui să efectueze revizuiri periodice cu referire la aspectul de mai sus Compilat de Srinivas Kante
Email: srinivaskante4u@gmail.com
și actualizați din când în când soluțiile DR și asigurați-vă că toate aplicațiile critice și serviciile
de asistență au replici perfecte în ceea ce privește performanța și disponibilitatea.
• Configurațiile serverelor, dispozitivelor de rețea și ale altor produse de la DC și DR trebuie
să fie identice în orice moment. Aceasta include patch-urile care sunt aplicate periodic la DC și
modificările aduse software-ului din când în când prin personalizare și parametrizare pentru a
ține cont de cerințele de reglementare, modificările sistemului etc.
• Verificările periodice pentru a asigura integritatea datelor și a tranzacțiilor dintre DC și DR
sunt obligatorii. Instrumentele automate adecvate pot fi utilizate în acest sens.
• Exercițiile DR efectuate în prezent periodic intră în categoria opririi planificate. Băncile
trebuie să dezvolte o metodologie adecvată pentru a efectua exerciții care sunt mai aproape de
un scenariu de dezastru real, astfel încât nivelul de încredere al echipei tehnice care preia acest
exercițiu să fie construit pentru a răspunde cerințelor în cazul unui dezastru real.
• Luarea în considerare a redundanței legate de telecomunicații și a canalelor alternative de
comunicare de date și voce în cazul unor exigențe ar trebui să fie încorporată ca parte a
planificării continuității afacerii.
• Urmează să se asigure că infrastructura de sprijin la DC și DR, și anume sistemele
electrice, mediul de aer condiționat și alte sisteme de sprijin nu prezintă un singur punct de
defecțiune și dispune de un sistem de management și monitorizare a clădirii pentru
monitorizarea continuă a resurselor. Monitorizarea timpului de funcționare trebuie făcută
conform cerințelor și acordurilor cu furnizorii respectivi. Aceleași cerințe trebuie să fie luate în
considerare în cazul în care configurația DC/DR se află într-o locație externalizată sau într-o
configurație comună partajată.
• Având în vedere necesitatea de a minimiza drastic pierderile de date în timpul exigențelor
și de a permite recuperarea rapidă și continuitatea operațiunilor critice de afaceri, băncile
trebuie să ia în considerare arhitectura DR aproape de site. Băncile majore cu o utilizare
semnificativă a canalului de livrare a clienților și o participare semnificativă pe piețele
financiare/sistemele de plată și decontare ar putea avea nevoie să ia în considerare un plan de
acțiune pentru crearea unei arhitecturi DR aproape de site pe termen mediu (de exemplu, trei
ani).
• Se poate înființa un forum/organizație de alarmă și criză la nivel de industrie (în care sunt
reprezentați participanții cheie pe piață și cei mai importanți furnizori de servicii de
infrastructură financiară). Șefii BCP din instituțiile participante pot alcătui nivelul de vârf al
acestei organizații de criză, nivelurile inferioare formând o rețea între cei responsabili de
domeniile de lichiditate, plăți de mare valoare, tranzacții de plată cu amănuntul și IT. Oricare
dintre instituții poate invoca organizația de alarmă activând nivelul afectat.
• Poate fi luat în considerare un site web pentru informații despre BCP la nivel de industrie,
în beneficiul industriei.
• Există programe în SUA precum Telecommunications Service Priority System (TSPS),
Government Emergency Telecommunications Service (GETS) și Wireless Priority Service
Program (WPS) pentru furnizarea de servicii prioritare de disponibilitate și recuperare a
telecomunicațiilor în timpul exigențelor pentru infrastructurile și instituțiile critice. În mod
similar, Guvernul Indiei poate declara sectorul bancar, inclusiv piețele financiare, drept
infrastructură critică și poate lua în considerare instituirea unor astfel de măsuri speciale pentru
serviciile de infrastructură prioritare pentru a permite efectuarea de servicii bancare critice și
tranzacții pe piața financiară în timpul exigențelor.
Despre educația clienților:
• Consiliul de Administrație/Conducerea Senior trebuie să se angajeze în procesul de
inițiative de educare a consumatorilor prin furnizarea de resurse adecvate, evaluarea eficienței
procesului și ajustarea și îmbunătățirea măsurilor de educare a clienților în mod continuu.
• Pentru a obține sprijinul dorit pentru program, este important să se identifice și să se
implice părțile interesate cheie în luarea deciziilor, planificare, implementare și evaluare. Un
grup de lucru sau un comitet poate fi creat pentru a stabili un obiectiv clar pentru obiectivul
final, în consultare cu părțile interesate cheie, pentru a defini în mod clar rolurile,
responsabilitățile și responsabilitățile, pentru a comunica într-o manieră deschisă, clară și în

timp util, permițând flexibilitate în abordări pentru a se potrivi nevoilor diferitelor părți
interesate. , sprijiniți formarea și dezvoltarea pentru a asigura o schimbare în comportament și
cultură, învățați din experiențele anterioare și în curs și sărbătoriți realizările.
• Băncile trebuie să urmeze un proces sistematic pentru a dezvolta un program de
conștientizare prin etapele de planificare și proiectare, execuție și management și evaluare și
corectare a cursului.
• Deoarece programele de conștientizare ar trebui să fie personalizate pentru publicul
specific, este important să identificăm și să segmentăm utilizatorii țintă pentru programe - cum
ar fi clienții băncilor, angajații, personalul de aplicare a legii, profesioniștii în riscul de fraudă,
partenerii media etc.
• Crearea consensului între factorii de decizie și părțile interesate pentru sprijin financiar și
administrativ este un pas important în program. În acest sens, trebuie identificate atât costurile
fixe, cât și cele variabile.
• Deoarece grupurile țintă obțin informații dintr-o varietate de surse, mai mult de un canal
de comunicare ar putea fi folosit pentru a le implica cu succes.
• Ar trebui format un grup de cercetare pentru a actualiza continuu echipa de comunicații cu
cele mai recente tendințe și modus operandi în evoluție. Echipa va menține un depozit de
materiale, cum ar fi studii de caz, e-mailuri eșantioane, mostre de documente frauduloase,
practici internaționale/dezvoltări etc.
• Evaluarea efectelor diferitelor campanii pentru grupuri țintă specifice poate fi măsurată
prin cercetări calitative (de exemplu focus grupuri, interviuri) și/sau cantitative (de exemplu
chestionare, sondaje omnibus). Evaluarea în funcție de metrici, obiective de performanță etc. ar
trebui, de asemenea, efectuată pentru a verifica eficacitatea campaniei și pentru a stabili lecțiile
învățate pentru a îmbunătăți inițiativele viitoare.
• La nivel de industrie, fiecare bancă ar trebui să aibă o politică documentată, mecanisme de
formare și unități de cercetare. Materialul poate fi adunat din aceste unități pentru a fi utilizat
pe o platformă mai mare în vederea unui obiectiv comun.
Pe probleme juridice:
• Comitetul de management al riscurilor de la nivel de consiliu trebuie să pună în aplicare
procese pentru a se asigura că riscurile juridice care decurg din legile cibernetice sunt
identificate și abordate în mod adecvat. De asemenea, trebuie să se asigure că funcțiile în cauză
sunt dotate cu personal adecvat și că personalul care le gestionează este instruit pentru a
îndeplini funcția în mod eficient. Grupul de risc operațional trebuie să încorporeze riscurile
legale ca parte a cadrului de risc operațional și să ia măsuri pentru atenuarea riscurilor evaluate.
Funcția juridică din cadrul băncii trebuie să consilieze grupurile de afaceri cu privire la
problemele juridice care decurg din utilizarea tehnologiei informației.
• Ar trebui să existe un sistem robust în bănci pentru a urmări tranzacțiile de natura la care
se face referire în orientările statutare privind CSB (cum ar fi PMLA și PMLR) și pentru a le
raporta în termenul stabilit. Pe lângă riscul de penalizare, acesta implică un risc reputațional
pentru astfel de entități.
• În conformitate cu Legea NI, un cec în formă electronică a fost definit ca „o imagine în
oglindă” a unui cec pe hârtie. Expresia „imagine în oglindă” nu pare a fi adecvată. Expresia
„imagine în oglindă a” poate fi înlocuită cu expresia „grafică electronică care arată” sau orice
altă expresie care surprinde intenția în mod adecvat.
• Definiția unui cec în formă electronică are în vedere o semnătură digitală cu sau fără
semnătură biometrică și un sistem cripto asimetric. Deoarece definiția a fost inserată în anul
2002, este de înțeles că a captat doar semnătura digitală și sistemul cripto asimetric tratate în
conformitate cu secțiunea 3 din Legea IT, 2000. Deoarece Legea IT, 2000 a fost modificată în
anul 2008 pentru a prevedea și semnătura electronică, poate fi necesară o modificare adecvată
în acest sens în Legea NI, astfel încât semnătura electronică să poată fi utilizată și pe cecurile
în formă electronică.
• Există incertitudine în ceea ce privește semnificația unei expresii cruciale, cum ar fi
„intermediar”, conform Legii IT din 2000 și astfel cum a fost modificată prin Legea de
modificare a IT, 2008. Ca atare, este necesar ca o modificare legislativă să fie clarificată în
ceea ce privește sensul expresiei „intermediar” în ceea ce privește băncile și instituțiile
financiare.
• O interpretare combinată a Secțiunii 2(p) și a sub-secțiunilor (1) și (2) din Secțiunea 3 din
Legea IT arată clar că, în conformitate cu Legea, o înregistrare electronică poate fi autentificată
prin aplicarea unei „semnături digitale” și dacă o parte dorește să autentifice înregistrarea
electronică prin aplicarea unei semnături digitale, metoda sau procedura electronică de aplicare
a semnăturii digitale va fi un sistem cripto asimetric și o funcție hash. În timp ce autentificarea
unei înregistrări electronice prin aplicarea unei semnături digitale este opțională, procedura de
aplicare a semnăturii digitale, și anume utilizarea unui sistem cripto asimetric și a funcției hash,
este obligatorie.
• Întrebarea care se pune în considerare este dacă o parte poate fi legată de tranzacțiile
efectuate prin mijloace electronice (fie prin ATM-uri, internet sau altfel), deși înregistrările
electronice în cauză nu sunt autentificate prin utilizarea semnăturilor digitale/electronice.
Citind secțiunea 65B (1) din Legea indiană privind probele, este clar că înregistrările
electronice pot fi dovedite în instanță, chiar dacă nu sunt autentificate prin utilizarea
semnăturilor digitale sau electronice, dacă sunt îndeplinite condițiile menționate în acestea.
Dificultatea de a dovedi diferitele condiții stabilite în sub-secțiunile (2) și (3) din secțiunea 65B
din Indian Evidence Act este ameliorată într-o mare măsură de subsecțiunea (4) din aceasta, în
temeiul căreia certificatul unei persoane care ocupă o poziție oficială responsabilă în legătură
cu funcționarea dispozitivului relevant sau gestionarea activităților relevante (oricare este
cazul) trebuie să constituie o dovadă a oricărei aspecte menționate în certificat.
• Guvernul ar trebui să specifice un număr suficient de agenții în conformitate cu secțiunea
79A din Legea indiană privind probele pentru a ajuta instanțele să ajungă la o decizie cu privire
la valoarea probatorie a înregistrărilor electronice, indiferent dacă este aplicată o semnătură
digitală sau electronică.
• Tranzacțiile financiare, cum ar fi operațiunile de conturi bancare și operațiunile cu cardul
de credit, sunt efectuate de bănci într-un mod semnificativ, folosind carduri, numere de pin și
parole etc. Băncile folosesc multe caracteristici de securitate pentru a preveni fraudele pe cât
posibil. „Metoda de autentificare cu doi factori” propusă (metoda 2F) este, de asemenea, un
pas în aceeași direcție. Poate să nu fie ideal să impuneți o anumită tehnologie (semnături
digitale cu sistem cripto asimetric și funcție hash) pentru autentificarea tuturor tranzacțiilor
electronice de către bănci.
• Ca măsură pe termen scurt, se recomandă ca Reguli să fie elaborate de Guvernul Central în
conformitate cu Secțiunea 5 din Legea IT, în sensul că, în ceea ce privește internetul sau e
tranzacțiile bancare, metoda 2F sau orice altă tehnică de autentificare furnizată de bănci și
utilizată de clienți vor fi valabile și obligatorii în ceea ce privește astfel de tranzacții, chiar dacă
nu este aplicată o „semnătură digitală” sau „semnătură electronică”.
• Licența ISP limitează nivelul de criptare pentru indivizi, grupuri sau organizații la o
lungime a cheii de numai 40 de biți în algoritmi de cheie simetrică sau echivalente. RBI a
stipulat criptarea SSL/128 de biți ca nivel minim de securitate. SEBI a stipulat criptarea pe
64/128 de biți pentru tranzacțiile și serviciile bazate pe Internet. Regulile privind Tehnologia
Informației (Autoritățile de Certificare), 2000 impun ca „tehnici de criptare dovedite la nivel
internațional” să fie utilizate pentru stocarea parolelor. Un comitet de criptare constituit de
guvernul central în temeiul secțiunii 84A din Legea IT din 2000 este în proces de formulare a
regulilor cu privire la criptare. Este posibil ca băncile să permită o putere de criptare mai mare.
• Secțiunea 43A din Legea IT tratează aspectul compensației pentru neprotecția datelor.
Guvernul central nu a prescris termenul „date cu caracter personal sensibile” și nici nu a
prescris o „practică de securitate standard și rezonabilă”. Până la efectuarea acestor prescripții,
datele sunt asigurate de securitate și protecție numai așa cum poate fi specificat într-un acord
între părți sau așa cum poate fi specificat în orice lege.
• Legea IT din 2000, astfel cum a fost modificată, expune băncile atât răspunderii civile, cât
și penale. Răspunderea civilă ar putea consta în expunerea la plata daunelor sub formă de
despăgubiri de până la ` 5 milioane în conformitate cu Legea Tehnologia Informației
modificată în fața ofițerului de adjudecare și peste ` 5 milioane într-o instanță de jurisdicție
competentă. Conducerea de vârf a băncilor ar putea suferi, de asemenea, expunerea la
răspunderea penală, având în vedere prevederile capitolului XI al Legii privind tehnologia
informației modificată, iar expunerea la răspunderea penală ar putea consta în închisoare pe un
termen care s-ar extinde de la trei ani până la închisoare pe viață, precum și un amenda. Mai
mult, diferite infracțiuni legate de computer sunt enumerate în diferite prevederi ale Legii.
• În ultimul timp, au existat multe cazuri de „phishing” în industria bancară, reprezentând o
amenințare majoră pentru clienții care folosesc facilitățile de internet banking. Deși se poate
spune că secțiunea 66D din Legea IT modificată acoperă, în linii mari, infracțiunea de
phishing, tentativa de a comite actul de phishing nu este pedepsită. Se sugerează că este
necesar să se prevadă în mod specific o pedeapsă și pentru tentativa de phishing, pentru a
descuraja persoanele să o încerce.
• Problema dacă secțiunea 43A, citită cu secțiunea 72 și 72A din Legea IT, 2000, abordează
problema protecției datelor în mod adecvat sau dacă acestea trebuie completate cu dispoziții pe
termen lung (care pot ajuta la facilitarea protecției și păstrării datelor eficace și eficiente ), ar
depinde de prescripțiile Guvernului Central. În acest raport au fost oferite diverse sugestii în
acest sens.
• Este necesar să se echilibreze interesele clienților și cele ale băncilor și să se ofere
protecție băncilor împotriva oricăror acte frauduloase sau neglijente ale clientului. Nu este
oportun să lăsați o problemă atât de importantă să fie tratată în documentație. În acest sens,
trebuie adoptate prevederi legale corespunzătoare.
• Deși nu există o legislație specifică în India care să se ocupe doar de „transferul electronic
de fonduri” și care să fie bazată pe protecția consumatorilor, anumite preocupări au fost tratate
și în Legea privind sistemele de plată și decontare, reguli, regulamente, instrucțiuni etc. emise
în temeiul acesteia. precum prevederile de drept general. Cu toate acestea, poate fi oportun să
existe unele prevederi similare cu cele din Legea EFT care exonerează banca de răspundere în
cazul fraudei din partea clientului sau a unei defecțiuni tehnice etc. (de exemplu, prevederi
care se referă la „fondul electronic neautorizat”. transferuri” și răspunderea consumatorului
pentru transferuri neautorizate).
Legea privind tehnologia informației (modificare), 2008

Principalul act indian care abordează provocările juridice în special în ceea ce privește
internetul este Legea privind tehnologia informației (modificare) din 2008 sau, pe scurt, Legea
IT. Subliniem secțiunile care au cea mai mare relevanță pentru internet și democrație. Aceasta
include secțiuni referitoare la ridicările guvernamentale, monitorizarea și interceptarea
comunicării și răspunderea intermediarului.
Secțiunea 69A și regulile de blocare: Permiterea guvernului să blocheze conținutul în

anumite circumstanțe
Secțiunea 69A din Legea IT (modificarea) din 2008, permite guvernului central să blocheze
conținutul în cazul în care consideră că acest conținut amenință securitatea statului;
suveranitatea, integritatea sau apărarea Indiei; relații de prietenie cu statele străine; ordine
publică; sau pentru a preveni incitarea la comiterea unei infracțiuni identificabile referitoare la
oricare dintre cele de mai sus. Un set de proceduri și garanții la care guvernul trebuie să adere
atunci când face acest lucru au fost stabilite în ceea ce au devenit cunoscute sub numele de
Reguli de blocare.
• Secțiunea 79 și regulile IT: Privatizarea cenzurii în India

Secțiunea 79 din Legea privind tehnologia informației (modificare) din 2008 reglementează
răspunderea unei game largi de intermediari din India. Secțiunea a ajuns în lumina
reflectoarelor în principal din cauza infamelor Reguli de ghidare intermediare, sau Reguli IT,
care au fost făcute în baza acesteia. Regulile IT constituie o mișcare importantă și
îngrijorătoare către privatizarea cenzurii în India.
• Secțiunile 67 și 67A: Fără nuditate, vă rog

Cantitățile mari de material „obscen” care circulă pe internet au atras mult timp comentarii în
India. Nu este surprinzător, așadar, la fel cum obscenitatea este interzisă offline în țară, deci
este și online. Cele mai importante instrumente pentru a o reduce sunt secțiunile 67 și 67A din
Legea IT, care interzic materialele obscene și, respectiv, sexual explicite.
• Secțiunea 66A: Nu trimiteți mesaje jignitoare

Secțiunea 66A din Legea privind tehnologia informației (modificare) din 2008 interzice
trimiterea de mesaje jignitoare printr-un dispozitiv de comunicare (adică printr-un mediu
online). Tipurile de informații pe care le acoperă sunt mesaje jignitoare cu un caracter
amenințător sau un mesaj despre care expeditorul știe că este fals, dar care este trimis cu
scopul de a „provoca supărare, inconvenient, pericol, obstrucție, insultă, vătămare, intimidare
criminală, dușmănie, ura sau rea voință. Dacă sunteți rezervat în temeiul Secțiunii 66A, puteți
risca până la 3 ani de închisoare împreună cu o amendă.
• Libertate de exprimare
A echilibra libertatea de exprimare cu alte drepturi ale omului este, uneori, o sarcină dificilă și
delicată. De la discursul instigator la ură la răspunderea intermediară, dezvăluim și aruncăm
mai multă lumină asupra diferitelor provocări care fac această sarcină deosebit de complicată,
propunând căi de urmat care pot consolida și promova și mai mult dreptul la libertatea de
exprimare, în India și nu numai.
• Securitate cibernetică, supraveghere și drepturile omului

Odată cu apariția noii tehnologii, au apărut noi amenințări de securitate pentru oameni,
companii și state. Adesea, răspunsurile la astfel de amenințări, inclusiv exercitarea de către
statele a puterii lor fără precedent de a-și supraveghea populațiile, au fost criticate pentru
impactul lor negativ asupra drepturilor omului. Securitatea și drepturile omului nu mai pot fi
reconciliate în era internetului?
Legea privind tehnologia informației (modificare) din 2008, un act de modificare a Legii IT
din 2000, a primit acordul președintelui la 5 februarie 2009. Mai mulți experți în domeniul
juridic și în securitate sunt în proces de analiză a conținutului și a posibilelor efecte ale
modificărilor. Obiectivul acestei note este de a încerca să studieze posibilele implicații și
impacturi asupra companiilor indiene. Această notă nu intenționează să fie o analiză
cuprinzătoare a modificărilor, ci doar anumite puncte cheie care ar putea avea un impact
asupra companiilor indiene
Protejarea datelor
Legea IT din 2000 nu avea nicio referire specifică la protecția datelor, dulapul fiind o
prevedere pentru a trata vandalismul datelor ca o infracțiune. Guvernul a introdus un proiect de
lege separat numit „Legea din 2006 privind protecția datelor cu caracter personal”, care este în
curs în Parlament și este probabil să cadă. ITA 2008 a introdus două secțiuni care abordează
aspectele privind protecția datelor într-o anumită măsură, ceea ce dă naștere la anumite
considerații cheie pentru sector.
Secțiunile luate în considerare sunt:
Secțiunea 43A: Despăgubiri pentru neprotecția datelor
Secțiunea 72A: Pedeapsa pentru dezvăluirea de informații cu încălcarea contractului legal
Secțiunea 43A prevede
În cazul în care o persoană juridică, care deține, manipulează sau manipulează date sau
informații personale sensibile dintr-o resursă informatică pe care o deține, o controlează sau o
operează, este neglijentă în implementarea și menținerea practicilor și procedurilor rezonabile
de securitate și, prin urmare, cauzează pierderi sau câștiguri necorespunzătoare oricărei
persoane , această persoană juridică va fi obligată să plătească despăgubiri, cu titlu de
despăgubire, persoanei astfel afectate.
Cu titlu de explicație: „Corporație înseamnă companii indiene”
„Practicile rezonabile de securitate înseamnă un contract reciproc între client și furnizorul de
servicii SAU conform legii specificate. În absența ambelor, atunci așa cum a specificat
Guvernul Central
Prin urmare, ar fi important ca companiile indiene să analizeze în mod serios SLA-urile și
acordurile care au fost semnate cu clienții pentru a înțelege implicațiile privind protecția
datelor. Același lucru este valabil și pentru înțelegerea legilor aplicabile.
O modificare majoră este că această clauză nu menționează limita de compensare de Rs. 1
Crore care a fost acolo ca parte a secțiunii 43 din ITA 2000. Aceasta înseamnă că nu există o
limită superioară pentru daune care pot fi solicitate. Aceasta este, în esență, „răspundere
nelimitată” pentru companiile indiene, care ar putea provoca implicații grave de afaceri.
Secțiunea 72A:
Conform acestei secțiuni, dezvăluirea fără consimțământ expune o persoană, inclusiv un
„intermediar”, la trei ani de închisoare cu amendă de până la Rs. Cinci lacs sau ambele.
Această secțiune folosește termenul „informații personale” și nu „informații personale
sensibile” ca în secțiunea 43A. Prin urmare, s-ar putea aplica oricărei informații obținute
pentru a furniza servicii. Prin urmare, în anumite privințe, lărgește definiția informațiilor.
2. Conservarea informațiilor
În cadrul amendamentelor există mai multe referiri la „furnizori de servicii” sau
„intermediari”, care într-o anumită formă s-ar aplica tuturor companiilor indiene.
de exemplu, Secțiunea 67C: Păstrarea și păstrarea informațiilor de către intermediari.
Intermediarul va păstra și reține informațiile care pot fi specificate pe durata și în modul și
formatul pe care guvernul central le poate prescrie”. Orice intermediar care încalcă în mod
intenționat sau cu bună știință prevederile se pedepsește cu închisoare pe o perioadă de până la
3 ani și se pedepsește și cu amendă.
Notificările la timp pentru conservare etc. nu sunt încă lansate. Cu toate acestea, deoarece
aceasta este o infracțiune „cognoscibilă”, orice inspector de poliție poate începe investigații
împotriva CEO-ului unei companii.
În afară de cele două aspecte discutate în această notă, există și alte domenii care ar putea fi, de
asemenea, considerații pentru Ex
Sec. 69: Puterea de a emite instrucțiuni pentru interceptarea sau monitorizarea sau decriptarea
oricărei informații prin orice resursă computerizată.
Sec. 69B: Puterea de a autoriza monitorizarea și colectarea de date sau informații de trafic prin
orice resursă de computer pentru Cyber Security.etc.
În rezumat, managementul riscului IT și răspunsul trebuie să fie analizate de către toate
companiile din diverse motive, inclusiv asigurarea clienților, conformitatea, reglementările
clienților, protecția activelor informaționale etc. Amendamentele ITA 2008 ne oferă câțiva
factori suplimentari pentru considerente care ar putea avea un impact semnificativ asupra
afacerii. Reglementările și legile privind tehnologia informației ar deveni mai stricte și mai
definite; prin urmare, este imperativ ca organizațiile să fie conștiente și pregătite.
Prezentare generală a operațiunilor IT
Introducere:
Pentru băncile în care sistemele de tehnologie a informației (IT) sunt utilizate pentru
gestionarea informațiilor, operațiunile IT ar trebui să sprijine procesarea și stocarea
informațiilor, astfel încât informațiile necesare să fie disponibile în timp util, fiabil, sigur și
rezistent.
Operațiunile IT reprezintă un set de capabilități organizaționale specializate care oferă valoare

clienților (interni sau externi) sub formă de servicii IT. Capabilitățile iau forma unor funcții și
procese pentru gestionarea serviciilor pe parcursul ciclului de viață al tehnologiei. Operațiunile
IT ar trebui să asigure eficacitatea și eficiența în furnizarea și sprijinirea acestor servicii pentru
a asigura valoare pentru clienți.
Domeniu de aplicare:
Funcțiile acoperite ca parte a operațiunilor IT sunt :
Managementul serviciilor IT
Managementul Infrastructurii
Managementul ciclului de viață al aplicației
Cadrul de risc pentru operațiunile IT
Consiliul, conducerea superioară:
Roluri si responsabilitati :
Consiliul de Administrație al Băncii are responsabilitatea finală pentru supravegherea

funcționării eficiente a funcțiilor operaționale IT. Managementul superior ar trebui să asigure
implementarea unui mediu sigur de operare IT. Politicile și procedurile definite ca parte a
operațiunilor IT ar trebui să sprijine scopurile și obiectivele băncii, precum și cerințele
statutare.
Zonele funcționale, în cadrul previzualizării acestor roluri, sunt :
Operațiuni IT de bază
Operațiuni IT specifice liniei de afaceri
Orice operațiuni IT legate de afiliați
Operațiunile partenerilor de afaceri (inclusiv cele ale furnizorilor de asistență IT, dacă
există)
Consiliul sau conducerea superioară ar trebui să ia în considerare riscul asociat cu operațiunile

IT existente și planificate și toleranța la risc și apoi să stabilească și să monitorizeze politicile
de management al riscului.
Structura organizationala :
Operațiunile IT includ servicii de afaceri care sunt disponibile clienților interni sau externi care
utilizează IT ca componentă de livrare a serviciilor, cum ar fi serviciile bancare mobile sau
prin internet. Operațiunile IT includ componente care sunt utilizate pentru a sprijini
operațiunile IT: aplicație de birou de service, instrumente de gestionare a biletelor și
evenimentelor etc. Băncile pot lua în considerare includerea mediului de testare și asigurare a
calității (pe lângă mediul de producție) în domeniul operațiunilor IT.
Biroul de service : Biroul de service este punctul principal de contact (Punctul unic de
contact sau SPOC) pentru clienții interni și externi. Pe lângă gestionarea incidentelor
și probleme, oferă, de asemenea, interfață cu alte procese de operare IT, cum ar fi

cererea de modificare (RFC), îndeplinirea cererilor, managementul configurației,
managementul nivelului de servicii și managementul disponibilității etc. Poate avea
următoarele funcții:
Interacțiunea cu clienții (e-mail, voce sau chat): legătura de primă linie cu clienții
Înregistrarea și urmărirea incidentelor și problemelor sau solicitărilor de modificare
Menținerea clienților informați cu privire la starea și progresul cererii
Efectuarea unei evaluări inițiale a cererilor, încercarea de a le rezolva prin managementul cunoștințelor
sau escaladarea, pe baza nivelurilor de servicii convenite
Proceduri de monitorizare și escaladare în raport cu SLA-ul corespunzător
Gestionarea ciclului de viață al cererii, inclusiv închiderea și verificarea
Coordonarea grupurilor de asistență din a doua linie și terțe părți
Furnizarea de informații de management pentru îmbunătățirea serviciilor
Identificarea problemelor
Inchidere incidente si confirmare cu clientul
Contribuie la identificarea problemelor
Efectuarea de sondaje de satisfacție a utilizatorilor
O structură pentru Service Desk care permite utilizarea optimă a resurselor ar include :
Birou de service local
Birou central de servicii
Birou virtual de servicii
Urmăriți Soarele, adică în fusuri orare, astfel încât biroul de service să fie disponibil pentru asistență și
înregistrarea incidentelor non-stop
Grupuri specializate de birouri de service
Managementul operațiunilor IT
Managementul operațiunilor IT este o funcție care este responsabilă în primul rând de gestionarea și
întreținerea de zi cu zi a infrastructurii IT a unei organizații, asigurând livrarea serviciilor la nivelul
convenit, așa cum este definit de Acordul privind nivelul de servicii (SLA).
Managementul operațiunilor IT poate avea următoarele funcții:

Control operațional: Supraveghează execuția și monitorizarea activităților și evenimentelor

operaționale din infrastructura IT care se află în previzualizarea operațiunilor IT. Activitățile de
control operațional sunt în mod normal efectuate de Centrul de operațiuni de rețea (NOC) sau de
Podul de operațiuni. Pe lângă execuția și monitorizarea sarcinilor de rutină, controlul operațiunii
implică și următoarele activități:
Managementul consolei
Programarea locurilor de muncă
Backup și restaurare
Managementul imprimării și al ieșirii
Activități generale de întreținere
Facility Management: se referă la gestionarea mediului IT fizic al centrului de date, sălilor de

calculatoare și site-urilor de recuperare
Structura de management al operațiunilor: Din toate motivele practice, echipele de gestionare a aplicațiilor și
de gestionare a infrastructurii ar trebui să facă parte din operațiunile IT. Astfel, aceste funcții gestionează și
execută activități operaționale, în timp ce altele le deleg pentru a dedica funcția operațiunilor IT.
Managementul aplicațiilor:
Aceasta implică manipularea și gestionarea aplicației pe măsură ce parcurge întregul ciclu de viață. Ciclul de
viață cuprinde atât dezvoltarea de aplicații, cât și activitățile de gestionare a aplicațiilor. Subactivitățile care pot fi
definite pentru funcțiile de gestionare a aplicațiilor sunt:
Dezvoltarea aplicației: se referă la activitățile necesare pentru a planifica, proiecta și construi o aplicație
care în cele din urmă este utilizată de o parte a organizației pentru a răspunde unei cerințe de afaceri.
Aceasta include, de asemenea, achiziția, achiziția, găzduirea și furnizarea de aplicații
Întreținerea/Managementul aplicației: se concentrează pe activitățile care sunt implicate cu

implementarea, operarea, suportul și optimizarea aplicației
Funcțiile legate de gestionarea aplicațiilor pot include următoarele:
Gestionarea aplicațiilor operaționale, fie că sunt dezvoltate de furnizor, fie sunt disponibile la raft sau
intern
Acesta acționează ca un custode al cunoștințelor tehnice și al expertizei legate de gestionarea și

susținerea aplicațiilor. Acesta asigură că cunoştinţele tehnice şi expertiza necesare pentru proiectarea,
dezvoltarea, testarea, gestionarea şi îmbunătăţirea serviciilor IT sunt identificate, dezvoltate şi
perfecţionate. Prin urmare, participă la managementul operațiunilor IT
Se asigură că resursele adecvate sunt instruite și desfășurate în mod eficient pentru a furniza, construi,
tranzita, opera și îmbunătăți tehnologia necesară pentru gestionarea și sprijinirea serviciilor IT.
Acesta definește și execută programe de formare
Documentează seturile de abilități disponibile în cadrul unei organizații și abilitățile care trebuie
dezvoltate pentru a gestiona gestionarea aplicațiilor ca funcție
Acesta definește standarde care trebuie adaptate la definirea unei noi arhitecturi de aplicații și
implicarea în proiectarea și construirea de noi servicii

Evaluează riscul implicat într-o arhitectură de aplicație
Înregistrează feedback-uri privind disponibilitatea și activitățile de gestionare a capacității
Proiectează și efectuează teste pentru funcționalitatea, performanța și gestionabilitatea serviciilor IT
Acesta definește și gestionează instrumentele de gestionare a evenimentelor
Acesta participă la gestionarea incidentelor, problemelor, performanței, schimbărilor și edițiilor și la

îndeplinirea resurselor
Acesta oferă informații despre sistemul de management al configurației
Structura de gestionare a aplicațiilor: deși activitățile de gestionare a aplicațiilor sunt generice și consecvente
între aplicații; funcția de gestionare a aplicațiilor, din toate motivele practice, nu este îndeplinită de un singur
departament sau grup. Este alcătuit din domenii tehnice conform setului de abilități tehnice și expertiză.
Unele dintre acestea pot fi:
Aplicație financiară
Aplicații de infrastructură
Aplicații de mesagerie și colaborare
Portal web sau aplicații web
Aplicații Contact Center
Aplicații specifice funcției
Managementul Infrastructurii
Este funcția principală responsabilă pentru furnizarea de expertiză tehnică și managementul general al
infrastructurii IT. Obiectivul său principal este de a ajuta la planificarea, implementarea și întreținerea unei
infrastructuri tehnice stabile pentru a sprijini procesele de afaceri ale unei organizații.
Managementul infrastructurii poate avea următoarele funcții:
Gestionați componentele infrastructurii IT pentru un mediu, care se încadrează în previzualizarea

operațiunilor IT
Acesta acționează ca un custode al cunoștințelor tehnice și al expertizei, legate de managementul

infrastructurii IT. Se asigură că cunoștințele tehnice și expertiza necesare pentru proiectarea, dezvoltarea,
testarea, gestionarea și îmbunătățirea serviciilor IT sunt identificate, dezvoltate și perfecționate.
Se asigură că resursele adecvate sunt instruite și desfășurate în mod eficient pentru a livra, construi, tranzita,
opera și îmbunătăți tehnologia necesară pentru furnizarea și sprijinirea infrastructurii IT.
Ajută la definirea și executarea programelor de instruire
Ajută să documenteze seturile de abilități disponibile în cadrul unei organizații și abilitățile necesare pentru a
fi dezvoltate pentru a gestiona gestionarea infrastructurii ca funcție
Definirea standardelor care trebuie adaptate la definirea noii arhitecturi IT și implicarea în proiectarea și
construirea de noi servicii
Evaluarea riscurilor pentru arhitectura infrastructurii IT
Feedback-uri privind disponibilitatea și activitățile de gestionare a capacității
Proiectarea și efectuarea de teste pentru funcționalitatea, performanța și gestionabilitatea serviciilor IT
Definirea si managementul instrumentelor de management de evenimente
Participarea la managementul incidentelor, problemelor, performanței, schimbărilor și eliberărilor și

îndeplinirea resurselor
Funcția de management al infrastructurii ar trebui să ofere informații sau să gestioneze configurația

Sistemului de management
Structura de gestionare a infrastructurii : Din toate motivele practice, funcția de gestionare a infrastructurii nu este
îndeplinită de un singur departament sau grup, ea constă din domenii tehnice conform setului de abilități tehnice și
expertiză, unele dintre acestea sunt:
Echipa de management mainframe
Echipa de management al serverului
Echipa de gestionare a stocării
Echipa de suport al rețelei
Echipa de suport desktop
Echipa de gestionare a bazei de date
Echipa de management middleware
Echipa de servicii de director
Echipa de internet
Echipa de mesagerie
Echipa de telefonie bazată pe IP
Componentele cadrului operațional IT: a) Risc

management
Băncile ar trebui să își analizeze mediul de operare IT, inclusiv tehnologia, resursele umane și procesele
implementate, pentru a identifica amenințările și vulnerabilitățile. Aceștia ar trebui să efectueze o evaluare
periodică a riscurilor care ar trebui să identifice:
Riscuri interne și externe

Riscurile asociate cu platformele, sistemele sau procesele individuale, precum și cu unitățile de

procesare automată
În timpul identificării riscurilor, un proces de evaluare a riscurilor ar trebui să cuantifice probabilitatea unei
amenințări și vulnerabilități, precum și consecințele financiare ale unui astfel de eveniment. Băncile ar trebui să ia
în considerare, de asemenea, interdependențele dintre elementele de risc, deoarece amenințările și vulnerabilitățile
au potențialul de a compromite rapid sistemele și procesele interconectate și interdependente.
Băncile ar trebui să implementeze un mediu rentabil și axat pe risc. Mediul de control al riscurilor ar trebui să
ofere îndrumări, responsabilitate și aplicabilitate, atenuând în același timp riscurile.
Categorizarea riscurilor : Ca parte a identificării și evaluării riscurilor, băncile ar trebui să identifice

evenimente sau activități care ar putea perturba operațiunile sau ar putea afecta negativ reputația sau
câștigurile și să evalueze conformitatea cu cerințele de reglementare. Riscurile identificate pot fi clasificate în
linii mari în următoarele categorii:
Eșecuri strategice: acestea ar putea include implementarea necorespunzătoare, eșecul furnizorului,

definirea necorespunzătoare a cerințelor, incompatibilitatea cu infrastructura aplicației existente etc.
Acesta va include, de asemenea, conformitatea cu reglementările
Eșecuri de proiectare: ar putea include management inadecvat de proiect, depășiri de costuri și timp,
erori de programare și eșecuri de migrare a datelor, printre altele
Eșecuri de tranziție: ar putea include planificarea inadecvată a capacității, cerințe de disponibilitate

definite necorespunzător, SLA / OLA / contracte de bază nedefinite în mod corespunzător și
încălcări ale securității informațiilor, printre altele
Atenuarea riscurilor : Odată ce organizația a identificat, analizat și clasificat riscurile, organizația ar trebui să
definească următoarele atribute pentru fiecare componentă a riscului:
Probabilitatea de a avea loc;
Impact financiar;
Impactul reputațional;
Impactul conformității cu reglementările;
Impact juridic.
Pe lângă atributele specificate mai sus, o organizație ar trebui să ia în considerare și acestea:
Venituri pierdute
Pierderea cotei de piata
Nerespectarea cerințelor de reglementare
Probabilitate de litigiu
Cheltuieli de recuperare a datelor

Cheltuieli de reconstrucție
Acestea, împreună cu procesul de afaceri implicat, ar trebui să fie utilizate pentru a prioritiza acțiunile de atenuare
a riscurilor și cadrul de control.
Procese operaționale IT
Strategia IT
Procesele din cadrul Strategiei IT oferă îndrumări pentru a identifica, selecta și prioritiza serviciile care sunt
aliniate la cerințele de afaceri. Strategia IT, ca cadru, oferă feedback operațiunilor IT cu privire la serviciile care
urmează să fie susținute și procesele lor de afaceri subiacente și prioritizarea acestor servicii etc.
Un cadru de strategie IT bine definit va sprijini operațiunile IT în sprijinirea serviciilor IT așa cum este cerut de
afacere și definite în OLA / SLA.
Procesele de strategie IT oferă linii directoare care pot fi utilizate de bănci pentru a proiecta, dezvolta și
implementa operațiunile IT nu doar ca o capacitate organizațională, ci și ca un activ strategic.
Management financiar : oferă mecanisme și tehnici operațiunilor IT pentru a cuantifica în termeni financiari,
valoarea serviciilor IT pe care le suportă, valoarea activelor care stau la baza furnizării acestor servicii și
calificarea previziunii operaționale.
Avantajele implementării procesului de management financiar sunt:
Ajută la luarea deciziilor
Viteza schimbărilor
Managementul portofoliului de servicii
Conformitate financiară și control
Control operational
Captarea și crearea de valoare
Evaluarea serviciului
Este mecanismul care poate fi luat în considerare de bănci pentru cuantificarea serviciilor, care sunt disponibile
clienților (interni sau externi) și susținute de operațiunile IT din punct de vedere financiar. Acesta ajută funcțiile
de operare IT pentru a prezenta implicarea funcției în sprijinirea activității de bază a băncii.
Managementul financiar utilizează Evaluarea serviciilor pentru a cuantifica termenii financiari, valoarea
serviciilor IT susținute de operațiunile IT. Oferă un plan din care companiile pot înțelege ceea ce le este livrat de
fapt din IT. Combinată cu managementul nivelului de servicii, evaluarea serviciilor este mijlocul pentru un acord
reciproc cu companiile, cu privire la ce este un serviciu, care sunt componentele sale și costul și valoarea acestuia.
Service Evaluation cuantifică, în termeni financiari, finanțarea căutată de o afacere și IT pentru serviciile
furnizate, pe baza valorii convenite a acelor servicii. Activitatea presupune identificarea costurilor de bază pentru
servicii și apoi cuantificarea valorii percepute, adăugate de activele de servicii ale furnizorului pentru a încheia o
valoare finală a serviciului.
Evaluarea serviciului va avea două componente, acestea fiind:
Valoarea de furnizare: costul real de bază al IT, legat de furnizarea unui serviciu, inclusiv toate elementele de
îndeplinire – tangibile și intangibile. Intrările provin din sistemele financiare și constă în plata resurselor
efective consumate de IT în furnizarea serviciilor. Acest element de cost include articole precum:
Costul licenței hardware și software
Taxe anuale de întreținere pentru hardware și software
Resursele de personal utilizate în susținerea sau întreținerea serviciilor
Utilitățile, centrul de date sau alte facilități taxează
Impozite, capital sau dobânzi
Costuri de conformitate
Valoarea potențialului serviciului: este componenta cu valoare adăugată bazată pe percepția clientului asupra
valorii serviciului sau a utilității marginale așteptate și a garanției din utilizarea serviciilor în
comparație cu ceea ce este posibil folosind propriile active ale clientului.
Managementul portofoliului
Acesta oferă linii directoare care pot fi luate în considerare de bănci pentru a guverna investițiile în managementul
serviciilor în cadrul unei întreprinderi și pentru a le gestiona pentru valoare. Managementul portofoliului conține
informații pentru toate serviciile existente, precum și pentru fiecare serviciu propus – cele care sunt în faza
conceptuală.
Fiecare serviciu, care face parte din portofoliul de servicii, ar trebui să includă un caz de afaceri, care este un
model a ceea ce se așteaptă să realizeze un serviciu. Este justificarea urmăririi unui curs de acțiune pentru a
îndeplini obiectivele organizaționale declarate. Cazul de afaceri se leagă de strategia de servicii și finanțare. Este
evaluarea managementului unui serviciu în ceea ce privește beneficiile potențiale și resursele și capacitățile
necesare pentru furnizarea și menținerea serviciului. Cadrul de management al portofoliului definit de bănci ar
trebui să evidențieze controalele, care sunt definite pentru a dezvolta un serviciu IT de la faza conceptuală la faza
de lansare și apoi la tranziția la mediul de producție. În timpul dezvoltării serviciilor IT, impactul financiar al
noului serviciu asupra operațiunii IT ar trebui, de asemenea, verificat, care va ajuta operațiunile IT în validarea
serviciului.
Managementul cererii
Procesul de management al cererii oferă linii directoare care pot fi folosite de bănci pentru a înțelege procesele de
afaceri pe care operațiunile IT le suportă pentru a identifica, analiza și codifica modelele de activități de afaceri
(PBA) pentru a oferi suficient de bază pentru cerințele de capacitate. Analiza și urmărirea tiparelor de activitate
ale procesului de afaceri face posibilă estimarea cererii de servicii. De asemenea, este posibil să se prevadă
cererea de active de servicii subiacente care sprijină aceste servicii.
Ghidurile de management al cererii ar trebui să ia în considerare, de asemenea, implicarea operațiunilor IT în

dezvoltarea serviciului de la faza conceptuală până la faza live, astfel încât să existe o transparență a cererii de
servicii noi în operațiunile IT.
II) Proiecta
Faza de proiectare a operațiunilor IT oferă liniile directoare și procesele, care pot fi utilizate de bănci pentru a
gestiona schimbarea peisajului de afaceri. Componentele care ar trebui luate în considerare la proiectarea unui nou
serviciu IT sau la efectuarea unei modificări la serviciul IT existent sunt:
Procese de afaceri
Servicii IT
Acorduri privind nivelul serviciilor

Infrastructură IT
Mediul IT
Date de informare
Aplicații
Servicii suport
Echipe de suport
Furnizori
Proiectarea serviciului: Acesta nu ar trebui să ia în considerare componentele în mod izolat, ci trebuie să ia în

considerare și relația dintre fiecare dintre componente și dependențele lor de orice altă componentă
sau serviciu.
Faza de proiectare: Oferă un set de procese și linii directoare care pot fi utilizate de bănci pentru a proiecta
servicii IT, susținute de operațiuni IT, care să satisfacă obiectivele de afaceri, cerințele de
conformitate și cerințele de risc și securitate. Procesele oferă, de asemenea, linii directoare pentru a
identifica și gestiona riscurile și pentru a proiecta servicii IT sigure și rezistente.
Gestionarea catalogului de servicii
De-a lungul anilor, infrastructura IT a băncilor a crescut și s-a dezvoltat. Pentru a stabili un peisaj IT precis, se
recomandă definirea, producerea și întreținerea unui Catalog de servicii IT . Poate fi considerat ca un depozit care
oferă informații despre toate serviciile IT susținute de cadrul IT Operations.
Procesul de management al catalogului de servicii oferă linii directoare, utilizate de bănci pentru a defini și
gestiona catalogul de servicii, care oferă o informație consecventă și exactă cu privire la toate serviciile IT
disponibile clienților (interni sau externi). De asemenea, se asigură că catalogul de servicii este disponibil pentru
utilizatori, care sunt autorizați să-l acceseze. Ar trebui să conțină detalii despre toate serviciile care sunt în
producție, precum și serviciile care sunt pregătite pentru tranziție. Băncile pot lua în considerare următoarele
atribute care urmează să fie incluse în catalogul de servicii:
Definiţia Service
Categorizarea serviciilor (aplicații de afaceri și suport IT)
Criticitatea serviciului
Clasa de recuperare în caz de dezastru
Parametrii acordului la nivel de serviciu

Mediul de servicii (producție, testare, asigurare a calității, punere în scenă etc.)
Starea suportului IT (operațional și tranzacțional etc.)
Grupul de management al configurației
Grupul de management al incidentelor
Grupul de management al problemelor
Grupul de management al schimbărilor și lansărilor
Proprietar de servicii
Manager la nivel de serviciu
Detalii principalele activități de afaceri
Interdependența de elementele de configurare
Interdependența față de portofoliul de servicii
Catalogul de servicii oferă detalii despre serviciile disponibile clienților, cum ar fi utilizarea prevăzută, procesele
de afaceri pe care le permit și nivelul și calitatea serviciului pe care clientul se poate aștepta de la fiecare serviciu.
Băncile pot lua în considerare, de asemenea, încorporarea „mecanismului de rambursare”, așa cum este definit în
managementul financiar, în catalogul de servicii.
Un catalog de servicii are două aspecte :
Catalog de servicii de afaceri: conține detalii despre toate serviciile IT furnizate unui client, împreună cu
relațiile cu unitățile de afaceri și procesele de afaceri care se bazează pe serviciile IT. Aceasta este
vizualizarea clientului a catalogului. Business Service Catalog facilitează dezvoltarea unui proces robust de
management al nivelului de servicii.
Catalog de servicii tehnice: conține detalii despre toate serviciile IT livrate unui client, împreună cu relația
acestuia cu serviciile de asistență și partajate, relația cu elementele de configurare (CI). CI pot fi un activ sau
o componentă de serviciu sau orice alt element care se află sub controlul managementului configurației. În
funcție de configurația stabilită a strategiei, un articol poate varia foarte mult în complexitate, dimensiune și
tip. Poate varia de la servicii sau sisteme întregi la un singur modul software sau o componentă software
minoră. (Elementele de configurare sunt explicate în detaliu în secțiunea „Active ale serviciilor și
managementul configurației” din ghid.) Facilitează dezvoltarea relației dintre servicii, CI, SLA și OLA
subiacente și grupurile de asistență, care sprijină serviciile pe tot parcursul vieții. ciclu.
Managementul nivelului de servicii
Acest proces definește cadrul care poate fi utilizat de bănci pentru a planifica, coordona și elabora, conveni,
monitoriza și raporta atributele serviciilor utilizate pentru măsurarea calității serviciilor. Cadrul său include, de
asemenea, linii directoare pentru revizuirea continuă a realizărilor serviciilor pentru a se asigura că este menținută
și îmbunătățită calitatea serviciului necesară și justificabilă din punct de vedere al costurilor. Pe lângă serviciile și
SLA-urile actuale, acest management oferă linii directoare pentru a se asigura că noile cerințe sunt capturate.
Aceste servicii și SLA noi sau modificate sunt dezvoltate pentru a se potrivi nevoilor și așteptărilor afacerii.
Procesul de management al nivelului de servicii ar trebui să poată îndeplini următoarele obiective :
Definiți, documentați, conveniți, monitorizați, măsurați, raportați și revizuiți nivelul serviciilor IT

Asigurați-vă că sunt definite ținte specifice și cuantificabile pentru serviciile IT
Asigurați-vă că operațiunile IT și consumatorii au așteptări clare, fără ambiguitate, cu privire la nivelul

serviciilor de furnizat
Asigurați-vă că măsurile proactive, pentru îmbunătățirea nivelului de servicii furnizate, sunt

implementate dacă costurile sunt justificate
La definirea cadrului SLM pentru bănci, ar trebui luate în considerare și următoarele aspecte
Acord la nivel operațional pentru a se asigura că sunt definite și dezvoltate acorduri la nivel operațional
(OLA) cu alte grupuri de sprijin; aceste OLA ar trebui să fie în conformitate cu SLA-urile pe care le
acceptă
Contractul de bază cu furnizorul pentru a se asigura că toate contractele de bază cu furnizorii cu

furnizorii sau furnizorii sunt definite și dezvoltate: aceste contracte ar trebui să fie în conformitate cu
SLA, pe care le sprijină
În timp ce definiți Acordul privind nivelul de servicii ca parte a cadrului de management al nivelului de
servicii, pot fi luate în considerare următoarele opțiuni:
SLA bazat pe servicii: structura sa acoperă atribute pentru un singur serviciu în cadrul unei organizații.
De exemplu, SLA pentru serviciul de internet banking
SLA bazat pe client: structura acoperă atributele pentru toate serviciile pentru un set definit de clienți.
De exemplu, SLA pentru clienții IMM-urilor
SLA cu mai multe niveluri: Structură SLA pe mai multe niveluri
poate fi definit conform ierarhiei organizaționale. De exemplu, SLA pentru birouri corporative, sucursale și sedii
centrale
Atributele care sunt incluse în SLA ar trebui să fie cele care pot fi monitorizate și măsurate în mod eficient.
Atributele care sunt incluse în SLA pot fi clasificate în atribute operaționale, de răspuns, de disponibilitate și de
securitate. Cadrul de management al nivelului de servicii ar trebui, de asemenea, să definească linii directoare
pentru revizuirea acordurilor de nivel de serviciu, acordurilor de nivel operațional și a contractelor care stau la
baza, pentru a se asigura că acestea sunt aliniate la nevoile și strategia de afaceri. Acestea ar trebui să se asigure că
serviciile acoperite și obiectivele pentru fiecare sunt relevante. Și că nu se schimbă nimic semnificativ care să
anuleze în vreun fel acordul. Cadrul de management al nivelului de servicii definit ar trebui să aibă, de asemenea,
linii directoare definite pentru înregistrare și gestionare, inclusiv escaladarea reclamațiilor și complimentelor.
Managementul Capacității
Procesul oferă cadrul și liniile directoare care pot fi adaptate de bănci pentru a se asigura că există o capacitate IT
justificabilă din punct de vedere al costurilor și se potrivește cu cerințele de afaceri actuale și viitoare, identificate
în Acordul privind nivelul de servicii.
Procesul de management al capacității oferă linii directoare pentru :
Produceți și mențineți un plan de capacitate care reflectă cerințele actuale și viitoare ale afacerii
Gestionați performanța serviciului astfel încât să atingă sau să depășească obiectivele de performanță
convenite
Diagnosticarea și rezolvarea incidentelor și problemelor legate de performanță și capacitate

Evaluați impactul tuturor modificărilor asupra planului de capacitate și a performanței serviciilor IT susținute
de operațiunile IT
Asigurați-vă că sunt luate măsuri proactive pentru a îmbunătăți performanța serviciilor, ori de câte ori acest
lucru este justificabil din punct de vedere al costurilor.
Una dintre activitățile cheie definite ca parte a procesului de management al capacității este producerea și
menținerea, în mod continuu, a planului de capacitate, care descrie nivelul actual de utilizare a resurselor și
performanța serviciilor. Planurile de capacitate pot include, de asemenea, prognozarea cerințelor viitoare pentru a
sprijini activitățile de afaceri. Procesul poate fi împărțit în trei:
Managementul capacității de afaceri: definește liniile directoare pentru transpunerea planurilor de nevoi de
afaceri în cerințe pentru serviciile IT și infrastructura de sprijin, asigurând că cerințele viitoare de afaceri
pentru serviciile IT sunt cuantificate, proiectate, planificate și implementate. Intrările pentru viitoarele
cerințe IT provin din portofoliul de servicii și managementul cererii.
Managementul capacității de servicii: Acesta definește liniile directoare pentru managementul, controlul și
predicția performanței de la capăt la capăt și a capacității de utilizare a serviciilor IT și a sarcinilor de
lucru live și operaționale. Acesta oferă linii directoare pentru a se asigura că performanța serviciilor IT
este monitorizată și măsurată.
Managementul capacității componentelor: definește linii directoare pentru a identifica și înțelege

performanța, capacitatea și utilizarea fiecărei componente individuale într-o tehnologie utilizată pentru a
susține serviciile IT, inclusiv infrastructura, mediul, datele și aplicațiile.
O diferență majoră între sub-procese constă în datele care sunt monitorizate și colectate. De exemplu, nivelul de
utilizare a componentelor individuale din infrastructură: procesoare, discuri și legături de rețea va fi sub
Component Capacity Management. În timp ce ratele de transfer ale tranzacțiilor și timpii de răspuns vor fi în
Managementul capacității de servicii. Business Capacity Management se va ocupa de date, specifice
volumele de afaceri. Băncile care adaptează procesul de management al capacității ar trebui să se asigure că cadrul
său cuprinde toate domeniile tehnologiei (hardware, software, resurse umane, facilități etc.)
Managementul Disponibilității
Disponibilitatea și fiabilitatea serviciilor IT pot influența direct satisfacția clienților și reputația băncilor. Prin
urmare, managementul disponibilității este esențial pentru a se asigura că IT-ul oferă „nivelul potrivit” de servicii
cerut de companie pentru a-și îndeplini obiectivele. Procesul oferă cadrul și liniile directoare care pot fi adaptate
de bănci pentru a se asigura că nivelul de disponibilitate a serviciilor (pentru toate serviciile) este egal sau
depășește cerințele actuale și viitoare, așa cum sunt definite în Acordul privind nivelul de servicii.
Procesul de management al disponibilității oferă linii directoare, astfel încât băncile să poată :
Produceți și mențineți un plan de disponibilitate actualizat adecvat, care reflectă nevoile actuale și viitoare ale
afacerii
Asigurați-vă că realizările privind disponibilitatea serviciilor ating sau depășesc obiectivele convenite, prin
gestionarea serviciilor și a obiectivelor de disponibilitate legate de resurse
Asistență la diagnosticarea și rezolvarea incidentelor și problemelor legate de disponibilitate
Asigurați-vă că măsurile proactive de îmbunătățire a disponibilității serviciilor sunt implementate oriunde

este justificat de cost să faceți acest lucru
Atunci când implementează procesele de management al disponibilității, băncile ar trebui să ia în considerare

următoarele:
Toate serviciile și tehnologia operaționale, susținute de operațiuni IT și pentru care există un SLA formal
Servicii noi în care au fost stabilite cerințele și acordul privind nivelul de servicii
Aspecte ale serviciilor și componentelor IT care pot afecta disponibilitatea, care pot include formarea,
abilitățile, eficacitatea procesului, procedurile și instrumentele
Procesul de management al disponibilității are două elemente cheie :
Activități reactive: Aspectul reactiv al managementului disponibilității implică monitorizarea, măsurarea,

analiza și gestionarea evenimentelor, incidentelor, problemelor și modificărilor, implicând
indisponibilitatea
Activități proactive: Acest aspect implică planificarea, proiectarea și îmbunătățirea disponibilității
Atributele care pot fi utilizate de către bănci pentru raportarea disponibilității serviciilor IT pot fi :
Disponibilitate: Capacitatea unui serviciu, componentă sau CI de a îndeplini funcția convenită atunci când
este necesar.
Timp de service convenit - Timp de nefuncționare
Disponibilitate (%) = ------------------------------------- x100 De acord

Timp de service
Timpul de nefuncționare ar trebui inclus în calculul de mai sus numai atunci când are loc în „Timpul de
service convenit”.
Timpul mediu între incidente de serviciu (MTBSI): MTBSI se referă la durata unui serviciu; componenta sau
CI își poate îndeplini funcția convenită fără întrerupere.
Timp disponibil în ore

MTBSI =------------------------------------
Numărul de pauze
Timpul mediu între defecțiuni (MTBF): MTBF se referă la durata unui serviciu; componenta sau CI își poate
îndeplini funcția convenită fără a raporta o defecțiune.
Timp disponibil în ore – Timp total de nefuncționare în ore
MTBF =
Numărul de pauze
Timpul mediu dintre eșecuri (MTBF): este timpul mediu dintre recuperarea de la un incident și apariția
următorului incident, este cunoscut și sub denumirea de timp de funcționare. Această măsurătoare se referă la
fiabilitatea serviciului IT susținut de operațiunile IT.
Timpul mediu de reparare (MTTR): MTTR se referă la cât de rapid și eficient un serviciu, componentă sau CI
poate fi restabilit la funcționarea normală după defecțiune.
Timp total de nefuncționare în ore
MTTR = -------------------------------------
Numărul de pauze
Timpul mediu de reparare (MTTR): Acesta este timpul mediu dintre apariția unei defecțiuni și recuperarea
serviciului. Este cunoscut și sub denumirea de timp de nefuncționare. Această măsurătoare se referă la
recuperabilitatea și funcționalitatea serviciilor IT susținute de operațiunile IT.
Funcții vitale de afaceri
Când definesc obiectivele de disponibilitate pentru un serviciu de afaceri, băncile ar trebui să ia în considerare
identificarea Funcției Vitale de Afacere (VBF). VBF reprezintă elemente critice de afaceri ale unui proces susținut
de servicii IT. De exemplu, un bancomat va avea următoarele funcții de afaceri:
Distribuirea numerarului
Reconciliere cu contul relevant
Imprimarea declarațiilor.
Dintre acestea trei, distribuirea numerarului și reconcilierea ar trebui considerate funcții vitale de afaceri,
influențând proiectarea disponibilității și costurile asociate.
Gestionarea furnizorilor
Cerințele complexe ale afacerii necesită abilități și capacități extinse din partea IT pentru a susține procesele de
afaceri, prin urmare colaborarea cu furnizorii de servicii și rețelele de valoare sunt o parte integrantă a soluției de
afaceri end-to-end. Procesul de management al furnizorilor oferă cadrul și liniile directoare care pot fi utilizate de
bănci pentru a gestiona relațiile cu furnizorii, furnizorii și contractanții. Acest cadru asigură că furnizorii și
serviciile pe care le furnizează sunt gestionate pentru a sprijini țintele de servicii IT și așteptările de afaceri. Scopul
acestui proces de management este acela de a obține un raport calitate/preț de la furnizori și de a se asigura că
furnizorii respectă obiectivele cuprinse în contracte și acorduri, respectând toți termenii și condițiile.
Procesul de management al furnizorilor oferă linii directoare care pot fi folosite de bănci pentru:
Implementarea și aplicarea politicilor furnizorilor
Mentinerea bazei de date furnizor si contacte
Clasificarea suplimentelor și a persoanelor de contact și evaluarea riscurilor
Evaluarea și selecția furnizorilor și a contractelor
Elaborarea, negocierea si acordarea contractelor
Revizuirea, reînnoirea și rezilierea contractului
Managementul furnizorilor și performanța furnizorilor
Acordul și implementarea planurilor de îmbunătățire a serviciilor și furnizorilor
Mentinerea contractelor standard, termenilor si conditiilor
Managementul soluționării litigiilor contractuale
Managementul furnizorilor subcontractati
III) Tranziție
Faza de tranziție oferă cadre și procese care pot fi utilizate de bănci pentru:
Evaluați capacitățile serviciului și profilul de risc al serviciului nou sau al modificărilor înainte ca acesta să fie
lansat în mediul de producție
Evaluați și mențineți integritatea tuturor activelor de serviciu identificate și a elementelor de configurare

necesare pentru a susține serviciul
Gestionarea activelor și configurației serviciului
Procesul de management al activelor și configurației de servicii oferă cadrul și liniile directoare care pot fi utilizate
de bănci pentru a gestiona activele de servicii și elementele de configurare care sprijină serviciile de afaceri.
Cadrul oferă linii directoare pentru:
Identificați, controlați, înregistrați, auditați și verificați activele serviciului și elementele de configurare,

inclusiv versiunea de referință a serviciului controlează atributele și relațiile acestora.
Gestionați și protejați integritatea activelor de serviciu și a elementelor de configurare pe parcursul ciclului de

viață a serviciului, asigurându-vă că sunt utilizate numai activele autorizate și că se fac numai modificările
autorizate.
Asigurați integritatea elementelor de configurare necesare pentru a sprijini serviciile de afaceri și

infrastructura IT prin stabilirea și menținerea unui Sistem de management al configurației precis și complet.
Furnizați informații precise despre elementele de configurare pentru a ajuta la procesul de gestionare a
modificărilor și edițiilor.
Managementul activelor de servicii gestionează activele de-a lungul ciclului său de viață, de la achiziție până la
eliminare. Implementarea cadrului de management al activelor și configurației de servicii are implicații legate de
costuri și resurse și, prin urmare, trebuie purtate discuții strategice cu privire la prioritățile care trebuie abordate.
De exemplu, băncile pot decide să se concentreze inițial pe activele IT de bază (hardware și software) și pe
serviciile și activele care sunt esențiale pentru afaceri sau acoperite de conformitatea cu reglementările legale.
Componentele care pot fi considerate ca parte a gestionării activelor și configurației serviciului sunt:
Elemente de configurare: acestea pot fi un activ sau o componentă de serviciu sau orice element care se află
sub controlul managementului configurației. În funcție de configurația stabilită a strategiei, elementul
poate varia foarte mult în complexitate, dimensiune și tip. Poate varia de la un întreg serviciu sau sistem
la un singur modul software sau o componentă software minoră.
Dacă se dorește, băncile pot defini o structură ierarhică pentru elementele de configurare. De exemplu,
băncile pot defini Core Banking ca un element de configurare care poate avea aplicații diferite ca subset de
Element de configurare al elementului de configurare Core Banking. Fiecare element de configurare poate
avea module ca subset care pot avea două elemente de configurare, acestea fiind găzduire și suport pentru
aplicații. Gazduirea poate fi apoi subdivizata in elemente de configurare care pot fi servere, sisteme de
operare, baze de date, componente de retea.
Sistem de management al configurației: Pentru a gestiona mediul IT mare și complex, băncile pot lua în
considerare implementarea unui sistem de suport cunoscut sub numele de Sistem de management al
configurației. Pe lângă deținerea de informații despre elementele de configurare, componentele acestora
și relația dintre elementele de configurare, Sistemul de management al configurației poate fi folosit și
pentru a corela serviciile și elementele de configurare; acest tip de instantaneu va ajuta la identificarea
proactivă a incidentelor, evenimentelor etc.
Biblioteci securizate: Biblioteca securizată este o colecție de CI software, electronice sau documente. Accesul
la articolele dintr-o bibliotecă securizată este restricționat. Biblioteca securizată este utilizată pentru
controlul și eliberarea componentelor pe parcursul ciclului de viață al serviciului.
Biblioteca media definitivă: Biblioteca media definitivă (DML) este o bibliotecă securizată care poate fi
utilizată pentru a stoca versiuni definitive autorizate ale tuturor CI-urilor media. Stochează copiile master
ale versiunilor care au trecut verificările de asigurare a calității.
Linia de referință de configurare: Această linie de bază este configurația unui serviciu, produs sau
infrastructură care a fost revizuită și convenită în mod oficial, care ulterior servește drept bază pentru
activități ulterioare și care poate fi schimbată numai printr-o procedură formală de modificare. Linia de
bază a configurației captează și reprezintă un set de elemente de configurare care sunt legate între ele.
Instantaneu: definește starea curentă a elementelor de configurare sau a unui mediu.
Managementul schimbărilor: Acest proces oferă linii directoare care pot fi utilizate de bănci pentru
gestionarea modificărilor pentru a se asigura că modificările sunt înregistrate, evaluate, autorizate,
prioritizate, planificate, testate, implementate, documentate și revizuite într-o manieră și mediu controlat.
Obiectivul principal al procedurilor de management al schimbării este de a asigura evaluarea:
Riscuri
Modificați autorizația
Continuitatea afacerii
Schimbarea impactului
iv) Operațiuni
Această fază, ca parte a ciclului de viață de management al serviciilor, este responsabilă pentru executarea și
realizarea proceselor care optimizează costul calității serviciilor. Ca parte a organizației, este responsabilă pentru a
permite întreprinderilor să îndeplinească obiectivele. Ca parte a tehnologiei, este responsabil pentru funcționarea
eficientă a componentelor care sprijină serviciile de afaceri.
Management de evenimente
Procesul de management al evenimentelor oferă liniile directoare care pot fi folosite de bănci pentru a defini
cadrul de monitorizare a tuturor evenimentelor relevante care au loc prin infrastructura IT. Acesta oferă punctul de
intrare pentru execuția multor procese și activități ale operațiunilor de servicii.
Evenimentul poate fi definit ca orice eveniment detectabil sau perceptibil care are semnificație pentru gestionarea
infrastructurii IT sau furnizarea de servicii IT. Cadrul de management al evenimentelor, atunci când este definit, va
avea două mecanisme de monitorizare, acestea sunt:
Monitorizare activă: Monitorizarea activă este legată de sondarea elementelor de configurare semnificative
pentru afaceri pentru a determina starea și disponibilitatea acestora. Orice deviere de la starea normală trebuie
raportată echipei corespunzătoare pentru a lua măsuri.
Monitorizare pasivă: Monitorizarea pasivă detectează și corelează alertele operaționale sau comunicațiile
generate de Elementele de configurare.
Gestionarea evenimentelor poate fi aplicată oricărui aspect al gestionării serviciilor care trebuie controlat. Aceste
componente pot fi:
Elemente de configurare
Condiții de mediu
Monitorizarea licenței software
Breșe de securitate
Portofoliul de management al evenimentelor poate avea diferite tipuri de evenimente, unele dintre acestea sunt:
Informațional: evenimente care semnifică operațiuni obișnuite, de exemplu, notificarea că o lucrare

programată a fost finalizată
Avertisment: evenimente care semnifică devierea de la cursul normal de acțiune, de exemplu un utilizator
care încearcă să se autentifice cu o parolă incorectă. Evenimentele excepționale vor necesita investigații
suplimentare pentru a determina un mediu care ar fi putut duce la o excepție
Excepții: evenimente, care sunt neobișnuite. Evenimentele pot necesita o monitorizare mai atentă. În unele
cazuri, starea se va rezolva de la sine. De exemplu, combinații neobișnuite de sarcini de lucru pe măsură ce
sunt finalizate, operațiunile normale se vor restabili. În alte cazuri, intervenția operațională va fi necesară dacă
situația se repetă
Un incident este o întrerupere neplanificată a unui serviciu IT sau reducerea calității unui serviciu IT. Eșecul unui
element de configurare care nu a afectat încă serviciul va fi, de asemenea, un incident.
Procesul de management al incidentelor oferă linii directoare care pot fi implementate de către bănci pentru
gestionarea incidentelor, astfel încât restabilirea operațiunilor de serviciu cât mai rapid posibil și pentru a minimiza
impactul negativ asupra operațiunilor de afaceri. Obiectivul principal al procedurilor de management al
incidentelor este de a asigura cel mai bun nivel posibil de calitate și disponibilitate a serviciilor.
Managementul problemelor
Procesul de management al problemelor oferă un cadru, care poate fi implementat de bănci pentru a minimiza
impactul negativ al incidentelor asupra infrastructurii IT și a afacerii prin identificarea cauzei principale,
înregistrarea erorilor cunoscute, furnizarea și comunicarea soluțiilor, găsirea de soluții permanente și prevenirea
reapariției incidentelor. legate de aceste erori. Managementul problemelor crește stabilitatea și integritatea
infrastructurii.
Procesul de management al problemelor include activități necesare pentru a desfășura cauzele principale ale
incidentelor și pentru a determina rezolvarea acestor probleme de bază. Procedurile de gestionare a problemelor
includ, de asemenea, implementarea rezoluției prin Schimbare
Proceduri de management și proceduri de management al lansărilor. Aceasta include, de asemenea, redresarea

adecvată și soluționarea incidentelor care nu pot fi rezolvate din cauza cazurilor de afaceri sau a lipsurilor tehnice.
Tendință periodică
poate fi efectuată o analiză a problemelor în ceea ce privește sistemele sau canalele cu care se confruntă clienții și
se pot lua măsuri adecvate.
Managementul accesului
Procesul de management al accesului oferă liniile directoare, care pot fi implementate de bănci pentru a limita
accesul la serviciile IT numai la acele persoane și aplicații care sunt autorizate în mod corespunzător pe baza
politicilor și standardelor organizaționale. Managementul accesului permite organizației să gestioneze
confidențialitatea, integritatea datelor organizației, infrastructura IT și aplicațiile.
PLANIFICAREA CONTINUITĂȚII AFACERILOR
Introducere
Rolul esențial pe care îl joacă sectorul bancar în creșterea și stabilitatea economică, atât la nivel național, cât și la
nivel individual, necesită servicii continue și de încredere. Contribuția sporită a canalelor bancare electronice 24x7
a crescut cererea de a formula linii directoare consolidate de planificare a continuității afacerii (BCP) care să
acopere aspectele critice ale oamenilor, proceselor și tehnologiei.
BCP face parte din planul general de management al continuității afacerii (BCM) al unei organizații, care este
„pregătirea unei organizații”, care include politici, standarde și proceduri pentru a asigura continuitatea, reluarea și
recuperarea proceselor de afaceri critice, la un nivel convenit și limitarea impactului dezastrului asupra oamenilor,
proceselor și infrastructurii (inclusiv IT); sau pentru a minimiza consecințele operaționale, financiare, juridice,
reputaționale și alte consecințe materiale care decurg dintr-un astfel de dezastru.
Managementul eficient al continuității afacerii încorporează de obicei analize de impact asupra afacerii, strategii
de redresare și planuri de continuitate a afacerii, precum și un program de guvernanță care acoperă un program de
testare, un program de instruire și conștientizare, un program de comunicare și de gestionare a crizelor.
Roluri, responsabilități și structură organizatorică Consiliul de administrație al
Directori și conducerea superioară
Consiliul de administrație al unei bănci are responsabilitatea finală și supravegherea activității BCP a unei bănci.
Consiliul aprobă Politica de Continuitate a Afacerii a unei bănci. Managementul superior este responsabil pentru
supravegherea procesului BCP care include :
Determinarea modului în care instituția va gestiona și controla riscurile identificate
Alocarea de personal cu cunoștințe și resurse financiare suficiente pentru implementarea

BCP
Prioritizarea funcțiilor critice de afaceri
Desemnarea unui comitet BCP care va fi responsabil pentru managementul continuității afacerii
Conducerea de vârf ar trebui să revizuiască anual caracterul adecvat al redresării afacerii instituției, planurile
de urgență și rezultatele testelor și să le prezinte Consiliului.
Conducerea de top ar trebui să ia în considerare evaluarea gradului de adecvare a planificării de urgență și
testarea periodică a acestora de către furnizorii de servicii ori de câte ori operațiunile critice sunt externalizate.
Asigurarea faptului că BCP este revizuit și aprobat în mod independent cel puțin o dată pe an;
Asigurarea că angajații sunt instruiți și conștienți de rolurile lor în implementarea programului

BCP
Asigurarea că BCP este testat în mod regulat la nivelul întregii întreprinderi
Revizuirea programului de testare BCP și a rezultatelor testelor în mod regulat și
Asigurarea că BCP este actualizat continuu pentru a reflecta mediul de operare actual
.1 Șeful BCP sau coordonatorul continuității activității
Un funcționar superior trebuie desemnat ca șef al activității sau funcției BCP.
Responsabilitățile sale includ:
Dezvoltarea unui BCP la nivel de întreprindere și prioritizarea obiectivelor de afaceri și a operațiunilor critice
care sunt esențiale pentru recuperare
Planificarea continuității afacerii să includă recuperarea, reluarea și întreținerea tuturor aspectelor 23business,
nu doar recuperarea componentelor tehnologice; Având în vedere integrarea rolului instituției pe piețele
financiare;
Actualizarea regulată a planurilor de continuitate a afacerii pe baza modificărilor proceselor de afaceri,

recomandărilor de audit și lecțiile învățate din testare
Urmând o abordare ciclică, orientată pe proces, care include o analiză a impactului asupra afacerii (BIA), o
evaluare a riscurilor, management și monitorizare și testare
Luând în considerare toți factorii și decideți să declarați o „criză”
1.2 Comitetul BCP sau Echipa de management al crizelor
Deoarece banca electronică are funcții răspândite în mai mult de un departament, este necesar ca fiecare
departament să își înțeleagă rolul în plan. De asemenea, este important ca fiecare să-și dea sprijinul pentru a-l
menține. În cazul unui dezastru, fiecare trebuie să fie pregătit pentru un proces de recuperare, care vizează
protecția funcțiilor critice. În acest scop, ar fi util ca într-o eventualitate un înființat precum Comitetul BCP,
însărcinat cu implementarea BCP, și ca toate departamentele să își îndeplinească rolurile respective într-o manieră
coordonată.
Prin urmare, un comitet format din înalți oficiali din departamente precum HR, IT, Juridic, Business și Securitatea
Informației trebuie să fie instituit cu următorul mandat larg:
Să exercite, să mențină și să invoce planul de continuitate a afacerii, după cum este necesar
Comunică, antrenează și promovează conștientizarea
Asigurați-vă că Planul de Continuitate a Afacerii (BCP) se potrivește cu alte planuri și cerințe ale autorităților
în cauză
Probleme bugetare
Asigurați instruire și conștientizare cu privire la BCP pentru echipele și angajații implicați
Coordonarea activităților altor echipe de recuperare, continuitate, răspuns și gestionarea deciziilor cheie.
Acestea determină activarea BCP
Alte funcții presupun gestionarea chestiunilor legale care evoluează în urma dezastrului și gestionarea
relațiilor publice și a anchetelor media
1.3 Echipele BCP
Trebuie să existe echipe adecvate pentru diferite aspecte ale BCP la biroul central, precum și birouri individuale de
control sau la nivel de sucursală, după caz. Printre echipele care pot fi considerate în funcție de nevoi se numără
echipa de răspuns la incident, echipa de acțiuni și operațiuni în situații de urgență, echipa din anumite funcții de
business, echipa de evaluare a daunelor, echipele IT pentru hardware, software, suport de rețea, echipa de
aprovizionare, echipa de organizare logistică. , echipa de relocare, echipa de suport administrativ, echipa de
coordonare. Orientări ilustrative pentru comitete sau echipe pentru BCP sunt furnizate în Anexa C.
2. Componentele critice ale cadrului de management al continuității afacerii
Trebuie luate în considerare cerințele BCP enunțate în acest document. Sarcina revine Consiliului și conducerii
superioare pentru a genera componente detaliate ale BCP în lumina activităților, sistemelor și proceselor unei
bănci individuale.
2.1 Metodologia BCP
Băncile ar trebui să ia în considerare metodologiile și standardele BCP – BS 25999 de la BSI – care urmează
„Principiul Plan-Do-Check-Act”.
Metodologia BCP ar trebui să includă:
Faza 1: Analiza impactului asupra afacerii
Identificarea afacerilor critice, a resurselor deținute și partajate cu funcții de sprijin pentru a elabora analiza
impactului asupra afacerii (BIA)
Formularea obiectivelor de timp de recuperare (RTO), pe baza BIA. De asemenea, poate fi ajustat periodic
prin compararea cu cele mai bune practici din industrie
Ipoteze critice și dure în ceea ce privește dezastrul, astfel încât cadrul să fie suficient de exhaustiv pentru a
aborda cele mai stresante situații

Identificarea obiectivului punctului de recuperare (RPO), pentru pierderea de date pentru fiecare dintre
sistemele critice și strategia de a face față unei astfel de pierderi de date
Proceduri alternative în timpul sistemelor de timp nu sunt disponibile și estimând cerințele de resurse
Faza 2: Evaluarea riscurilor
Evaluare structurată a riscurilor bazată pe o analiză cuprinzătoare a impactului asupra afacerii. Această
evaluare ia în considerare toate procesele de afaceri și nu se limitează la facilitățile de procesare a
informațiilor.
Managementul riscului prin implementarea strategiei/arhitecturii adecvate pentru a atinge RTO-urile și RPO-
urile agreate ale băncii.
Impact asupra restabilirii funcțiilor critice de afaceri, inclusiv sistemele orientate către clienți și sistemele de
plată și decontare, cum ar fi plăți de numerar, bancomate, servicii bancare prin internet sau centre de apeluri
Dependența și riscul implicat în utilizarea resurselor externe și a sprijinului
Faza 3: Determinarea alegerilor și a strategiei de continuitate a afacerii
BCP ar trebui să evolueze dincolo de domeniul tehnologiei informației și trebuie să acopere, de asemenea,
oamenii, procesele și infrastructura
Metodologia ar trebui să se dovedească pentru siguranța și bunăstarea oamenilor din sucursală / locația
exterioară la momentul dezastrului.
Definiți acțiunile de răspuns pe baza claselor identificate de dezastre.
Pentru a ajunge la planul de reluare a procesului selectat, trebuie să luați în considerare acceptarea riscului
pentru bancă, industrie și reglementările aplicabile
Faza 4: Dezvoltarea și Implementarea BCP
Planuri de acțiune, adică: acțiuni de răspuns definite specifice proceselor băncii, manuale practice (a face și a
nu se face, paragrafe specifice personalizate pentru unitățile de afaceri individuale) și proceduri de testare
Stabilirea succesiunii manageriale și a puterilor de urgență
Compatibilitatea și coordonarea planurilor de urgență atât la bancă, cât și la furnizorii săi de servicii
Procedura de recuperare nu trebuie să compromită mediul de control din locația de recuperare
Deținerea de planuri de urgență specifice pentru fiecare aranjament de externalizare bazate pe gradul de
semnificație al activității externalizate în activitatea băncii
Actualizare periodică pentru a absorbi schimbările din instituție sau furnizorii săi de servicii. Exemple de
situații care ar putea necesita actualizarea planurilor includ achiziția de noi echipamente, modernizarea
sistemelor operaționale și modificări în:
Personal
Adrese sau numere de telefon

Strategie de afaceri
Locație, dotări și resurse
Legislație
Contractori, furnizori și clienți cheie Procese – noi sau retrase Risc (operațional și financiar)
2.3 Factori cheie care trebuie luați în considerare pentru proiectarea BCP
La proiectarea BCP ar trebui luați în considerare următorii factori:
Probabilitatea unor evenimente neplanificate, inclusiv dezastre naturale sau provocate de om, cutremure,
incendii, uragane sau dezastre biochimice
Amenintari de securitate
Creșterea infrastructurii și interdependențelor aplicațiilor
Cerințe de reglementare și de conformitate, care devin din ce în ce mai complexe
Eșecul aranjamentelor cheie ale terților
Globalizarea și provocările de a opera în mai multe țări.
1.4 Considerații BCP
Băncile trebuie să ia în considerare implementarea unui proces BCP pentru a reduce la un nivel acceptabil
impactul întreruperilor cauzate de dezastre și defecțiuni de securitate printr-o combinație de măsuri
preventive și de recuperare.
BCP ar trebui să includă măsuri pentru identificarea și reducerea probabilității de risc pentru a limita
consecințele incidentelor dăunătoare și pentru a permite reluarea la timp a operațiunilor esențiale. BCP ar
trebui, printre altele, să ia în considerare reputația, riscurile operaționale, financiare și de reglementare.
Eșecul sistemelor critice sau întreruperea proceselor vitale de afaceri ar putea împiedica recuperarea la timp a
operațiunilor. Prin urmare, managementul instituției financiare trebuie să înțeleagă pe deplin
vulnerabilitățile asociate cu interrelațiile dintre diferitele sisteme, departamente și procese de afaceri.
Aceste vulnerabilități ar trebui încorporate în BIA, care analizează corelația dintre componentele
sistemului și serviciile pe care le oferă.
Diverse instrumente pot fi utilizate pentru a analiza aceste interdependențe critice, cum ar fi o analiză a
fluxului de lucru, o organigramă, o topologie de rețea și înregistrări de inventar. O analiză a fluxului de
lucru poate fi efectuată prin observarea operațiunilor zilnice și intervievarea angajaților pentru a
determina ce resurse și servicii sunt împărțite între diferitele departamente. Această analiză, împreună cu
celelalte instrumente, va permite managementului să înțeleagă diferite priorități de procesare, cerințe de
documentare și interrelațiile dintre diferitele sisteme. Următoarele probleme atunci când se determină
interdependențe critice în cadrul organizației:
Personal cheie;
Înregistrări vitale;
Echipamente partajate, hardware, software, fișiere de date și spațiu de lucru;
Procese de producție;
Servicii pentru clienți;
Conectivitate la rețea; și
Sisteme de Management al Informatiei.
Considerații cheie la formularea unui BCP:

Asigurarea procesării prompte și precise a tranzacțiilor cu valori mobiliare, inclusiv, dar fără a
se limita la, preluarea comenzilor, introducerea comenzilor, executarea, compararea, alocarea,
compensarea și decontarea tranzacțiilor cu valori mobiliare, menținerea conturilor clienților,
accesul la conturile clienților și livrarea de fonduri și titluri de valoare.
Onorarea tuturor plăților clienților (adică obligația)

Acordarea de prioritate plății tranzacției în cursul zilei
Asigurarea accesului prompt clienților la fondurile și titlurile lor – ar trebui luate măsuri pentru a
pune la dispoziția clienților fondurile și titlurile de valoare ale clienților în cazul unei întreruperi
semnificative a activității.
Continuarea conformității cu cerințele de raportare de reglementare etc.
Ar trebui menținut un cadru unic al BCP pentru a se asigura că toate planurile sunt consecvente și pentru a
identifica prioritățile și dependențele pentru testare și întreținere.
Un cadru BCP ar trebui să ia în considerare următoarele:
Condiții pentru activarea planurilor, care descriu un proces care trebuie urmat (cum se evaluează situația, cine
urmează să fie implicat etc.) înainte de activarea fiecărui plan
Proceduri de urgență, care descriu acțiunile care trebuie întreprinse în urma unui incident care pune în pericol
operațiunile comerciale și/sau viața umană. Aceasta ar trebui să includă aranjamente pentru
managementul relațiilor publice și pentru o legătură eficientă cu autoritățile publice corespunzătoare, de
exemplu poliția, pompierii, serviciile de sănătate și administrația locală.
Identificarea resurselor și locațiilor de procesare, disponibile pentru a le înlocui pe cele care sprijină
activitățile critice; proceduri alternative care descriu acțiunile care trebuie întreprinse pentru a muta
activitățile esențiale de afaceri sau serviciile de asistență în locații temporare alternative și pentru a
readuce în funcțiune procesele de afaceri în intervalele de timp necesare
Identificarea informațiilor care trebuie să facă backup și a locației pentru stocare, precum și cerința ca
informațiile să fie salvate în scop de copiere de rezervă într-un program stabilit și respectarea acestuia
Proceduri de reluare, care descriu acțiunile care trebuie întreprinse pentru a reveni la operațiunile normale de
afaceri
Un program de întreținere care specifică cum și când va fi testat planul și procesul de menținere a planului
Activități de conștientizare și educație, care sunt concepute pentru a crea înțelegerea operațiunilor și funcțiilor
bancare critice, a proceselor de continuitate a afacerii și pentru a asigura
că procesele continuă să fie eficiente
Responsabilitățile persoanelor, descriind cine este responsabil pentru executarea carei componente a planului.
Alternativele trebuie nominalizate după cum este necesar.
(g) Planificarea pandemiei
Pandemiile sunt definite ca epidemii, sau focare la oameni, de boli infecțioase care au capacitatea de a se răspândi
rapid pe suprafețe mari, posibil la nivel mondial. Efectele economice negative ale unei pandemii ar putea fi
semnificative, atât la nivel național, cât și internațional. Datorită rolului lor financiar și economic crucial,
instituțiile financiare ar trebui să aibă planuri în vigoare care să descrie modul în care se vor descurca într-un
eveniment pandemic.
Planificarea pandemiei prezintă provocări unice pentru managementul instituțiilor financiare. Spre deosebire de
dezastrele naturale, dezastrele tehnice, actele rău intenționate sau evenimentele teroriste, impactul unei pandemii
este mult mai dificil de determinat din cauza diferenței anticipate de amploare și durată. În plus, în timp ce
dezastrele și întreruperile tradiționale au în mod normal durate limitate, pandemiile apar în general în mai multe
valuri, fiecare durând două până la trei luni. În consecință, nicio persoană sau organizație nu este ferită de efectele
adverse care ar putea rezulta în urma unui eveniment pandemic.
Una dintre cele mai semnificative provocări probabile de la un eveniment pandemic sever va fi lipsa de personal
din cauza absenteismului. Aceste diferențe și provocări evidențiază necesitatea ca toate instituțiile financiare,
indiferent de dimensiunea lor, să planifice pentru un eveniment pandemic atunci când își dezvoltă BCP.
Este important ca instituțiile să țină activ la curent cu evoluțiile internaționale și naționale și cu avizele de sănătate
emise în acest sens.
În consecință, BCP al unei bănci trebuie să prevadă următoarele :
Un program preventiv pentru a reduce probabilitatea ca operațiunile unei bănci să fie afectate în mod
semnificativ de un eveniment pandemic, incluzând: monitorizarea potențialelor focare, educarea
angajaților, comunicarea și coordonarea cu furnizorii și furnizorii de servicii critice, pe lângă furnizarea
de formare și instrumente adecvate de igienă pentru angajati.
O strategie documentată care prevede extinderea eforturilor de pandemie ale instituției, astfel încât
acestea să fie în concordanță cu efectele unei anumite etape a unui focar de pandemie, cum ar fi primele
cazuri de oameni care contractează boala în străinătate sau în India și primele cazuri în cadrul
organizației în sine. Strategia va trebui, de asemenea, să contureze planuri care să precizeze cum să se
recupereze după un val de pandemie și pregătirile adecvate pentru orice val(e) următor(e).
Un cadru cuprinzător de facilități, sisteme sau proceduri care oferă organizației capacitatea de a-și
continua operațiunile critice în cazul în care un număr mare de personal al instituției nu este disponibil
pentru perioade prelungite. Astfel de proceduri ar putea include distanțarea socială pentru a minimiza
contactul cu personalul, telecommuting, redirecționarea clienților de la sucursală la servicii bancare
electronice sau efectuarea de operațiuni de pe site-uri alternative.
Cadrul ar trebui să ia în considerare impactul reacțiilor clienților și cererea potențială pentru servicii
bancare online, bancare telefonice, bancomate și servicii de asistență pentru apeluri și încrederea crescută
în acestea. În plus, ar trebui luate în considerare posibilele acțiuni ale autorităților de sănătate publică și
ale altor autorități guvernamentale care pot afecta funcțiile de afaceri critice ale unei instituții financiare.
Un program de testare pentru a se asigura că practicile și capacitățile instituției de planificare a

pandemiei sunt eficiente și vor permite operațiunilor critice să continue.
Un program de supraveghere pentru a asigura revizuirea și actualizările continue ale planului de

pandemie, astfel încât politicile, standardele și procedurile să includă informații actualizate și relevante
furnizate de surse guvernamentale sau de programul de monitorizare al instituției.
Băncile pot lua în considerare, de asemenea, asigurarea pentru a transfera riscul unei terțe părți, având
totuși atenția cuvenită în ceea ce privește siguranța plăților în cazul unor întreruperi.
Testarea unui BCP
– Băncile trebuie să testeze în mod regulat BCP pentru a se asigura că sunt actualizate și eficiente: Testarea BCP ar
trebui să includă toate aspectele și elementele constitutive ale unei bănci, adică oamenii, procesele și resursele
(inclusiv tehnologia). BCP, după testarea completă sau parțială poate eșua. Motivele sunt ipoteze incorecte,
neglijeri sau schimbări în echipamente sau personal. Testele BCP ar trebui să se asigure că toți membrii echipei de
recuperare și alți membri ai personalului relevant sunt la curent cu planurile. Programul de testare pentru BCP ar
trebui să indice cum și când trebuie testată fiecare componentă a unui plan. Se recomandă testarea frecventă a
componentelor individuale ale planurilor (planurilor), de obicei cel puțin o dată pe an. Ar trebui utilizate o
varietate de tehnici pentru a oferi asigurarea că planul (planurile) va funcționa în viața reală.
– Băncile ar trebui să-și implice auditorii interni (inclusiv auditorii SI) pentru a audita eficacitatea BCP: iar
testarea periodică a acestuia ca parte a activității lor de audit intern și constatările/recomandările lor în acest sens
ar trebui incluse în raportul lor către Consiliul de administrație.
– Băncile ar trebui să ia în considerare planificarea unui exercițiu BCP împreună cu terții critici: pentru a furniza
servicii și asistență pentru a continua cu procesele minime necesare preidentificate.
– Băncile ar trebui, de asemenea, să-și mute periodic operațiunile: inclusiv oamenii, procesele și resursele (IT și
non-IT) la locația planificată de transfer sau DR pentru a testa eficiența BCP și, de asemenea, pentru a măsura
timpul de recuperare necesar pentru a aduce operațiunile la normal functionare.
– Băncile ar trebui să ia în considerare efectuarea testului de mai sus fără deplasarea personalului băncii la locația
DR . Acest lucru va ajuta la testarea gradului de pregătire a personalului alternativ de la locația DR.
– Băncile ar trebui să ia în considerare efectuarea de exerciții BCP neplanificate: în care doar un set restrâns de
oameni și anumiți personal identificat pot fi conștienți de exercițiu și nu personalul de podea sau de afaceri. În
astfel de cazuri, băncile ar trebui să aibă o „echipă de observație” desfășurată la locație pentru a studia și a asimila
răspunsurile și nevoile diferitelor echipe. Pe baza rezultatelor acestui studiu, băncile ar trebui să își revizuiască
Planul BCP pentru a se potrivi cerințelor de teren.
3.1 Tehnici de testare
Mai jos sunt câteva dintre tehnicile ilustrative care pot fi utilizate în scopuri de testare BCP :
Testare de masă pentru scenarii (discutarea aranjamentelor de redresare a afacerii folosind exemple de
întreruperi) Simulări (în special pentru instruirea oamenilor în rolurile lor post-incidentă sau de gestionare a
crizelor)
Testare de recuperare tehnică (asigurându-se că sistemele informaționale pot fi restaurate eficient)
Testarea recuperării la un site alternativ (desfășurarea proceselor de afaceri în paralel cu operațiunile de

recuperare departe de site-ul principal)
Teste ale facilităților și serviciilor furnizorilor (asigurându-se că serviciile și produsele furnizate extern
vor îndeplini angajamentul contractat)
Repetiții complete (testarea faptului că organizația, personalul, echipamentele, facilitățile și procesele pot
face față întreruperilor)
Testare de simulare: Este atunci când participanții aleg un scenariu specific și simulează o situație BCP la
locație. Aceasta implică testarea tuturor resurselor: oameni, IT și altele, cărora li se cere să permită continuitatea
afacerii pentru un scenariu ales. Accentul este pus pe demonstrarea capacității, inclusiv cunoștințe, interacțiune în
echipă și capacități de luare a deciziilor. De asemenea, poate specifica jocul de rol cu răspuns simulat în
locații/facilități alternative pentru a realiza pașii critici, a recunoaște dificultățile și a rezolva problemele.
Testarea componentelor: Aceasta este pentru a valida funcționarea unei părți individuale sau a unui sub-proces
al unui proces, în cazul invocării BCP. Se concentrează pe testarea în profunzime a piesei sau a subprocesului
pentru a identifica și a se pregăti pentru orice risc care ar putea împiedica buna funcționare a acestuia. De
exemplu, testarea comutatorului ATM.
Fiecare organizație trebuie să definească frecvența, programul și grupurile de zone de afaceri, selectate pentru
testare după ce a fost efectuată o analiză de risc și impact asupra afacerii.
Banca poate lua în considerare liniile directoare ample furnizate mai jos pentru a determina frecvența de testare pe
baza criticii unui proces:
Impact asupra Testare de masă Sun tree Simulare Testarea Complet
proceselor testarea componentelor Repetiții
Înalt Trimestrial Trimestrial Trimestrial Trimestrial Anual
Mediu Trimestrial Semestrial Semestrial Anual Anual
Scăzut Semestrial Anual N/A N/A N/A
Întreținerea și reevaluarea planurilor
BCP-urile ar trebui menținute prin revizuiri și actualizări anuale pentru a asigura eficacitatea lor continuă.
Procedurile ar trebui incluse în programul de management al schimbărilor al organizației pentru a se
asigura că problemele privind continuitatea activității sunt abordate în mod corespunzător. Ar trebui să
fie atribuită responsabilitatea pentru revizuirile regulate ale fiecărui plan de continuitate a afacerii.
Identificarea modificărilor aranjamentelor/proceselor de afaceri, care nu sunt încă reflectate în planurile
de continuitate a afacerii, ar trebui să fie urmată de o actualizare corespunzătoare a planului în mod
periodic, să spunem trimestrial. Acest lucru ar necesita un proces de transmitere a oricăror modificări ale
activității, structurii, sistemelor, software-ului, hardware-ului, personalului sau facilităților instituției
către coordonatorul/echipa BCP. Dacă este semnificativă
au avut loc schimbări în mediul de afaceri sau dacă constatările auditului justifică modificări ale BCP sau
programului de testare, liniile directoare ale politicii de continuitate a afacerii și cerințele programului ar
trebui actualizate în consecință.
Modificările ar trebui să urmeze procesul formal de gestionare a modificărilor instituit de bancă pentru
documentele sale de politică sau proceduri. Acest proces formal de control al schimbărilor ar trebui să
asigure că planurile actualizate sunt distribuite și consolidate prin revizuiri regulate ale planului complet.
O copie a BCP, aprobată de către consiliu, ar trebui să fie transmisă pentru citire către RBI în fiecare an. În
plus, banca trebuie să prezinte și:
– O declarație anuală la sfârșitul fiecărui exercițiu financiar care descrie sistemele critice, putregaiurile
acestora și strategia băncii de a le realiza și
– O declarație trimestrială, care raportează defecțiuni majore în timpul perioadei pentru sistemele critice,
segmentul de clienți sau serviciile afectate din cauza defecțiunilor și măsurile luate pentru a evita astfel de
defecțiuni în viitor.
Aspecte procedurale ale BCP
Un BCP eficient ar trebui să țină cont de potențialul dezastrelor pe o zonă extinsă, care afectează o regiune
întreagă, și de pierderea sau inaccesibilitatea rezultată a personalului. De asemenea, ar trebui să ia în
considerare și să abordeze interdependențele, atât bazate pe piață, cât și geografice, între participanții la
sistemul financiar, precum și furnizorii de servicii de infrastructură.
În plus, băncile ar trebui, de asemenea, să ia în considerare necesitatea punerii în aplicare a site-urilor de

rezervă necesare pentru sistemele lor critice de plată care interacționează cu sistemele din centrele de date
ale Băncii de Rezervă.
Băncile pot lua în considerare, de asemenea, să ruleze unele procese critice și operațiuni de afaceri de la site-
urile primare și secundare, în care fiecare ar oferi backup celuilalt.
Și anume prioritizarea procesului și locația alternativă pentru personalul din următoarele categorii:
• Dealeri și comercianți
• Operațiuni (de exemplu, casier, ghișeu de împrumut, casierie etc.)
• Personalul departamentului de trezorerie
• Echipa de vanzari
• personal IT
• Personal cu funcții corporative (HR, Admin).
• Testarea cuprinzătoare ar ajuta băncile să ajusteze în continuare procesele BCP/DR pentru a le asigura
robustețea și, de asemenea, să permită trecerea fără probleme la site-ul DR, în funcție de prioritatea
și scara proceselor identificate pentru fiecare proces.
Toate procesele critice ar trebui să fie documentate pentru a reduce dependența de personal pentru
scenariile în care personalul nu poate ajunge la sediul desemnat de birou.
Personalul de rezervă/standby trebuie identificat pentru toate rolurile critice. Ar trebui dezvoltată o
matrice de apeluri pentru a coordona mai bine viitoarele apeluri de urgență care implică autoritățile
financiare individuale, asociațiile comerciale din sectorul financiar și alte bănci și părți interesate. În plus,
organizația ar trebui să aibă un arbore de apeluri cu ramuri în anumite regiuni/procese de afaceri. Pe baza
naturii urgenței, o anumită ramură/întregul arbore de apeluri ar trebui să fie activată.
Partea relevantă a BCP adoptată ar trebui, de asemenea, diseminată tuturor celor interesați, inclusiv clienților,
astfel încât conștientizarea să le permită să reacționeze pozitiv și în consonanță cu BCP. Acest lucru ar
ajuta la menținerea încrederii clientului în instituția bancară, iar posibilitatea unei rulări bancare ar fi
redusă exponențial. Partea planului păstrată în domeniul public ar trebui, în mod normal, să se limiteze la
informații referitoare la pregătirea generală a băncilor în acest sens, fără nicio precizare detaliată, pentru a
proteja băncile de a deveni vulnerabile la amenințările de securitate.
Băncile ar trebui să ia în considerare formularea unei „strategii de comunicare” clare, cu ajutorul personalului
de management media, pentru a controla conținutul și forma știrilor care sunt difuzate clienților lor în
perioade de panică.
Băncile ar trebui să ia în considerare un plan BCP detaliat pentru a face față calamităților naturale/dezastrelor.
Ar trebui documentată o politică formală de excepție, care va ghida personalul din zonele afectate să
acționeze independent până la reluarea conexiunii cu lumea exterioară.
Ghidul menționat mai sus ar trebui să aibă excepții documentate pentru procesul critic, care va asigura
continuarea procesului critic fără formalitățile operaționale obișnuite.
După ce aprobările sau permisiunile corespunzătoare sunt obținute intern și de la RBI, băncile ar trebui să ia
în considerare pregătirea unui ghid pentru relaxarea anumitor reguli/cerințe pentru clienții afectați de
calamitate.
Ca:
Extinderea termenului de plată a împrumutului/dobânzilor
Emiterea unui nou împrumut cu documentele minime necesare
Eliminarea taxelor de întârziere la plată și a penalităților în anumite cazuri
Permiterea retragerii de numerar mai mult decât în mod normal de la bancomate
Băncile pot lua în considerare accelerarea compensării cecurilor pentru clienți, direcționând toate cecurile
către o altă regiune decât cea afectată de calamitate. În cazul unei calamități grave, băncile ar trebui să ia
în considerare limitarea împrumuturilor existente pentru a facilita eforturile de reconstrucție ale
guvernului. pentru zonele de calamitate. Băncile pot lua în considerare, de asemenea, să asigure
procesarea rapidă a cererilor de împrumut, de preferință în 48 de ore de la primirea acestor cereri. Ar
trebui să ia în considerare expedierea facturii de credit, a notelor de acord etc. datorate clientului prin a
avea
un aranjament pentru a imprima același lucru într-o locație alternativă și ar trebui să ia în considerare
acceptarea plăților întârziate pentru taxele cardului de credit pentru clienții din zona afectată de
calamitate.
De asemenea, băncile pot depune eforturi pentru reluarea serviciilor bancare prin înființarea de birouri satelit,
ghișee de extensie sau facilități bancare mobile.
Aspecte de infrastructură ale BCP
– Băncile ar trebui să ia în considerare acordarea unei atenții deosebite disponibilității facilităților de bază, cum ar
fi electricitate, apă și cutie de prim ajutor în toate birourile. (de exemplu, evaluați nevoia de rezervă a energiei
electrice nu doar pentru sistemele sale, ci și pentru oamenii săi și gestionarea infrastructurii, cum ar fi aerul
condiționat central.)
– Băncile ar trebui să ia în considerare atribuirea dreptului de proprietate pentru fiecare zonă. Procedurile de
urgență, planurile manuale de rezervă și planurile de reluare ar trebui să fie în responsabilitatea proprietarilor
resurselor sau proceselor de afaceri adecvate implicate.
– Sistemele interne de telecomunicații și transmițătoarele fără fir de pe clădiri ar trebui să aibă putere de rezervă.
Sistemele redundante, cum ar fi telefoanele cu linie analogică și telefoanele prin satelit (unde este cazul), și alte
măsuri simple, cum ar fi asigurarea disponibilității bateriilor suplimentare pentru telefoanele mobile, se pot
dovedi esențiale pentru menținerea comunicațiilor într-o defecțiune a infrastructurii la scară largă.
– Ar trebui luate în considerare posibile aranjamente de rezervă și servicii alternative ar trebui efectuate în
coordonare cu furnizorii de servicii, contractorii, furnizorii în baza unui acord sau contract scris, care să
stabilească rolurile și responsabilitățile fiecărei părți, pentru a face față situațiilor de urgență. De asemenea,
impunerea de penalități, inclusiv acțiuni în justiție, poate fi inițiată de o organizație împotriva furnizorilor de
servicii sau a contractanților sau a furnizorilor, în cazul nerespectării sau necooperării.
– Când sunt identificate noi cerințe, procedurile de urgență stabilite: de exemplu, planurile de evacuare sau orice
aranjamente de rezervă existente, ar trebui modificate după caz.
– Băncile pot lua în considerare resursele de rezervă (de exemplu, articole de papetărie necesare pentru tipărirea
cecurilor, imprimante speciale, ștampile) într-o locație operațională secundară.
– Planurile pot fi, de asemenea, aliniate în mod corespunzător cu cele ale autorităților guvernamentale locale
– Băncile ar trebui să ia în considerare să nu depoziteze hârtii critice, fișiere, servere la parter unde există
posibilitatea de inundații sau afundarea apei. Cu toate acestea, băncile ar trebui să ia în considerare și evitarea
etajelor superioare ale clădirilor mai înalte pentru a reduce impactul din cauza incendiului probabil.
– Zonele de depozitare rezistente la foc și la apă trebuie luate în considerare pentru documentele critice.
– Băncile ar trebui să ia în considerare mijloace alternative de sursă de energie (cum ar fi achiziționarea mai
multor motorine/baterie de rezervă de urgență etc.) pentru perioade lungi de întreruperi de curent.
– Băncile ar trebui să ia în considerare un număr de asistență de urgență sau un mesaj IVR naționalizat pentru a
rezolva întrebările clienților și pentru a se asigura că situația de panică este evitată. Pentru aceasta, ar trebui
identificat un centru de apeluri alternativ pentru zona de rezervă pentru a prelua sarcina parțială a zonei afectate
de calamitate. Persoana/echipa desemnată trebuie să fie responsabilă pentru Compiled by Srinivas Kante Email:
care să permită devierea liniei. Un serviciu similar poate fi luat în considerare și în beneficiul comunicării legate
de angajați.
Aspecte umane ale BCP
Oamenii sunt o componentă vitală a oricărei organizații. Prin urmare, acestea ar trebui să fie parte integrantă a
unui BCP. În general, planurile sunt adesea prea concentrate pe problemele tehnice, prin urmare, se sugerează să
fie încorporată o secțiune separată referitoare la oameni, inclusiv detalii privind bunăstarea personalului,
consiliere, considerente privind relocarea etc. De asemenea, ar trebui implementat un programator de
conștientizare a BCP, care servește la consolidarea implicării personalului în BCP. Acest lucru se poate face prin
buletine informative ale programului de introducere, exerciții de formare a personalului etc.
Băncile trebuie să ia în considerare pregătirea mai multor angajați pentru anumite locuri de muncă critice (ire. în
absența unui angajat, munca nu trebuie să fie blocată sau întârziată). Ei trebuie să ia în considerare formarea
încrucișată a angajaților pentru funcții critice și proceduri de operare a documentelor. Băncile ar trebui să ia în
considerare posibilitatea de a activa capabilități și resurse de lucru de la domiciliu pentru angajații care
îndeplinesc funcții critice.
Rolul resurselor umane în contextul BCP
Echipa de gestionare a crizelor: Ca membru principal al CMT, HR oferă îndrumări echipei cu privire la
problemele legate de oameni, inclusiv evacuarea, bunăstarea, dacă să invoce linia de incidente HR, aranjamente
alternative de călătorie și ce să comunice personalului.
Linia pentru incidente HR: Operată din cadrul funcției HR centralizate, linia de asistență pentru incidente este
invocată în acele cazuri, în care există posibile victime sau personal dispărut, ca urmare a unui incident. Invocată
de CMT, linia este gestionată de ofițeri de resurse umane calificați, instruiți în modul de a face față apelanților
aflați în dificultate. Personalul poate primi un card de urgență, care include numărul liniei de incident.
Informațiile de pe linia fierbinte sunt actualizate în mod regulat. Facilitatea le permite managerilor de linie să țină
echipa centrală de criză la curent cu locația și bunăstarea personalului. Bunăstarea și sprijinul permanent pentru
personal sunt oferite și prin intermediul unui furnizor de asistență pentru angajați.
Aranjamente excepționale de călătorie: planurile de transport ar trebui luate în considerare în cazul în care este
nevoie de relocare. Personalul cheie trebuie identificat, inclusiv detalii despre locul în care se află, iar vehiculele
sunt în așteptare pentru a le transporta, dacă este necesar.
Aspecte tehnologice ale BCP
Există multe aplicații și servicii în sistemul bancar care sunt extrem de critice în natură și, prin urmare, necesită o
disponibilitate ridicată și toleranță la erori pentru a fi luate în considerare la proiectarea și implementarea soluției.
Acest aspect este de luat în considerare în special la proiectarea soluției de data center și a soluției de rețea
corporativă.
Strategii de recuperare a datelor
Înainte de a selecta o strategie de recuperare a datelor (DR), un planificator DR ar trebui să se refere la BCP al
organizației sale, care ar trebui să indice valorile cheie ale obiectivului punctului de recuperare și al obiectivului
de timp de recuperare pentru procesele de afaceri:
Recovery Point Objective (RPO) – Latența acceptabilă a datelor care vor fi recuperate
Obiectiv de timp de recuperare (RTO) – perioada de timp acceptabilă pentru restabilirea funcției
Obiectivul punctului de recuperare trebuie să se asigure că pierderea maximă tolerabilă de date pentru fiecare
activitate nu este depășită. Obiectivul de timp de recuperare trebuie să se asigure că perioada maximă tolerabilă
de întrerupere (MTPD), pentru fiecare activitate, nu este depășită. Valorile specificate pentru procesele de afaceri
trebuie apoi mapate la sistemele și infrastructura IT subiacente care sprijină acele procese. Odată ce valorile RTO
și RPO au fost mapate la infrastructura IT, planificatorul DR poate determina cea mai potrivită strategie de
recuperare pentru fiecare sistem. O notă importantă aici este însă că afacerea stabilește în cele din urmă bugetul
IT. Prin urmare, valorile RTO și RPO trebuie să se potrivească cu bugetul disponibil și cu criticile
procesului/funcției de afaceri.
O listă de strategii comune pentru protecția datelor:
Backup-uri realizate pe bandă și trimise în afara site-ului la intervale regulate (de preferință zilnic)
Backup-uri efectuate pe disc la fața locului și copiate automat pe discul extern sau făcute direct pe discul
extern
Replicarea datelor într-o locație în afara amplasamentului, ceea ce depășește necesitatea de a restaura datele
(numai sistemele trebuie apoi restaurate sau sincronizate). În general, aceasta utilizează tehnologia
rețelei de stocare (SAN).
Sisteme de înaltă disponibilitate care păstrează atât datele, cât și sistemul replicat, off-site, permițând accesul
continuu la sisteme și date
În multe cazuri, o organizație poate alege să folosească un furnizor externalizat de recuperare în caz de dezastru
pentru a oferi un site și sisteme de rezervă, mai degrabă decât să-și folosească propriile facilități la distanță. Pe
lângă pregătirea pentru nevoia de recuperare a sistemelor, organizațiile trebuie să implementeze și măsuri de
precauție cu scopul de a preveni, în primul rând, un dezastru. Acestea pot include unele dintre următoarele:
Oglinzi locale ale sistemelor sau datelor. Utilizarea tehnologiei de protecție a discurilor, cum ar fi RAID
Protectoare de supratensiune — pentru a minimiza efectul supratensiunii asupra echipamentelor electronice

delicate
Alimentare neîntreruptă (UPS) sau generator de rezervă pentru a menține sistemele în funcțiune în cazul unei
căderi de curent
Prevenirea incendiilor - alarme, stingătoare
Software antivirus și măsuri de securitate
Un plan de recuperare în caz de dezastru face parte din BCP. Dictează fiecare aspect al procesului de recuperare,
inclusiv:
Ce evenimente denotă posibile dezastre;
Ce oameni din organizație au autoritatea să declare un dezastru și, prin urmare, să pună în aplicare
planul;
Secvența evenimentelor necesare pregătirii site-ului de rezervă odată ce a fost declarat un dezastru;
Rolurile și responsabilitățile întregului personal cheie în ceea ce privește realizarea planului;
Un inventar al hardware-ului și software-ului necesar pentru restabilirea producției;
Un program care listează personalul care va ocupa locul de rezervă, inclusiv un program de rotație
pentru a sprijini operațiunile în desfășurare fără a epuiza membrii echipei de dezastru.
Un plan de recuperare în caz de dezastru trebuie să fie un document viu; pe măsură ce centrul de date se modifică,
planul trebuie actualizat pentru a reflecta acele modificări.
Este de remarcat faptul că problemele tehnologice sunt un derivat al planului de continuitate a afacerii și al
managementului.
De exemplu, BCP și Management vor duce la analiza impactului asupra afacerii, care va duce la analiza
impactului asupra performanței (PIA). Aceasta va depinde de performanța tehnologică a Arhitecturii totale a
soluțiilor IT.
A amplifica analiza impactului asupra afacerii înseamnă a identifica operațiunile și serviciile critice, dependențele
cheie interne și externe și nivelurile adecvate de rezistență. De asemenea, analizează riscurile și cuantifică
impactul acelor riscuri din punctul de vedere al perturbărilor de afaceri. De exemplu, pentru a oferi servicii
clienților de ultimă generație atât la nivel de sucursală, cât și la canalele de livrare, trebuie să luăm în considerare
nivelurile de servicii care sunt angajate.
Dacă o tranzacție ATM trebuie să aibă loc în 10 secunde și retragerea sau depunerea numerarului trebuie să aibă
loc în 60 de secunde la ghișeu, atunci pe baza încărcăturii se poate calcula numărul de clienți care pot fi deserviți
într-o zi. Exemplul de mai sus este de a înțelege faptul că latența de afaceri introdusă de sistem este o combinație
de tehnologie, proces și oameni. Prin urmare, latența tehnică este un derivat al latenței de afaceri angajate, iar
arhitectura soluției tehnologice trebuie să ofere același lucru la sarcini diferite.
Arhitectura soluției tehnologice pentru a răspunde cerințelor specifice BCM sunt:
Performanţă
Disponibilitate
Securitate și control acces
Conformitatea cu standardele pentru a asigura interoperabilitatea

Performanța arhitecturii soluției tehnologice pentru operațiuni trebuie cuantificată. Ar trebui să fie posibil să se
măsoare, după cum este necesar, parametrii cuantificați. (De exemplu, dacă latența pentru o tranzacție complexă
inițiată la sucursală trebuie să fie finalizată în patru secunde sub sarcină de vârf, ar trebui să fie posibilă existența
unor medii de măsurare adecvate pentru a se asigura că nu au avut loc degradări de performanță din cauza
încărcărilor în creștere.)
Arhitectura soluției trebuie să fie proiectată cu o disponibilitate ridicată și fără un singur punct de eșec. Este
inevitabil ca o arhitectură de soluție complexă cu produse punctuale din diferite surse procurate și implementate
în momente diferite în timp să aibă o întrerupere din când în când, iar problema importantă este că, cu SLA-uri
clar definite, timp mediu pentru restaurare, ar trebui să fie posibil. pentru a identifica defecțiunea și a remedia
aceeași fără nicio degradare a performanței.
În consecință, în ceea ce privește aspectele de performanță și disponibilitate, următoarele arhitecturi trebuie să fie
proiectate și configurate pentru a oferi niveluri ridicate de timp de funcționare non-stop pentru a asigura
funcționarea neîntreruptă.
Însumarea proceselor necesare:
–Arhitectura soluției centrului de date
–Arhitectura soluției DR
–Arhitectura soluției de locație în apropiere
– Arhitectura de rețea și securitate a întreprinderii
– Arhitectura sucursalei sau a canalului de livrare
– Pe baza observației de mai sus, băncilor li se cere să facă următoarele: să preia auditul de performanță și
disponibilitate a soluțiilor implementate pentru a se asigura că arhitectura este proiectată și implementată fără un
singur punct de eșec.
– Auditează arhitectura implementată pentru toate aplicațiile și serviciile esențiale pentru misiune și rezolvă
preocupările care apar într-un mod limitat în timp.
– Investigați periodic întreruperile care se confruntă din când în când, care sunt mini-dezastre care au ca rezultat
indisponibilitatea serviciilor pentru o perioadă scurtă de timp, sistemele care nu răspund atunci când tranzacțiile
sunt inițiate la nivel de sucursală, canalele de livrare nefuncționând pentru un scurt timp perioadă de timp pentru a
se asigura că serviciul pentru clienți nu este afectat.
– Asigurarea disponibilității soluțiilor tehnologice adecvate pentru măsurarea și monitorizarea funcționării

produselor. Și, aveți oameni tehnici competenți și capabili în cadrul sistemului pentru a rezolva problemele
rapid.
Problemele detaliate mai sus trebuie avute în vedere la finalizarea arhitecturii centrului de date și a
arhitecturii rețelei corporative, care se așteaptă să aibă redundanță încorporată în soluție, fără un singur punct
de eșec.
Referitor la arhitectura rețelei, se recomandă ca Băncile să construiască în redundanțe după cum urmează:
Redundanță la nivel de legătură
Redundanță la nivel de cale
Redundanță la nivel de rută
Redundanță la nivel de echipament
Redundanță la nivelul furnizorului de servicii
Probleme în alegerea unui site de rezervă și implementarea unei soluții DC sau DR:
Site de rezervă: este o locație în care o organizație se poate muta cu ușurință în urma unui dezastru, cum ar fi
incendiu, inundație, amenințare teroristă sau alt eveniment perturbator. Aceasta este o parte integrantă a
planului de recuperare în caz de dezastru și a planificării mai ample a continuității activității unei organizații.
Un site de rezervă poate fi o altă locație operată de organizație sau contractată printr-o companie specializată
în servicii de recuperare în caz de dezastru. În unele cazuri, o organizație va avea un acord cu o a doua
organizație pentru a opera un site comun de rezervă.
Există trei tipuri principale de site-uri de rezervă:
site-uri reci locuri calde site-uri calde
Diferențele dintre ele sunt determinate de costurile și efortul necesar implementării fiecăruia.
Un alt termen folosit pentru a descrie un site de rezervă este un site de recuperare a zonei de lucru.
Cold Sites: Un site rece este cel mai ieftin tip de site de rezervă pentru o organizație. Nu include copii de
siguranță ale datelor și informațiilor din locația originală a organizației și nici hardware-ul deja configurat.
Lipsa hardware-ului contribuie la costurile minime de pornire ale site-ului rece, dar necesită timp
suplimentar după dezastru pentru ca operațiunea să funcționeze la o capacitate apropiată de cea anterioară
dezastrului.
Site-uri fierbinți: un site fierbinte este o copie a site-ului original al organizației, cu sisteme
computerizate complete, precum și copii de rezervă aproape complete ale datelor utilizatorului.
Sincronizarea în timp real între cele două site-uri poate fi utilizată pentru a oglindi mediul de date al site-ului
original, utilizând legături de rețea extinsă și software specializat. În urma unei perturbări a site-ului inițial,
site-ul fierbinte există astfel încât organizația să se poată reloca cu pierderi minime la operațiunile normale.
În mod ideal, un site fierbinte va fi pus în funcțiune în câteva ore sau chiar mai puțin. Este posibil ca
personalul să fie în continuare mutat pe site-ul fierbinte, astfel încât este posibil ca site-ul fierbinte să fie
operațional din perspectiva procesării datelor înainte ca personalul să se fi relocat. Capacitatea site-ului
fierbinte poate sau nu să se potrivească cu capacitatea site-ului inițial, în funcție de cerințele organizației.
Acest tip de site de rezervă este cel mai scump
a functiona. Site-urile fierbinți sunt populare în rândul organizațiilor care operează procese în timp real, cum ar fi
instituțiile financiare, agențiile guvernamentale și furnizorii de comerț electronic
Site-uri calde: Un site cald este, destul de logic, un compromis între cald și rece. Aceste site-uri vor avea
hardware și conectivitate deja stabilite, deși la o scară mai mică decât locul de producție original sau chiar un site
fierbinte. Site-urile calde vor avea copii de rezervă la îndemână, dar este posibil să nu fie complete și pot avea
între câteva zile și o săptămână. Un exemplu ar fi benzile de rezervă trimise la site-ul cald prin curier
8.1 Următoarele probleme apar în alegerea unui site de rezervă și în implementarea unei soluții DC/DR:
Arhitecturile soluției DC și DR nu sunt identice pentru toate aplicațiile și serviciile. Aplicațiile și serviciile
critice, și anume soluțiile de retail, corporative, de finanțare comercială și de afaceri guvernamentale, precum și
canalele de livrare au aceleași configurații DR, în timp ce aplicațiile surround sau de interfață nu au suport DR.
Băncile vor trebui să efectueze o revizuire periodică cu referire la aspectul de mai sus și să actualizeze din când
în când soluțiile DR și să se asigure că toate aplicațiile și serviciile critice au o replică perfectă în ceea ce privește
performanța și disponibilitatea.
Configurațiile serverelor, dispozitivelor de rețea și ale altor produse de la DC și DR trebuie să fie identice în
orice moment. Acestea includ patch-urile care sunt aplicate periodic la DC și modificările aduse software-ului din
când în când prin personalizare și parametrizare pentru a ține cont de cerințele de reglementare, modificări de
sistem etc.
Verificările periodice cu referire la asigurarea integrității datelor și a tranzacțiilor între DC și DR sunt

obligatorii. Ar putea fi realizat la sfârșitul săptămânii sau ca parte a procesului EoD / BoD.
Soluțiile trebuie să aibă un parametru definit pentru Recovery Time Objective (RTO) și Recovery Point
Objective (RPO). Acești doi parametri au o influență foarte clară asupra aspectelor tehnologice, precum și asupra
procesului definit pentru trecerea la DR și a nivelurilor de competență necesare trecerii în intervalul de timp
specificat.
Valorile alese pentru RTO și RPO sunt mai mult să urmeze practica industriei și nu derivate din primele
principii. Prin urmare, exercițiile DR care sunt efectuate periodic trebuie să se asigure că parametrii de mai sus
sunt respectați cu strictețe.
Procesele de operațiuni tehnologice care sprijină operațiunile de afaceri (cum ar fi EOD/BOD) trebuie incluse
în mod oficial în Planul de continuitate IT.
Băncile pot lua în considerare, de asemenea, obiectivele de timp de recuperare și obiectivele punctului de
recuperare (RTO/RPO) pentru serviciile oferite și nu doar o aplicație specifică. De exemplu, pentru portalul de
internet și nu pentru serviciile bancare cu amănuntul. Acest lucru se face pentru a evita orice inconsecvență în
înțelegerea utilizatorilor de afaceri.
Exercițiile DR efectuate în prezent periodic intră în categoria opririi planificate. Băncile trebuie să dezvolte o
metodologie adecvată pentru a efectua exercițiile care sunt mai aproape de scenariul de dezastru real, astfel încât
Compiled by Srinivas Kante Email: srinivaskante4u@gmail.com
nivelul de încredere al echipei tehnice care preia acest exercițiu este construit pentru a răspunde cerinței în cazul
unui dezastru real.
De asemenea, se recomandă ca infrastructura de suport la DC și DR, și anume sistemele electrice, mediul de

aer condiționat și alte sisteme de sprijin să nu aibă un singur punct de defecțiune și să aibă un sistem de
management și monitorizare a clădirii pentru a monitoriza constant și continuu resursele. Daca se specifica ca
solutia are o disponibilitate mare de
95 măsurat lunar și un timp mediu de restabilire de 2 ore în cazul oricărei defecțiuni, trebuie să includă și
sistemul de suport.
Mecanismul de replicare a datelor urmat între DC și DR este mecanismul de replicare asincron și implementat
în întreaga industrie, fie folosind tehnici de replicare a bazei de date, fie tehnici de replicare bazate pe stocare. Au
merite și demerite relative. RTO și RPO discutate mai devreme, împreună cu mecanismul de replicare utilizat și
transferul de date necesar să fie realizat în timpul sarcinii de vârf vor decide lățimea de bandă necesară între DC
și DR. RPO-ul este direct legat de latența permisă pentru datele de tranzacție de la DC pentru a actualiza baza de
date la DR. Prin urmare, procesul implementat pentru cerința de replicare a datelor trebuie să se conformeze celor
de mai sus și să nu compromită integritatea datelor și a tranzacției.
Având în vedere necesitatea de a minimiza drastic pierderea de date în timpul exigențelor și de a permite
recuperarea rapidă și continuitatea operațiunilor critice de afaceri, băncile ar putea avea nevoie să ia în
considerare arhitectura DR aproape de site. Băncile majore cu o utilizare semnificativă a canalului de livrare a
clienților și o participare semnificativă pe piețele financiare/sistemele de plată și decontare ar putea avea nevoie
să aibă un plan de acțiune pentru crearea unei arhitecturi DR aproape de site pe termen mediu (de exemplu, în
decurs de trei ani).
8.2 Probleme/Provocări în implementarea DC/DR de către bănci
În ciuda progreselor considerabile în proiectarea echipamentelor și a serviciilor de telecomunicații și

recuperare, recuperarea în caz de dezastru IT devine o provocare. Aspectele de continuitate și recuperare
au un impact asupra strategiei IT, iar implicațiile costurilor provoacă bugetele IT.
Fereastra de timp pentru recuperare se micșorează în fața cererii de operațiuni 24/365. Unele studii susțin că
aproximativ 30% din aplicațiile cu disponibilitate ridicată trebuie recuperate în mai puțin de trei ore.
Încă 45 la sută în 24 de ore, înainte ca pierderile să devină nesustenabile; alții susțin că 60% din
sistemele de planificare a resurselor întreprinderii (ERP) trebuie să fie restaurate în mai puțin de 24 de
ore. Aceasta înseamnă că metodele tradiționale de backup și restaurare off-site nu mai sunt adesea
adecvate. Pur și simplu, durează prea mult pentru a recupera copii de rezervă incrementale și complete
ale imaginilor diferitelor aplicații interdependente (să fac backup la momente diferite), să le sincronizați
și să recreați poziția ca la dezastru. Funcționarea continuă – oglindirea datelor în locații în afara
amplasamentului și calcularea și telecomunicațiile de așteptare – poate fi singura soluție.
O evaluare a riscurilor și o analiză a impactului asupra afacerii ar trebui să stabilească justificarea

continuității pentru anumite servicii și aplicații IT și de telecomunicații.
Obținerea unei securități solide (asigurarea securității) nu este o activitate unică. Nu poate fi obținut doar prin
achiziționarea și instalarea de software și hardware adecvat. Este un proces continuu care necesită o
evaluare regulată a stării de sănătate a securității organizației și pași proactivi pentru a detecta și remedia
orice vulnerabilitate. Fiecare bancă ar trebui să aibă acces rapid și fiabil la expertiză pentru urmărirea
comportamentelor suspecte, monitorizarea utilizatorilor și efectuarea criminalisticii. Raportarea adecvată
către autoritățile în cauză – cum ar fi RBI/IDRBT/CERT-In și alte instituții ar trebui să fie un proces
secundar automat ori de câte ori au loc astfel de evenimente.
Pașii importanți care trebuie instituționalizați sunt următorii:
Autoevaluarea riguroasă a măsurilor de securitate de către bănci și auditul de securitate cuprinzător

de către agenții externe, așa cum este detaliat în „Capitolul privind securitatea informațiilor” anterior.
Pregătire aleatorie pentru securitate. Se propune ca o „bancă de întrebări” suficient de mare legată
de securitatea sănătății organizației să fie pregătită și dată echipelor de inspecție ale RBI care merg la
inspecția băncilor. Un subset aleatoriu al acestor interogări ar putea fi apoi dat echipei IT a unei bănci
pentru care trebuie să fie răspunsuri.
furnizate aproape în timp real. Exemple de verificări legate de conturile de utilizator ar putea fi numărul
de conturi noi, conturile desființate, cele mai active conturi. Ar putea exista și demonstrații de recuperare
a datelor din arhive.
Pot apărea și probleme de telecomunicații: este important să ne asigurăm că există legături relevante și că
capacitatea de comunicații este compatibilă. Trebuie verificată caracterul adecvat al capacității de voce și
date. Telefonia trebuie să fie comutată de la locul dezastrului la cel de așteptare. BCP al unei instituții
financiare ar trebui să ia în considerare abordarea liniilor directoare privind diversitatea pentru
capacitățile sale de telecomunicații. Acest lucru este deosebit de important pentru sectorul serviciilor
financiare, care asigură procese critice de plată, compensare și decontare; cu toate acestea, orientările
privind diversitatea ar trebui să fie luate în considerare de toate instituțiile financiare și ar trebui să fie
proporționale cu dimensiunea, complexitatea și profilul general de risc al instituției. Orientările privind
diversitatea pot include aranjamente cu mai mulți furnizori de telecomunicații. Totuși, rutarea diversă
poate fi dificil de realizat, deoarece operatorii primari de telecomunicații pot avea un acord cu aceiași
sub-transportatori pentru a furniza servicii de acces local, iar acești sub-transportatori pot avea, de
asemenea, un contract cu aceiași furnizori de servicii de acces local. Instituțiile financiare nu au niciun
control asupra numărului de segmente de circuit care vor fi necesare și, de obicei, nu au o relație de
afaceri cu niciunul dintre sub-transportatori. În consecință, este important ca instituțiile financiare să
înțeleagă relația dintre operatorul lor principal de telecomunicații și acești diferiți sub-transportatori și
modul în care această rețea complexă se conectează la facilitățile lor primare și de rezervă. Pentru a
determina dacă furnizorii de telecomunicații folosesc același sub-operator sau furnizor de servicii de
acces local, băncile pot lua în considerare efectuarea unei urmăriri end-to-end a tuturor circuitelor critice
sau sensibile pentru a căuta puncte unice de defecțiune, cum ar fi un comutator comun, un router, un
PBX. , sau birou central de telefon.
Băncile pot lua în considerare următoarele componente de diversitate de telecomunicații pentru a îmbunătăți
BCP:
Media alternative, cum ar fi sistemele wireless securizate
Echipament de rețea cu protocol de Internet care oferă capabilități ușor de configurat de

redirecționare și de echilibrare a încărcării traficului
Servicii locale către mai mult de un birou central al operatorului de telecomunicații sau diverse
căi fizice către birouri centrale independente
Cabluri multiple, diverse din punct de vedere geografic și puncte de intrare separate
Circuite de releu cadru care nu necesită interconexiuni de rețea, ceea ce cauzează adesea
întârzieri din cauza punctelor de concentrare între furnizorii de releu de cadru
Surse de alimentare separate pentru echipamente cu generator sau sursă de alimentare

neîntreruptă de rezervă
(vii) Conexiuni separate la locații de rezervă
Utilizarea regulată a mai multor facilități în care traficul este împărțit continuu între
conexiuni; și
Furnizori separați pentru nevoile de infrastructură hardware și software.
Băncile trebuie să își monitorizeze relația de servicii cu furnizorii de telecomunicații: Pentru a gestiona mai
eficient riscurile inerente. În coordonare cu furnizorii, conducerea ar trebui să se asigure că strategiile de

gestionare a riscurilor includ
următoarele, cel puțin:
– Stabiliți acorduri de nivel de serviciu care abordează măsurile de urgență și gestionarea schimbărilor
pentru serviciile furnizate;
– Asigurați-vă că căile de telecomunicații primare și de rezervă nu au în comun un singur punct de

defecțiune
– Stabiliți procese de inventariere și validare periodică a circuitelor de telecomunicații și a căilor de

rutare prin testare cuprinzătoare.
Unii furnizori oferă un serviciu drop-ship ca alternativă la ocuparea site-ului de așteptare. Adică, în cazul
unei defecțiuni a echipamentului, de exemplu, aceștia vor lăsa un înlocuitor în loc să insiste ca clientul
să ocupe locul de așteptare, cu toate inconvenientele pe care le-ar putea implica. Dar este esențial să se
efectueze o inspecție a amplasamentului pentru a se asigura că pot fi parcate pe locul dorit. Majoritatea
site-urilor comerciale de standby care oferă IT și facilități de recuperare a zonei de lucru nu garantează
un serviciu: contractul oferă doar acces la echipament. Deși cei mai mulți furnizori de renume vor
negocia un acord privind nivelul de servicii care specifică calitatea serviciului, acesta este rareori oferit.
Este important să vă asigurați că serviciul unei bănci nu va suferi de un timp de nefuncționare sau de răspuns
inacceptabil. Vânzătorul poate avea personal calificat disponibil – dar acest lucru este rareori garantat și au
un cost. În ceea ce privește costul, pot exista taxe suplimentare de plătit pentru testare, la invocarea unui
dezastru și pentru ocuparea într-un dezastru. Structura de taxare a furnizorului trebuie, de asemenea, luată în
considerare cu atenție.
Riscuri de externalizare: În teorie, un site comercial de așteptare cald sau cald este disponibil 24/365. Are
personal calificat să asiste la recuperare. Echipamentul său este permanent actualizat, în timp ce
echipamentele mai vechi rămân suportate. Este întotdeauna disponibil pentru utilizare și oferă perioade
de testare o dată sau de două ori pe an. Practica poate fi diferită. În zilele noastre, organizațiile au o
gamă largă de echipamente de la diferiți furnizori și modele diferite de la același furnizor. Nu toate site-
urile comerciale de standby sunt capabile să suporte întreaga gamă de echipamente pe care le poate avea
o bancă. În schimb, vânzătorii formează alianțe cu alții – dar acest lucru poate însemna că efortul de
recuperare al unei bănci este împărțit între mai multe site-uri de așteptare. Este posibil ca site-ul de
așteptare să nu aibă echipamente IT identice: în loc de utilizarea unui echipament identic, va oferi o
partiție pe un computer sau server mare compatibil. Este posibil ca sistemele de operare și pachetele de
securitate să nu fie aceeași versiune pe care o folosește de obicei clientul. Aceste aspecte pot provoca
eșecuri atunci când se încearcă recuperarea sistemelor și aplicațiilor IT – iar controlul slab al
schimbărilor la locul de recuperare ar putea provoca un dezastru la întoarcerea la site-ul normal.
Este responsabilitatea managerului/băncii IT să asigure recuperarea efectivă de către acei furnizori, care aplică
cele mai înalte standarde, susținând acest lucru printr-un contract strict, definind în mod clar specificațiile și
cerințele tehnice ale serviciului și acordurile de nivel de serviciu.
Informații și securitatea rețelei
Introducere:
Informațiile și cunoștințele bazate pe acestea au devenit din ce în ce mai mult recunoscute ca „active
informaționale”, care sunt factori vitali pentru operațiunile de afaceri. Prin urmare, ele solicită organizațiilor să
ofere niveluri adecvate de protecție. Pentru bănci, în calitate de furnizori de bani sub formă fizică sau în biți și
octeți, informațiile fiabile sunt și mai critice și, prin urmare, securitatea informațiilor este un domeniu vital de
îngrijorare.
Informațiile solide se află în centrul proceselor de gestionare a riscurilor dintr-o bancă. Calitatea inadecvată a
datelor este probabil să inducă erori în luarea deciziilor. Calitatea datelor necesită construirea de procese,
proceduri și discipline pentru gestionarea informațiilor și asigurarea integrității, acurateței, completitudinii și
actualității acestora. Atributele fundamentale care susțin calitatea datelor ar trebui să includă acuratețea,
integritatea, coerența, completitudinea, validitatea, actualitatea, accesibilitatea, capacitatea de utilizare și
auditabilitatea. Calitatea datelor furnizate de diverse aplicații depinde de calitatea și integritatea datelor pe care se
construiesc acele informații. Entitățile care tratează informațiile ca pe un activ organizațional critic sunt într-o
poziție mai bună pentru a le gestiona în mod proactiv.
Securitatea informațiilor nu se ocupă doar de informații în diverse canale, cum ar fi vorbite, scrise, tipărite,
electronice sau orice alt mediu, ci și de manipulare a informațiilor în ceea ce privește crearea, vizualizarea,
transportul, stocarea sau distrugerea. Aceasta este în contrast cu securitatea IT, care se referă în principal. cu
securitatea informațiilor în limitele domeniului tehnologic al infrastructurii de rețea. Din punct de vedere al
securității informațiilor, natura și tipul compromisului nu sunt la fel de semnificative precum faptul că securitatea
a fost încălcată.
Pentru a realiza o guvernanță eficientă a securității informațiilor, conducerea băncii trebuie să stabilească și să
mențină un cadru care să ghideze dezvoltarea și întreținerea unui program cuprinzător de securitate a
informațiilor.
Principii de bază ale securității informațiilor:
De peste douăzeci de ani, securitatea informațiilor a considerat că confidențialitatea, integritatea și

disponibilitatea (cunoscute sub numele de triada CIA) sunt principiile de bază. Există o dezbatere continuă cu
privire la extinderea acestui trio clasic. Alte principii, cum ar fi Autenticitatea, Non-repudierea și
responsabilitatea, devin, de asemenea, considerații cheie pentru instalațiile practice de securitate.
Confidențialitate: Confidențialitatea este termenul folosit pentru a preveni dezvăluirea informațiilor către
persoane sau sisteme neautorizate. De exemplu, o tranzacție cu cardul de credit pe internet necesită ca
numărul cardului de credit să fie transmis de la cumpărător la comerciant și de la comerciant la o rețea
de procesare a tranzacțiilor. Sistemul încearcă să impună confidențialitatea prin criptarea numărului
cardului în timpul transmiterii, prin limitarea locurilor în care acesta poate apărea (în baze de date,
fișiere jurnal, copii de siguranță, chitanțe tipărite și așa mai departe) și prin restricționarea accesului la
locurile în care este stocat. . Dacă o parte neautorizată obține numărul cardului în vreun fel, a avut loc o
încălcare a confidențialității. Încălcările confidențialității iau mai multe forme, cum ar fi Hacking,
Phishing, Vishing, e-mail-spoofing, SMS spoofing și trimiterea de cod rău intenționat prin e-mail sau
prin rețele bot, așa cum sa discutat mai devreme.
Integritate: În securitatea informațiilor, integritatea înseamnă că datele nu pot fi modificate fără

autorizație. Acesta nu este același lucru cu integritatea referențială în bazele de date.
Integritatea este încălcată atunci când un angajat din greșeală sau cu intenție rău intenționată șterge
fișiere de date importante, când este capabil să-și modifice propriul salariu într-o bază de date de
salarizare, când un angajat folosește programe și deduce sume mici de bani din toate conturile clienților
și le adaugă. în contul propriu (numit și tehnica salamului), atunci când un utilizator neautorizat
vandalizează un site web și așa mai departe.
La o scară mai mare, dacă un proces automatizat nu este scris și testat corect, actualizările în bloc ale
unei baze de date ar putea modifica datele într-un mod incorect, lăsând compromisă integritatea datelor.
Profesioniștii în securitatea informațiilor au sarcina de a găsi modalități de implementare a controalelor
care previn erorile de integritate.
Disponibilitate: Pentru ca orice sistem informatic să-și servească scopul, informațiile trebuie să fie
disponibile atunci când sunt necesare. Aceasta înseamnă că sistemele de calcul utilizate pentru stocarea
și procesarea informațiilor, controalele de securitate utilizate pentru a le proteja și canalele de
comunicație folosite pentru a le accesa trebuie să funcționeze corect. Sistemele de înaltă disponibilitate
urmăresc să rămână disponibile în orice moment, prevenind întreruperile serviciului cauzate de
întreruperile de curent, defecțiunile hardware și upgrade-urile sistemului. Asigurarea disponibilității
implică, de asemenea, prevenirea atacurilor de tip denial-of-service (DoS) și a atacurilor distribuite de
denial-of-service (DDoS).
Autenticitate: în domeniul computerelor, al afacerilor electronice și al securității informațiilor, este

necesar să se asigure că datele, tranzacțiile, comunicările sau documentele (electronice sau fizice) sunt
autentice. De asemenea, este important pentru autenticitate să se valideze că ambele părți implicate sunt
cine pretind că sunt.
Nerepudierea : În drept, non-repudierea implică intenția cuiva de a-și îndeplini obligațiile în baza unui
contract/tranzacție. De asemenea, implică faptul că o parte la o tranzacție nu poate nega că a primit sau a
trimis o înregistrare electronică. Comerțul electronic folosește tehnologii precum semnăturile digitale și
criptarea pentru a stabili autenticitatea și non-repudierea.
În plus față de cele de mai sus, există și alte concepte și principii legate de securitate atunci când
proiectați o politică de securitate și implementați o soluție de securitate. Acestea includ identificarea,
autorizarea, responsabilitatea și auditul.
Identificare: Identificarea este procesul prin care un subiect își declară o identitate și este inițiată
responsabilitatea. Un subiect trebuie să ofere o identitate unui sistem pentru a începe procesul de
autentificare, autorizare și responsabilitate. Furnizarea unei identități poate fi tastarea unui nume de
utilizator, glisarea unui card inteligent, fluturarea unui dispozitiv de proximitate, rostirea unei fraze sau
poziționarea feței, a mâinii sau a degetului pentru o cameră sau un dispozitiv de scanare. Dovada unui
număr ID de proces reprezintă, de asemenea, procesul de identificare. Fără identitate, un sistem nu are
nicio modalitate de a corela un factor de autentificare cu subiectul.
Autorizare: Odată ce un subiect este autentificat, accesul trebuie să fie autorizat. Procesul de autorizare
asigură că activitatea solicitată sau accesul la un obiect este posibil având în vedere drepturile și
privilegiile atribuite identității autentificate. În cele mai multe cazuri, sistemul evaluează o matrice de
control al accesului care compară subiectul, obiectul și activitatea intenționată. Dacă acțiunea specifică
este permisă, subiectul este autorizat. În rest, subiectul nu este autorizat.
Responsabilitate și auditare: Politica de securitate a unei organizații poate fi aplicată în mod

corespunzător numai dacă este menținută responsabilitatea, adică securitatea poate fi menținută numai
dacă subiecții sunt trași la răspundere pentru acțiunile lor. Responsabilitatea eficientă se bazează pe
capacitatea de a dovedi identitatea unui subiect și de a urmări activitățile acestuia. Responsabilitatea este
stabilită prin legarea unui om de activitățile unei identități online prin intermediul
servicii de securitate și mecanisme de auditare, autorizare, autentificare și identificare. Astfel,

responsabilitatea umană depinde în cele din urmă de puterea procesului de autentificare. Fără un proces
de autentificare destul de puternic, există îndoială că persoana corectă asociată cu un anumit cont de
utilizator a fost entitatea reală care controla acel cont de utilizator atunci când a avut loc o acțiune
nedorită.
Guvernanța securității informațiilor
Guvernanța securității informațiilor constă în conducerea, structurile organizaționale și procesele care protejează
informațiile și atenuează amenințările crescânde la securitatea informațiilor, precum cele detaliate mai sus.
Rezultatele critice ale guvernanței securității informațiilor includ:
Alinierea securității informațiilor cu strategia de afaceri pentru a sprijini obiectivele organizaționale
Managementul și diminuarea riscurilor și reducerea impactului potențial asupra resurselor

informaționale la un nivel acceptabil
Managementul performanței securității informațiilor prin măsurarea, monitorizarea și raportarea

măsurătorilor de guvernare a securității informațiilor pentru a se asigura că obiectivele organizaționale
sunt atinse Optimizarea investițiilor în securitatea informațiilor în sprijinul obiectivelor organizaționale
Este important să se ia în considerare necesitatea și beneficiile organizaționale ale guvernanței securității

informațiilor. Acestea includ o predictibilitate sporită și reducerea incertitudinii în operațiunile de afaceri, un
nivel de asigurare că deciziile critice nu se bazează pe informații greșite, permițând gestionarea eficientă și
eficientă a riscurilor, protecție împotriva potențialului crescând de răspundere juridică, îmbunătățirea procesului,
pierderi reduse din cauza securității. -evenimentele conexe și prevenirea consecințelor catastrofale și
îmbunătățirea reputației pe piață și în rândul clienților.
Un program cuprinzător de securitate trebuie să includă următoarele activități principale:
Dezvoltarea și întreținerea continuă a politicilor de securitate

Atribuirea rolurilor, responsabilităților și răspunderii pentru securitatea informațiilor
Dezvoltarea/menținerea unui cadru de securitate și control care constă din standarde, măsuri, practici și
proceduri
Clasificarea și atribuirea dreptului de proprietate asupra activelor informaționale
Evaluări periodice ale riscurilor și asigurarea unor controale adecvate, eficiente și testate pentru oameni,
procese și tehnologie pentru a îmbunătăți securitatea informațiilor
Asigurarea securității este parte integrantă a tuturor proceselor organizaționale
Procese de monitorizare a incidentelor de securitate
Procese eficiente de gestionare a identității și a accesului
Generarea de metrici semnificative ale performanței securității
Sesiuni de conștientizare legate de securitatea informațiilor pentru utilizatori/funcționari, inclusiv înalți
oficiali și membri ai consiliului de administrație
Structura organizațională, roluri și responsabilități:
Consilii de administrație/Senior Management
Consiliul de Administrație este responsabil în ultimă instanță pentru securitatea informațiilor. Managementul
superior este responsabil pentru înțelegerea riscurilor pentru bancă pentru a se asigura că acestea sunt abordate în
mod adecvat din perspectiva guvernanței. Pentru a face acest lucru în mod eficient este nevoie de gestionarea
riscurilor, inclusiv a riscurilor de securitate a informațiilor, prin integrarea guvernanței securității informațiilor în
cadrul general de guvernanță al organizației. Se raportează că eficacitatea guvernării securității informațiilor

depinde de implicarea consiliului de administrație/a conducerii superioare în aprobarea politicii și monitorizarea
adecvată a funcției de securitate a informațiilor.
Rolul major al managementului de vârf implică implementarea politicii de securitate a informațiilor aprobate de
Consiliu, stabilirea proceselor organizaționale necesare pentru securitatea informațiilor și furnizarea resurselor
necesare pentru securitatea informațiilor de succes. Este esențial ca managementul superior să stabilească o
așteptare pentru un cibernetic puternic
securitate și să comunice acest lucru oficialilor lor de pe linie. De asemenea, este esențial ca conducerea
organizațională superioară să stabilească o structură pentru implementarea unui program de securitate a
informațiilor care să permită implementarea unui program de securitate a informațiilor consecventă și eficientă,
pe lângă asigurarea răspunderii indivizilor pentru performanța lor în ceea ce privește securitatea cibernetică.
Având în vedere că sistemul bancar de astăzi este dependent în mare măsură de sistemele informatice și deoarece
majoritatea cerințelor de procesare internă ale băncilor sunt electronice, este esențial ca sistemele de securitate
adecvate să fie complet integrate în sistemele informatice ale băncilor. Ar fi optim să le clasificăm pe baza
analizei de risc a diferitelor sisteme din fiecare bancă și trebuie să existe strategii specifice de atenuare a
riscurilor.
Echipa/funcția de securitate a informațiilor
Băncile ar trebui să formeze o funcție/grup separat de securitate a informațiilor care să se concentreze exclusiv pe
managementul securității informațiilor. Ar trebui să existe o separare a atribuțiilor Ofițerului/Grupului de
securitate care se ocupă exclusiv de securitatea sistemelor informatice și Divizia de Tehnologia Informației care
implementează efectiv sistemele informatice. Organizarea funcției de securitate a informațiilor ar trebui să fie
proporțională cu natura și dimensiunea activităților unei bănci, inclusiv o varietate de sisteme bancare electronice
și canale de livrare ale unei bănci. Funcția de securitate a informațiilor ar trebui să dispună de resurse adecvate în
ceea ce privește numărul de personal, nivelul de competențe și instrumente sau tehnici precum evaluarea
riscurilor, arhitectura de securitate, evaluarea vulnerabilității, evaluarea criminalistică etc. În timp ce
grupul/funcția de securitate a informațiilor în sine și structurile legate de guvernanța securității informațiilor nu ar
trebui să fie externalizate, componentele operaționale specifice legate de securitatea informațiilor pot fi
externalizate, dacă resursele necesare nu sunt disponibile în cadrul unei bănci. Cu toate acestea, controlul și
responsabilitatea finală revin băncii.
Comitetul de securitate a informațiilor
Deoarece securitatea informațiilor afectează toate aspectele unei organizații, pentru a lua în considerare
securitatea informațiilor dintr-o perspectivă la nivelul întregii bănci, ar trebui format un comitet director de
directori cu termeni de referință formali. Ofițerul șef pentru securitatea informațiilor ar fi secretarul membru al
Comitetului. Comitetul poate include, printre alții, directorul executiv (CEO) sau persoana desemnată, directorul
financiar (CFO), directorii unității de afaceri, directorul de informații (CIO)/ șef IT, șefii de resurse umane,
juridic, managementul riscurilor, audit , operațiuni și relații publice.
Un comitet de conducere servește ca un canal de comunicare eficient pentru scopurile și direcțiile

managementului și oferă o bază continuă pentru asigurarea alinierii programului de securitate cu obiectivele
organizaționale. De asemenea, este esențială în realizarea schimbării comportamentului către o cultură care
promovează bunele practici de securitate și respectarea politicilor.
Responsabilitățile majore ale Comitetului de securitate a informațiilor, printre altele, includ:
Dezvoltarea și facilitarea implementării politicilor, standardelor și procedurilor de securitate a

informațiilor pentru a se asigura că toate riscurile identificate sunt gestionate în cadrul apetitului pentru
risc al unei bănci
Aprobarea și monitorizarea proiectelor majore de securitate a informațiilor și a stadiului planurilor și

bugetelor de securitate a informațiilor, stabilirea priorităților, aprobarea standardelor și procedurilor
Sprijinirea dezvoltării și implementării unui program de management al securității informațiilor la

nivelul întregii bănci
Revizuirea situației incidentelor de securitate și a diferitelor evaluări și activități de monitorizare a
securității informațiilor în cadrul băncii

Revizuirea stării programelor de conștientizare a securității

Evaluarea noilor evoluții sau probleme legate de securitatea informațiilor
Raportarea Consiliului de Administrație asupra activităților de securitate a informațiilor
Procesele-verbale ale reuniunilor comitetului de conducere ar trebui să fie păstrate pentru a documenta activitățile
și deciziile comitetului, iar o revizuire a securității informațiilor trebuie transmisă consiliului trimestrial.
Chief Information Security Officer (CISO)
Un funcționar de nivel suficient de înalt, de rang de GM/DGM/AGA, ar trebui desemnat ca informații șef
Ofițer de securitate, responsabil cu articularea și aplicarea politicilor pe care băncile le folosesc pentru a-și proteja
activele informaționale, în afară de coordonarea aspectelor legate de securitate/implementarea în cadrul
organizației, precum și a agențiilor externe relevante. CISO trebuie să raporteze direct șefului de management al
riscurilor și nu ar trebui să aibă o relație de raportare directă cu CIO. Cu toate acestea, CISO poate avea o relație
de lucru cu CIO pentru a dezvolta raportul necesar pentru a înțelege infrastructura și operațiunile IT, pentru a
construiți o securitate eficientă în IT în întreaga bancă, în acord cu cerințele și obiectivele de
afaceri.
Componentele critice ale securității informațiilor:
Politici și proceduri:
Băncile trebuie să elaboreze Politica de securitate a informațiilor

aprobată de Consiliu și să identifice și să implementeze măsuri/practici adecvate de management al
securității informațiilor, ținând cont de nevoile lor de afaceri. Politicile trebuie susținute cu standarde,
orientări și proceduri relevante. Un cadru de politică ar include, printre altele,/lua în considerare
următoarele:
O strategie de securitate a informațiilor care este aliniată cu obiectivele de afaceri și cerințele

legale
Obiective, domeniu de aplicare, proprietate și responsabilitate pentru politică
Structura organizatorică a securității informațiilor
Rolurile și responsabilitățile în materie de securitate a informațiilor care pot include informații
roluri specifice securității, cum ar fi manager/ofițer de securitate IT, administratori, specialiști
în securitatea informațiilor și roluri specifice activelor informaționale, cum ar fi proprietari,
custozi, utilizatori finali
- - Revizuiri periodice ale politicii – cel puțin o dată pe an și în cazul unor modificări
semnificative care necesită revizuire
- - O revizuire periodică de conformitate a politicii – despre aderarea utilizatorilor la politicile de

securitate a informațiilor și supusă comitetului de securitate a informațiilor.
- - Excepții: o politică de excepție pentru gestionarea cazurilor de nerespectare a politicii de
securitate a informațiilor, inclusiv aspecte critice, cum ar fi criteriile de excepție, inclusiv dacă
există o nevoie reală de excepții, gestionarea jurnalului sau a registrului de excepții, autoritatea
de a acorda derogări, expirarea excepțiilor și periodicitatea revizuirii excepțiilor acordate. În
cazul în care se acordă scutiri, băncile trebuie să revizuiască și să evalueze caracterul adecvat al
controalelor compensatorii inițial și în mod continuu. Trebuie să se obțină o aprobare de la
CISO cu privire la excepții
Măsuri penale pentru încălcarea politicilor și procesul care trebuie urmat în caz de încălcare
Identificarea, autorizarea și acordarea accesului la activele IT (de către persoane fizice și alte
active IT)
Abordarea diferitelor etape ale vieții unui activ IT pentru a se asigura că cerințele de securitate
a informațiilor sunt luate în considerare în fiecare etapă a ciclului de viață
Un proces de monitorizare și management al incidentelor pentru a aborda identificarea și
clasificarea incidentelor, raportarea, escaladarea, păstrarea probelor, procesul de investigare
Managementul soluțiilor tehnologice pentru securitatea informațiilor, cum ar fi un firewall, software

antivirus/anti-malware, sisteme de detectare/prevenire a intruziunilor, sisteme criptografice și
instrumente/tehnici de monitorizare/analiza jurnalelor
Managementul și monitorizarea furnizorilor de servicii care prevede supravegherea gestionării riscurilor
de securitate a informațiilor de către terți
Indicarea clară a utilizării acceptabile a activelor IT, inclusiv a sistemelor de aplicații care definesc
responsabilitățile de securitate a informațiilor ale utilizatorilor (personal, furnizori de servicii și clienți) în
ceea ce privește utilizarea activelor IT
Cerințe referitoare la recrutarea și selecția personalului calificat și a contractorilor externi care definesc
cadrul de verificare și monitorizare a personalului, ținând cont de riscul de securitate a informațiilor
Strategie de formare periodică și perfecționare a competențelor personalului de securitate a informațiilor,

cerință de formare profesională continuă
Politicile specifice care ar fi necesare includ, dar fără a se limita la, următoarele:
Control logic al accesului
Gestionarea activelor
Control acces la rețea
Gestionarea parolelor
Securitatea e-mailului
Acces de la distanță
Calculul mobil
Securitatea retelei
Securitatea aplicației
Backup și arhivare
Securitatea sistemului de operare
Administrarea și securitatea bazelor de date
Siguranță fizică
Managementul Capacității
Răspunsul și gestionarea incidentelor
Software rău intenționat
managementul activelor IT/media
Managementul schimbării
Gestionarea patch-urilor
Securitatea internetului
Desktop
Criptare
Securitatea canalelor electronice de livrare
Securitate wireless
Migrarea aplicației/datelor
Responsabilitatea pentru securitate este sporită prin fișe clare de post, contracte de muncă și recunoașteri de
conștientizare a politicilor. Este important să se comunice rolurile și responsabilitățile generale și specifice de
securitate pentru toți angajații în cadrul fișelor de post. Fișele postului pentru personalul de securitate ar trebui, de
asemenea, să descrie în mod clar sistemele și procesele pe care le vor proteja și responsabilitatea lor față de
procesele de control. Conducerea trebuie să se aștepte ca toți angajații, ofițerii și contractorii/consultanții să
respecte politicile de securitate și utilizare acceptabilă și să protejeze activele instituției, inclusiv informațiile.
Având în vedere rolul critic al tehnologiilor de securitate ca parte a cadrului de securitate a informațiilor, băncile
trebuie să le supună unor controale adecvate de-a lungul ciclului lor de viață, cum ar fi orientări privind utilizarea
lor, standarde și proceduri care indică obiectivele și cerințele detaliate ale soluțiilor tehnologice specifice pentru
securitatea informațiilor individuale, autorizare pentru persoanele care vor manipula tehnologia, abordarea
problemelor de segregare a sarcinilor, configurațiile adecvate ale dispozitivelor care oferă cea mai bună securitate
posibilă, evaluarea periodică a eficacității acestora și ajustarea lor în consecință și identificarea oricăror modificări
neautorizate.
Dovezile digitale sunt similare cu orice altă formă de dovadă legală - trebuie să facă față provocărilor aduse
integrității sale, manipularea lor trebuie urmărită și documentată cu atenție și trebuie să fie autentificată
corespunzător.
de către personalul în cauză conform cerințelor legale. Deoarece dovezile rezidă pe sau sunt generate de un
dispozitiv digital, un oficial calificat în domeniul securității informațiilor sau un examinator calificat în
criminalistică digitală poate fi necesar să fie implicat în procesul de manipulare pentru a se asigura că orice fapte
materiale sunt păstrate și introduse în mod corespunzător. Trebuie să existe o politică adecvată în acest sens.
Evaluare a riscurilor
Probabilitatea ca o amenințare să folosească o vulnerabilitate pentru a provoca un rău creează un risc. Când o amenințare
folosește o vulnerabilitate pentru a provoca un rău, are un impact. În contextul securității informațiilor, impactul este o
pierdere a disponibilității, integrității și confidențialității și, eventual, alte pierderi (venituri pierdute, pierderi de vieți
omenești, pierderi de proprietate).
Evaluarea riscurilor este competența de bază a managementului securității informațiilor. Evaluarea riscului trebuie să
identifice, pentru fiecare activ din domeniul său de aplicare, combinațiile de amenințare/vulnerabilitate care au
probabilitatea de a afecta confidențialitatea, disponibilitatea sau integritatea activului respectiv - din punct de vedere al
afacerii, conformității sau contractuale. Standarde precum ISO27001 și ISO 27002 sunt explicite în ceea ce privește
solicitarea unei evaluări a riscurilor înainte de selectarea și implementarea oricăror controale și sunt la fel de explicite că
selectarea fiecărui control trebuie să fie justificată de o evaluare a riscurilor.
În termeni largi, procesul de management al riscului constă în:
Identificarea activelor si estimarea valorii acestora. Unele aspecte care trebuie incluse sunt oamenii, clădirile, hardware-
ul, software-ul, datele (electronic, tipărit) și consumabile
Efectuarea unei evaluări a amenințărilor care poate include aspecte precum acte în natură, acte de război, accidente, acte
rău intenționate care provin din interiorul sau din exteriorul organizației
Efectuarea unei evaluări a vulnerabilității pentru fiecare vulnerabilitate și calcularea probabilității ca aceasta să fie
exploatată. Evaluarea politicilor, procedurilor, standardelor, instruirii, securității fizice, controlului calității și
securității tehnice în acest sens
Calcularea impactului pe care fiecare amenințare l-ar avea asupra fiecărui activ prin analiză calitativă sau cantitativă
Identificarea, selectarea și implementarea controalelor adecvate. Oferirea de răspuns proporțional, inclusiv considerații
precum productivitatea, rentabilitatea și valoarea activului
Evaluarea eficacității măsurilor de control. Asigurarea că controalele oferă protecția necesară și rentabilă.
Procesul de management al riscului este un proces iterativ continuu. Mediul de afaceri este în continuă schimbare și noi
amenințări și vulnerabilități apar în fiecare zi. Alegerea contramăsurilor sau a controalelor utilizate pentru gestionarea
riscurilor trebuie să atingă un echilibru între productivitate, rentabilitatea contramăsurilor și valoare.
a activului informaţional care este protejat. Evaluarea riscurilor ar trebui să fie efectuată de o echipă de oameni care au
cunoștințe despre domenii specifice ale afacerii. Evaluarea poate utiliza o analiză calitativă subiectivă bazată pe o opinie
informată sau, acolo unde sunt disponibile cifre fiabile și informații istorice, o analiză cantitativă.
Metodele cantitative presupun atribuirea unor măsurători numerice care pot fi introduse în analiză pentru a determina
riscurile totale și reziduale. Diferitele aspecte care sunt considerate parte a măsurătorilor includ costurile pentru
protejarea informațiilor și a sistemelor informaționale, valoarea respectivelor informații și a acelor sisteme, frecvența și
probabilitatea amenințărilor și eficacitatea controalelor. Un neajuns al metodelor cantitative este lipsa de date fiabile și
predictive privind frecvența și probabilitatea amenințărilor. Acest neajuns este în general abordat prin atribuirea de
valori numerice bazate pe judecăți calitative.
Analiza calitativă implică utilizarea scenariilor și încercările de a determina gravitatea amenințărilor și eficacitatea
controalelor. Analiza calitativă este prin definiție subiectivă, bazându-se pe judecată, cunoștințe, experiență anterioară și
informații din industrie. Tehnicile calitative pot include expuneri, sondaje/chestionare, interviuri și grupuri de lucru
specifice pentru a obține informații despre diferitele scenarii.
Inventar și clasificare a informațiilor/datelor
Controlul eficient necesită un inventar detaliat al activelor informaționale. O astfel de listă este primul pas în clasificarea
activelor și determinarea nivelului de protecție care trebuie asigurat fiecărui bun.
Registrul de inventar al fiecărui activ de informații ar trebui să includă cel puțin:
O identificare clară și distinctă a activului
Valoarea sa relativă pentru organizație

Locația sa
Clasificarea sa de securitate/risc
Grupul său de active (unde activul face parte dintr-un sistem informațional mai mare)
Proprietarul său
Custodele său desemnat
Activele informaționale au grade diferite de sensibilitate și criticitate în îndeplinirea obiectivelor de afaceri. Prin atribuirea
unor clase sau niveluri de sensibilitate și criticitate resurselor informaționale și stabilirea unor reguli/cerințe de securitate
specifice pentru fiecare clasă, este posibil să se definească nivelul de control al accesului care ar trebui aplicat fiecărui activ
de informații. Clasificarea informațiilor reduce riscul și costul supraprotejării sau subprotejării resurselor informaționale în
alinierea securității cu obiectivele de afaceri, deoarece ajută la construirea și menținerea unei perspective consecvente și
uniforme a cerințelor de securitate pentru activele informaționale în întreaga organizație. Standardele ISO 27001 cer
inventarierea activelor informaționale și clasificarea, manipularea și etichetarea informațiilor în conformitate cu liniile
directoare prestabilite.
Definirea rolurilor și responsabilităților
Toate responsabilitățile și responsabilitățile definite și documentate trebuie stabilite și comunicate întregului personal și
conducerii relevante. Unele dintre cele majore includ:
Proprietarul informațiilor
Acesta este un director de afaceri sau un manager de afaceri care este responsabil pentru activele de informații comerciale
ale unei bănci.
Responsabilitățile ar include, dar nu se vor limita la:
Atribuirea clasificării inițiale a informațiilor și revizuirea periodică a clasificării pentru a se asigura că încă
îndeplinește nevoile afacerii
Asigurarea că controalele de securitate sunt în vigoare proporționale cu clasificarea
Revizuirea și asigurarea actualității drepturilor de acces asociate activelor de informații pe care le dețin
Determinarea cerințelor de securitate, a criteriilor de acces și a cerințelor de backup pentru activele de

informații pe care le dețin
Depozitarul informațiilor
Depozitul de informații, de obicei un oficial al sistemelor informatice, este delegatul proprietarului de informații cu
responsabilitățile principale pentru a se ocupa de copierea de rezervă și de recuperare a informațiilor de afaceri.
Responsabilitățile includ, dar nu se limitează la, următoarele:
Efectuarea backup-urilor conform cerințelor de backup stabilite de proprietarul informațiilor
Când este necesar, restaurarea informațiilor pierdute sau corupte de pe mediul de rezervă pentru a readuce aplicația
la starea de producție
Asigurarea că cerințele de păstrare a înregistrărilor sunt îndeplinite pe baza cerințelor proprietarului informațiilor
Proprietarul aplicației
Proprietarul aplicației este managerul liniei de afaceri care este pe deplin responsabil pentru îndeplinirea funcției de afaceri
deservite de aplicație. Responsabilitățile, printre altele, includ:
Stabilirea criteriilor de acces al utilizatorilor, cerințelor de disponibilitate și pistelor de audit pentru aplicațiile lor
Asigurarea controalelor de securitate asociate cu aplicația sunt proporționale cu suportul pentru cel mai înalt nivel
de clasificare a informațiilor utilizat de aplicație
Efectuarea sau delegarea următoarelor - administrarea zilnică a securității, aprobarea cererilor de acces cu excepții,
acțiuni adecvate privind încălcările de securitate atunci când sunt notificate de către administrația de securitate,
revizuirea și aprobarea tuturor modificărilor aduse aplicației înainte de a fi plasate în mediul de producție și
verificarea monedei drepturilor de acces ale utilizatorilor la aplicație
Manager de utilizatori
Managerul de utilizator este managerul sau supervizorul imediat al unui angajat sau al oficialului de resurse umane al
funcției de afaceri în care lucrează un angajat. El are responsabilitatea supremă pentru toate ID-urile de utilizator și activele
de informații deținute de angajații băncii. În cazul persoanelor fizice non-angajate precum antreprenori, consultanți etc.,
acest manager este responsabil de activitatea și de activele bancare utilizate de aceste persoane. El/ea este de obicei
managerul responsabil pentru angajarea contractantului extern. Responsabilitățile includ următoarele:
- ‫ۯ‬-Ɩ--- Informarea administrației de securitate a încetării oricărui angajat, astfel încât ID-ul utilizatorului
deținut de acea persoană poate fi revocat, suspendat sau făcut inaccesibil în timp util
- ‫ۯ‬-Ɩ--- Informarea administrației de securitate cu privire la transferul oricărui angajat dacă transferul implică
modificarea drepturilor de acces sau privilegiilor
- ‫ۯ‬-Ɩ--- Raportarea oricărui incident de securitate sau incident suspectat către funcția de securitate a
informațiilor
- ‫ۯ‬-Ɩ--- Asigurarea faptului că angajații sunt la curent cu politicile, procedurile și standardele relevante de
securitate
față de care sunt răspunzători
Administrator de securitate
Administratorii de securitate au competențele de a seta controale de securitate la nivel de sistem sau de a administra ID-uri
de utilizator și drepturi de acces la resursele de informații. Acești administratori de securitate raportează de obicei la funcția
de securitate a informațiilor. Responsabilitățile includ următoarele:
Înțelegerea diferitelor medii de date și impactul acordării accesului la acestea
Asigurarea că solicitările de acces sunt în concordanță cu instrucțiunile de informare și liniile directoare de securitate
Administrarea drepturilor de acces conform criteriilor stabilite de către Deținătorii de informații
Crearea și eliminarea ID-urilor de utilizator conform instrucțiunilor managerului de utilizatori
Administrarea sistemului în sfera de aplicare a fișei postului și a responsabilităților funcționale
Distribuirea și urmărirea rapoartelor de încălcare a securității
Utilizator final
Utilizatorii finali ar fi orice angajați, contractori sau vânzători ai băncii care utilizează resursele sistemelor informatice ca
parte a muncii lor. Responsabilitățile includ:
Menținerea confidențialității parolelor de conectare

Asigurarea securității informațiilor încredințate în grija acestora
Utilizarea activelor comerciale ale băncilor și a resurselor de informații numai în scopuri aprobate de conducere
Respectarea tuturor politicilor, procedurilor, standardelor și liniilor directoare de securitate a informațiilor

Raportarea promptă a incidentelor de securitate către conducere.
Controlul accesului
Un proces eficient de acces la activele informaționale este una dintre cerințele critice ale securității informațiilor.
Sabotajul intern, spionajul clandestin sau atacurile furtive ale angajaților, contractorilor și vânzătorilor de încredere
sunt printre cele mai grave riscuri potențiale cu care se confruntă o bancă. Angajații actuali și trecuti, contractorii,
vânzătorii și cei care au o cunoaștere intimă a funcționării interioare a sistemelor, operațiunilor și controalelor
interne ale băncii au un avantaj semnificativ față de atacatorii externi. Un atac de succes ar putea pune în pericol
încrederea clienților în sistemele și procesele de control intern ale unei bănci.
Prin urmare, accesul la activele informaționale trebuie să fie autorizat de către o bancă numai acolo unde există o
nevoie comercială valabilă și numai pentru perioada de timp specifică în care este necesar accesul. Diferiții factori
care trebuie luați în considerare atunci când se autorizează accesul la utilizatori și la activele informaționale, printre
altele, includ rolul de afaceri, locația fizică, metoda de conectivitate, accesul de la distanță, timpul, starea anti-
malware și actualizarea corecțiilor, natura dispozitivului utilizat și software/sistem de operare.
Furnizarea accesului implică diferite etape, cum ar fi identificarea și autentificarea, care implică determinarea
persoanei sau a activului IT care solicită acces și confirmarea identității pretinse și a autorizației. Aceasta implică o
evaluare a dacă accesul la un activ de informații este permis prin cerere sau pe baza nevoilor afacerii și a nivelului
de securitate a informațiilor cerut. Aceste procese sunt aplicabile atât utilizatorilor, cât și activelor IT.
O bancă ar trebui să ia măsurile adecvate pentru a identifica și a autentifica utilizatorii sau activele IT. Puterea
necesară a autentificării trebuie să fie proporțională cu riscul. Tehnicile obișnuite pentru creșterea capacității de
identificare și autentificare includ utilizarea unor tehnici de parole puternice (adică lungime crescută, complexitate,
limitări de reutilizare și frecvența modificărilor) și creșterea numărului și/sau tipului de factori de autentificare
utilizați.
Exemplele în care poate fi necesară o putere de autentificare crescută, având în vedere riscurile implicate, includ:
administrarea sau alt acces privilegiat la activele IT sensibile sau critice, accesul de la distanță prin rețele publice la
activele sensibile și activitățile care prezintă un risc mai mare, cum ar fi transferurile de fonduri către terți etc.
Perioada pentru care autentificarea este valabilă ar trebui să fie proporțională cu riscul.
Printre controalele importante pe care băncile trebuie să le ia în considerare se numără:
Un proces sistematic de aplicare și autorizare a creării de ID-uri de utilizator și a matricei de control al
accesului
Efectuarea unei evaluări a riscurilor și acordarea drepturilor de acces pe baza acesteia. De exemplu,
contractorii și personalul temporar ar avea riscuri inerente mai mari
Implementarea politicilor de control al accesului bazate pe roluri menite să asigure o segregare

eficientă a sarcinilor
Modificarea numelor de utilizator și/sau parolelor implicite ale sistemelor și interzicerea partajării ID-
urilor și parolelor de utilizator, inclusiv conturile generice
Modificarea drepturilor de acces ori de câte ori are loc o schimbare a rolului sau a responsabilității și
eliminarea drepturilor de acces la încetarea raporturilor de muncă
Procese de notificare în timp util a funcției de securitate a informațiilor cu privire la adăugările,
ștergerile și schimbările de rol ale utilizatorilor
Reconcilierea periodică a ID-urilor de utilizator într-un sistem și a utilizatorilor efectivi care trebuie să
aibă acces și ștergerea ID-urilor inutile, dacă există
Auditul înregistrării și monitorizarea accesului la activele IT de către toți utilizatorii

Evaluări regulate ale accesului utilizatorilor de către proprietarii de active de informații pentru a se
asigura că accesul adecvat este menținut
Aplicarea principiului celor patru ochi la activele IT foarte critice/sensibile Luarea în considerare
dezactivarea ID-urilor de utilizator ale utilizatorilor aplicațiilor critice care se află în concediu prelungit
(vii) Băncile pot lua în considerare utilizarea soluțiilor automate pentru a permite controlul eficient al accesului și
gestionarea ID-urilor utilizatorilor. Astfel de soluții ar trebui, de asemenea, gestionate eficient pentru a asigura o
gestionare robustă a accesului.
În scopuri de responsabilitate, o bancă ar trebui să se asigure că utilizatorii și activele IT sunt identificate în mod
unic și că acțiunile lor sunt auditabile.
Procesele și sistemele de tranzacție ar trebui să fie concepute astfel încât să se asigure că niciun angajat/furnizor de
servicii externalizat nu poate intra, autoriza și finaliza o tranzacție.
Trebuie menținută segregarea între cei care inițiază datele statice (inclusiv conținutul paginii web) și cei
responsabili cu verificarea integrității acestora. Mai mult, ar trebui menținută segregarea între cei care dezvoltă și
cei care administrează sistemele de e-banking.
Sistemele de e-banking ar trebui testate pentru a se asigura că segregarea sarcinilor nu poate fi ocolită.
Poate fi luat în considerare sistemul de autentificare reciprocă. Autentificarea reciprocă, numită și autentificare în
două sensuri, este o caracteristică de securitate în care un proces client trebuie să-și dovedească identitatea unui
server, iar serverul trebuie să își dovedească identitatea clientului, înainte ca orice trafic de aplicație să fie trimis prin
client-la- conexiune la server. Identitatea poate fi dovedită printr-o terță parte de încredere și utilizarea secretelor
partajate sau prin mijloace criptografice, ca în cazul unei infrastructuri cu chei publice. De exemplu, cu autentificarea
reciprocă implementată, o conexiune poate avea loc numai atunci când clientul are încredere în certificatul digital al
serverului și serverul are încredere în certificatul clientului. Schimbul de certificate se va face prin protocoale
speciale precum protocolul Transport Layer Security (TLS). Acest proces reduce riscul ca un utilizator nebănuit de
rețea să dezvăluie din neatenție informații de securitate pe un site web rău intenționat sau nesigur.
Administratorii de sistem, ofițerii de securitate, programatorii și personalul care efectuează operațiuni critice au în
mod invariabil capacitatea de a provoca daune grave sistemelor bancare pe care le întrețin sau le operează în virtutea
funcțiilor lor de muncă și a accesului privilegiat. Personalul cu drepturi ridicate de acces la sistem ar trebui să fie
supravegheat îndeaproape, cu toate activitățile lor de sistem înregistrate, deoarece au cunoștințe interne și resurse
pentru a eluda controalele sistemelor și procedurile de securitate. Unele dintre practicile de control și securitate
enumerate mai jos trebuie luate în considerare:
Implementarea autentificării cu doi factori pentru utilizatorii privilegiați

Instituirea unor controale puternice asupra accesului de la distanță de către utilizatorii privilegiați
Restricționarea numărului de utilizatori privilegiați
Acordarea accesului privilegiat în funcție de „necesitate” sau „necesitate de făcut” Menținerea

înregistrării de audit a activităților de sistem efectuate de utilizatori privilegiați Asigurarea că utilizatorii
privilegiați nu au acces la jurnalele de sistem în care activitățile lor sunt capturate
Efectuarea periodică de audit sau revizuire de management a jurnalelor Interzicerea partajării ID-urilor
privilegiate și a codurilor lor de acces Interzicerea vânzătorilor și contractorilor să obțină acces privilegiat
la sisteme fără supraveghere și monitorizare atentă
Protejarea datelor de rezervă împotriva accesului neautorizat.
Securitatea informațiilor și ciclul de viață al activelor informaționale
Securitatea informațiilor trebuie să fie luată în considerare în toate etapele ciclului de viață al unui activ informațional,
cum ar fi planificarea, proiectarea, achiziția și implementarea, întreținerea și eliminarea. Băncile trebuie să aplice
tehnici sistematice orientate spre managementul proiectelor pentru a gestiona schimbările materiale în timpul
acestor etape și pentru a se asigura că cerințele de securitate a informațiilor au fost abordate în mod adecvat.
Trebuie să existe controale la nivel de planificare și proiectare pentru a se asigura că securitatea informațiilor este
încorporată în arhitectura generală a sistemelor informatice și că soluțiile implementate sunt în conformitate cu
politicile și cerințele de securitate a informațiilor ale unei bănci.
Ar fi necesare suport continuu și controale de întreținere pentru a se asigura că activele IT continuă să îndeplinească
obiectivele de afaceri. Controalele majore în acest sens includ controale de management al schimbărilor pentru a se
asigura că obiectivele de afaceri continuă să fie îndeplinite după schimbare; controale de management al
configurației pentru a se asigura că configurația minimizează vulnerabilitățile și este definită, evaluată, întreținută
și gestionată; controale de implementare și de mediu pentru a se asigura că mediile de dezvoltare, testare și
producție sunt separate în mod corespunzător; și controale de gestionare a corecțiilor pentru a gestiona evaluarea și
aplicarea patch-urilor la software care abordează vulnerabilitățile cunoscute în timp util
Celelalte controale relevante includ managementul nivelului de servicii, managementul furnizorilor, managementul
capacității și managementul configurației, care sunt descrise în capitolele următoare. Trebuie utilizate controalele de
dezafectare și distrugere pentru a se asigura că securitatea informațiilor nu este compromisă pe măsură ce activele IT
ajung la sfârșitul duratei de viață utilă. (de exemplu, prin strategii de arhivare și ștergerea informațiilor sensibile
înainte de eliminarea activelor IT.)
Securitatea personalului
Proprietarii de aplicații acordă utilizatorilor legitimi acces la sistemele care sunt necesare pentru îndeplinirea sarcinilor
lor, iar personalul de securitate aplică drepturile de acces în conformitate cu standardele instituției. Datorită
nivelurilor lor de acces intern și cunoștințelor intime despre procesele instituțiilor financiare, utilizatorii autorizați
reprezintă o potențială amenințare pentru sisteme și date. De asemenea, angajații, contractanții sau angajații terți își
pot exploata accesul legitim la computer din motive răuvoitoare sau frauduloase. Mai mult, gradul de acces intern
acordat unor utilizatori poate crește riscul de deteriorare accidentală sau pierdere de informații și sisteme.
Expunerile la risc din partea utilizatorilor interni includ modificarea datelor, ștergerea datelor de producție și de rezervă,
întreruperea/distrugerea sistemelor, utilizarea abuzivă a sistemelor pentru câștig personal sau pentru a deteriora
instituția, ținerea ostatică a datelor și furtul datelor strategice sau ale clienților pentru scheme de spionaj sau fraudă.
Băncile ar trebui să aibă un proces pentru a verifica informațiile despre cererea de angajare pentru toți angajații noi.
Verificări suplimentare de antecedente și de credit pot fi garantate în funcție de sensibilitatea unui anumit loc de
muncă sau a unui anumit nivel de acces. Personalul cu acces privilegiat, cum ar fi administratorii, personalul de
securitate cibernetică etc., ar trebui să fie supus unor verificări și verificări riguroase ale antecedentelor. Instituțiile ar
trebui să verifice dacă contractanții sunt supuși unor proceduri similare de verificare. Considerentele de verificare ar
include:
Referințe de caracter – de afaceri și personale

Confirmarea experienței anterioare, a dosarului academic și a calificărilor profesionale
Confirmarea identității printr-un act de identitate emis de guvern
De asemenea, trebuie să existe o rotație periodică a sarcinilor între utilizatori sau personal, ca măsură prudentă de
risc.
Siguranță fizică
Confidențialitatea, integritatea și disponibilitatea informațiilor pot fi afectate prin accesul fizic și deteriorarea sau
distrugerea componentelor fizice. Conceptual, aceste riscuri de securitate fizică sunt atenuate prin implementări
orientate pe zonă. Zonele sunt zone fizice cu cerințe de securitate fizică diferite. Cerințele de securitate ale fiecărei
zone sunt în funcție de sensibilitatea datelor conținute sau accesibile prin zonă și a componentelor de tehnologie a
informației din zonă.
Cerințele pentru fiecare zonă ar trebui determinate prin evaluarea riscurilor. Evaluarea riscurilor ar trebui să includă,
dar fără a se limita la, amenințări cum ar fi prăbușirea aeronavei, efecte chimice, praf, interferență cu alimentarea
electrică, radiații electromagnetice, explozivi, incendiu, fum, furt/distrugere, vibrații/cutremur, apă, criminali,
terorism, politici probleme (de exemplu, greve, întreruperi) și alte amenințări bazate pe locația geografică unică a
entității, configurația clădirii, mediul/entitățile învecinate etc.
O bancă trebuie să implementeze următoarele controale de mediu:
Locația sigură a activelor critice care oferă protecție împotriva amenințărilor naturale și provocate de om
Restricționați accesul la zone sensibile, cum ar fi centrele de date, care include și proceduri detaliate pentru
gestionarea accesului de către personal, furnizori terți și vizitatori
Mecanisme de prevenire adecvate pentru diversele amenințări indicate mai sus
Mecanisme de monitorizare pentru detectarea compromisurilor controalelor de mediu referitoare la temperatură,
apă, fum, alarme de acces, alerte de disponibilitate a serviciilor (alimentare, telecomunicații, servere), revizuiri jurnal
de acces etc.
Instruirea și conștientizarea utilizatorilor
Este recunoscut faptul că veriga umană este cea mai slabă verigă din lanțul de securitate a informațiilor. Prin urmare, există
o nevoie vitală pentru un program de formare inițială și continuă și de conștientizare a securității informațiilor. Programul
poate fi actualizat periodic ținând cont de schimbările în securitatea informațiilor, amenințări/vulnerabilități și/sau cadrul de
securitate a informațiilor al băncii. Trebuie să existe un mecanism de urmărire a eficacității programelor de formare printr-
un proces de evaluare/testare conceput pentru testarea înțelegerii politicilor relevante de securitate a informațiilor, nu doar
inițial, ci și periodic. În orice moment, o bancă trebuie să mențină un statut actualizat cu privire la instruirea și
conștientizarea utilizatorilor în ceea ce privește securitatea informațiilor, iar chestiunea trebuie să fie un punct important de
pe ordinea de zi în timpul reuniunilor Comitetului de securitate a informațiilor.
Unele dintre domeniile care ar putea fi încorporate ca parte a programului de conștientizare a utilizatorilor includ:
Politici/proceduri relevante de securitate a informațiilor
Utilizarea acceptabilă și adecvată a activelor IT

Controale de acces, inclusiv standarde referitoare la parole și alte cerințe de autentificare
Măsuri referitoare la utilizarea corectă a e-mailului și a internetului

Protecție fizică
Calcularea de la distanță și utilizarea dispozitivelor mobile
Manipularea în siguranță a datelor/informațiilor sensibile
Fiind precaut față de ingineria socială încearcă să se despartă de detaliile confidențiale
Raportarea promptă a oricăror incidente și preocupări de securitate
Managementul incidentelor este definit ca procesul de dezvoltare și menținere a capacității de a gestiona

incidentele în cadrul unei bănci, astfel încât expunerea să fie limitată și recuperarea realizată într-un obiectiv de
timp specificat. Incidentele pot include utilizarea greșită a activelor de calcul, dezvăluirea de informații sau
evenimente care amenință continuarea proceselor de afaceri.
Activitățile majore care trebuie luate în considerare ca parte a cadrului de management al incidentelor includ:
Dezvoltarea și implementarea proceselor pentru prevenirea, detectarea, analiza și răspunsul la incidentele

de securitate a informațiilor
Stabilirea proceselor de escaladare și comunicare și linii de autoritate
Dezvoltarea de planuri pentru a răspunde și a documenta incidentele de securitate a informațiilor
Stabilirea capacității de investigare a incidentelor de securitate a informațiilor prin diverse moduri, cum ar
fi criminalistica, colectarea și conservarea dovezilor, analiza jurnalelor, interviurile etc.
Dezvoltarea unui proces de comunicare cu părțile interne și organizațiile externe (de exemplu, autorități
de reglementare, mass-media, forțele de ordine, clienți)
Integrarea planurilor de răspuns la incidente de securitate a informațiilor cu planul de recuperare în caz de
dezastru și de continuitate a afacerii al organizației
Organizarea, instruirea și echiparea echipelor pentru a răspunde incidentelor de securitate a informațiilor
Testarea și rafinarea periodică a planurilor de răspuns la incidente de securitate a informațiilor

Efectuarea de analize și revizuiri post-mortem pentru a identifica cauzele incidentelor de securitate a
informațiilor, dezvoltarea acțiunilor corective și reevaluarea riscului și ajustarea adecvată a controalelor
pentru a reduce riscurile aferente în viitor
Tipurile obișnuite de incidente includ, dar fără a se limita la, întreruperi/degradarea serviciilor din cauza
problemelor hardware, software sau de capacitate, acces neautorizat la sisteme, furt de identitate, scurgere/pierdere
de date, software și hardware rău intenționat, procese de backup eșuate, atacuri de refuzare a serviciului și
probleme de integritate a datelor.
O bancă trebuie să aibă strategii clare de responsabilitate și comunicare pentru a limita impactul incidentelor
de securitate a informațiilor prin mecanisme definite de escaladare și raportare către consiliu și conducerea
superioară și comunicarea cu clienții, după caz. Strategiile de gestionare a incidentelor ar ajuta, de obicei, la
respectarea cerințelor de reglementare. De asemenea, instituțiile ar trebui să notifice în mod proactiv CERT-
In/IDRBT/RBI cu privire la incidentele de securitate cibernetică.
Toate incidentele de securitate sau încălcările politicilor de securitate trebuie aduse la cunoștința CISO.
Controlul și securitatea aplicațiilor:

Instituțiile financiare au diferite tipuri de aplicații, cum ar fi sistemul bancar de bază, canale de livrare precum
ATM-uri, servicii bancare prin internet, servicii bancare mobile, servicii bancare telefonice, sisteme de operare în
rețea, baze de date, sisteme de management al resurselor întreprinderii (ERP), sisteme de management al relațiilor
cu clienții (CRM) etc. ., toate folosite în diferite scopuri comerciale. Apoi aceste instituții au parteneri, contractori,
consultanți, angajați și angajați temporari. Utilizatorii accesează, de obicei, mai multe tipuri diferite de sisteme pe
parcursul sarcinilor lor zilnice, ceea ce face dificilă și plină de obstacole controlul accesului și asigurarea nivelului
necesar de protecție pe diferite tipuri de date. Această complexitate poate duce la găuri neprevăzute și
neidentificate în protecția întregii infrastructuri, inclusiv controale suprapuse și contradictorii, precum și
nerespectarea politicilor și reglementărilor.
Există probleme bine-cunoscute de securitate a sistemelor informaționale asociate cu aplicațiile software,

indiferent dacă software-ul este dezvoltat intern sau achiziționat dintr-o sursă externă. Atacatorii pot folosi multe
căi diferite prin aplicație pentru a dăuna afacerii. Fiecare dintre aceste căi reprezintă un risc care poate fi sau nu
suficient de grav pentru a merita atenție. Uneori, aceste căi sunt ușor de găsit și exploatat și uneori sunt extrem de
dificile. În mod similar, prejudiciul care este cauzat poate varia de la minor la major. Pentru a determina riscul
pentru sine, o bancă poate evalua probabilitatea asociată cu agentul de amenințare, vectorul de atac și slăbiciunea
securității și o poate combina cu o estimare a impactului tehnic și de afaceri asupra organizației. Împreună, acești
factori determină riscul general.
Următoarele sunt măsurile importante de control al aplicațiilor și de atenuare a riscurilor care trebuie
implementate de bănci:
Fiecare aplicație ar trebui să aibă un proprietar care va fi de obicei funcția de afaceri în cauză care
utilizează aplicația
Unele dintre rolurile proprietarilor de aplicații includ:
Prioritizarea oricăror modificări care trebuie făcute aplicației și autorizarea modificărilor
Decizia privind clasificarea/declasificarea datelor și procedurile de arhivare/eliminare pentru

datele referitoare la o aplicație conform politicilor/cerințelor de reglementare/statutare relevante.
Asigurarea faptului că în aplicație sunt integrate controale adecvate prin implicarea activă în
proiectarea, dezvoltarea, testarea și procesul de schimbare
Asigurarea faptului că aplicația îndeplinește nevoile de afaceri/funcționale ale utilizatorilor

Asigurarea faptului că funcția de securitate a informațiilor a revizuit securitatea aplicației
Luarea deciziilor cu privire la orice aplicații noi care urmează să fie achiziționate/dezvoltate sau
orice aplicații vechi care urmează să fie aruncate
Informarea echipei de securitate a informațiilor cu privire la achiziționarea unei aplicații și
evaluarea aplicației pe baza cerințelor politicii de securitate
Asigurarea că procesul de management al schimbărilor este urmat pentru orice modificare a
aplicației
Asigurarea faptului că noile aplicații care sunt achiziționate/dezvoltate respectă politica de

securitate a informațiilor
Asigurarea că jurnalele sau pistele de audit, după cum este necesar, sunt activate și monitorizate
pentru aplicații
Toate sistemele de aplicații trebuie testate înainte de implementare într-o manieră robustă în
ceea ce privește controalele pentru a se asigura că acestea îndeplinesc politicile/regulile de
afaceri ale băncii și prescripțiile/cerințele de reglementare și legale. În sistem trebuie să fie
integrate controale robuste, iar dependența de orice comenzi manuale trebuie redusă la
minimum. Înainte ca sistemul să fie activ, ar trebui să existe claritate asupra pistelor de audit și
a câmpurilor specifice care trebuie să fie capturate ca parte a pistelor de audit și a unui proces
de monitorizare a pistei de audit sau a jurnalelor, inclusiv personalul responsabil pentru acestea.
O bancă trebuie să încorporeze securitatea informațiilor în toate etapele dezvoltării software-

ului. Acest lucru ar ajuta la îmbunătățirea calității software-ului și la minimizarea expunerii la
vulnerabilități. Pe lângă funcționalitățile de afaceri, cerințele de securitate referitoare la
controlul accesului la sistem, autentificarea, autorizarea tranzacțiilor, integritatea datelor,
înregistrarea activității sistemului, pista de audit, urmărirea evenimentelor de securitate și
gestionarea excepțiilor trebuie să fie specificate clar în etapele inițiale ale dezvoltării/achiziției
sistemului. De asemenea, ar fi necesară o verificare a conformității cu standardele de securitate
ale băncii și cu cerințele de reglementare/statutare.
Toate sistemele de aplicații trebuie să aibă trasee de audit împreună cu politica/procedura de

monitorizare a jurnalelor pentru astfel de sisteme, inclusiv alocarea clară a responsabilităților în
acest sens. Fiecare aplicație care afectează informații critice/sensibile, de exemplu, care
afectează aspectele financiare, ale clienților, de control, de reglementare și juridice, trebuie să
ofere piste de audit detaliate/capacitate de înregistrare cu detalii precum id-ul tranzacției, data,
ora, id-ul inițiatorului, id-ul autorizatorului, acțiunile întreprinse de un anumit ID de utilizator
etc. Alte detalii precum înregistrarea adresei IP a computerului client, identitatea terminalului
sau locația pot fi, de asemenea, luate în considerare.
Aplicațiile trebuie, de asemenea, să prevadă, printre altele, înregistrarea încercărilor de

conectare nereușite, accesul la opțiuni sensibile din aplicație, de exemplu, modificări ale
înregistrării principale, acordarea drepturilor de acces, utilizarea utilităților sistemului,
modificări ale configurației sistemului etc.
Traseele de audit trebuie să fie stocate într-o perioadă definită conform oricăror cerințe
interne/de reglementare/statutare și ar trebui să se asigure că nu sunt modificate.
Ar trebui să existe standarde/proceduri documentate pentru administrarea aplicației, care sunt

aprobate de proprietarul aplicației și menținute la zi.
Mediile de dezvoltare, testare și producție trebuie să fie separate în mod corespunzător.
Accesul ar trebui să se bazeze pe principiul cel mai mic privilegiu și „nevoia de a cunoaște”
proporțional cu responsabilitățile postului. Trebuie aplicată o segregare adecvată a sarcinilor.
Ar trebui să existe controale privind actualizarea informațiilor comerciale „statice” cheie, cum
ar fi fișierele principale ale clienților, modificările parametrilor etc.
Orice modificare a unui sistem/date de aplicație trebuie să fie justificată de nevoile reale de
afaceri și de aprobări susținute de documentație și supuse unui proces robust de gestionare a
modificărilor. Managementul schimbării ar presupune generarea unei cereri, evaluarea riscului,
autorizarea de la o autoritate corespunzătoare, implementarea, testarea și verificarea modificării
efectuate.
Ar trebui identificate potențiale deficiențe/încălcări ale securității (de exemplu, ca urmare a

analizei comportamentului utilizatorului sau a modelelor de trafic în rețea).
Ar trebui să existe măsuri pentru a reduce riscul de furt, fraudă, eroare și modificări
neautorizate ale informațiilor prin măsuri precum supravegherea activităților și separarea
sarcinilor.
Aplicațiile nu trebuie să permită ca intrările neautorizate să fie actualizate în baza de date. În
mod similar, aplicațiile nu trebuie să permită nicio modificare după autorizarea unei intrări.
Orice modificări ulterioare trebuie făcute numai prin inversarea intrării originale autorizate și
prin trecerea unei noi înscrieri.
Actualizările directe ale bazei de date nu ar trebui permise decât în timpul exigențelor, cu o
nevoie clară de afaceri și după autorizarea corespunzătoare conform politicii relevante.
Accesul la promptul bazei de date trebuie limitat doar la administratorul bazei de date.
În aplicație trebuie să fie integrate controale robuste de validare a intrărilor, procesare și ieșire.
Ar trebui să existe o procedură pentru a reduce dependența de câțiva indivizi cheie.
Trebuie luate în considerare alertele cu privire la utilizarea aceluiași aparat atât pentru
tranzacțiile producătorului, cât și a celor de verificare.
Ar trebui să existe o legătură adecvată între o solicitare de modificare și acțiunea
corespunzătoare întreprinsă. De exemplu, șeful sau codul contabil specific care a fost creat ca
urmare a unei solicitări specifice ar trebui stabilit în mod clar.
Rapoartele și jurnalele de eroare/excepție trebuie revizuite și orice problemă trebuie

remediată/rezolvată cel mai devreme.
Funcții sau aplicații critice care se ocupă cu financiar, reglementare și juridic, MIS și
evaluarea/managementul riscului, (de exemplu, calculul adecvării capitalului, ALM, calcularea
VaR, active ponderate la risc, clasificarea și provizionarea NPA, compilarea bilanțului,
sistemul AML, reevaluare a soldurilor în valută, calcularea câștigurilor/pierderilor MTM etc.)
trebuie făcută prin sisteme de aplicare adecvate și nu manual sau semi-automatizat prin foi de
calcul. Acestea prezintă riscuri legate de integritatea și fiabilitatea datelor. Utilizarea foilor de
calcul în acest sens ar trebui să fie restricționată și ar trebui înlocuită cu aplicații IT adecvate
într-un interval de timp definit, în mod treptat.
Băncile pot obține declarații de integritate a aplicației în scris de la furnizorii de sisteme de
aplicații, oferind un nivel rezonabil de asigurare cu privire la faptul că aplicația nu conține
programe malware în momentul vânzării, fără erori evidente și fără canale secrete din cod (din
versiunea aplicației în curs de livrare, precum și orice versiuni/modificări ulterioare efectuate).
Pentru toate aplicațiile critice, fie codul sursă trebuie să fie primit de la furnizor, fie un acord de
escrow software cu o terță parte pentru a asigura disponibilitatea codului sursă în cazul în care
vânzătorul iese din activitate. Trebuie să se asigure că actualizările de produse și remedierea
programelor sunt incluse și în acordul de escrow.
Aplicațiile trebuie configurate pentru a deconecta utilizatorii după o anumită perioadă de
inactivitate. Aplicația trebuie să asigure transferul tranzacțiilor incomplete și, altfel, să asigure
integritatea datelor în cazul deconectarii.
Ar trebui să existe controale de interfață adecvate. Transferul de date de la un proces la altul

sau de la o aplicație la alta, în special pentru sistemele critice, nu ar trebui să aibă nicio
intervenție manuală pentru a preveni orice modificare neautorizată. Procesul trebuie să fie
automatizat și integrat corespunzător cu mecanismul de autentificare și traseele de audit,
permițând „Procesarea directă” între aplicații sau din surse de date pentru a înlocui orice
intervenție manuală/procese semi-automatizate, cum ar fi extragerea datelor din fișiere text și
încărcarea către țintă. sistem, importul într-o foaie de calcul etc. În plus, trebuie efectuate
validări adecvate și reconcilierea datelor între interfețele/aplicațiile relevante din cadrul băncii.
Banca trebuie să integreze în mod adecvat sistemele și aplicațiile, după cum este necesar,
pentru a îmbunătăți integritatea și fiabilitatea datelor.
Arhitectura aplicațiilor cu mai multe niveluri trebuie luată în considerare pentru sistemele
critice relevante, cum ar fi sistemele de internet banking, care diferențiază controlul sesiunii,
logica de prezentare, validarea de intrare pe partea serverului, logica de afaceri și accesul la

baza de date.
În cazul în care datele referitoare la operațiunile din India sunt stocate și/sau procesate în
străinătate, de exemplu, de către bănci străine, trebuie să existe controale adecvate, cum ar fi
segregarea datelor și controale stricte de acces bazate pe „nevoia de a cunoaște” și controale
robuste ale schimbării. Banca ar trebui să fie în măsură să demonstreze în mod adecvat același
lucru autorității de reglementare. Accesul autorităților de reglementare la astfel de
date/înregistrări și alte informații relevante nu ar trebui să fie împiedicat în niciun fel, iar RBI
ar avea dreptul de a determina efectuarea unei inspecții a centrului de procesare/centrul de date
și a registrelor și a conturilor acestuia de către unul sau mai mulți dintre funcționarii săi. sau
angajați sau alte persoane.
O examinare/testare a securității aplicației, inițial și în timpul schimbărilor majore, trebuie

efectuată folosind o combinație de revizuire a codului sursă, încărcare la stres, testare a
excepțiilor și revizuire a conformității pentru a identifica tehnicile de codare nesigure și
vulnerabilitățile sistemelor într-o măsură rezonabilă.

Jurnalele critice ale sistemului de aplicații/pistele de audit trebuie, de asemenea, să fie copiate
de rezervă ca parte a politicii de backup a aplicației.
Testarea robustă a securității sistemului, în ceea ce privește sistemele e-banking critice, trebuie
să încorporeze, printre altele, specificații referitoare la scurgerea de informații, logica de
afaceri, autentificarea, autorizarea, validarea datelor de intrare, gestionarea excepțiilor/erorile,
gestionarea sesiunii, criptografia și detaliile logare, după caz. Acestea trebuie efectuate cel puțin
anual.
Controale de migrare:
Trebuie să existe o politică de migrare documentată, care să indice cerința unei foi de parcurs / plan de
migrare / metodologie pentru migrarea datelor (care include verificarea completității, consecvenței și
integrității activității de migrare și a activităților pre și post migrare, împreună cu responsabilitățile și
termenele de finalizare). de aceeași). Trebuie obținute aprobări explicite de la utilizatori/proprietari de
aplicații după fiecare etapă de migrare și după procesul de migrare complet. Traseele de audit trebuie să
fie disponibile pentru a documenta conversia, inclusiv mapările și transformările datelor.
Aspectele cheie care trebuie luate în considerare includ:
A. Integritatea datelor – indicând faptul că datele nu sunt modificate manual sau electronic de către
o persoană, program, înlocuire sau suprascriere în noul sistem. Integritatea, prin urmare, include
variația erorilor din cauza unor factori precum transpunerea, transcripția etc.
Completitudine - asigurarea faptului că numărul total de înregistrări din baza de date sursă este
transferat în noua bază de date (presupunând că numărul de câmpuri este același)
Confidențialitatea datelor în curs de conversie — asigurarea faptului că datele sunt copiate de
rezervă înainte de migrare pentru referințe viitoare sau orice urgență care ar putea apărea în
urma procesului de migrare a datelor
Consecvența datelor — câmpul/înregistrarea solicitată din noua cerere ar trebui să fie în

concordanță cu cea din cererea inițială. Acest lucru ar trebui să permită consecvența în
repetabilitatea exercițiului de testare
Continuitate — noua aplicație ar trebui să poată continua cu înregistrări mai noi ca adiție (sau
anexă) și să ajute la asigurarea continuității afacerii fără întreruperi
Este o bună practică ca ultima copie a datelor înainte de conversia de pe vechea platformă și prima copie
a datelor după conversia pe noua platformă să fie păstrate separat în arhivă pentru orice referință viitoare.
Jurnalele de erori referitoare la perioada pre-migrare/migrare/post-migrare, împreună cu analiza cauzei

principale și acțiunile întreprinse, trebuie să fie disponibile pentru revizuire.
Băncile ar putea avea nevoie să migreze datele complete ale tranzacțiilor și traseele de audit de la
sistemul vechi la noul sistem. În caz contrar, băncile ar trebui să aibă capacitatea de a accesa datele
tranzacționale mai vechi și de a pune cap la cap traseul tranzacțiilor dintre sistemele mai vechi și cele
mai noi, pentru a satisface orice cerințe de supraveghere/legale care pot apărea.
Implementarea noilor tehnologii:
Băncile trebuie să efectueze diligența necesară cu privire la noile tehnologii, deoarece pot introduce
expuneri suplimentare la riscuri. O bancă trebuie să autorizeze utilizarea și desfășurarea pe scară largă în
mediul de producție a tehnologiilor care au ajuns la o stare în care există un set general agreat de
controale acceptate de industrie și s-au efectuat diligență și teste solide pentru a determina problemele de
securitate ale tehnologia sau în cazul în care controalele compensatorii sunt suficiente pentru a preveni
un impact semnificativ și pentru a respecta apetitul pentru risc și așteptările de reglementare ale
instituției.
Orice produse comerciale noi introduse împreună cu sistemele informaționale subiacente trebuie
evaluate ca parte a unui proces formal de aprobare a produsului care încorporează, printre altele, aspecte
legate de securitate și îndeplinirea prescripțiilor legale și de reglementare relevante. O bancă trebuie să
dezvolte un proces de autorizare care să implice o evaluare a riscului care să echilibreze beneficiile noii
tehnologii cu riscul.
Criptare
Tipuri de criptare:
Criptarea simetrică este utilizarea aceleiași chei și algoritm de către creatorul și cititorul unui fișier sau mesaj.
Creatorul folosește cheia și algoritmul pentru a cripta, iar cititorul le folosește pe ambele pentru a decripta.
Criptarea simetrică se bazează pe secretul cheii. Dacă cheia este capturată de către un atacator, fie atunci când
este schimbată între părțile care comunică, fie în timp ce una dintre părți folosește sau stochează cheia, atacatorul
poate folosi cheia și algoritmul pentru a decripta mesajele sau pentru a se preface ca creator de mesaje. .
Criptarea asimetrică reduce riscul expunerii cheilor prin utilizarea a două chei legate matematic, cheia privată și
cheia publică. Când o cheie este folosită pentru a cripta, numai cealaltă cheie poate decripta. Prin urmare, o
singură cheie (cheia privată) trebuie păstrată secretă. Cheia care este schimbată (cheia publică) nu prezintă niciun
risc dacă devine cunoscută. De exemplu, dacă individul A are o cheie privată și publică cheia publică, individul B
poate obține cheia publică, poate cripta un mesaj individului A și îl poate trimite. Atâta timp cât o persoană își
păstrează cheia privată în siguranță împotriva dezvăluirii, numai persoana A va putea decripta mesajul.
Zonele sau situațiile tipice care necesită implementarea tehnicilor criptografice, având în vedere riscurile
implicate, includ transmiterea și stocarea de date/informații critice și/sau sensibile într-un mediu
„neîncrezător” sau în care este necesar un grad mai ridicat de securitate, generarea de coduri PIN pentru
clienți care sunt utilizate de obicei pentru tranzacțiile cu cardul și serviciile online, detectarea oricărei
modificări neautorizate a datelor/informațiilor și verificarea autenticității tranzacțiilor sau a
datelor/informațiilor.
Deoarece securitatea se bazează în primul rând pe cheile de criptare, gestionarea eficientă a cheilor este
crucială. Sistemele eficiente de management al cheilor se bazează pe un set agreat de standarde,
proceduri și metode sigure care se adresează
Generarea de chei pentru diferite sisteme criptografice și diferite aplicații

Generarea și obținerea cheilor publice și distribuirea cheilor către utilizatorii vizați, inclusiv modul
în care cheile ar trebui să fie activate la primire
Stocarea cheilor, inclusiv modul în care utilizatorii autorizați obțin acces la chei și modificarea sau
actualizarea cheilor, inclusiv regulile privind când trebuie schimbate cheile și cum se va face acest
lucru
Gestionarea cheilor compromise, revocarea cheilor și specificarea modului în care cheile ar trebui
retrase sau dezactivate
Recuperarea cheilor pierdute sau corupte ca parte a managementului continuității afacerii
Arhivarea, distrugerea cheilor
Înregistrarea auditului activităților cheie legate de management
Instituirea unor date de activare și dezactivare definite, limitând perioada de utilizare a cheilor
Sistemele securizate de management al cheilor se caracterizează prin următoarele măsuri de precauție:
Protecție fizică suplimentară a echipamentelor utilizate pentru generarea, stocarea și arhivarea

cheilor criptografice
Utilizarea tehnicilor criptografice pentru a menține confidențialitatea cheilor criptografice
Segregarea sarcinilor, fără ca nicio persoană să aibă cunoștințe despre întreaga cheie criptografică
(adică controale pentru două persoane) sau să aibă acces la toate componentele care alcătuiesc
aceste chei
Asigurarea managementului cheii este complet automatizat (de exemplu, personalul nu are
posibilitatea de a expune o cheie sau de a influența crearea cheii)
Asigurarea că nicio cheie nu apare vreodată necriptată
Asigurați-vă că cheile sunt alese aleatoriu din întreg spațiul de chei, de preferință de hardware
Asigurarea că cheile de criptare a cheilor sunt separate de cheile de date. Nicio dată nu apare nicio
dată în text clar care a fost criptat folosind o cheie de criptare a cheii. (O cheie de criptare a cheilor
este folosită pentru a cripta alte chei, asigurându-le împotriva dezvăluirii.)
Asigurați-vă că cheile cu durată lungă de viață sunt puțin utilizate. Cu cât o cheie este folosită mai
mult, cu atât mai mare este oportunitatea pentru un atacator de a descoperi cheia
Asigurați-vă că cheile sunt schimbate frecvent.

Asigurarea că cheile care sunt transmise sunt trimise în siguranță către părți bine autentificate.
Asigurarea că echipamentul generator de chei este securizat din punct de vedere fizic și logic de la
construcție până la primire, instalare, exploatare și scoatere din serviciu.
În mod normal, este de așteptat un minim de criptare SSL de 128 de biți. Progresele constante în
hardware-ul computerelor, criptoanaliza și tehnicile distribuite de forță brută pot induce utilizarea
periodică a cheilor de lungimi mai mari. Este de așteptat ca băncile să evalueze în mod corespunzător
cerințele de securitate asociate cu sistemele lor bancare prin internet și cu alte sisteme relevante și să
adopte o soluție de criptare proporțională cu gradul de confidențialitate și integritate necesar. Băncile ar
trebui să selecteze doar algoritmi de criptare care sunt standarde internaționale bine stabilite și care au
fost supuși unui control riguros de către o comunitate internațională de criptografi sau aprobați de
organisme profesionale autorizate, furnizori de securitate reputați sau agenții guvernamentale.
Securitatea datelor
Băncile trebuie să definească și să implementeze proceduri pentru a asigura integritatea și coerența tuturor
datelor stocate în formă electronică, cum ar fi bazele de date, depozitele de date și arhivele de date.
O teorie a securității datelor urmărește să stabilească cerințe uniforme bazate pe risc pentru protecția
elementelor de date. Pentru a se asigura că protecția este uniformă în interiorul și în afara instituției, pot fi
utilizate instrumente precum clasificările datelor și profilurile de protecție, așa cum sa indicat mai devreme
în capitol.
Clasificarea datelor și profilurile de protecție sunt complexe de implementat atunci când rețeaua sau
stocarea este văzută ca o utilitate. Din cauza acestei complexități, unele instituții tratează toate informațiile
la acel nivel ca și cum ar fi de cea mai mare sensibilitate și implementează criptarea ca măsură de protecție.
Complexitatea implementării clasificării datelor în alte straturi sau în alte aspecte ale operațiunii unei
instituții poate duce la utilizarea altor proceduri de diminuare a riscurilor. Adecvarea este o funcție a
gradului de atenuare a riscului și nu a procedurii sau instrumentului utilizat pentru atenuarea riscului.
Politicile privind manipularea, eliminarea și tranzitul media ar trebui implementate pentru a permite
utilizarea profilurilor de protecție și pentru a reduce în alt mod riscurile pentru date. Dacă nu sunt utilizate
profiluri de protecție, politicile ar trebui să atingă același scop ca și profilurile de protecție, care este acela
de a furniza același grad de risc rezidual, indiferent dacă informațiile sunt în tranzit sau stocate, cine
controlează direct datele sau unde depozitarea poate fi.
Ar trebui să existe o stocare sigură a media. Controalele ar putea include controale fizice și de mediu, cum
ar fi protecția împotriva incendiilor și inundațiilor, limitarea accesului prin mijloace precum încuietori
fizice, tastatură, parole, elemente biometrice etc., etichetare și acces înregistrat. Conducerea ar trebui să
stabilească controale de acces pentru a limita accesul la media, asigurându-se în același timp că toți
angajații au autorizația de a accesa datele minime necesare pentru a-și îndeplini responsabilitățile.
Informațiile mai sensibile, cum ar fi documentația de sistem, codul sursă al aplicației și datele tranzacțiilor
de producție ar trebui să aibă controale mai extinse pentru a se proteja împotriva modificărilor (de exemplu,
verificări de integritate, hashuri criptografice). În plus, politicile ar trebui să reducă la minimum distribuirea
informațiilor sensibile, inclusiv a tipăririlor care conțin informațiile. Periodic, personalul de securitate,
personalul de audit și proprietarii de date ar trebui să revizuiască nivelurile de autorizare și listele de
distribuție pentru a se asigura că rămân adecvate și actuale.
Stocarea datelor în dispozitive portabile, cum ar fi laptop-uri și PDA-uri, pune probleme unice. Atenuarea
acestor riscuri implică de obicei criptarea datelor sensibile, controale de acces furnizate de gazdă etc.
Băncile au nevoie de proceduri adecvate de eliminare atât pentru mediile electronice, cât și pe hârtie.
Contractele cu firme terțe de eliminare ar trebui să abordeze proceduri acceptabile de eliminare. Pentru
mediile de computer, datele rămân frecvent pe suport după ștergere. Deoarece aceste date pot fi recuperate,
tehnici suplimentare de eliminare ar trebui aplicate datelor sensibile, cum ar fi distrugerea fizică,
suprascrierea datelor, demagnetizarea etc.
Băncile ar trebui să mențină securitatea mass-media în timpul tranzitului sau atunci când sunt partajate cu
terți. Politicile ar trebui să includă cerințe contractuale care să includă controalele necesare bazate pe
riscuri, restricții privind transportatorii utilizați și proceduri de verificare a identității curierilor.
Băncile ar trebui să cripteze conturile clienților și datele tranzacțiilor care sunt transmise, transportate,
livrate sau trimise prin curier către părți externe sau alte locații, ținând cont de toate joncturile intermediare
și punctele de tranzit de la sursă la destinație.
Alte câteva aspecte care trebuie luate în considerare includ blocarea adecvată, filtrarea și monitorizarea
mecanismelor electronice, cum ar fi e-mailul și imprimarea și monitorizarea software-ului și hardware-ului
neautorizat, cum ar fi software-ul de spargere a parolelor, înregistrările de chei, punctele de acces wireless
etc.
Preocupările cu privire la necesitatea de a controla și proteja mai bine informațiile sensibile au dat naștere
unui nou set de soluții care vizează creșterea capacității unei întreprinderi de a-și proteja activele
informaționale. Aceste soluții variază în ceea ce privește capacitățile și metodologiile lor, dar, în mod
colectiv, au fost plasate într-o categorie cunoscută sub numele de prevenirea scurgerilor de date (DLP).
Acesta oferă o abordare cuprinzătoare care acoperă oamenii, procesele și sistemele care identifică,
monitorizează și protejează datele în uz (de exemplu, acțiuni la punctul final), datele în mișcare (de
exemplu, acțiunile de rețea) și datele în repaus (de exemplu, stocarea datelor) prin inspecție profundă a
conținutului și cu un cadru de management centralizat.
Majoritatea soluțiilor DLP includ o suită de tehnologii care facilitează trei obiective cheie:
Localizați și catalogați informațiile sensibile stocate în întreaga întreprindere
Monitorizați și controlați mișcarea informațiilor sensibile în rețelele întreprinderii
Monitorizează și controlează mișcarea informațiilor sensibile pe sistemele utilizatorilor finali Băncile

pot lua în considerare astfel de soluții, dacă este necesar, după ce le evaluează potențialul de a îmbunătăți
securitatea datelor.
Evaluarea vulnerabilității
La scurt timp după ce noi vulnerabilități sunt descoperite și raportate de către cercetătorii sau vânzătorii de
securitate, atacatorii proiectează codul de exploatare rău intenționat și apoi lansează acel cod împotriva
țintelor de interes. Orice întârziere semnificativă în găsirea sau remedierea software-ului cu vulnerabilități
critice oferă o oportunitate ample pentru atacatorii persistenti de a pătrunde, obținerea controlului asupra
mașinilor vulnerabile și accesul la datele sensibile pe care le conțin. Băncile care nu scanează pentru
vulnerabilități și nu abordează defectele descoperite în mod proactiv se confruntă cu o probabilitate
semnificativă de a avea sistemele lor computerizate compromise.
Următoarele sunt câteva dintre măsurile propuse:
Instrumentele automate de scanare a vulnerabilităților trebuie utilizate împotriva tuturor
sistemelor din rețelele lor în mod periodic, să zicem lunar sau săptămânal sau mai frecvent.
Băncile ar trebui să se asigure că scanarea vulnerabilităților este efectuată într-un mod
autentificat (adică, configurarea scanerului cu acreditările de administrator) cel puțin
trimestrial, fie cu agenți care rulează local pe fiecare sistem final pentru a analiza configurația
de securitate, fie cu scanere la distanță cărora li se acordă drepturi administrative pe sistemul
testat, pentru a depăși limitările scanării vulnerabilităților neautentificate.
Băncile ar trebui să compare rezultatele scanărilor back-to-back ale vulnerabilităților pentru a
verifica dacă vulnerabilitățile au fost abordate fie prin corecție, implementarea unui control
compensator, fie prin documentarea și acceptarea unui risc rezonabil de afaceri. O astfel de
acceptare a riscurilor de afaceri pentru vulnerabilitățile existente ar trebui să fie revizuită
periodic pentru a determina dacă controalele compensatorii mai noi sau patch-urile ulterioare
pot aborda vulnerabilitățile care au fost acceptate anterior sau dacă condițiile s-au schimbat
crescând riscul.
Instrumentele de scanare a vulnerabilităților ar trebui să fie reglate pentru a compara serviciile

care ascultă pe fiecare mașină cu o listă de servicii autorizate. Instrumentele ar trebui ajustate în
continuare pentru a identifica schimbările în timp asupra sistemelor atât pentru serviciile
autorizate, cât și pentru cele neautorizate.
Funcția de securitate ar trebui să aibă o stare actualizată cu privire la numărul de vulnerabilități
critice neatenuate, pentru fiecare departament/diviziune, să planifice pentru atenuare și ar trebui

să partajeze rapoarte de vulnerabilitate care indică probleme critice cu conducerea superioară
pentru a oferi stimulente eficiente pentru atenuare.
Stabilirea proceselor continue de monitorizare a securității
O bancă trebuie să aibă procese de monitorizare robuste pentru a identifica evenimentele și modelele de
activitate neobișnuite care ar putea avea un impact asupra securității activelor IT. Puterea controalelor de
monitorizare trebuie să fie proporțională cu criticitatea unui activ IT. Alertele ar trebui investigate în timp
util, cu un răspuns adecvat determinat.
Procesele obișnuite de monitorizare includ înregistrarea activității (inclusiv excepții de la activitatea

aprobată), de exemplu, dispozitiv, server, activitate în rețea, alerte de senzori de securitate; monitorizarea
accesului personalului sau terților la date/informații sensibile pentru a se asigura că acestea sunt dintr-un
motiv de afaceri valid, scanarea sistemelor gazdă pentru vulnerabilități cunoscute, verificări pentru a
determina dacă controalele de securitate a informațiilor funcționează conform așteptărilor și sunt în curs de
desfășurare.
respectate, verificarea dacă utilități/comenzi puternice au fost dezactivate pe gazdele atașate prin utilizarea
unor instrumente precum „network sniffer”), profilarea mediului și a clienților, verificarea existenței și
configurarea rețelelor wireless neautorizate prin utilizarea instrumentelor automate, descoperirea existenței
unor rețele neautorizate. sisteme prin utilizarea instrumentelor de descoperire și mapare a rețelei și
detectarea modificărilor neautorizate ale documentelor electronice și fișierelor de configurare prin utilizarea
software-ului de monitorizare a integrității fișierelor.
Rețelele băncilor ar trebui concepute pentru a sprijini o monitorizare eficientă. Considerațiile de proiectare
includ politicile de trafic de rețea care abordează comunicațiile permise între computere sau grupuri de
computere, domeniile de securitate care implementează politicile, plasarea senzorilor pentru a identifica
încălcările politicii și traficul anormal, natura și amploarea înregistrării, stocarea și protecția jurnalelor și
capacitatea de a implementa informații suplimentare. senzori ad-hoc atunci când este necesar.
Băncile ar trebui să stabilească o alocare clară a responsabilităților pentru monitorizarea regulată, iar
procesele și instrumentele în acest sens ar trebui să fie în măsură să gestioneze volumul de monitorizare
necesar, reducând astfel riscul ca un incident să nu fie detectat.
Activele IT foarte sensibile și/sau critice ar trebui să aibă jurnalul activat pentru a înregistra evenimente și
monitorizate la un nivel proporțional cu nivelul de risc.
Utilizatorii, cum ar fi administratorii de sistem, cu privilegii de acces ridicate ar trebui să fie supuși unui
nivel mai mare de monitorizare în lumina riscurilor crescute implicate.
Integritatea jurnalelor și proceselor de monitorizare ar trebui să fie protejată prin controale adecvate de acces
și segregarea sarcinilor.
Băncile ar trebui să examineze frecvent toate conturile de sistem și să dezactiveze orice cont care nu poate fi
asociat cu un proces de afaceri și cu proprietarul afacerii. Rapoartele care pot fi generate de sisteme și
revizuite frecvent pot include, printre altele, o listă de conturi blocate, conturi dezactivate, conturi cu parole
care depășesc vârsta maximă a parolei și conturi cu parole care nu expiră niciodată.
Băncile ar trebui să stabilească și să urmeze un proces de revocare a accesului la sistem prin dezactivarea
conturilor imediat după rezilierea unui angajat sau contractant.
Băncile ar trebui să monitorizeze în mod regulat utilizarea tuturor conturilor, deconectarea automată a
utilizatorilor după o perioadă standard de inactivitate.
Băncile ar trebui să monitorizeze utilizarea contului pentru a determina conturile latente care nu au fost
utilizate pentru o anumită perioadă, să zicem 15 zile, notificând utilizatorul sau managerul utilizatorului cu
privire la inactivitate. După o perioadă mai lungă, să zicem 30 de zile, contul poate fi dezactivat.
În mod periodic, să zicem lunar sau trimestrial, băncile ar trebui să solicite managerilor să coreleze angajații
și contractanții activi cu fiecare cont aparținând personalului lor administrat. Administratorii de
securitate/sistem ar trebui apoi să dezactiveze conturile care nu sunt alocate angajaților sau contractorilor
activi.
Băncile ar trebui să monitorizeze încercările de a accesa conturile dezactivate prin înregistrarea de audit.
Băncile ar trebui să valideze setările jurnalului de audit pentru fiecare dispozitiv hardware și software-ul
instalat pe acesta, asigurându-se că jurnalele includ o dată, marca temporală, adrese sursă, adrese de
destinație și diverse alte elemente utile ale fiecărui pachet și/sau tranzacție. Sistemele ar trebui să
înregistreze jurnalele într-un format standardizat, cum ar fi intrările syslog. Dacă sistemele nu pot genera
jurnale într-un format standardizat, băncile trebuie să implementeze instrumente de normalizare a jurnalelor
pentru a converti jurnalele într-un format standardizat.
Administratorii de sistem și personalul de securitate a informațiilor ar trebui să ia în considerare elaborarea
de profiluri ale evenimentelor obișnuite din sistemele date, astfel încât să poată regla detectarea pentru a se
concentra pe activități neobișnuite, reducând falsele pozitive, identifică mai rapid anomaliile și împiedică
copleșirea analiștilor cu alerte nesemnificative.
Următoarele tehnologii/factori oferă capabilități pentru detectarea și analiza eficientă a atacurilor:
Informații de securitate și management al evenimentelor (SIEM) - produsele SIEM oferă

cunoaștere a situației prin colectarea, agregarea, corelarea și analiza datelor disparate din
diverse surse. Informațiile furnizate de aceste instrumente ajută la înțelegerea sferei unui
incident.
Sistemul de detectare și prevenire a intruziunilor (IDS și IPS) - Produsele IPS care au capacități
de detectare ar trebui să fie utilizate pe deplin în timpul unui incident pentru a limita orice
impact suplimentar asupra organizației. Produsele IDS și IPS sunt adesea sursa principală de
informații care duc la identificarea unui atac. Odată ce atacul a fost identificat, este esențial să
se activeze seturile de reguli IPS adecvate pentru a bloca propagarea ulterioară a incidentelor și
pentru a sprijini izolarea și eradicarea.
Analiza comportamentului rețelei (NBA) - Instrumentele de detectare a anomaliilor la nivelul
rețelei vor furniza date despre tiparele de trafic care indică un incident. Odată ce un incident a
fost identificat prin utilizarea acestor instrumente, este important să captați acele informații în
scopul sprijinirii activităților de atenuare ulterioare, inclusiv a fluxului de lucru operațional,
pentru a vă asigura că informațiile din aceste instrumente sunt direcționate către echipa de
răspuns adecvată.
Furnizor de servicii de securitate gestionate (MSSP) - Dacă o organizație a externalizat
gestionarea evenimentelor de securitate către un MSSP, acesta din urmă ar trebui să furnizeze o
notificare atunci când un incident necesită atenție. Organizația trebuie să obțină cât mai multe
informații cu privire la incident de la MSSP și să implementeze pași de remediere conform
recomandărilor MSSP.
Băncile trebuie, de asemenea, să monitorizeze în mod proactiv diverse surse autentice, cum ar fi CERT-
In, furnizorii de securitate etc., pentru orice sfaturi legate de securitate și să ia măsurile adecvate în
consecință.
Măsuri de securitate împotriva programelor malware:
Software-ul rău intenționat este un aspect integral și periculos al amenințărilor bazate pe internet care
vizează utilizatorii finali și organizațiile prin moduri precum navigarea pe web, atașamentele de e-mail,
dispozitivele mobile și alți vectori. Codul rău intenționat poate modifica conținutul unui sistem și poate
captura date sensibile. Se poate răspândi și în alte sisteme. Programele malware moderne urmăresc să evite
detectarea bazată pe semnături și comportamentale și poate dezactiva instrumentele antivirus care rulează pe
sistemul vizat. Software-ul antivirus și anti-spyware, denumit în mod colectiv instrumente anti-malware,
ajută la apărarea împotriva acestor amenințări încercând să detecteze programele malware și să blocheze
execuția acestora.
Controalele tipice pentru protejarea împotriva codului rău intenționat folosesc combinații stratificate de
tehnologie, politici și proceduri și instruire. Controalele sunt de natură preventivă și detectivă/corectivă.
Controalele sunt aplicate la nivel de gazdă, rețea și utilizator:
La nivel de gazdă : diferitele măsuri la nivel de gazdă includ întărirea gazdei (inclusiv aplicarea de
corecții și configurații de securitate adecvate ale
sistem de operare (OS), browsere și alte programe software conștient de rețea), luând în considerare
implementarea firewall-urilor bazate pe gazdă pe fiecare computer intern și în special laptop-uri alocate
utilizatorilor de telefonie mobilă. Multe firewall-uri bazate pe gazdă au, de asemenea, capacități de
hashing a aplicațiilor, care sunt utile în identificarea aplicațiilor care ar fi putut fi troianizate după
instalarea inițială, luând în considerare IPS gazdă și software-ul de verificare a integrității combinate cu
controale stricte ale modificărilor și gestionarea configurației, auditarea periodică a configurațiilor gazdei,
ambele manuale. și automatizate.
La nivel de rețea : Diferitele măsuri includ limitarea transferului de fișiere executabile prin perimetru,
monitorizarea IDS și IPS a traficului de rețea de intrare și de ieșire, inclusiv antivirus, anti-spyware și
monitoare de trafic bazate pe semnături și anomalii, rutarea listelor de control al accesului (ACL-uri) care
limitează conexiunile de intrare și de ieșire, precum și conexiunile interne la cele necesare în scopuri
comerciale, servere proxy care inspectează pachetele de intrare și de ieșire pentru indicatori de cod rău
intenționat și blochează accesul la serverele de distribuție a malware cunoscute sau suspectate, filtrarea
pentru a proteja împotriva atacurilor cum ar fi cross-site scripting și injecție SQL.
La nivel de utilizator : educația utilizatorului în ceea ce privește conștientizarea, practicile de calcul
sigure, indicatorii codului rău intenționat și acțiunile de răspuns.
Funcțiile administrative de securitate ale întreprinderii pot fi utilizate zilnic pentru a verifica numărul de
sisteme care nu au cele mai recente semnături anti-malware. Toate evenimentele de detectare a malware-ului
trebuie trimise la instrumentele de administrare anti-malware ale întreprinderii și la serverele de jurnal de
evenimente.
Băncile ar trebui să utilizeze software anti-malware și funcții de actualizare automată a semnăturilor pentru a
actualiza automat fișierele de semnătură și motoarele de scanare ori de câte ori furnizorul publică actualizări.
După aplicarea unei actualizări, sistemele automate ar trebui să verifice dacă fiecare sistem a primit
actualizarea semnăturii. Banca ar trebui să monitorizeze jurnalele consolei antivirus pentru a corecta orice
sisteme care nu au reușit să fie actualizate. Sistemele implementate pentru securitatea clienților ar trebui să
ofere o administrare simplificată prin management central și să ofere vizibilitate critică asupra amenințărilor
și vulnerabilităților. De asemenea, ar trebui să se integreze cu software-ul de infrastructură existent, cum ar fi
Active Directory, pentru o protecție sporită și un control mai mare.
Administratorii nu ar trebui să se bazeze exclusiv pe software-ul AV și filtrarea e-mailurilor pentru a detecta

infecțiile cu viermi. Jurnalele de la firewall-uri, senzorii de detectare și prevenire a intruziunilor, serverele
DNS și jurnalele serverului proxy ar trebui monitorizate zilnic pentru semne de infecții cu viermi, inclusiv,
dar fără a se limita la:
Încercările de conexiune SMTP de ieșire de la orice altceva decât gateway-urile de e-mail SMTP
ale unei bănci
Scanare excesivă sau neobișnuită pe porturile TCP și UDP 135-139 și 445

Încercări de conectare la IRC sau orice alte porturi neobișnuite pentru mediu Încercări excesive
din partea sistemelor interne de a accesa site-uri web non-business Trafic excesiv de la un anumit
sau un grup de sisteme interne
Interogări DNS excesive de la sistemele interne către același nume de gazdă și pentru nume de
gazdă cunoscute „inexistente”. Utilizarea unui mijloc centralizat, cum ar fi o gazdă syslog pentru
a colecta jurnalele de pe diferite dispozitive și sisteme, poate ajuta la analiza informațiilor
Băncile ar trebui să configureze laptopurile, stațiile de lucru și serverele astfel încât să nu ruleze automat
conținutul de pe jetoane USB, hard disk-uri USB, CD-uri/DVD-uri, dispozitive SATA externe, partajări de
rețea montate sau alte medii amovibile.
Băncile ar trebui să configureze sistemele astfel încât să efectueze o scanare automată antimalware a
suporturilor amovibile atunci când este introdus.
Băncile pot lua în considerare, de asemenea, implementarea instrumentelor Network Access Control (NAC)
pentru a verifica configurația securității și conformitatea la nivel de corecție a dispozitivelor înainte de a
acorda acces la o rețea. Network Admission Control (NAC) restricționează accesul la rețea pe baza identității
sau poziției de securitate a unei organizații. Când NAC este implementat, va forța un utilizator sau o mașină
care caută acces la rețea pentru autentificare înainte de a acorda accesul real la rețea. O conexiune WiFi
tipică (negratuită) este o formă de NAC. Utilizatorul trebuie să prezinte un fel de acreditări (sau un card de
credit) înainte de a primi acces la rețea. Sistemele de control al admiterii în rețea permit dispozitivelor
neconforme să li se refuze accesul, să fie plasate într-o zonă de carantină sau să li se acorde acces
restricționat la resursele de calcul, împiedicând astfel nodurile nesigure să infecteze rețeaua. Componenta
cheie a programului de control al admiterii în rețea este Agentul de încredere, care rezidă pe un sistem de
puncte terminale și comunică cu routerele din rețea. Informațiile sunt apoi transmise către un server de
control al accesului securizat (ACS) unde sunt luate deciziile de control al accesului. ACS direcționează
ruterul să efectueze aplicarea împotriva punctului final.
Filtrarea atașamentelor de e-mail - Băncile ar trebui să filtreze diferite tipuri de atașamente la poarta de e-
mail, cu excepția cazului în care este necesar pentru o utilizare specifică în afaceri. Câteva exemple
includ .ade .cmd
.eml .ins .mdb .mst .reg .url .wsf .adp .com .exe .isp .mde .pcd .scr .vb .wsh .bas .cpl
.hlp .js .msc .pif .sct .vbe .bat .crt .hta .jse .msi .pl .scx .vbs .chm .dll .inf.lnk .msp .pot
.shs .wsc…etc. Băncile ar trebui să ia în considerare doar permisiunea extensiilor de fișiere cu un caz de
afaceri documentat și filtrarea tuturor celorlalte.
Gestionarea patch-urilor:
Trebuie să existe un proces de gestionare a corecțiilor pentru a aborda vulnerabilitățile tehnice și software-ul
rapid și eficient, pentru a reduce probabilitatea apariției unui impact serios asupra afacerii.
Ar trebui să existe standarde/proceduri documentate pentru gestionarea patch-urilor. Standardele/procedurile

pentru managementul patch-urilor ar trebui să includă o metodă de definire a rolurilor și responsabilităților
pentru gestionarea patch-urilor, determinarea importanței sistemelor (de exemplu, pe baza informațiilor
gestionate, procesele de afaceri suportate și mediile în care sunt utilizate), înregistrarea corecții care au fost
aplicate (de exemplu, folosind un inventar al activelor computerizate, inclusiv nivelul lor de corecție).
Procesul de gestionare a patch-urilor ar trebui să includă aspecte precum:
Determinarea metodelor de obținere și validare a patch-urilor pentru a se asigura că patch-ul
provine dintr-o sursă autorizată
Identificarea vulnerabilităților aplicabile aplicațiilor și sistemelor utilizate de organizație
Evaluarea impactului asupra afacerii implementării patch-urilor (sau neimplementarea unui

anumit patch)
Asigurarea că patch-urile sunt testate
Descrierea metodelor de implementare a patch-urilor, de exemplu, printr-o manieră automată
Raportarea despre starea implementării patch-urilor în întreaga organizație
Inclusiv metode de tratare a implementării eșuate a unui patch (de

exemplu, redistribuirea patch-ului).
Ar trebui stabilite metode pentru a proteja informațiile și sistemele în cazul în care nu există nicio corecție
disponibilă pentru o vulnerabilitate identificată, de exemplu, dezactivarea serviciilor și adăugarea de
controale de acces suplimentare. Organizațiile ar trebui să implementeze instrumente automate de gestionare
a corecțiilor și instrumente de actualizare a software-ului pentru toate sistemele pentru care astfel de
instrumente sunt disponibile. și în siguranță.
Organizațiile ar trebui să măsoare întârzierea corectării noilor vulnerabilități și să se asigure că întârzierea nu
depășește valorile de referință stabilite de organizație, care ar trebui să fie mai puțin pentru corecțiile critice,
să zicem nu mai mult de o săptămână, cu excepția cazului în care este disponibil un control de atenuare care
blochează exploatarea.
Patch-urile critice trebuie evaluate într-un mediu de testare înainte de a fi actualizate în producție pe
sistemele întreprinderii. Dacă astfel de corecții distrug aplicațiile critice de afaceri pe mașinile de testare,
organizația trebuie să elaboreze alte controale de atenuare care să blocheze exploatarea pe sistemele în care
patch-ul este dificil de implementat din cauza impactului său asupra funcționalității afacerii.
Managementul schimbării:
Ar trebui stabilit un proces de management al schimbării, care să acopere toate tipurile de schimbări. De
exemplu, upgrade-uri și modificări ale aplicației și software-ului, modificări ale informațiilor comerciale,
„remedieri” de urgență și modificări ale computerelor/rețelelor care acceptă aplicația.
Procesul de management al schimbărilor ar trebui să fie documentat și să includă aprobarea și testarea
modificărilor pentru a se asigura că acestea nu compromit controalele de securitate, efectuarea modificărilor
și semnarea acestora pentru a se asigura că sunt efectuate corect și în siguranță, revizuirea modificărilor
finalizate pentru a se asigura că nu au fost efectuate modificări neautorizate. făcut.
Următorii pași ar trebui să fie luați înainte de aplicarea modificărilor la mediul live:
Solicitările de modificare ar trebui să fie documentate (de exemplu, pe un formular de cerere de

modificare) și acceptate numai de la persoane autorizate, iar modificările trebuie aprobate de o
autoritate corespunzătoare.
Impactul potențial al schimbărilor asupra afacerii ar trebui evaluat (de exemplu, în ceea ce privește riscul
general și impactul asupra altor componente ale aplicației)
Modificările ar trebui testate pentru a ajuta la determinarea rezultatelor așteptate (de exemplu,
implementarea patch-ului în mediul live)
Modificările trebuie revizuite pentru a se asigura că nu compromit controalele de securitate (de exemplu,
verificând software-ul pentru a se asigura că nu conține cod rău intenționat, cum ar fi un cal troian sau
un virus)
Ar trebui stabilite poziții de retragere, astfel încât aplicația să se poată recupera după modificări eșuate
sau rezultate neașteptate
Modificările aplicației ar trebui să fie efectuate de persoane calificate și competente, capabile să facă
modificări corect și în siguranță și aprobate de un oficial de afaceri corespunzător.
Piste de audit
Băncile trebuie să se asigure că există piste de audit pentru activele IT care îndeplinesc cerințele de afaceri
ale băncilor, inclusiv cerințele de reglementare și legale, facilitând auditul, servind drept dovezi
criminalistice atunci când este necesar și asistând la soluționarea litigiilor. Aceasta ar putea include, după
caz, diverse domenii precum tranzacții cu consecințe financiare, deschiderea, modificarea sau închiderea
conturilor clienților, modificări ale datelor de bază sensibile, accesarea sau copierea datelor/informațiilor
sensibile; și acordarea, modificarea sau revocarea drepturilor sau privilegiilor de acces la sisteme pentru
accesarea activelor IT sensibile.
Părțile de audit ar trebui să fie securizate pentru a asigura integritatea informațiilor capturate, inclusiv
păstrarea dovezilor. Păstrarea pistelor de audit ar trebui să fie în conformitate cu cerințele de afaceri, de
reglementare și legale.
Unele considerații pentru securizarea integrității fișierelor jurnal includ:

Criptarea fișierelor jurnal care conțin date sensibile sau care se transmit prin rețea Asigurarea
unei capacități de stocare adecvate pentru a evita golurile în colectarea datelor
Securizarea copiei de rezervă și eliminarea fișierelor jurnal
Înregistrarea datelor pe medii de numai scriere, cum ar fi un disc sau o unitate de tip WORM
Setarea parametrilor de înregistrare pentru a interzice orice modificare a datelor scrise anterior
După cum sa indicat mai devreme, activitățile de rețea și gazdă sunt în mod obișnuit înregistrate pe gazdă și
trimise prin rețea la o unitate centrală de înregistrare care poate procesa datele de înregistrare într-un format
comun. Procesul, numit normalizare, permite analiza în timp util și eficientă a jurnalelor.
Alte aspecte legate de logare care trebuie luate în considerare includ:

Toate accesul de la distanță la o rețea internă, fie prin VPN, dial-up sau alt mecanism, ar trebui
să fie înregistrate în mod pronunțat
Sistemele de operare ar trebui să fie configurate pentru a înregistra evenimentele de control al

accesului asociate cu un utilizator care încearcă să acceseze o resursă, cum ar fi un fișier sau un
director, fără permisiunile corespunzătoare. Personalul de securitate și/sau administratorii
desemnați în acest sens ar trebui să identifice anomaliile în jurnale și să revizuiască în mod
activ anomaliile, documentând constatările lor în mod continuu
Fiecare bancă poate considera că în rețeaua lor sunt disponibile cel puțin două surse de timp
sincronizate de la care toate serverele și echipamentele de rețea preiau informații de timp în
mod regulat, astfel încât marcajele de timp din jurnale să fie consecvente
Dispozitivele de delimitare a rețelei, inclusiv firewall-uri, IPS-uri bazate pe rețea și proxy-uri de

intrare și de ieșire pot fi configurate pentru a înregistra în mod verbos tot traficul (atât permis,
cât și blocat) care sosește pe dispozitiv
Având în vedere multitudinea de dispozitive și sisteme, băncile ar trebui să ia în considerare implementarea

unui instrument de sistem SIEM (Security Information and Event Management) pentru agregarea și
consolidarea jurnalelor de la mai multe mașini/sisteme și pentru corelarea și analiza jurnalelor, așa cum sa
indicat mai devreme în capitol. În plus, jurnalele de evenimente pot fi corelate cu informațiile din scanările
de vulnerabilități pentru a îndeplini două obiective. În primul rând, personalul ar trebui să verifice dacă
activitatea instrumentelor obișnuite de scanare a vulnerabilităților în sine este înregistrată. Și, în al doilea
rând, personalul ar trebui să poată corela evenimentele de detectare a atacurilor cu rezultatele anterioare ale
scanării vulnerabilităților pentru a determina dacă exploit-ul dat a fost folosit împotriva unei ținte cunoscute
vulnerabile.
Sistemele bancare electronice ar trebui să fie proiectate și instalate pentru a capta și menține probele
criminalistice într-un mod care să mențină controlul asupra probelor și să prevină falsificarea și colectarea
de probe false.
În cazurile în care sistemele de procesare și pistele de audit aferente sunt responsabilitatea unui furnizor de
servicii terț, banca trebuie să se asigure că are acces la pistele de audit relevante întreținute de furnizorul de
servicii, pe lângă faptul că se asigură că pistele de audit întreținute de furnizorul de servicii îndeplinesc
standardele băncii.
Rapoarte și valori de securitate a informațiilor
Aranjamentele de monitorizare a securității ar trebui să ofere factorilor de decizie cheie și conducerii

superioare/Consiliului de administrație o viziune informată asupra aspectelor precum eficacitatea și
eficiența aranjamentelor de securitate a informațiilor, domeniile în care este necesară îmbunătățirea,
informațiile și sistemele care sunt supuse unui nivel inacceptabil de risc. , performanță față de ținte
cantitative, obiective, acțiuni necesare pentru a ajuta la minimizarea riscului (de exemplu, revizuirea
apetitului pentru risc al organizației, înțelegerea mediului de amenințare la securitatea informațiilor și
încurajarea proprietarilor de afaceri și de sisteme să remedieze riscurile inacceptabile).
Ar trebui să existe aranjamente pentru monitorizarea stării de securitate a informațiilor din organizație, care
să fie documentate, convenite cu managementul de vârf și efectuate în mod regulat. Informațiile generate de
monitorizarea stării de securitate a informațiilor din organizație ar trebui utilizate pentru a măsura
eficacitatea strategiei de securitate a informațiilor, a politicii de securitate a informațiilor și a arhitecturii de
securitate.
Analiza efectuată ca parte a aranjamentului de monitorizare și raportare a securității poate include, printre
altele, următoarele:
Detalii referitoare la incidentele de securitate a informațiilor și impactul acestora
Măsuri luate pentru ca astfel de evenimente să nu se repete în viitor
Principalele rezultate ale auditului intern și extern/evaluării vulnerabilității/testelor de penetrare și
starea remedierii
Statistici de securitate operațională, cum ar fi date de jurnal de firewall, detalii de gestionare a
corecțiilor și numărul de e-mailuri spam
Costuri asociate cu pierderi financiare, penalități legale sau de reglementare și profil(uri) de risc
Progrese față de planurile/strategiile de securitate

Analiza capacității și performanței sistemelor de securitate
Analiza infrastructurii și software-ului
Analiza fraudei
Informațiile colectate ca parte a aranjamentelor de raportare de securitate ar trebui să includă detalii despre
toate aspectele riscului informațional, cum ar fi criticitatea informațiilor, vulnerabilitățile identificate și
nivelul amenințărilor, potențialele impacturi asupra afacerii și starea controalelor de securitate în vigoare.
Informațiile despre starea de securitate a organizației ar trebui furnizate factorilor de decizie cheie/părților
interesate, cum ar fi consiliul de administrație, conducerea de vârf, membrii Comitetului pentru securitatea
informațiilor și organismelor externe relevante, cum ar fi autoritățile de reglementare, după caz.
Metricurile pot fi un instrument eficient pentru managerii de securitate pentru a discerne eficacitatea
diferitelor componente ale politicii și programelor lor de securitate, securitatea unui anumit sistem, produs
sau proces, eficacitatea și eficiența furnizării serviciilor de securitate, impactul evenimentelor de securitate
asupra proceselor de afaceri. și capacitatea personalului sau a departamentelor din cadrul unei organizații de
a aborda problemele de securitate pentru care sunt responsabili. În plus, ele pot fi utilizate pentru a crește
nivelul de conștientizare a securității în cadrul organizației. Măsurarea caracteristicilor de securitate poate
permite managementului să mărească controlul și să conducă îmbunătățiri suplimentare ale procedurilor și
proceselor de securitate.
Fiecare dimensiune a cadrului de management al riscului de securitate IT poate fi măsurată prin cel puțin o
măsurătoare pentru a permite monitorizarea progresului către obiectivele stabilite și identificarea
tendințelor. Utilizarea valorilor trebuie orientată către zonele cu cea mai mare criticitate. În general, se
sugerează că valorile eficiente trebuie să urmeze acronimul SMART, adică specifice, măsurabile,
realizabile, repetabile și dependente de timp.
În plus, poate fi conceput un set cuprinzător de indicatori care oferă măsuri prospective și retrospective,
cum ar fi indicatorii cheie de performanță și indicatori cheie de risc.
Eficacitatea unui sistem de metrici de securitate în atenuarea riscului depinde de completitudinea și
acuratețea măsurătorilor și de analiza eficientă a acestora. Măsurătorile ar trebui să fie fiabile și suficiente
pentru a justifica deciziile de securitate care afectează situația de securitate a instituției, să aloce resurse
pentru sarcinile legate de securitate și să ofere o bază pentru rapoartele legate de securitate.
Unele valori ilustrative includ acoperirea software-ului anti-malware și procentul de actualizare a acestora,
latența patch-urilor, gradul de instruire a utilizatorilor, valorile legate de vulnerabilități etc.
Securitatea informațiilor și furnizorii/furnizorii de servicii critice
Băncile folosesc furnizori de servicii terți într-o varietate de capacități diferite. Poate fi un furnizor de
servicii Internet (ISP), un furnizor de aplicații sau servicii gestionate (ASP/MSP) sau un furnizor de servicii
de afaceri (BSP). Acești furnizori pot îndeplini adesea funcții importante pentru bancă și, de obicei, pot
necesita acces la informații confidențiale, aplicații și sisteme.
Atunci când întreprinderile folosesc terți, aceștia pot deveni o componentă cheie în controalele unei
întreprinderi și în atingerea obiectivelor de control aferente. Conducerea trebuie să evalueze rolul pe care
terțul îl îndeplinește în raport cu mediul IT, controalele aferente și obiectivele de control.
Eficacitatea controalelor de la terți poate spori capacitatea unei întreprinderi de a-și atinge obiectivele de
control. În schimb, controalele ineficiente ale terților pot slăbi capacitatea unei bănci de a-și atinge
obiectivele de control. Aceste deficiențe pot apărea din multe surse, inclusiv lacune în mediul de control
care decurg din externalizarea serviciilor către o terță parte, proiectarea defectuoasă a controlului, care
determină operarea ineficientă a controalelor, lipsa de cunoștințe și/sau lipsa de experiență a personalului
responsabil cu funcțiile de control și supra- încrederea pe controalele terței părți (când nu există controale
compensatorii în cadrul întreprinderii).
Furnizorii terți pot afecta o întreprindere (inclusiv partenerii săi), procesele, controalele și obiectivele de
control pe mai multe niveluri diferite. Aceasta include efectele care decurg din lucruri precum viabilitatea
economică a furnizorului terț, furnizorul terț
accesul la informațiile care sunt transmise prin sistemele și aplicațiile lor de comunicare, disponibilitatea
sistemelor și aplicațiilor, integritatea procesării, dezvoltarea aplicațiilor și procesele de management al
schimbărilor și protecția sistemelor și a activelor informaționale prin recuperare de rezervă, planificare de
urgență și redundanță.
Lipsa controalelor și/sau slăbiciunea în proiectarea, funcționarea sau eficacitatea acestora poate duce la
consecințe precum pierderea confidențialității și confidențialității informațiilor, sistemele care nu sunt
disponibile pentru utilizare atunci când este necesar, acces neautorizat și modificări ale sistemelor, aplicațiilor
sau datelor, modificări ale sistemelor. , aplicații sau date care apar care au ca rezultat defecțiuni ale sistemului
sau de securitate, pierderea datelor, pierderea integrității datelor, pierderea protecției datelor sau
indisponibilitatea sistemului, pierderea resurselor sistemului și/sau a activelor de informații și costurile
crescute suportate de întreprindere ca urmare din oricare dintre cele de mai sus.
Relația dintre întreprindere și un furnizor terț ar trebui să fie documentată sub forma unui contract încheiat.
Diferitele detalii și cerințe în materie sunt acoperite în capitolul „Externalizarea IT”.
Securitatea retelei
Protecția împotriva amenințărilor cibernetice în creștere necesită mai multe straturi de apărare, cunoscute sub
numele de apărare în profunzime. Deoarece fiecare organizație este diferită, această strategie ar trebui să se
bazeze pe un echilibru între protecție, capacitate, cost, performanță și considerații operaționale. Apărarea în
profunzime pentru majoritatea organizațiilor ar trebui să ia în considerare cel puțin următoarele două
domenii:
Protejarea limitelor sau perimetrului enclavei
Protejarea mediului de calcul.
Granița enclavei este punctul în care rețeaua organizației interacționează cu Internetul. Pentru a controla
fluxul de trafic prin granițele rețelei și pentru a controla conținutul acesteia în căutarea atacurilor și a
dovezilor de mașini compromise, apărările la frontieră ar trebui să fie multistratificate, bazându-se pe
firewall-uri, proxy-uri, rețele perimetrale DMZ și sisteme de prevenire a intruziunilor și a intruziunilor bazate
pe rețea. Sisteme de detectare.
Trebuie remarcat faptul că liniile de delimitare dintre rețelele interne și externe se diminuează prin
interconectivitate sporită în interiorul și între organizații și utilizarea sistemelor fără fir. Aceste linii estompate
permit uneori atacatorilor să obțină acces în interiorul rețelelor, ocolind sistemele de graniță. Cu toate acestea,
chiar și cu această neclaritate, implementarea eficientă a securității se bazează în continuare pe apărări ale
granițelor atent configurate care separă rețelele cu niveluri diferite de amenințare, seturi diferite de utilizatori
și niveluri diferite de control. Apărarea eficientă pe mai multe straturi a rețelelor perimetrale ajută la scăderea
numărului de atacuri de succes, permițând personalului de securitate să se concentreze asupra atacatorilor
care au conceput metode pentru a ocoli restricțiile la graniță.
O abordare eficientă pentru securizarea unei rețele mari implică împărțirea rețelei în domenii logice de
securitate. Un domeniu de securitate logic este o parte distinctă a unei rețele cu politici de securitate care
diferă de alte domenii și controale de perimetru care impun accesul la nivel de rețea. Diferențele pot fi mult
mai mari decât controalele de rețea, cuprinzând personal, gazdă și alte probleme. Înainte de a stabili domenii
de securitate, băncile trebuie să mapeze și să configureze rețeaua pentru a identifica și controla toate punctele
de acces. Considerentele privind configurarea rețelei ar putea include următoarele acțiuni:
Identificarea diferitelor aplicații și sisteme accesate prin intermediul rețelei
Identificarea tuturor punctelor de acces la rețea, inclusiv diverse canale de telecomunicații, cum ar fi
ethernet, wireless, frame relay, linii dedicate, acces dial-up la distanță, extranet, internet
Maparea conectivității interne și externe între diverse segmente de rețea

Definirea cerințelor minime de acces pentru serviciile de rețea
Determinarea celei mai adecvate configurații de rețea pentru a asigura securitatea și performanța
corespunzătoare pentru bancă
Cu o înțelegere clară a conectivității la rețea, băncile pot evita introducerea unor vulnerabilități de securitate
reducând la minimum accesul la domenii mai puțin de încredere și utilizând criptare și alte controale pentru
conexiuni mai puțin sigure. Băncile pot determina apoi implementarea cea mai eficientă a protocoalelor,
routerelor de filtrare, firewall-urilor, gateway-urilor, serverelor proxy și/sau izolarea fizică pentru a
restricționa accesul. Unele aplicații și procese de afaceri pot necesita segregarea completă de rețeaua
corporativă, de exemplu, împiedicând conectivitatea între rețeaua corporativă și sistemul de transfer prin
cablu. Alții pot restricționa accesul prin plasarea serviciilor care trebuie accesate de fiecare zonă în propriul
domeniu de securitate, numit în mod obișnuit o zonă demilitarizată.
Domeniile de securitate sunt delimitate de perimetre. Controalele tipice de perimetru includ firewall-uri care
funcționează la diferite straturi de rețea, prevenirea codurilor rău intenționate, filtrarea de ieșire,
dispozitivele de detectare și prevenire a intruziunilor și controale asupra serviciilor de infrastructură, cum ar
fi DNS. Controalele perimetrale pot exista pe dispozitive separate sau pot fi combinate sau consolidate pe
unul sau mai multe dispozitive. Consolidarea pe un singur dispozitiv ar putea îmbunătăți securitatea prin
reducerea cheltuielilor administrative. Cu toate acestea, consolidarea poate crește riscul printr-o capacitate
redusă de a îndeplini anumite funcții și existența unui singur punct de defecțiune.
Câteva dispozitive de protecție a rețelei sunt explicate pe scurt, după cum urmează:
Firewall-uri: scopul principal al unui firewall este controlul accesului. Prin limitarea comunicațiilor de
intrare (de la Internet la rețeaua internă) și de ieșire (de la rețeaua internă la Internet), diverși vectori de
atac pot fi redusi. Firewall-urile pot oferi servicii suplimentare, cum ar fi traducerea adreselor de rețea și
gateway-ul de rețea privată virtuală.
Instituțiile financiare au patru tipuri principale de firewall din care să aleagă: filtrare de pachete,
inspecție de stat, servere proxy și firewall-uri la nivel de aplicație. Orice produs poate avea caracteristici
ale unuia sau mai multor tipuri de firewall. Selectarea unui tip de firewall depinde de multe caracteristici
ale zonei de securitate, cum ar fi cantitatea de trafic, sensibilitatea sistemelor și a datelor și aplicațiile.
Firewall-uri cu filtre de pachete
Firewall-urile de filtrare a pachetelor evaluează anteturile fiecărui pachet de intrare și de ieșire pentru a se asigura
că are o adresă internă validă, provine de la o adresă externă permisă, se conectează la un protocol sau serviciu
autorizat și conține instrucțiuni de antet de bază valide. Dacă pachetul nu se potrivește cu politica predefinită
pentru traficul permis, atunci firewall-ul renunță la pachet. Filtrele de pachete, în general, nu analizează conținutul
pachetului dincolo de informațiile din antet. Printre punctele slabe majore asociate firewall-urilor de filtrare a
pachetelor se numără incapacitatea de a preveni atacurile care exploatează vulnerabilitățile și funcțiile specifice
aplicației, deoarece filtrul de pachete nu examinează conținutul pachetelor, iar funcționalitatea de înregistrare este
limitată la aceleași informații utilizate pentru a lua decizii de control al accesului.
Firewall-uri de inspecție de stat
Firewall-urile de inspecție cu stat sunt filtre de pachete care monitorizează starea conexiunii TCP. Fiecare sesiune
TCP începe cu o „strângere de mână” inițială comunicată prin steaguri TCP din informațiile din antet. Când se
stabilește o conexiune, firewall-ul adaugă informațiile de conectare într-un tabel. Firewall-ul poate compara apoi
pachetele viitoare cu tabelul de conexiune sau de stare. Acest lucru verifică în esență că traficul de intrare este ca
răspuns la solicitările inițiate din interiorul firewall-ului.
Firewall-uri pentru server proxy
Serverele proxy acționează ca un intermediar între adresele IP interne și externe și blochează accesul direct la
rețeaua internă. În esență, ele rescriu antetele pachetelor pentru a înlocui IP-ul serverului proxy cu IP-ul mașinii
interne și trimite pachetele către și de la mașinile interne și externe. Datorită acestei capacități limitate, serverele
proxy sunt utilizate în mod obișnuit în spatele altor dispozitive firewall. Firewall-ul principal primește tot traficul,
determină ce aplicație este vizată și predă traficul către
server proxy. Serverele proxy comune sunt serverul de nume de domeniu (DNS), serverul web (HTTP) și serverul
de e-mail (SMTP). Serverele proxy memorează frecvent în cache cererile și răspunsurile, oferind potențiale
beneficii de performanță.
În plus, serverele proxy oferă un alt nivel de control al accesului prin segregarea fluxului de trafic Internet pentru
a sprijini capacitatea suplimentară de autentificare și înregistrare în jurnal, precum și filtrarea conținutului.
Serverele proxy web și de e-mail, de exemplu, sunt capabile să filtreze pentru potențial cod rău intenționat și
comenzi specifice aplicației. Serverele proxy cresc în importanță pe măsură ce protocoalele sunt tunelizate prin
alte protocoale.
Firewall-uri la nivel de aplicație
Firewall-urile la nivel de aplicație efectuează screening la nivel de aplicație, incluzând de obicei capabilitățile de
filtrare ale firewall-urilor de filtrare a pachetelor cu validare suplimentară a conținutului pachetului pe baza
aplicației. Firewall-urile la nivel de aplicație captează și compară pachetele cu informațiile de stare din tabelele de
conexiune. Spre deosebire de un firewall cu filtru de pachete, un firewall la nivel de aplicație continuă să
examineze fiecare pachet după ce conexiunea inițială este stabilită pentru anumite aplicații sau servicii, cum ar fi
telnet, FTP, SMTP etc. Firewall-ul la nivel de aplicație poate oferi o filtrare suplimentară a încărcăturii de pachete
pentru comenzi, protocoale, lungimea pachetului, autorizare, conținut sau anteturi nevalide. Firewall-urile la nivel
de aplicație oferă cel mai puternic nivel de securitate.
Politica de firewall
O politică de firewall stabilește așteptările conducerii cu privire la modul în care ar trebui să funcționeze
paravanul de protecție și este o componentă a cadrului general de management al securității. Tipurile de
comunicații de intrare acceptabile pentru organizație trebuie să fie definite în mod explicit în politicile de firewall.
Deoarece firewall-ul este de obicei una dintre primele linii de apărare, accesul la dispozitivul firewall în sine
trebuie controlat strict.
Politica ar trebui să abordeze cel puțin diverse aspecte precum topologia și arhitectura firewall-urilor și tipul
firewall-urilor utilizate, amplasarea fizică a componentelor firewall-ului, traficul permis și monitorizarea
traficului firewall-ului, actualizarea firewall-ului, coordonarea cu mecanismele de monitorizare a securității și de
răspuns la intruziune, responsabilitatea pentru monitorizarea și aplicarea politicii de firewall, protocoalele și
aplicațiile permise, auditarea regulată a configurației unui firewall și testarea eficienței firewall-ului și
planificarea pentru situații de urgență.
Cu toate acestea, nu ar trebui să se bazeze pe firewall-urile pentru a oferi protecție completă împotriva atacurilor.
Băncile ar trebui să completeze firewall-urile cu politici de securitate puternice și o serie de alte controale. De
fapt, firewall-urile sunt potențial vulnerabile la atacuri, inclusiv falsificarea adreselor IP de încredere, refuzul
serviciului prin supraîncărcarea firewall-ului cu solicitări excesive sau pachete malformate, sniffing de date care
sunt transmise în afara rețelei, cod ostil încorporat în HTTP, SMTP sau legitime. alt trafic care îndeplinește toate
regulile firewall etc. Băncile își pot reduce vulnerabilitatea la aceste atacuri prin configurarea și proiectarea
rețelei, implementarea solidă a arhitecturii sale firewall care include mai multe puncte de filtrare, monitorizarea și
managementul firewallului activ și monitorizarea securității integrate. În multe cazuri, controalele suplimentare
de acces în cadrul sistemului de operare sau al aplicației vor oferi mijloace suplimentare de apărare.
Având în vedere importanța firewall-urilor ca mijloc de control al accesului, bunele practici legate de firewall
includ:
Utilizarea unui set de reguli care interzice tot traficul de intrare și de ieșire care nu este permis în mod
specific
Folosind NAT și DNS împărțit pentru a ascunde numele și adresele sistemelor interne din rețelele
externe
Utilizarea conexiunilor proxy pentru conexiunile HTTP de ieșire și filtrarea codului rău intenționat
Întărirea paravanului de protecție prin eliminarea tuturor serviciilor inutile și corecțiile adecvate,
îmbunătățirea și întreținerea întregului software de pe unitatea paravanului de protecție
Restricționarea capacităților de mapare a rețelei prin firewall, în primul rând prin blocarea traficului de
intrare ICMP (Internet Control Messaging Protocol)
Faceți backup pentru firewall-uri pe medii interne și nu face backup pentru firewall pe servere din rețele
protejate
Activitate de înregistrare, cu revizuirea zilnică a administratorului și limitarea accesului administrativ la
puține persoane
Utilizarea dispozitivelor și practicilor de monitorizare a securității pentru a monitoriza acțiunile pe

firewall și pentru a monitoriza comunicațiile permise prin firewall
Administrarea firewall-ului utilizând comunicații criptate și autentificare puternică, accesarea firewall-

ului numai de pe dispozitive securizate și monitorizarea tuturor accesului administrativ. Efectuarea
modificărilor numai prin proceduri de control al modificărilor bine administrate.
Firewall-ul trebuie, de asemenea, configurat pentru traficul de rețea de ieșire autorizat. În cazul unei gazde
compromise în interiorul rețelei, filtrarea de ieșire sau de ieșire poate conține acel sistem și îl poate împiedica să
comunice de ieșire cu controlerul lor - ca în cazul rețelelor bot. De multe ori, firewall-urile permit în mod implicit
orice trafic de ieșire, prin urmare, organizațiile ar putea avea nevoie să definească în mod explicit politicile de
comunicare de ieșire acceptabile pentru rețelele lor. În cele mai multe cazuri, conexiunile de ieșire acceptabile ar
include SMTP la orice adresă numai de la gateway-urile dvs. de e-mail SMTP, DNS la orice adresă de la un
server DNS intern pentru a rezolva numele gazdelor externe, HTTP și HTTPS de la un server proxy intern pentru
ca utilizatorii să le poată naviga site-uri web, NTP către anumite adrese de server de timp de la un server de timp
intern, orice porturi cerute de Anti-Virus, filtrarea spam-ului, filtrarea web sau software-ul de gestionare a
corecțiilor numai către adresele corespunzătoare ale furnizorului pentru a derula actualizările și orice altă regulă
în care cazul de afaceri este documentat și aprobat de conducerea corespunzătoare.
Perimetrele pot conține firewall-uri proxy sau alte servere care acționează ca un punct de control pentru navigarea
pe Web, e-mail, P2P și alte comunicări. Acele firewall-uri și servere sunt utilizate frecvent pentru a aplica politica
de securitate a instituției asupra comunicațiilor primite. Aplicarea se face prin filtrare antivirus, anti-spyware și
anti-spam, blocarea descărcării fișierelor executabile și alte acțiuni. În măsura în care filtrarea se face pe bază de
semnătură, poate fi necesară actualizarea frecventă a semnăturilor, așa cum a fost explicat mai devreme.
Serverele perimetrale servesc și la inspectarea comunicațiilor de ieșire pentru conformitatea cu politica de

securitate a instituției. Routerele de perimetru și firewall-urile pot fi configurate pentru a impune politici care
interzic generarea comunicațiilor de ieșire de la anumite computere. În plus, serverele proxy ar putea fi
configurate pentru a identifica și bloca datele clienților și alte date care nu ar trebui să fie transmise în afara
domeniului de securitate.
b) Sisteme de detectare a intruziunilor (IDS)
Scopul unui IDS este de a identifica traficul de rețea aproape în timp real. Majoritatea IDS-urilor folosesc
semnături pentru a detecta scanări de porturi, programe malware și alte comunicații anormale în rețea.
Amplasarea ideală a unui IDS este atât externă organizației, cât și intern, chiar în spatele firewall-ului. Acest
lucru ar permite unei bănci să vadă traficul care se apropie de organizație, precum și traficul care a trecut cu
succes prin firewall. Dimpotrivă, va exista vizibilitate asupra traficului intern care încearcă să comunice în
exteriorul rețelei – deosebit de util pentru situațiile în care activitatea rău intenționată provine din interiorul
paravanului de protecție.
Pentru a utiliza în mod eficient un IDS de rețea (NIDS), o instituție trebuie să aibă o înțelegere solidă a capacității
de detectare și a efectului plasării, reglajului și a altor apărări ale rețelei asupra capacității de detectare.
Metodologia de detectare bazată pe semnătură citește pachetele de rețea și compară conținutul pachetelor cu
semnăturile sau caracteristicile unice ale atacurilor cunoscute. Când este recunoscută o potrivire între citirile
curente și o semnătură, IDS generează o alertă. O slăbiciune în metoda de detectare bazată pe semnătură este că
trebuie să existe o semnătură pentru ca o alertă să fie generată. Semnăturile sunt scrise fie pentru a captura
exploit-urile cunoscute, fie pentru a alerta asupra vulnerabilităților suspectate. Detectarea bazată pe vulnerabilități
are în general o bază largă, alertând asupra multor exploit-uri pentru aceeași vulnerabilitate și potențial alertând
asupra exploit-urilor care nu sunt încă cunoscute, ceea ce nu este cazul semnăturilor bazate pe exploatare care se
pot baza doar pe exploatări specifice și poate să nu avertizeze atunci când se încearcă o exploatare nouă sau
necunoscută anterior.
Această problemă poate fi deosebit de acută dacă instituția nu își actualizează continuu semnăturile pentru a
reflecta lecțiile învățate din atacurile asupra ei înșiși și asupra altora, precum și evoluțiile în tehnologiile
instrumentelor de atac. De asemenea, poate pune probleme atunci când semnăturile se adresează doar atacurilor
cunoscute. O altă slăbiciune este capacitatea NIDS de a citi traficul. Dacă NIDS rămâne în urmă în citirea
pachetelor de rețea, traficului i se poate permite să ocolească NIDS. Un astfel de trafic poate conține atacuri care,
altfel, ar determina NIDS să emită o alertă.
Metoda de detectare bazată pe anomalii detectează în general abaterile de la o linie de bază. Linia de bază poate fi
fie bazată pe protocol, fie bazată pe comportament. Linia de bază bazată pe protocol detectează diferențele dintre
pachetele detectate pentru un anumit protocol și RFC-urile (Requests for Comment) ale Internetului aferente
protocolului respectiv. De exemplu, un câmp antet ar putea depăși dimensiunea așteptată stabilită de RFC.
Metoda de detectare a anomaliilor bazată pe comportament creează un profil statistic al activității normale pe
gazdă sau rețea. Activitatea normală este, în general, măsurată pe baza volumului de trafic, a protocoalelor
utilizate și a modelelor de conexiune între diferite dispozitive. Se stabilesc repere pentru activitate pe baza acelui
profil. Când activitatea curentă depășește limitele identificate, este generată o alertă. Punctele slabe ale acestui
sistem implică capacitatea sistemului de a modela cu exactitate activitatea, relația dintre activitatea valabilă în
perioada modelată și activitatea valabilă în perioadele viitoare și potențialul ca activitate rău intenționată să aibă
loc în timp ce modelarea este efectuată. Această metodă este utilizată cel mai bine în medii cu activitate
previzibilă și stabilă.
Detectarea anomaliilor poate fi un supliment eficient la metodele bazate pe semnătură prin semnalizarea
atacurilor pentru care încă nu există semnătură. Amplasarea corectă a senzorilor NIDS este o decizie strategică
determinată de informațiile pe care banca încearcă să le obțină. Plasarea în afara paravanului de protecție va
furniza alarme IDS legate de toate atacurile, chiar și de cele care sunt blocate de paravanul de protecție. Cu aceste
informații, o instituție poate dezvolta o imagine a potențialilor adversari și a expertizei lor pe baza sondelor pe
care le emit împotriva rețelei.
Deoarece plasarea este menită să obțină informații despre atacatori, mai degrabă decât să alerteze asupra
atacurilor, reglarea face, în general, NIDS mai puțin sensibil decât dacă este plasat în interiorul paravanului de
protecție. Un NIDS din afara paravanului de protecție va alerta în general cu privire la cel mai mare număr de
atacuri nereușite, în timp ce monitorizarea NIDS din spatele paravanului de protecție este menită să detecteze și
să alerteze asupra intruziunilor ostile. Pot fi utilizate mai multe unități NIDS, plasarea fiind determinată de căile
de atac așteptate către datele sensibile. În general, cu cât NIDS este mai aproape de datele sensibile, cu atât mai
importante sunt reglarea, monitorizarea și răspunsul la alertele NIDS. În general, se recomandă ca NIDS să poată
fi plasat în orice locație în care traficul de rețea de la entități externe este permis să intre în rețele controlate sau
private.
„Tuning” se referă la crearea de semnături și filtre de alertă care pot distinge între traficul de rețea normal și
traficul potențial rău intenționat, pe lângă faptul că implică crearea și implementarea diferitelor acțiuni de alertă și
înregistrare în funcție de gravitatea atacului perceput. Reglarea corectă este esențială atât pentru detectarea fiabilă
a atacurilor, cât și pentru
permiterea unui răspuns bazat pe prioritate. Dacă IDS nu este reglat corespunzător, volumul de alerte pe care le
generează poate degrada identificarea intruziunilor și capacitatea de răspuns.
Rețelele comutate reprezintă o problemă pentru un IDS de rețea, deoarece comutatoarele de obicei nu transmit
trafic către toate porturile, în timp ce NIDS poate avea nevoie să vadă tot traficul pentru a fi eficient. Când
comutatoarele nu au un port care să primească tot traficul, o bancă poate fi nevoită să-și modifice rețeaua pentru a
include un hub sau alt dispozitiv pentru a permite IDS-ului să monitorizeze traficul. Criptarea reprezintă o
potenţială limitare pentru un NIDS. Dacă traficul este criptat, eficacitatea NIDS poate fi limitată la detectarea
anomaliilor pe baza informațiilor de antet necriptate. Această limitare poate fi depășită prin decriptarea pachetelor
din IDS la rate proporționale cu fluxul de trafic. Decriptarea este o caracteristică specifică dispozitivului care
poate să nu fie încorporată în toate unitățile NIDS.
Toate metodele de detectare NIDS au ca rezultat fals pozitive (alerte acolo unde nu există atac) și fals negative
(nicio alertă când are loc un atac). În timp ce falsele negative reprezintă în mod evident o preocupare, falsele
pozitive pot, de asemenea, împiedica detectarea. Atunci când personalul de securitate este copleșit de numărul de
fals pozitive, revizuirea lor a rapoartelor NIDS poate fi mai puțin eficientă, permițând astfel ca atacurile reale să
fie raportate de către NIDS, dar să nu ia măsuri adecvate. În plus, pot regla NIDS pentru a reduce numărul de fals
pozitive, ceea ce poate crește numărul de fals negative. Testarea bazată pe risc este necesară în acest sens pentru a
se asigura că capacitatea de detectare este adecvată.
c) Sisteme de prevenire a intruziunilor în rețea
Sistemele de prevenire a intruziunilor în rețea (NIPS) sunt un mecanism de control al accesului care permit sau
interzice accesul pe baza unei analize a antetelor pachetelor și a încărcăturilor utile de pachete. Ele sunt similare
cu firewall-urile deoarece sunt localizate în linia de comunicații, compară activitatea cu deciziile preconfigurate
privind tipul de pachete de filtrat sau blocat și răspund cu acțiuni preconfigurate. Unitățile IPS detectează în
general evenimentele de securitate într-un mod similar cu unitățile IDS și sunt supuse acelorași limitări. După
detectare, totuși, unitatea IPS are capacitatea de a întreprinde acțiuni dincolo de simpla alertă asupra activității
potențiale rău intenționate și înregistrarea pachetelor, cum ar fi blocarea fluxurilor de trafic de la o gazdă
ofensătoare. Capacitatea de a întrerupe comunicațiile poate fi utilă atunci când activitatea poate fi identificată în
mod clar ca fiind rău intenționată. Atunci când activitatea nu poate fi identificată în mod clar, de exemplu în cazul
în care poate exista un fals pozitiv, alerta similară IDS este de obicei preferabilă blocării. Deși unitățile IPS sunt
dispozitive de control al accesului, multe dintre aceste unități implementează un model de securitate diferit de
firewall-urile. Firewall-urile permit de obicei doar traficul necesar în scopuri comerciale sau doar traficul „bun
cunoscut”. Unitățile IPS sunt de obicei configurate pentru a interzice traficul care declanșează semnături sau
trafic „cunoscut rău”, permițând în același timp toate celelalte. Cu toate acestea, unitățile IPS pot fi configurate
pentru a imita mai îndeaproape un dispozitiv care permite doar traficul „bun cunoscut”. Unitățile IPS conțin și o
„listă albă” de adrese IP care nu ar trebui să fie blocate niciodată. Lista vă ajută să vă asigurați că un atacator nu
poate realiza un refuz de serviciu prin falsificarea IP-ului unei gazde critice.
d) Carantină
Punerea în carantină a unui dispozitiv protejează rețeaua de coduri sau acțiuni potențial rău intenționate. De
obicei, un dispozitiv care se conectează la un domeniu de securitate este interogat pentru conformitatea cu
politica de securitate a domeniului. Dacă dispozitivul nu este conform, acesta este plasat într-o parte restricționată
a rețelei până când se conformează. De exemplu, dacă nivelul de corecție nu este actual, dispozitivul nu este
permis să intre în domeniul de securitate până când patch-urile corespunzătoare nu sunt descărcate și instalate.
e) Plasare DNS
Protecția eficientă a serverelor DNS ale instituției este esențială pentru menținerea securității comunicațiilor
instituției. O mare parte a protecției este asigurată de securitatea gazdei Cu toate acestea, plasarea DNS-ului este,
de asemenea, un factor important. Plasarea optimă este DNS divizat, unde un server DNS cu firewall oferă
informații din domeniul public către exterior
și nu efectuează interogări recursive, iar un al doilea server DNS, într-un domeniu de securitate intern și nu în
DMZ, efectuează interogări recursive pentru utilizatorii interni.
Îmbunătățirea securității rețelelor
Pe lângă cele de mai sus, următorii se numără printre factorii care trebuie urmați pentru îmbunătățirea securității
rețelelor:
Inventarul de dispozitive și software autorizate și neautorizate.

Configurații/întărire sigure pentru tot hardware-ul și software-ul de pe laptopuri, stații de
lucru și servere și dispozitive de rețea, cum ar fi firewall-uri, routere și comutatoare.
Gestionarea configurației începe cu linii de bază de securitate bine testate și documentate
pentru diferite sisteme. Trebuie să existe linii de bază documentate de securitate pentru
toate tipurile de sisteme informatice.
Identificarea tuturor conexiunilor la rețelele critice și efectuarea analizei de risc, inclusiv

necesitatea fiecărei conexiuni. Toate conexiunile inutile la rețelele critice trebuie
deconectate.
Implementarea caracteristicilor de securitate recomandate de furnizorii de dispozitive și
sisteme.
Stabilirea unor controale puternice asupra oricărui mediu care este utilizat ca ușă în spate
în rețeaua critică. Dacă există uși din spate sau conexiuni cu furnizorii în sistemele critice,
trebuie implementată o autentificare puternică pentru a asigura comunicații sigure.
Implementarea sistemului de detectare a intruziunilor interne și externe, a sistemului de
răspuns la incident și stabilirea monitorizării incidentelor 24x7
Efectuarea de audituri tehnice, inclusiv evaluarea vulnerabilității dispozitivelor și rețelelor

critice și a oricăror alte rețele conectate, pentru a identifica problemele de securitate
Efectuarea de anchete de securitate fizică și evaluarea tuturor site-urilor la distanță
conectate la rețeaua critică pentru a evalua securitatea acestora. Orice locație care are o
conexiune la rețeaua critică este o țintă, în special site-uri la distanță fără echipaj sau
nepăzite. De asemenea, este necesar să se identifice și să evalueze orice sursă de
informații, inclusiv cabluri telefonice/rețea de calculatoare/fibră optică la distanță care ar
putea fi conectate; legături radio și cu microunde care pot fi exploatate; terminale de
calculator care ar putea fi accesate; și puncte de acces la rețeaua locală wireless.
Identificați și eliminați punctele unice de eșec.
Stabilirea „echipelor roșii” critice pentru a identifica și evalua posibile scenarii de atac.
Este necesar să se introducă informațiile rezultate din evaluarea „Echipa roșie” în
procesele de management al riscului pentru a evalua informațiile și a stabili strategii de
protecție adecvate.
Documentarea arhitecturii de rețea și identificarea sistemelor care servesc funcții critice

sau care conțin informații sensibile care necesită niveluri suplimentare de protecție.
Stabilirea unui proces riguros, continuu de management al riscului.
Stabilirea unei strategii de protecție a rețelei și a securității stratificate bazate pe principiul
apărării în profunzime este o necesitate absolută pentru bănci. Acest lucru ar necesita
măsuri adecvate pentru abordarea vulnerabilităților la nivelul hardware-ului, sistemului de
operare, middleware-ului, bazelor de date, rețelei și aplicațiilor. Securitatea nu este un
eveniment, ci un proces care necesită ca toate componentele sale să funcționeze bine
împreună pentru eficacitatea lor. În plus, fiecare strat trebuie protejat împotriva altor
sisteme de pe același strat. De exemplu, pentru a vă proteja împotriva amenințărilor
interne, restricționați utilizatorii să acceseze doar acele resurse necesare pentru a-și
îndeplini funcțiile de serviciu.
m. Stabilirea backup-urilor sistemului și a planurilor de recuperare în caz de dezastru. Stabiliți

un plan de recuperare în caz de dezastru care să permită recuperarea rapidă din orice
situație de urgență (inclusiv un atac cibernetic).
Stabilirea politicilor și desfășurarea de instruire pentru a minimiza probabilitatea ca

personalul organizațional să dezvăluie din neatenție informații sensibile cu privire la
proiectarea sistemului critic, operațiunile sau controalele de securitate prin încercări de
inginerie socială. Orice solicitări de informații din partea unor persoane necunoscute
trebuie trimise la o locație centrală de securitate a rețelei pentru verificare și îndeplinire.
Oamenii pot fi o verigă slabă într-o rețea altfel sigură, așa cum a fost indicat mai devreme
în capitol.
Funcțiile de control al rețelei ar trebui să fie îndeplinite de persoane cu pregătire și
experiență adecvate. Funcțiile de control al rețelei ar trebui separate, iar sarcinile ar trebui
schimbate în mod regulat, acolo unde este posibil. Software-ul de control al rețelei trebuie
să restricționeze accesul operatorului de la îndeplinirea anumitor funcții (de exemplu,
capacitatea de a modifica/șterge jurnalele de activitate ale operatorului).
Software-ul de control al rețelei ar trebui să mențină o pistă de audit a tuturor activităților
operatorului. Traseele de audit ar trebui să fie revizuite periodic de conducerea
operațiunilor pentru a detecta orice activitate neautorizată de operațiuni de rețea.
Standardele și protocoalele de funcționare a rețelei ar trebui să fie documentate și puse la

dispoziția operatorilor și ar trebui revizuite periodic pentru a asigura conformitatea.
Accesul la rețea de către inginerii de sistem ar trebui monitorizat și revizuit îndeaproape
pentru a detecta accesul neautorizat la rețea.
O altă îmbunătățire importantă a securității este capacitatea de a identifica utilizatorii la
fiecare pas al activității lor. Unele pachete de aplicații folosesc un ID de utilizator
predefinit. Au fost dezvoltate noi instrumente de monitorizare pentru a rezolva această
problemă.
Acces de la distanță:
Băncile pot oferi uneori angajaților, vânzătorilor și altora acces la rețeaua și resursele de calcul ale
instituției prin conexiuni externe. Aceste conexiuni sunt de obicei stabilite prin modemuri, internet sau linii
de comunicații private. Accesul poate fi necesar pentru a susține de la distanță sistemele instituției sau
pentru a sprijini operațiunile instituției în locații îndepărtate. În unele cazuri, accesul la distanță poate fi
solicitat periodic de către furnizori pentru a face remedieri de urgență a programelor sau pentru a susține un
sistem.
Accesul de la distanță la banca oferă unui atacator posibilitatea de a manipula și submina sistemele băncii
din afara perimetrului de securitate fizică. Conducerea ar trebui să stabilească politici care restricționează
accesul de la distanță și să fie conștienți de toate dispozitivele de acces la distanță atașate sistemelor lor.
Aceste dispozitive ar trebui să fie strict controlate.
Comenzile bune pentru accesul de la distanță includ următoarele acțiuni:

Interzicerea accesului la distanță prin politică și practică, cu excepția cazului în care există o nevoie
convingătoare de afaceri și necesită aprobarea conducerii pentru accesul la distanță
Revizuirea regulată a aprobărilor de acces la distanță și anularea celor care nu mai au o justificare
comercială convingătoare
Configurarea și securizarea adecvată a dispozitivelor de acces la distanță
Corectarea, actualizarea și întreținerea în mod corespunzător și în timp util a tuturor software-ului pe
dispozitivele de acces la distanță
Utilizarea criptării pentru a proteja comunicațiile dintre dispozitivul de acces și instituție și pentru a
proteja datele sensibile care se află pe dispozitivul de acces
Auditarea periodică a configurațiilor dispozitivului de acces și a nivelurilor de corecție
Utilizarea VLAN-urilor, segmentelor de rețea, directoarelor și a altor tehnici pentru a restricționa

accesul de la distanță la zonele și aplicațiile de rețea autorizate din cadrul instituției
Înregistrarea comunicațiilor de acces la distanță, analizarea acestora în timp util și urmărirea

anomaliilor
Centralizați modemul și accesul la Internet pentru a oferi un proces de autentificare consecvent și

pentru a supune traficul de rețea de intrare și de ieșire la protecții corespunzătoare de perimetru și
monitorizare a rețelei
Înregistrarea și monitorizarea datei, orei, utilizatorului, locației utilizatorului, durata și scopul pentru
toate accesul la distanță, inclusiv toate activitățile efectuate prin acces la distanță
Necesitatea unui proces de autentificare cu doi factori pentru accesul de la distanță (de exemplu, card
cu simboluri bazate pe PIN cu un generator de parole aleatoare unice sau PKI bazat pe simboluri)
Implementarea controalelor în concordanță cu sensibilitatea utilizării de la distanță. De exemplu,
utilizarea de la distanță pentru administrarea sistemelor sau bazelor de date sensibile poate include
controale precum restricționarea utilizării dispozitivului de acces prin politică și configurare,
necesitatea autentificarea dispozitivului de acces în sine și verificarea fiabilității dispozitivului de acces
înainte de a acorda acces.
Dacă accesul de la distanță se face prin modemuri, trebuie să urmați următorii pași:
Solicitați unui operator să lase modemurile deconectate sau dezactivate în mod implicit, să activeze
modemurile numai pentru solicitări externe specifice și autorizate și să dezactiveze modemul imediat
când scopul solicitat este îndeplinit
Configurați modemurile să nu răspundă la apelurile de intrare, dacă modemurile sunt destinate exclusiv
utilizării la ieșire
Utilizați funcțiile automate de returnare a apelurilor, astfel încât modemurile să apeleze doar un număr,
deși acesta este supus schemelor de redirecționare a apelurilor
Instalați o bancă de modemuri în care numărul exterior al modemurilor folosește un prefix diferit de
numerele interne și nu răspunde la apelurile primite
În timp ce utilizează accesul la distanță bazat pe Internet TCP/IP, organizațiile trebuie să stabilească o rețea
privată virtuală prin Internet pentru a comunica în siguranță pachetele de date prin această infrastructură
publică. Tehnologiile VPN disponibile aplică standardul de securitate IPSec Internet Engineering Task
Force (IETF) Avantajele lor sunt omniprezența, ușurința în utilizare, conectivitate ieftină și accesul numai
pentru citire, interogare sau copiere. Dezavantajele includ faptul că sunt mult mai puțin fiabile decât
circuitele dedicate, nu au o autoritate centrală și pot avea probleme de depanare.
Băncile trebuie să fie conștiente de faptul că utilizarea VPN-urilor pentru a permite accesul de la distanță la
sistemele lor poate crea găuri în infrastructura lor de securitate. Traficul criptat poate ascunde acțiuni
neautorizate sau software rău intenționat care poate fi transmis prin astfel de canale. Sistemele de detectare
a intruziunilor și scanerele de viruși capabile să decripteze traficul pentru analiză și apoi să-l cripteze și să-l
transmită către punctul final VPN ar trebui considerate controale preventive. O bună practică va termina
toate VPN-urile la același punct final într-un așa-numit concentrator VPN și nu va accepta VPN-uri
direcționate către alte părți ale rețelei.
Atacurile distribuite de tip Denial of Service (DDoS/DoS):
Băncile care oferă servicii bancare prin internet ar trebui să răspundă la condițiile neobișnuite
de trafic de rețea/performanța sistemului și la creșterea bruscă a utilizării resurselor sistemului,
care ar putea fi un indiciu al unui atac DDoS. În consecință, succesul oricăror acțiuni
preventive și reactive depinde de implementarea instrumentelor adecvate pentru a detecta,
monitoriza și analiza în mod eficient anomaliile în rețele și sisteme.
Ca parte a strategiei de apărare, băncile ar trebui să instaleze și să configureze dispozitivele de

securitate a rețelei discutate mai devreme în capitol pentru o capacitate rezonabilă de
prevenire/detecție. Potențialele blocaje și punctele singulare de eșec vulnerabile la atacurile
DDoS ar putea fi identificate prin codul sursă
revizuire, analiza designului rețelei și testarea configurației. Abordarea acestor vulnerabilități ar

îmbunătăți reziliența sistemelor.
Băncile pot lua în considerare, de asemenea, să includă considerații privind atacurile DoS în
procesul de selecție a ISP-ului. Un cadru de răspuns la incident ar trebui conceput și validat
periodic pentru a facilita răspunsul rapid la un atac DDoS sau un atac iminent. De asemenea,
băncile ar putea avea nevoie să se familiarizeze cu planurile de răspuns la incident ale
furnizorilor de servicii de internet și să le considere în mod adecvat ca parte a cadrului lor de
răspuns la incident. Pentru a promova o mai bună coordonare, băncile ar trebui să stabilească un
protocol de comunicare cu furnizorii de servicii de internet și să efectueze periodic exerciții
comune de răspuns la incidente.
Implementarea Sistemului de Management al Securității Informației ISO 27001
Băncile comerciale ar trebui să implementeze cele mai bune practici ale Sistemului de management al
securității informațiilor (ISMS) pentru funcțiile/procesele lor critice.
Cel mai cunoscut ISMS este descris în ISO/IEC 27001 și ISO/IEC 27002 și standardele conexe publicate
în comun de ISO și IEC. ISO 27001 se referă la modul de implementare, monitorizare, întreținere și
îmbunătățire continuă a unui sistem de management al securității informațiilor, în timp ce ISO 27002
oferă pași detaliați sau o listă de măsuri de securitate care pot fi utilizate la construirea unui ISMS. Alte
cadre precum COBIT și ITIL încorporează totuși aspecte de securitate, dar sunt orientate în principal spre
crearea unui cadru de guvernanță pentru informații și IT în general. Ca și în cazul tuturor proceselor de
management, un ISMS trebuie să rămână eficient și eficient pe termen lung, adaptându-se la schimbările
din organizația internă și mediul extern. ISO/IEC 27001, astfel, încorporează abordarea tipică „Planifică-
Efectuează-Verifică-Acționează” (PDCA) sau ciclul Deming:
Faza de Plan este despre proiectarea ISMS, evaluarea riscurilor de securitate a informațiilor și
selectarea controalelor adecvate.
Faza Do implică implementarea și operarea controalelor.
Obiectivul fazei de verificare este de a revizui și evalua performanța (eficiența și eficacitatea) ISMS.
În faza Act, modificările sunt făcute acolo unde este necesar pentru a readuce ISMS la performanță
de vârf. Un ISMS dezvoltat și bazat pe criterii de acceptare/respingere a riscurilor și care utilizează
certificarea acreditată de terți pentru a oferi o verificare independentă a nivelului de asigurare, este un
instrument de management extrem de util. Oferă posibilitatea de a defini și monitoriza nivelurile de
servicii atât în plan intern, cât și cu organizațiile contractante/partenere, demonstrând astfel măsura în
care există un control eficient al riscurilor de securitate.
În plus, o bancă ar trebui, de asemenea, să evalueze în mod regulat caracterul complet al cadrului său de
gestionare a riscului de securitate a informațiilor, în comparație cu colegii și cu alte cadre și standarde de
control stabilite, inclusiv orice cadre legate de securitate emise de instituții de renume precum IDRBT
sau DSCI.
În timp ce implementează ISO 27001 și aspecte din alte standarde relevante, băncile ar trebui să se
ferească de o listă de verificare de rutină, dar să se asigure că managementul securității este de natură
dinamică prin scanarea proactivă a mediului pentru noi amenințări și adaptate în mod adecvat la mediul
în schimbare.
Securitate wireless
Securitatea rețelelor wireless este o provocare, deoarece acestea nu au un perimetru bine definit sau puncte
de acces bine definite. Include toate dispozitivele wireless de comunicare de date, cum ar fi computerele
personale, telefoanele celulare, PDA-urile etc. conectate la rețelele interne ale unei bănci.
Spre deosebire de rețelele cu fir, monitorizarea neautorizată și atacurile de denial of service pot fi efectuate
fără o conexiune fizică prin cablu. În plus, dispozitivele neautorizate pot să se conecteze la rețea, să
efectueze atacuri de tip man-in-the-middle sau să se conecteze la alte dispozitive fără fir. Pentru a atenua
aceste riscuri, rețelele wireless se bazează pe utilizarea extinsă a criptării pentru a autentifica utilizatorii și
dispozitivele și pentru a proteja comunicațiile. Dacă o bancă folosește o rețea fără fir, ar trebui să evalueze
cu atenție riscul și să implementeze controale suplimentare adecvate. Exemplele de controale suplimentare
pot include unul sau mai multe dintre următoarele:
Tratarea rețelelor fără fir ca fiind rețele de încredere, permițând accesul prin dispozitive de protecție
similare cu cele folosite pentru a proteja rețeaua internă de mediul Internet
Utilizarea criptării end-to-end în plus față de criptarea oferită de conexiunea fără fir Utilizarea
controalelor puternice de autentificare și configurare la punctele de acces și la toți clienții Utilizarea
unui server de aplicații și terminale stupide
Ecranarea zonei în care funcționează rețeaua LAN fără fir pentru a proteja împotriva emisiilor
parazite și interferențelor semnalului
Monitorizarea și răspunsul la punctele de acces wireless și clienții neautorizați
Toate punctele de acces / stațiile de bază wireless conectate la rețeaua corporativă trebuie să fie înregistrate
și aprobate de funcția de securitate a informațiilor a unei bănci. Aceste puncte de acces/stații de bază trebuie
supuse unor teste de penetrare și audituri periodice. Trebuie să fie disponibil un inventar actualizat pe toate
plăcile de interfață de rețea fără fir utilizate în laptopurile sau computerele desktop ale companiei. Punctele
de acces/NIC fără fir nu trebuie instalate/activate în rețeaua unei bănci fără aprobarea funcției de securitate a
informațiilor.
Băncile ar trebui să se asigure că fiecare dispozitiv wireless conectat la rețea corespunde unei configurații
autorizate și unui profil de securitate, cu un proprietar documentat al conexiunii și o nevoie de afaceri
definită. Organizațiile ar trebui să refuze accesul la acele dispozitive wireless care nu au o astfel de
configurație și profil.
Băncile ar trebui să se asigure că toate punctele de acces wireless sunt gestionabile folosind instrumente de
management al întreprinderii. Instrumentele de scanare a vulnerabilităților rețelei ar trebui configurate
pentru a detecta punctele de acces wireless conectate la rețeaua cu fir. Dispozitivele identificate trebuie
reconciliate cu o listă de puncte de acces wireless autorizate. Punctele de acces neautorizate (adică
necinstiți) ar trebui dezactivate.
Băncile ar trebui să utilizeze sisteme wireless de detectare a intruziunilor (WIDS) pentru a identifica
dispozitivele fără fir necinstite și pentru a detecta încercările de atac și compromisurile reușite. Pe lângă
WIDS, tot traficul fără fir ar trebui monitorizat de un IDS cu fir pe măsură ce traficul trece în rețeaua cu fir.
Acolo unde a fost identificată o nevoie specifică de afaceri pentru acces wireless, băncile ar trebui să
configureze accesul wireless pe mașinile client pentru a permite accesul numai la rețelele wireless
autorizate.
Pentru dispozitivele care nu au un scop de afaceri wireless esențial, organizațiile ar trebui să ia în

considerare dezactivarea accesului wireless în configurația hardware (BIOS sau EFI), cu protecții prin
parolă pentru a reduce posibilitatea ca utilizatorul să anuleze astfel de configurații.
Băncile ar trebui să scaneze în mod regulat dispozitivele de infrastructură fără fir neautorizate sau
configurate greșit, folosind tehnici precum „conducerea războiului” pentru a identifica punctele de acces și
clienții care acceptă conexiuni peer-to-peer. Astfel de dispozitive neautorizate sau configurate greșit ar
trebui să fie eliminate din rețea sau să li se modifice configurațiile astfel încât să respecte cerințele de
securitate ale organizației.
Băncile ar trebui să se asigure că tot traficul fără fir folosește cel puțin criptarea AES folosită cu cel puțin
protecție WPA2. Băncile ar trebui să se asigure că rețelele wireless utilizează protocoale de autentificare,
cum ar fi EAP/TLS sau PEAP, care oferă protecție a acreditărilor și autentificare reciprocă.
Băncile ar trebui să se asigure că clienții fără fir utilizează acreditări puternice, cu mai mulți factori de
autentificare pentru a reduce riscul accesului neautorizat de la acreditările compromise.
Băncile ar trebui să dezactiveze capabilitățile de rețea fără fir peer-to-peer pe clienții fără fir, cu excepția
cazului în care o astfel de funcționalitate satisface o nevoie de afaceri documentată.
Băncile ar trebui să dezactiveze accesul la dispozitive periferice wireless (cum ar fi Bluetooth), cu excepția
cazului în care un astfel de acces este necesar pentru o nevoie de afaceri documentată.
Băncile pot lua în considerare configurarea tuturor clienților fără fir folosiți pentru a accesa alte rețele
critice sau pentru a gestiona datele organizației într-un mod astfel încât să nu poată fi utilizați pentru a se
conecta la rețelele publice fără fir sau la orice alte rețele în afara celor permise în mod specific de bancă.
Câteva cerințe referitoare la VPN care pot fi luate în considerare:
Accesul ar trebui să fie oferit numai dacă există un caz de afaceri autentic
Toate computerele cu dispozitive LAN fără fir trebuie să utilizeze o rețea privată virtuală (VPN)
configurată pentru a elimina tot traficul neautentificat și necriptat
Implementările wireless trebuie să mențină criptarea hardware punct-la-punct de cel puțin 128 de
biți. Sprijină o adresă hardware, cum ar fi adresa MAC, care poate fi înregistrată și urmărită și să
susțină autentificarea puternică a utilizatorului, care verifică cu o bază de date externă, cum ar fi
TACACS+, RADIUS etc.
Implementarea autentificării reciproce a utilizatorului și a serverului de autentificare și a sondajului

trebuie făcută înainte de localizarea punctelor de acces pentru a se asigura că semnalele sunt
limitate în interiorul locației cât mai mult posibil.
Comunicarea dintre stațiile de lucru și punctele de acces ar trebui să fie criptată folosind chei de
sesiune dinamice
Considerații privind continuitatea afacerii:
Evenimentele care declanșează implementarea unui plan de continuitate a afacerii pot avea implicații
semnificative de securitate. În funcție de eveniment, unele sau toate elementele mediului de securitate se pot
schimba. Pot exista diferite compromisuri între disponibilitate, integritate, confidențialitate și responsabilitate, cu
un apetit diferit pentru risc din partea managementului. Planurile de continuitate a afacerii ar trebui revizuite ca
parte integrantă a procesului de securitate.
Evaluările riscurilor ar trebui să ia în considerare riscurile în schimbare care apar în scenariile de continuitate a
afacerii și pozițiile diferite de securitate care pot fi stabilite. Strategiile ar trebui să ia în considerare mediul de risc
diferit și gradul de diminuare a riscului necesar pentru a proteja instituția în cazul în care planurile de continuitate
trebuie implementate. Implementarea ar trebui să ia în considerare pregătirea personalului adecvat în rolurile lor
de securitate și implementarea și actualizarea tehnologiilor și planurilor pentru site-urile de rezervă și rețelele de
comunicații. Aceste considerații de securitate ar trebui să fie integrate cu testarea implementărilor planului de
continuitate a afacerii. Mai multe informații despre „Planificarea continuității activității” sunt furnizate într-un
capitol separat.
Asigurarea securității informațiilor
Testare de penetrare:
Testarea de penetrare este definită ca un set oficial de proceduri concepute pentru a ocoli controalele de securitate
ale unui sistem sau organizație cu scopul de a testa rezistența acelui sistem sau organizație la un astfel de atac.
Testarea de penetrare este efectuată pentru a descoperi punctele slabe de securitate ale unui sistem și pentru a
determina modalitățile în care sistemul poate fi compromis de un potențial atacator. Testarea de penetrare poate
lua mai multe forme, dar, în general, un test constă într-o serie de „atacuri” împotriva unei ținte. Succesul sau
eșecul atacurilor și modul în care ținta reacționează la fiecare atac vor determina rezultatul testului.
Scopul general al unui test de penetrare este de a determina capacitatea subiectului de a rezista unui atac al unui
intrus ostil. Ca atare, testerul va folosi trucurile și tehnicile pe care le-ar putea folosi un atacator din viața reală.
Această strategie de atac simulată permite subiectului să descopere și să-și atenueze punctele slabe de securitate
înainte ca un atacator real să le descopere. Deoarece un test de penetrare este rareori un test cuprinzător al
securității sistemului, acesta ar trebui combinat cu alte monitorizări pentru a valida eficacitatea procesului de
securitate.
Testarea de penetrare trebuie efectuată cel puțin o dată pe an.
Audituri
Auditul compară practicile curente cu un set de politici/standarde/linii directoare formulate de instituție, autoritate
de reglementare, inclusiv orice cerințe legale. Conducerea băncii este responsabilă să demonstreze că standardele
pe care le adoptă sunt adecvate pentru instituție. Auditurile nu ar trebui să analizeze doar aspectele tehnice, ci și
procesul de guvernare a securității informațiilor.
Evaluare
O evaluare este un studiu pentru a localiza vulnerabilitățile de securitate și pentru a identifica acțiuni corective. O
evaluare diferă de un audit prin faptul că nu are un set de standarde pe care să le testeze. Diferă de un test de
penetrare prin oferirea testerului acces deplin la sistemele testate. Evaluările pot fi concentrate pe procesul de
securitate sau pe sistemul informațional. Ele se pot concentra, de asemenea, pe diferite aspecte ale sistemului
informațional, cum ar fi una sau mai multe gazde sau rețele. Evaluarea vulnerabilității a fost explicată mai
devreme în capitol.
Lucrarea de asigurare trebuie efectuată de experți/auditori independenți și instruiți corespunzător în securitatea

informațiilor. Punctele forte și punctele slabe ale aplicațiilor critice bazate pe internet, ale altor sisteme și rețele
critice trebuie realizate înainte de fiecare implementare inițială și cel puțin anual după aceea. Orice constatări
trebuie raportate și monitorizate folosind o metodologie sistematică de remediere a auditului sau de urmărire a
conformității.
O bancă trebuie să evalueze în mod regulat vulnerabilitățile de securitate a informațiilor și să evalueze

eficacitatea cadrului existent de gestionare a riscurilor de securitate IT, făcând toate ajustările necesare pentru a se
asigura că vulnerabilitățile emergente sunt abordate în timp util. Această evaluare ar trebui, de asemenea,
efectuată ca parte a oricărei modificări semnificative.
Sunt necesare procese robuste de evaluare a performanței pentru a oferi organizațiilor feedback cu privire la
eficacitatea politicii de securitate cibernetică și a implementării tehnice. Un semn al unei organizații mature este
una care este capabilă să identifice singur problemele, să efectueze analize ale cauzei principale și să
implementeze acțiuni corective eficiente care abordează problemele individuale și sistemice. Procese de
autoevaluare care fac în mod normal parte dintr-un cibernetic eficient Compilat de Srinivas Kante E-mail:
Programul de securitate include scanarea de rutină pentru vulnerabilități, auditarea automată a rețelei și - evaluări ale
performanței organizaționale și individuale legate de securitatea liniei de afaceri.
O bancă ar trebui să gestioneze cadrul de management al riscului de securitate a informațiilor în mod continuu ca
program de securitate urmând abordarea managementului de proiect, abordând lacunele de control într-un mod
sistematic.
Informații generale privind canalele de livrare
Furnizarea de diverse canale bancare electronice, cum ar fi ATM/carduri de debit/internet

banking/telefonic banking ar trebui să fie emisă numai la opțiunea clienților, pe baza unei cereri
electronice specifice scrise sau autentificate, împreună cu o confirmare pozitivă a termenilor și condițiilor
din partea clientului. Un client nu trebuie obligat să opteze pentru servicii în acest sens. Băncile ar trebui
să ofere clienților informații clare despre riscurile și beneficiile utilizării serviciilor de livrare prin e-
banking, pentru a le permite clienților să decidă cu privire la alegerea unor astfel de servicii.
Atunci când sunt introduse noi caracteristici sau funcții de operare, în special cele legate de securitate,
integritate și autentificare, banca trebuie să se asigure că clienții au suficiente instrucțiuni și informații
pentru a le putea utiliza în mod corespunzător.
Pentru a crește gradul de conștientizare în materie de securitate, băncile ar trebui să sensibilizeze clienții
cu privire la necesitatea de a-și proteja codurile PIN, jetoanele de securitate, detaliile personale și alte date
confidențiale.
Băncile sunt responsabile pentru siguranța și soliditatea serviciilor și sistemelor pe care le oferă clienților
lor. Reciproc, este, de asemenea, important ca clienții să ia măsuri de securitate adecvate pentru a-și
proteja dispozitivele și sistemele informatice și pentru a se asigura că integritatea lor nu este compromisă
atunci când se angajează în activități bancare online. Clienții trebuie să pună în aplicare măsurile sfătuite
de băncile lor cu privire la protejarea dispozitivelor sau computerelor pe care le folosesc pentru accesarea
serviciilor bancare.
Având în vedere schimbările constante care au loc în mediul internet și canalele de livrare online,
conducerea ar trebui să instituie un regim de monitorizare și conformitate a riscurilor în mod continuu
pentru a verifica performanța și eficacitatea procesului de management al riscului. Atunci când parametrii
de risc se modifică, procesul de risc trebuie actualizat și îmbunătățit în consecință. Ar trebui efectuate
reevaluarea măsurilor și ecuațiilor anterioare de control al riscului, testarea și auditarea reînnoite a
adecvării și eficacității procesului de management al riscului și a controalelor și măsurilor de securitate
aferente luate.
Internet banking:
Băncile trebuie să asigure măsuri de securitate adecvate pentru aplicațiile lor web și să ia măsuri rezonabile de
atenuare împotriva diferitelor riscuri de securitate web indicate mai devreme în capitol.
ii .Aplicațiile web nu ar trebui să stocheze informații sensibile în câmpuri HTML ascunse, cookie-uri sau orice altă
stocare la nivelul clientului care să conducă la compromiterea integrității datelor. Aplicațiile web critice ar trebui să
impună cel puțin nivelul de criptare SSL v3 sau Extended Validation – SSL / TLS 1.0 pe 128 de biți pentru toată
activitatea online.
iii .Restabilirea oricărei sesiuni după întrerupere ar trebui să necesite identificarea, autentificarea și autorizarea
normală a utilizatorului. În plus, validarea puternică pe partea serverului ar trebui să fie activată.
Băncile trebuie să urmeze o strategie de apărare în profunzime prin aplicarea unor măsuri de securitate robuste pe
diferite straturi tehnologice
Practici de autentificare pentru internet banking:
Metodologiile de autentificare implică trei „factori” de bază:
Ceea ce utilizatorul știe (de exemplu, parolă, PIN);

Ceva pe care utilizatorul are (de exemplu, card ATM, smart card); și
Ceva este utilizatorul (de exemplu, caracteristica biometrică, cum ar fi amprenta digitală).
Metodele de autentificare multifactor concepute și implementate corespunzător sunt mai fiabile și mai puternice
descurajatoare de fraudă și sunt mai greu de compromis. Principalele obiective ale autentificării în doi factori sunt de
a proteja confidențialitatea datelor contului clientului și a detaliilor tranzacțiilor, precum și de a spori încrederea în
internet banking prin combaterea diferitelor mecanisme de atac cibernetic precum phishing, keylogging,
spyware/malware și alte fraude bazate pe internet care vizează bănci și clienții acestora.
Implementarea autentificării cu doi factori și a altor măsuri de securitate pentru internet banking:
Având în vedere proliferarea atacurilor cibernetice și potențialele consecințe ale acestora, băncile ar trebui să
implementeze autentificarea cu doi factori pentru transferurile de fonduri prin internet banking.
Implementarea metodologiilor adecvate de autentificare ar trebui să se bazeze pe o evaluare a riscului

prezentat de sistemele bancare prin internet ale instituției. Riscul ar trebui evaluat în funcție de tipul de client
(de exemplu, retail sau corporativ/comercial); capacitățile tranzacționale ale clienților (de exemplu, plata
facturii, transferul de fonduri), sensibilitatea informațiilor despre clienți fiind comunicate atât băncii, cât și
volumul tranzacțiilor implicate.
Dincolo de factorul tehnologic, succesul unei anumite metode de autentificare depinde de politicile,
procedurile și controalele adecvate. O metodă eficientă de autentificare ar trebui să ia în considerare
acceptarea clienților, ușurința în utilizare, performanța fiabilă, scalabilitatea pentru a se adapta creșterii și
interoperabilitatea cu alte sisteme.
Există un risc legal în a nu folosi criptosistemul asimetric și funcția hash pentru autentificarea tranzacțiilor
electronice. Cu toate acestea, se observă că unele bănci folosesc încă o autentificare slabă bazată pe ID de
utilizator/parolă pentru transferurile de fonduri prin internet banking. Pentru a efectua tranzacții critice, cum
ar fi transferurile de fonduri, băncile, cel puțin, trebuie să implementeze o autentificare robustă și dinamică
cu doi factori prin combinarea ID utilizator/parolă și al doilea factor, cum ar fi (a) o semnătură digitală
(printr-un simbol care conține certificat digital și cheie privată asociată) (de preferință pentru clienții
corporativi) sau (b) OTP/cod de acces dinamic prin diferite moduri (cum ar fi SMS-uri prin telefoane mobile
sau token hardware).
Pentru a spori securitatea procesării online, procedurile de confirmare ale canalului secundar (cum ar fi
telefonia, SMS-urile, e-mailul etc.) ar trebui aplicate în ceea ce privește tranzacțiile peste valorile
prestabilite, crearea de noi legături de cont, înregistrarea detaliilor beneficiarului terților, modificarea
detaliilor contului sau revizuirea la limitele de transfer de fonduri. În conceperea acestor caracteristici de
securitate, banca ar trebui să țină cont de eficacitatea acestora și de preferințele diferite ale clienților pentru o
protecție suplimentară online.
Pe baza protocoalelor de autentificare reciprocă, clienții ar putea, de asemenea, autentifica site-ul web al
băncii prin mecanisme de securitate, cum ar fi mesaje/imagini de asigurare personală, schimbul de coduri de
securitate pentru răspuns la provocare și/sau verificarea certificatelor de server SSL (Secure Sockets Layer).
În ultima vreme, certificatele Extended Validation Secure Sockets Layer (EV-SSL) sunt din ce în ce mai
utilizate. Acestea sunt certificate SSL speciale care funcționează cu browsere web de înaltă securitate
identifica în mod clar identitatea organizațională a unui site Web. Cu toate acestea, trebuie remarcat faptul
că SSL este conceput doar pentru a cripta datele în tranzit la nivelul de transport al rețelei. Nu oferă
securitate de criptare end-to-end la nivelul aplicației.
O sesiune autentificată, împreună cu protocolul său de criptare, ar trebui să rămână intactă pe toată durata
interacțiunii cu clientul. În caz contrar, în cazul unei interferențe, sesiunea ar trebui să fie încheiată și
tranzacțiile afectate rezolvate sau anulate. Clientul trebuie să fie anunțat cu promptitudine cu privire la un
astfel de incident pe măsură ce sesiunea se încheie sau ulterior prin e-mail, telefon sau prin alte mijloace.
Modificările numărului de telefon mobil se pot face numai la cererea unei sucursale
Implementarea tastaturii virtuale

O perioadă de răcire pentru adăugarea de beneficiari și alerte prin SMS și e-mail atunci când se adaugă noi
beneficiari. Clienții ar trebui sfătuiți să adopte diferite măsuri de siguranță și practici bune în protejarea
computerului personal și să evite efectuarea de tranzacții financiare de pe computerele publice sau de la
internet cafe.
Procesul de monitorizare sau supraveghere a tranzacțiilor bazat pe risc trebuie să fie considerat un adjuvant.
O sesiune online ar trebui să fie încheiată automat după o perioadă fixă de timp, cu excepția cazului în care
clientul este re-autentificat pentru ca sesiunea existentă să fie menținută. Acest lucru împiedică un atacator
să mențină o sesiune de internet banking în viață pe termen nelimitat.
Prin definiție, adevărata autentificare multifactorială necesită utilizarea soluțiilor din două sau mai multe
dintre cele trei categorii de factori. Utilizarea mai multor soluții din aceeași categorie în puncte diferite ale
procesului poate face parte dintr-o abordare de securitate stratificată sau alte abordări de control
compensator, dar nu ar constitui o adevărată autentificare multifactorială.
Ca parte integrantă a arhitecturii de autentificare cu doi factori, băncile ar trebui, de asemenea, să
implementeze măsuri adecvate pentru a minimiza expunerea la un atac intermediar, care este mai frecvent
cunoscut sub numele de atac man-in-the-middle (MITM), man-in-the-browser( MITB) atac sau atac man-in-
the application. Băncile ar trebui, de asemenea, să ia în considerare și, dacă consideră necesar, să
implementeze următoarele măsuri de control și securitate pentru a minimiza expunerea la atacurile de tip
om-in-the middle:
OTP-uri specifice pentru adăugarea de noi beneficiari : Fiecare nou beneficiar ar trebui să fie
autorizat de către client pe baza unui OTP de pe un al doilea canal care arată, de asemenea, detaliile
beneficiarului sau semnătura de mână a clientului dintr-o procedură manuală care este verificată de bancă.
OTP-uri individuale pentru tranzacții de valoare (plăți și transferuri de fond) : Fiecare

tranzacție de valoare sau o listă aprobată de tranzacții de valoare peste un anumit prag de rupie determinat de
client ar trebui să necesite un nou OTP.
Fereastra de timp OTP : OTP-urile bazate pe provocări și pe timp oferă o securitate puternică,
deoarece perioada lor de valabilitate este controlată în întregime de bancă și nu depinde de comportamentul
utilizatorului. Se recomandă ca băncile să nu permită ca fereastra de timp OTP să depășească 100 de
secunde de fiecare parte a timpului serverului, deoarece cu cât fereastra de timp este mai mică, cu atât este
mai mic riscul de utilizare greșită a OTP.
Securitatea plăților și a transferului de fonduri : semnăturile digitale și codurile de autentificare

a mesajelor bazate pe chei (KMAC) pentru tranzacțiile de plată sau de transfer de fond ar putea fi luate în
considerare pentru detectarea modificărilor neautorizate sau injectării datelor de tranzacție într-un atac
intermediar. Pentru ca această soluție de securitate să funcționeze eficient, un client care folosește un token
hardware ar trebui să fie capabil să distingă procesul de generare a unei parole unice de procesul de semnare
digitală a unei tranzacții. Ceea ce semnează digital trebuie să fie, de asemenea, semnificativ pentru el, ceea
ce înseamnă că jetonul ar trebui să arate cel puțin în mod explicit numărul contului beneficiarului și suma
plății din care poate fi obținută o valoare hash în scopul creării unei semnături digitale. Ar trebui folosite
diferite chei criptografice pentru generarea de OTP și pentru semnarea tranzacțiilor.
Al doilea canal de notificare/confirmare : Banca trebuie să notifice clientul, printr-un al doilea

canal, cu privire la toate tranzacțiile de plată sau transfer de fonduri peste o valoare specificată determinată de
client.
Timp de expirare a sesiunii : o sesiune online va fi încheiată automat după o perioadă fixă de timp,
cu excepția cazului în care clientul este re-autentificat pentru ca sesiunea existentă să fie menținută. Acest lucru
împiedică un atacator să mențină o sesiune de internet banking în viață pe termen nelimitat.
Avertisment privind certificatul de server SSL : clienții serviciilor bancare prin internet ar trebui să fie informați și să li se
arate cum să reacționeze la avertismentul privind certificatul SSL sau EV-SSL
TEHNOLOGII EMERGENȚE ȘI SECURITATEA INFORMAȚIILOR:
Mai jos sunt discutate câteva tehnologii emergente care sunt din ce în ce mai mult adoptate/probabil să fie luate în
considerare în viitorul apropiat. Cu toate acestea, trebuie luate în considerare preocupările de securitate cu privire la astfel
de tehnologii.
Virtualizare
Fundal:
În ultimii 10 ani, tendința în centrul de date a fost către descentralizare, cunoscută și sub numele de scalare orizontală.
Serverele centralizate au fost considerate prea scumpe de cumpărat și întreținut. Datorită acestei cheltuieli, aplicațiile au
fost mutate de la un server mare partajat pe propria lor mașină fizică. Descentralizarea a ajutat la întreținerea continuă a
fiecărei aplicații, deoarece corecțiile și upgrade-urile puteau fi aplicate fără a interfera cu alte sisteme care rulează. Din
același motiv, descentralizarea îmbunătățește securitatea, deoarece un sistem compromis este izolat de alte sisteme din
rețea.
Cu toate acestea, sandbox-urile pentru aplicații ale descentralizării vin în detrimentul unui consum mai mare de energie,
mai mult spațiu fizic și un efort de management mai mare care a crescut costurile anuale de întreținere per mașină. Pe
lângă această suprasarcină de întreținere, descentralizarea scade eficiența fiecărei mașini, lăsând serverul mediu inactiv
85% din timp. Împreună, aceste ineficiențe elimină adesea orice economii promise prin descentralizare.
Virtualizarea este o soluție modificată între implementările centralizate și descentralizate. În loc să achiziționeze și să
întrețină un computer întreg pentru o aplicație, fiecărei aplicații i se poate oferi propriul sistem de operare și toate acele
sisteme de operare pot locui pe o singură piesă hardware. Acest lucru oferă beneficiile descentralizării, cum ar fi
securitatea și stabilitatea, profitând în același timp la maximum de resursele unei mașini.
Provocările virtualizării
Compatibilitate și suport – Adesea, dezvoltatorii de software nu sunt pregătiți să garanteze funcționarea

în siguranță a tuturor programelor lor în mașinile virtuale.
Licențiere – Este nevoie de o examinare amănunțită a licențelor sistemului de operare, precum și a altor
software-uri în ceea ce privește virtualizarea. Producătorii de sisteme de operare introduc unele limitări
Pagină 236
în utilizarea produselor lor în mașinile virtuale (în special versiunile OEM). Astfel de scenarii sunt
adesea descrise în capitole separate de licență. Pot exista, de asemenea, unele probleme cu software-ul
de licențiere bazat pe numărul de procesoare, deoarece o mașină virtuală poate emula un număr diferit
de procesoare decât într-un sistem gazdă.
Instruirea personalului - Această problemă este în prezent una dintre cele mai ardente, la fel ca și
dificultățile de a găsi experți exclusivi în virtualizare, care să poată implementa și întreține o
infrastructură virtuală. Platformele de virtualizare „grele” pot necesita o pregătire serioasă a
personalului care le va întreține.
Fiabilitate - Deoarece mai multe servere virtuale funcționează pe un singur server fizic, defecțiunile
componentelor hardware pot afecta toate serverele virtuale care rulează pe acesta. Planificarea și
implementarea strategiilor de recuperare în caz de dezastru pentru a asigura fiabilitatea unei
infrastructuri virtuale va fi o soluție mai bună.
Abordarea problemelor de securitate în virtualizare:
Există o concepție greșită că, dacă virtualizăm, să spunem, un Windows 2003 Server, acel sistem virtualizat ar trebui să
fie securizat, deoarece este complet separat de sistemul de operare VM Server și ar putea fi „protejat” de către VM Server.
Acest lucru nu este adevărat și există o mulțime de aspecte pe care trebuie să le cunoașteți despre securitatea virtualizării.
Atacul final asupra unui sistem gazdă virtual ar fi ca un sistem oaspete să ruleze cod rău intenționat, permițându-i să
obțină privilegii ridicate și să obțină acces la serverul VM de dedesubt. Dacă codul rău intenționat ar putea crea o nouă
mașină virtuală „fantomă” care ar putea fi controlată de atacator, aceștia ar avea acces deplin la gazda virtuală și la toți
oaspeții virtuali. Cu această formă de „hyperjacking”, atacatorul ar fi invizibil pentru software-ul tradițional de gestionare
a virtualizării și instrumentele de securitate. De acolo, atacatorul ar efectua un atac DoS (denial of service) prin
supraîncărcarea sistemelor invitate virtuale.
Mai jos acoperă mediile complete de virtualizare care sunt cel mai frecvent utilizate în servere. Mai jos sunt prezentate
câteva măsuri orientative majore. În plus, pot fi respectate măsurile de securitate detaliate recomandate de furnizor.
a. Securizarea platformei de virtualizare - Întărirea sistemului de operare cu partiții privilegiate – (i) Limitați utilizarea
resurselor VM: setați limite privind utilizarea resurselor (de exemplu, procesoare, memorie, spațiu pe disc, interfețe de
rețea virtuală) de către fiecare VM, astfel încât niciun VM să nu poată monopoliza resursele unui sistem. (ii) Asigurați
sincronizarea orei: asigurați-vă că gazda și oaspeții folosesc ora sincronizată în scopuri de investigație și criminalistică.
b. Programe și servicii inutile : toate programele inutile trebuie dezinstalate și toate serviciile inutile trebuie dezactivate.
c. Sistemul de operare gazdă trebuie corectat în mod regulat și în timp util pentru a se asigura că sistemul de operare
gazdă protejează în mod corespunzător sistemul în sine și sistemele de operare invitate. În plus, aceleași cerințe de
corecție se aplică și software-ului de virtualizare.
d. Restricții de spațiu de partiționare și alocare a resurselor : volumele sau partiționarea discurilor ar trebui să fie utilizate
pentru a preveni refuzările accidentale de serviciu de la mașinile virtuale (sisteme de operare invitate, sisteme de operare)
care umple alocările de spațiu disponibile și să permită plasarea controalelor de acces bazate pe roluri individual pe
fiecare virtuală mașină (OS invitat).
Pagină 237
e. Deconectați dispozitivele fizice neutilizate : VM-urile individuale pot fi configurate pentru a controla direct sau indirect
dispozitivele periferice atașate la sistemul gazdă. VM-urile ar trebui configurate implicit pentru a dezactiva astfel de
conexiuni. Conexiunile la dispozitivele periferice trebuie activate numai atunci când este necesar.
f. Dispozitive virtuale : asigurați-vă că dispozitivele virtuale pentru sistemele de operare invitate sunt asociate cu
dispozitivele fizice adecvate de pe sistemul gazdă, cum ar fi maparea dintre plăcile de interfață de rețea virtuală (NIC) la
NIC-urile fizice adecvate.
g. Partajarea fișierelor nu ar trebui să fie permisă între sistemele de operare gazdă și invitate : deși ar putea fi convenabil
să se activeze partajarea fișierelor de sistem între sistemele de operare gazdă și invitate, permiterea acestora introduce un
risc inacceptabil ca un sistem de operare invitat să schimbe în mod rău intenționat un fișier OS gazdă.
h. La fel ca în cazul serverelor fizice, sistemele virtuale trebuie să facă backup în mod regulat pentru recuperarea
erorilor.
i. Efectuarea înregistrării și auditării este esențială, împreună cu corelarea jurnalelor de server și rețea în infrastructurile
virtuale și fizice pentru a dezvălui vulnerabilitățile și riscurile de securitate
J. Accesul la rețea pentru sistemul de operare gazdă ar trebui să fie limitat doar la serviciile de management și, dacă este
necesar, accesul la rețea la stocare (iSCSI).
K. În mod ideal, un firewall ar trebui să fie plasat pe sistemul de operare gazdă pentru a proteja sistemul sau un firewall
ar trebui să fie cel puțin local pentru un număr mic de sisteme în scopuri de protecție, accesul fiind permis doar în scopuri
de management. În plus, firewall-ul ar trebui să restricționeze accesul doar la acele sisteme autorizate să gestioneze
infrastructura virtuală
l. Întărirea sistemului de operare pentru oaspeți - Minimizați numărul de conturi - oaspeții ar trebui să aibă conturile
necesare pentru a rula fiecare VM numai cu parole care sunt puternice, greu de ghicit, schimbate frecvent și furnizate
numai personalului care trebuie să aibă acces. Trebuie folosite acreditări separate pentru accesul la fiecare sistem de
operare invitat; acreditările nu trebuie partajate între sistemele de operare invitate și nu ar trebui să fie aceleași cu cele
utilizate pentru accesul la sistemul de operare gazdă
m. Sistemul de operare invitat trebuie protejat de un firewall care rulează pe sistemul de operare gazdă sau cel puțin
rulează local (adică, local pentru un număr mic de sisteme în scopuri de protecție). Firewall-ul trebuie să discrimineze
traficul inadecvat și/sau rău intenționat folosind comunicații de rețea eficiente pentru mediu (de exemplu, dacă se
folosește bridge-ul în loc de rutare).
n. Luați în considerare utilizarea capacităților de introspecție pentru a monitoriza securitatea activității care au loc între
sistemele de operare invitate. Acest lucru este deosebit de important pentru comunicațiile care, într-un mediu
nevirtualizat, au fost transmise prin rețele și monitorizate de controale de securitate a rețelei (cum ar fi firewall-uri de
rețea, dispozitive de securitate și senzori IDS/IPS de rețea).
Cloud Computing
Context : Mediul de calcul deținut de o companie este partajat cu companiile client prin intermediul serviciului web prin
Internet care găzduiește toate programele pentru a rula totul, de la e-mail la procesare de text la programe complexe de
analiză a datelor. Aceasta se numește cloud computing.
Termenul de cloud computing provine probabil de la utilizarea unei imagini cloud pentru a reprezenta Internetul sau un
Pagină 238
mediu de rețea mare. Nu ne interesează prea mult ce se află în cloud sau ce se întâmplă acolo, cu excepția faptului că
primim serviciile de care avem nevoie. Serviciul poate include software, platformă sau infrastructură.
La backend, cloud computing poate folosi virtualizarea și grid computing. În grid computing, computerele conectate în
rețea sunt capabile să acceseze și să utilizeze resursele oricărui alt computer din rețea.
Preocupări de cloud computing
Poate că cele mai mari preocupări legate de cloud computing sunt securitatea și confidențialitatea. Ideea de a preda date
importante unei alte companii îi îngrijorează pe unii. Directorii corporativi ar putea ezita să profite de un sistem de cloud
computing, deoarece nu pot păstra informațiile companiei lor sub cheie.
Confidențialitatea este o altă chestiune. Dacă un client se poate autentifica din orice locație pentru a accesa date și
aplicații, este posibil ca confidențialitatea clientului să fie compromisă. Companiile de cloud computing vor trebui să
găsească modalități de a proteja confidențialitatea clienților prin implementarea unor tehnici de autentificare fiabile.
Un sistem de cloud computing trebuie să asigure backup-ul tuturor informațiilor clienților săi.
Unele întrebări referitoare la cloud computing sunt mai legale. Utilizatorul sau compania care se abonează la serviciul de
cloud computing deține datele? Sistemul de cloud computing, care oferă spațiul de stocare real, îl deține? Este posibil ca o
companie de cloud computing să refuze unui client accesul la datele clientului respectiv? Mai multe companii, firme de
avocatură și universități dezbat aceste întrebări și alte întrebări despre natura cloud computingului. Astfel, există probleme
legate de securitatea și confidențialitatea datelor, de conformitate și aspecte legale/contractuale.
Câteva exemple de riscuri de cloud computing care trebuie gestionate includ:
Întreprinderile trebuie să fie deosebite în alegerea unui furnizor. Reputația, istoria și sustenabilitatea ar trebui să
fie toți factori de luat în considerare. Sustenabilitatea este de o importanță deosebită pentru a se asigura că
serviciile vor fi disponibile și că datele pot fi urmărite.
Furnizorul de cloud își asumă adesea responsabilitatea pentru gestionarea informațiilor, care este o parte critică a
afacerii. Nerespectarea nivelurilor de serviciu convenite poate afecta nu numai confidențialitatea, ci și
disponibilitatea, afectând grav operațiunile de afaceri.
Natura dinamică a cloud computing poate duce la confuzie cu privire la locul unde se află de fapt informațiile.
Atunci când este necesară regăsirea informațiilor, aceasta poate crea întârzieri.
Locația geografică a stocării și procesării datelor nu este certă, spre deosebire de centrul de date tradițional.
Fluxurile de date transfrontaliere, cerințele de continuitate a afacerii, păstrarea jurnalelor, păstrarea datelor,
pistele de audit sunt printre problemele care contribuie la provocările de conformitate în mediul Cloud
Computing.
Accesul terților la informațiile sensibile creează un risc de compromitere a informațiilor confidențiale. În cloud
Pagină 239
computing, acest lucru poate reprezenta o amenințare semnificativă pentru asigurarea protecției proprietății
intelectuale (IP), a secretelor comerciale și a informațiilor confidențiale ale clienților.
Problemele contractuale din serviciile cloud pot fi legate de proprietatea asupra proprietății intelectuale,
rezilierea unilaterală a contractului, blocarea furnizorului, stabilirea răspunderii și obligațiilor furnizorilor de
servicii cloud, clauza de ieșire etc.
Cloud-urile publice permit dezvoltarea unor sisteme de înaltă disponibilitate la niveluri de serviciu adesea
imposibil de creat în rețelele private, cu excepția unor costuri extraordinare. Dezavantajul acestei disponibilități
este potențialul de amestecare a activelor de informații cu alți clienți cloud, inclusiv concurenți. Respectarea
reglementărilor și legilor din diferite regiuni geografice poate fi o provocare pentru întreprinderi. În acest
moment, există puține precedente legale în ceea ce privește răspunderea în cloud. Este esențial să obțineți
consultanță juridică adecvată pentru a vă asigura că contractul specifică domeniile în care furnizorul de cloud
este responsabil și răspunzător pentru ramificațiile care decurg din potențiale probleme.
Datorită naturii dinamice a cloud-ului, este posibil ca informațiile să nu fie localizate imediat în cazul unui
dezastru. Continuitatea afacerii și planurile de recuperare în caz de dezastru trebuie să fie bine documentate și
testate. Furnizorul de cloud trebuie să înțeleagă rolul pe care îl joacă în ceea ce privește backup-urile, răspunsul
la incident și recuperarea. Obiectivele timpului de recuperare ar trebui să fie menționate în contract.
Furnizorii de servicii trebuie să demonstreze existența unor controale de securitate eficiente și robuste, asigurând clienții
că informațiile lor sunt securizate corespunzător împotriva accesului, modificării și distrugerii neautorizate. Întrebările
cheie pe care trebuie să le decideți sunt: Ce angajați (ai furnizorului) au acces la informațiile despre clienți? Se menține
segregarea sarcinilor între angajații furnizorilor? Cum sunt separate informațiile diferiților clienți? Ce controale sunt în
vigoare pentru a preveni, detecta și reacționa la încălcări
ESTE AUDIT
Introducere:
În ultimul deceniu, odată cu adoptarea crescută a tehnologiei de către bănci, complexitățile din mediul IT au dat naștere la
riscuri considerabile legate de tehnologie care necesită un management eficient.
Acest lucru a determinat băncile să implementeze un cadru de control intern, bazat pe diverse standarde și propriile
cerințe de control și liniile directoare actuale ale RBI. Ca urmare, conducerea Băncii și RBI au nevoie de o asigurare cu
privire la eficacitatea controalelor interne implementate și se așteaptă ca auditul IS să ofere o viziune independentă și
obiectivă asupra măsurii în care riscurile sunt gestionate.
În consecință, natura departamentului de Audit Intern a suferit o transformare majoră, iar auditurile IS câștigă importanță
pe măsură ce procesele cheie sunt automatizate sau activate de tehnologie. Prin urmare, este nevoie ca băncile să
reevalueze procesele de audit SI și să se asigure că obiectivele auditului SI sunt îndeplinite în mod eficient.
Scopul auditului IS include:
Determinarea eficacității planificării și supravegherii activităților IT
Pagină 240
Evaluarea adecvării proceselor de operare și a controalelor interne
Determinarea adecvării eforturilor de conformitate la nivel de întreprindere, legate de politicile IT și procedurile de

control intern
Identificarea zonelor cu controale interne deficiente, recomandarea acțiunilor corective pentru abordarea
deficiențelor și urmărirea, pentru a se asigura că managementul implementează în mod eficient acțiunile
necesare
În acest capitol au fost acoperite următoarele domenii:
Audit IS: Structura, rolurile și responsabilitățile organizației. Capitolul identifică părțile interesate ale auditului
IS, definește rolurile, responsabilitățile și competențele acestora necesare pentru a susține în mod adecvat funcția
de audit IS.
Carta sau politica de audit (care urmează să fie incluse în auditul SI): Acest punct abordează necesitatea
includerii auditului SI ca parte a Cartei sau politicii de audit.
Planificarea unui audit IS: Acest punct abordează planificarea unui audit IS, utilizând abordarea de audit bazată
pe risc. Începe cu înțelegerea conceptelor de evaluare a riscurilor IT, a metodologiei și definește universul de
audit IS, stabilirea domeniului și planificarea execuției unui audit.
Efectuarea unui audit IS: Acesta descrie pașii pentru executarea auditului, acoperind activități precum
înțelegerea procesului de afaceri și a mediului IT, rafinarea domeniului de aplicare și identificarea controalelor
interne, testarea pentru proiectarea și obiectivele controlului, probele de audit adecvate, documentarea
documentelor de lucru și concluziile testelor efectuate
Raportare și urmărire: Descrie rezumatul și memoriul auditului, cerințele pentru discutarea constatărilor cu
conducerea, finalizarea și transmiterea rapoartelor, efectuarea procedurilor de urmărire, arhivarea documentelor
și asigurarea auditului continuu
Evaluarea calității: Aceasta abordează aspectele de calitate care asigură supravegherea și exercitarea atenției
cuvenite.
Rol și responsabilități / Structura organizațională
Consiliul de administrație și conducerea superioară
Consiliul de administrație și conducerea superioară sunt responsabile pentru a se asigura că sistemul de control intern al
unei instituții funcționează eficient. Un element important al unei eficiente
sistemul de control intern este o funcție de audit intern care include o acoperire IT adecvată. Pentru a-și îndeplini
responsabilitatea de a oferi o funcție de audit independentă cu resurse suficiente pentru a asigura o acoperire IT adecvată,
Consiliul sau Comitetul de Audit ar trebui să activeze o funcție de audit intern, capabilă să evalueze în mod adecvat
controalele IT.
Comitetul de audit al Consiliului
Consiliul de administrație al unei instituții înființează un „Comitet de audit” pentru a supraveghea funcțiile de audit și
pentru a raporta periodic asupra chestiunilor de audit Consiliului de Administrație. Băncile ar trebui să permită formarea
comitetului de audit cu competențe adecvate pentru a gestiona complexitatea supravegherii auditului SI.
Un membru desemnat al unui comitet de audit trebuie să posede cunoștințe despre sistemele informaționale, controalele
Pagină 241
aferente și problemele de audit. Membrul desemnat ar trebui să aibă, de asemenea, competențe pentru a înțelege impactul
final al deficiențelor identificate în cadrul de control intern IT de către auditul IS. Comitetul ar trebui să aloce timp
adecvat constatărilor auditului SI identificate în timpul auditurilor SI, iar membrii Comitetului de Audit trebuie să
revizuiască problemele critice evidențiate și să ofere îndrumări adecvate conducerii unei bănci.
Ca parte a responsabilităților sale generale, comitetul ar trebui să fie, de asemenea, responsabil în ultimă instanță pentru
următoarele domenii de audit IS:
Conformitatea băncii cu cerințele legale și de reglementare, cum ar fi (printre altele) Legea privind tehnologia
informației din 2000, Legea privind tehnologia informației (amendament) din 2008, Legea privind cărțile
bancare (Dovezile) din 1891, Actul privind reglementarea bancară din 1949, Legea Rezervei Bank of India -
1934 și circulare și linii directoare RBI
Numirea șefului de audit IS
Efectuarea auditului IS
Evaluarea problemelor semnificative ale auditului IS

(Un consiliu sau membrii comitetului său de audit ar trebui să caute formare pentru a umple orice lacune în cunoștințele
legate de riscurile și controalele IT.)
Audit intern/functie de audit al sistemului informatic
Auditul intern este o parte a procesului de asigurare al Consiliului cu privire la integritatea și eficacitatea sistemelor și
controalelor. Este un grup independent care raportează direct Comitetului de Audit sau Consiliului de Administrație.
Auditul IS, fiind parte integrantă a auditului intern, necesită o structură organizațională cu roluri bine definite, care trebuie
să funcționeze în concordanță cu auditul intern și să ofere suport de audit tehnic în domeniile cheie de interes ale auditului
sau a universului acestuia, identificate de un audit intern. Departamentul de audit. O structură organizatorică de audit IS
bine definită asigură că sarcinile îndeplinite îndeplinesc obiectivul general de audit al unei bănci, păstrând în același timp
independența, obiectivitatea și competența acesteia.
În acest sens, băncile necesită o funcție separată de audit IS în cadrul unui departament de Audit Intern condus de un șef
de audit IS raportat șefului de audit intern sau directorului executiv de audit (CAE). Personalul trebuie să își asume
responsabilitatea generală și responsabilitatea funcțiilor de audit IS. În cazul în care banca folosește resurse externe pentru
efectuarea auditului SI în domeniile în care lipsesc competențele, responsabilitatea și responsabilitatea pentru astfel de
audituri SI externe rămân în continuare la șeful auditului SI și a CAE.
Componente și procese critice
Deoarece auditul IS este o parte integrantă a auditorilor interni, auditorilor li se va cere, de asemenea, să fie
independenți, competenți și să dea dovadă de grijă profesională.
Independență: Auditorii IS trebuie să acționeze independent de conducerea băncii. În problemele legate de audit, auditul
IS trebuie să fie independent de auditat, atât ca atitudine, cât și ca aspect. Carta sau politica de audit sau scrisoarea de
Pagină 242
angajament (în cazul furnizorului extern de servicii profesionale) ar trebui să abordeze independența și responsabilitatea
funcției de audit. În cazul în care independența este afectată (de fapt sau aparență), detaliile deprecierii trebuie dezvăluite
Comitetului de Audit sau Consiliului. Independența ar trebui să fie evaluată în mod regulat de către Comitetul de Audit.
În cazul rotației membrilor personalului de audit de la departamentul IT la Auditul SI, trebuie avut grijă să se asigure că
rolul trecut al acestor persoane nu afectează independența și obiectivitatea lor ca auditor SI.
În plus, pentru a asigura independența auditorilor IS, băncile ar trebui să se asigure că:
Auditorii au acces la informații și aplicații
Auditorii au dreptul de a efectua inspecții și analize independente ale datelor
Competență: Auditorii IS trebuie să fie competenți profesional, să aibă abilități, cunoștințe, pregătire și experiență
relevantă. Aceștia ar trebui să fie calificați corespunzător, să aibă certificări profesionale și să mențină competența
profesională prin educație și formare profesională. Întrucât IT cuprinde o gamă largă de tehnologii, auditorii IS ar trebui
să posede abilități proporționale cu tehnologia utilizată de o bancă. Aceștia ar trebui să fie profesioniști de audit
competenți, cu experiență suficientă și relevantă. Calificări precum CISA (oferită de ISACA), DISA (oferită de ICAI) sau
CISSP (oferită de ISC2), împreună cu doi sau mai mulți ani de experiență în audit IS, sunt de dorit. Ar trebui insistat
asupra unor criterii de calificare similare, de asemenea, în cazul furnizorilor de servicii profesionale externalizați.
Grija profesională cuvenită: Auditorii IS trebuie să aibă grijă profesională cuvenită, care include respectarea standardelor
profesionale de audit în efectuarea auditului. Șeful auditului SI ar trebui să se ocupe de orice problemă în aplicarea
acestora în timpul auditului. Auditorii IS trebuie să mențină cel mai înalt grad de integritate și conduită. Ei nu ar trebui să
adopte metode care ar putea fi considerate ilegale, neetice sau neprofesionale pentru a obține sau a executa un audit.
Outsourcing legat de auditul IS
Băncile pot decide să externalizeze execuția segmentelor planului de audit către furnizori externi de servicii profesionale,
în conformitate cu strategia generală de audit decisă în coordonare cu CAE și Comitetul de Audit. Acest lucru se poate
datora personalului inadecvat disponibil intern în cadrul băncii pentru a efectua audituri sau nivelurilor insuficiente de
personal calificat. Lucrările externalizate vor fi limitate la executarea auditurilor identificate în plan. Băncile trebuie să se
asigure că proprietatea și responsabilitatea generală a auditului IS, inclusiv procesul de planificare a auditului, evaluarea
riscurilor și urmărirea conformității rămân în cadrul băncii. Asistența externă poate fi obținută inițial pentru a pune în
aplicare procesele necesare în acest sens.
Atât CAE, cât și Comitetul de Audit ar trebui să se asigure că furnizorii externi de servicii profesionale numiți ar trebui să
fie competenți în domeniul de lucru care este externalizat și ar trebui să aibă experiență anterioară relevantă în acest
domeniu.
Carta de audit, Politica de audit pentru a include auditul IS
Pagină 243
Carta sau politica de audit este un document care ghidează și conduce activitățile unei funcții de audit intern. Auditul IS,
fiind parte integrantă a unui departament de Audit Intern, ar trebui, de asemenea, să fie guvernat de aceeași cartă sau
politică. Carta ar trebui să fie documentată astfel încât să conțină o descriere clară a mandatului, scopului,
responsabilității, autorității și responsabilității membrilor sau funcționarilor relevanți în ceea ce privește auditul SI (și
anume auditorii SI, managementul și Comitetul de audit), în afară de principiile de funcționare. Auditorul SI va trebui să
determine cum să realizeze implementarea standardelor de audit SI aplicabile, să folosească raționamentul profesional în
aplicarea lor și să fie pregătit să justifice orice abatere de la acestea.
Conținutul politicii de audit

Politica ar trebui să abordeze în mod clar aspectele de responsabilitate, autoritate și responsabilitate
Unele dintre aspecte includ:
Declarație de misiune
Domeniu de aplicare sau Acoperire
Metodologia de audit
Obiective
Independenţă
Relația cu Auditul Extern
Cerințe ale auditatului
Factorii critici de succes
indicatori de performanta
Alte Măsuri ale Performanței
Oferirea asigurării asupra mediului de control
Revizuirea controalelor privind confidențialitatea, integritatea și disponibilitatea datelor sau a sistemelor
Autoritate:
Include următoarele:
Mandatul de a efectua un audit IS
Alocarea resurselor
Dreptul de a accesa informațiile relevante, personalul, locațiile și sistemele
Domeniul de aplicare sau limitările domeniului de aplicare
Funcții de auditat
Așteptările auditatului
Structura organizationala
Gradarea funcționarilor sau personalului de audit IS
Responsabilitate: Unele dintre aspectele în acest sens includ următoarele:
Pagină 244
Linii de raportare către conducerea superioară, consiliul de administrație sau autoritatea desemnată
Evaluări ale performanței misiunii
Evaluările performanței personalului
Angajarea personalului sau dezvoltarea carierei
Formarea și dezvoltarea abilităților, inclusiv menținerea certificărilor profesionale, educație profesională continuă
Drepturile Auditaților
Evaluări independente de calitate
Evaluarea conformității cu standardele
Benchmarking performanță și funcții
Evaluarea Finalizării Planului de Audit
Acțiuni convenite (de exemplu, penalități atunci când oricare dintre părți nu își îndeplinește responsabilitățile)
Coordonează și asigură supravegherea altor funcții de control, cum ar fi managementul riscurilor, securitatea și
conformitatea
Politica ar trebui să acopere, de asemenea, metodologia de evaluare a auditului și evaluările de asigurare a calității. De
asemenea, ar trebui să existe o revizuire anuală a Politicii sau a Cartei de audit IS pentru a asigura relevanța continuă.
Comunicarea cu Auditații
Comunicarea eficientă cu entitățile auditate presupune luarea în considerare a următoarelor aspecte:
Descrierea unui serviciu, domeniul său de aplicare, disponibilitatea și promptitudinea livrării
Furnizarea de estimări de costuri sau bugete, dacă este necesar
Descrierea problemelor și posibilele soluții

Furnizarea de facilități adecvate și accesibile pentru o comunicare eficientă
Stabilirea relației dintre serviciul oferit și nevoile auditatului
Carta de audit formează o bază pentru comunicarea cu un auditat. Ar trebui să includă referințe relevante la acordurile de
nivel de serviciu pentru aspecte precum următoarele, după caz:
Disponibilitate pentru lucrări neplanificate
Livrarea rapoartelor
Cheltuieli
Răspuns la plângerile auditatului
Calitatea serviciului
Revizuirea performanței
Comunicarea cu auditatul
Necesită evaluare
Control Risc Autoevaluare
Acordul privind Termenii de Referință pentru Audit
Pagină 245
Procesul de raportare
Acordul constatărilor
Procesul de asigurare a calității
Auditorul IS ar trebui să ia în considerare stabilirea unui proces de asigurare a calității (de exemplu, interviuri, sondaje de
satisfacție a clienților sau anchete de performanță a misiunii) pentru a înțelege așteptările sale relevante pentru funcție.
Aceste nevoi ar trebui evaluate în raport cu Carta, pentru a îmbunătăți serviciul sau pentru a modifica prestarea serviciilor
sau Carta de audit, dacă este necesar.
Scrisoare de angajament
Scrisorile de logodnă sunt adesea folosite pentru sarcini individuale. Acestea stabilesc domeniul de aplicare și obiectivele
unei relații dintre o agenție externă de audit IS și o organizație. Scrisoarea ar trebui să abordeze cele trei aspecte de
responsabilitate, autoritate și responsabilitate.
Trebuie luate în considerare următoarele aspecte:
Responsabilitate: Aspectele abordate includ domeniul de aplicare, obiectivele, independența, evaluarea riscurilor,
cerințele specifice ale auditatului și rezultatele
Autoritate: Aspectele care trebuie abordate includ dreptul de acces la informații, personal, locații și sisteme relevante
pentru îndeplinirea misiunii, domeniul de aplicare sau orice limitări ale domeniului de aplicare și dovezi documentare sau
informații de acord cu termenii și condițiile misiunii.
Responsabilitate: domeniile abordate includ destinatarii desemnați sau vizați ai rapoartelor, drepturile auditaților,
evaluările calității, datele de finalizare convenite și bugetele sau taxele convenite, dacă sunt disponibile
Planificarea unui audit IS
(a) Introducere
Un program eficient de audit IS abordează expunerile la riscurile IT în cadrul unei bănci, inclusiv domeniile
managementului IT și planificarea strategică, operațiunile centrelor de date, arhitectura client sau server, rețele locale și
extinse, telecomunicații, securitate fizică și a informațiilor, servicii bancare electronice, aplicații utilizate în operațiunile
bancare, dezvoltarea sistemelor și planificarea continuității afacerii.
Un program de audit bine planificat și structurat corespunzător este esențial pentru a evalua practicile de management al
riscului, sistemele de control intern și conformitatea cu politicile privind riscurile legate de IT de orice dimensiune și
complexitate. Programele eficiente sunt concentrate pe risc, promovează controale IT solide, asigură soluționarea în timp
util a deficiențelor de audit și informează Comitetul de Audit cu privire la eficacitatea practicilor de management al
riscului și a sistemelor de control intern.
În trecut, Auditul Intern s-a concentrat pe testarea tranzacțiilor, testarea acurateței și fiabilității înregistrărilor contabile și
Pagină 246
a rapoartelor financiare, pe integritatea, fiabilitatea și actualitatea rapoartelor de control și pe respectarea cerințelor legale
și de reglementare.
Cu toate acestea, în scenariul în schimbare, există o nevoie crescută de lărgire, precum și redirecționare, a sferei de
aplicare a Auditului Intern pentru a evalua adecvarea procedurilor de management al riscului IT și a sistemelor de control
intern. Pentru a realiza acestea, băncile se îndreaptă către auditul intern bazat pe risc, care include, pe lângă testarea
selectivă a tranzacțiilor, o evaluare a sistemelor de management al riscului și a procedurilor de control predominante în
operațiunile unei bănci.
Abordarea auditului intern bazat pe risc ( RBIA) ajută la planificarea auditului IS.
Acesta include următoarele componente:

Înțelegerea conceptelor de evaluare a riscurilor IT
Adoptarea unei metodologii adecvate de evaluare a riscurilor IT – utilizată pentru a examina unitățile auditabile din
universul de audit SI și pentru a selecta zonele de revizuire pentru a le include în Planul anual SI care au cea mai
mare expunere la risc
Pașii implicați sunt:
Pasul 1: Caracterizarea sistemului
Pasul 2: Identificarea amenințărilor
Pasul 3: Identificarea vulnerabilităților
Pasul 4: Analiza de control
Pasul 5: Determinarea probabilității
Pasul 6: Analiza impactului
Pasul 7: Determinarea riscului
Ca parte a RBIA, planificarea auditului IS implică următoarele:
Definirea universului de audit IS: Acesta acoperă universul de audit IS, care definește domeniile care trebuie
acoperite
Domeniul de aplicare pentru auditul IS: Acesta abordează cerințele de acoperire și include:
Definirea obiectivelor și activităților de control
Luând în considerare materialitatea
Construirea unei perspective de risc de fraudă
Planificarea execuției unui audit: Acesta descrie pașii unui proces de planificare înainte ca auditul IS să înceapă
execuția planului.
Documentarea unui plan de audit
Pagină 247
Natura și amploarea testului de control

Tehnici de eșantionare
Standarde și cadre
Managementul resurselor
Componentele de mai sus sunt clarificate în sub-secțiunile de mai jos:
(b) Audit IS bazat pe risc

Această abordare de audit intern are ca scop dezvoltarea unui plan de audit bazat pe riscuri, ținând cont de riscurile
inerente ale unei afaceri sau locații și eficacitatea sistemelor de control care gestionează riscurile inerente. În această
abordare, fiecare activitate sau locație bancară, inclusiv funcția de management al riscului, este supusă unei evaluări a
riscurilor de către funcția de audit intern.
În 2002, RBI a emis „Notă de orientare privind auditul intern bazat pe risc” tuturor băncilor comerciale programate,
introducând sistemul de „audit intern bazat pe risc”.
Nota de orientare la nivel larg a furnizat următoarele aspecte:
Dezvoltarea unei politici bine definite pentru auditul intern bazat pe risc
Adoptarea unei metodologii de evaluare a riscurilor pentru formularea unui plan de audit bazat pe risc
Dezvoltarea profilului de risc și întocmirea matricei de risc asumând riscul inerent de afaceri și eficacitatea
sistemului de control pentru monitorizarea riscului
Pregătirea planului anual de audit, care să acopere riscurile și prioritizarea, pe baza nivelului și direcției fiecărui risc.
Stabilirea canalelor de comunicare între personalul de audit și conducere, pentru raportarea problemelor care
reprezintă o amenințare pentru afacerea unei bănci
Evaluarea periodică a metodologiei de evaluare a riscurilor
Identificarea personalului adecvat pentru a efectua auditul bazat pe riscuri și oferirea de formare relevantă a acestora.
Abordarea problemelor de tranziție și de management al schimbării
Planul general, elaborat, folosind abordarea de evaluare a riscurilor, permite Auditului Intern să identifice și să examineze
domeniile cheie de afaceri care au cea mai mare expunere și permite alocarea eficientă a resurselor de Audit. După cum s-
a afirmat mai devreme, auditul IS, fiind parte integrantă a auditului intern, este nevoie ca auditorii SI să se concentreze pe
riscurile IT, legate de domeniile de afaceri cu risc ridicat identificate de auditul intern pentru revizuire pe parcursul unui
an. Acest lucru permite auditului IS să ofere conducerii o asigurare cu privire la eficacitatea managementului riscului și a
controalelor interne care stau la baza proceselor de afaceri cu risc ridicat, care, atunci când sunt citite împreună cu
rapoartele de audit intern, oferă o viziune holistică a eficacității.
Auditul IS bazat pe risc trebuie să ia în considerare următoarele:
Identificarea datelor, aplicației, tehnologiei, facilităților și personalului unei instituții

Identificarea activităților și proceselor de afaceri din fiecare dintre acele categorii
Profilurile unităților de afaceri semnificative, departamentelor și liniilor de produse și
sistemelor, precum și riscurile de afaceri asociate și caracteristicile de control ale acestora,
Pagină 248
rezultând într-un document care descrie structura riscului și a controalelor în cadrul instituției
Utilizați un sistem de măsurare sau de notare care ierarhizează și evaluează riscurile de afaceri
și de control pentru unitățile de afaceri, departamente și produse
Include aprobarea consiliului sau a comitetului de audit a evaluărilor riscurilor și a planurilor

anuale de audit bazate pe riscuri care stabilesc programe de audit, cicluri, sfera programului de
lucru și alocarea resurselor pentru fiecare zonă auditată.
Implementarea Planului de Audit
În plus, în timp ce identifică riscurile IT, un auditor IS trebuie să ia în considerare impactul nealinierii cu orice orientări
legate de securitatea informațiilor emise de RBI pe baza recomandărilor din Capitolul 2 al acestui raport. De asemenea, ar
trebui să se asigure că toate sistemele, domeniile și procesele, indiferent de nivelul lor de risc, sunt acoperite într-o
perioadă de trei ani.
(c) Adoptarea unei metodologii adecvate de evaluare a riscurilor
Auditorul IS trebuie să definească, să adopte și să urmeze o metodologie adecvată de evaluare a riscurilor. Acest lucru ar
trebui să fie în concordanță cu accentul pus pe riscuri, care trebuie abordat ca parte a strategiei generale de audit intern.
Un program de audit IS bazat pe riscuri de succes se poate baza pe un sistem eficient de punctare la care se ajunge luând
în considerare toți factorii de risc relevanți.
Factorii de risc majori utilizați în sistemele de scorare includ: adecvarea controalelor interne, criticitatea afacerii, cerințele
de reglementare, cantitatea sau valoarea tranzacțiilor procesate, dacă sunt deținute informații cheie despre client, sistemele
care se confruntă cu clienții, potențialul de pierdere financiară, numărul
de tranzacții procesate, cerințele de disponibilitate, experiența conducerii și a personalului, cifra de afaceri, competența
tehnică, gradul de delegare, complexitatea tehnică și a procesului, stabilitatea aplicației, vechimea sistemului, pregătirea
utilizatorilor, numărul de interfețe, disponibilitatea documentației, gradul de dependență privind sistemul informatic,
cerințele de confidențialitate, modificările majore efectuate, observațiile anterioare de audit și supravegherea conducerii
superioare.
Pe baza matricei de risc de criticitate a afacerii și a riscului de sistem sau rezidual, aplicațiile sau sistemele pot fi
clasificate, în funcție de locul în care se încadrează pe „harta riscurilor” și, în consecință, se poate decide frecvența lor de
audit. Băncile ar trebui să elaboreze orientări scrise cu privire la utilizarea instrumentelor de evaluare a riscului și a
factorilor de risc și să le revizuiască împreună cu Comitetul de Audit sau Consiliul. Orientările de evaluare a riscurilor vor
varia pentru bănci, în funcție de dimensiunea, complexitatea, domeniul de activitate, diversitatea geografică și sistemele
tehnologice utilizate. Auditorii ar trebui să utilizeze liniile directoare pentru a clasifica zonele de risc majore și pentru a
defini gama de scoruri sau evaluări
(de exemplu, grupări precum risc scăzut, mediu sau ridicat sau o secvență numerică, cum ar fi 1 până la 5).
Orientările scrise de evaluare a riscurilor ar trebui să specifice următoarele elemente:
Durata maximă pentru ciclurile de audit pe baza procesului de evaluare a riscului: De exemplu, ciclul de audit al
aplicațiilor cu risc foarte mare până la mare poate fi la o frecvență cuprinsă între șase luni și 12, cererile cu risc
mediu pot fi de 18 luni (sau mai puțin) și până la 36 de luni. luni pentru zonele cu risc scăzut. Ciclurile de audit
nu ar trebui să fie deschise.
Pagină 249
Momentul evaluărilor riscurilor pentru fiecare domeniu de activitate sau departament: În timp ce evaluarea riscului
este de așteptat să fie anual, pot fi necesare evaluări frecvente dacă o instituție se confruntă cu o creștere rapidă
sau schimbare în operațiuni sau activități.
Cerințe de documentare pentru a sprijini evaluarea riscurilor și deciziile de punctare

Orientări pentru depășirea evaluărilor riscurilor în cazuri speciale și circumstanțele în care acestea pot fi depășite:
Exemplu: din cauza schimbărilor majore în sistem, a cerințelor suplimentare de reglementare sau legale, este
posibil ca o aplicație cu risc mediu să fie auditată mai frecvent.
Fără a aduce atingere celor de mai sus, guvernanța IT, aspectele legate de guvernanța securității informațiilor, controalele
generale critice ale IT, cum ar fi controalele și procesele centrelor de date și aplicațiile/sistemele de afaceri critice cu
implicații financiare/de conformitate, inclusiv raportarea reglementărilor, managementul riscurilor, accesul clienților
(canale de livrare) și sistemele MIS, trebuie să fie supuse auditului IS cel puțin o dată pe an (sau mai des, dacă este
justificat de evaluarea riscului).
Auditorii IS ar trebui să revizuiască periodic rezultatele proceselor de control intern și să analizeze datele financiare sau
operaționale pentru orice impact asupra evaluării riscurilor sau a punctajului. În consecință, unităților auditate ar trebui să
li se solicite să țină auditorii la curent cu schimbările majore, cum ar fi introducerea unui nou produs, implementarea unui
nou sistem, conversiile aplicațiilor, schimbări semnificative în organizație sau personal, cerințe de reglementare și legale,
incidente de securitate. .
Definirea Universului de Audit IS
Un univers de audit este un rezultat al procesului de evaluare a riscurilor. Acesta definește domeniile de audit care
urmează să fie acoperite de auditorul IS. Este de obicei o structură la nivel înalt care identifică procesele, resursele,
riscurile și controalele legate de IT, permițând o selecție bazată pe risc a zonelor de audit. Riscurile IT cu care se
confruntă băncile din cauza tehnologiilor emergente, prioritizarea Universului de audit IS, selecția tipurilor de audituri
care trebuie efectuate, optimizarea resurselor disponibile și asigurarea calității constatărilor, sunt provocări cu care se
confruntă auditul IS.
Universul de audit IS poate fi construit în jurul celor patru tipuri de resurse și procese IT:
Cum ar fi sisteme de aplicații, informații sau date, infrastructură (tehnologie și facilități precum hardware, sisteme de
operare, sisteme de gestionare a bazelor de date, rețele, multimedia și mediul care le găzduiește și le susține și care
permite procesarea aplicațiilor) și oamenii (personal intern sau externalizat). necesare pentru planificarea, organizarea,
achiziționarea, implementarea, furnizarea, sprijinirea, monitorizarea și evaluarea sistemelor și serviciilor informaționale).
Provocarea este de a oferi „nivelul potrivit de granularitate” în definiția universului, astfel încât să fie eficient și eficient.
Deși acest lucru este diferit pentru fiecare bancă, mai jos sunt câteva dintre considerentele pentru definirea auditurilor IS:
Utilizarea unor definiții prea largi pentru auditurile SI (de exemplu, controalele generale IT) va asigura o extindere a
domeniului de aplicare a procedurilor de audit. Șeful auditului IS trebuie să se asigure că definiția fiecărui audit
IS este o descriere exactă a ceea ce este revizuit.
Audit Universe pentru un an ar trebui să atingă toate straturile din mediul IT. Deși fiecare mediu IT este diferit,
straturile tind să fie aceleași. Dacă un plan de audit IS nu include o analiză pentru fiecare dintre straturi, există
șanse ca planul, în ansamblu, să fie deficitar.
Pagină 250
Auditurile IS ar trebui să fie structurate astfel încât să asigure o raportare eficientă și logică. De exemplu: Auditurile
IS ale tehnologiilor omniprezente (de exemplu, rețele sau procese) sunt mai eficiente atunci când sunt auditate la
nivel de întreprindere.
Auditurile IS ar trebui să abordeze riscurile adecvate. În multe cazuri, bugetele auditului IS sunt determinate înainte
de efectuarea evaluării riscului IT. Acest lucru duce inevitabil la una dintre cele două situații:
Un număr inadecvat de ore de audit este împărțit pe prea multe audituri, ceea ce are ca rezultat audituri de calitate proastă,
deoarece nu este suficient timp.
Auditurile care ar trebui efectuate nu sunt efectuate deoarece bugetul nu permite acest lucru.
Scoping pentru auditul IS
Informațiile colectate de auditorii IS în timpul evaluării riscului IT despre procesarea sistemului IT și mediul operațional,
amenințări, vulnerabilități, impact și controale, permit identificarea obiectivelor și activităților de control care trebuie
testate pentru eficacitatea proiectării și implementării și eficacitatea operațională a acestuia.
Scoping joacă un rol crucial în eficacitatea generală. Acest lucru este exacerbat de necesitatea auditorilor IS de a se
integra cu auditorii de proces, operaționali sau financiari și cu procedurile pe care le efectuează, în special în medii cu
aplicații CBS mari integrate, unde un număr mare de controale cheie ale procesului sunt conținute în sisteme. . (O listă
ilustrativă a domeniilor care pot face parte din domeniul de aplicare al auditului IS este dată în Anexa-B.)
Auditurile IS ar trebui să acopere, de asemenea, sucursale, cu accent pe sucursalele mari și mijlocii, în domenii precum
controlul parolelor, ID-urile utilizatorului, securitatea sistemului de operare, anti-malware, maker-checker, segregarea
sarcinilor, securitatea fizică, revizuirea rapoartelor de excepție sau piste de audit, politica BCP și/sau testare.
Rapoarte și circulare emise de RBI pentru domenii specifice care trebuie, de asemenea, acoperite în
Domeniul auditului IS:

Raportul Comitetului pentru Auditul Informatic (datat: 2 aprilie 2002) Circulară privind Auditul Sistemului
Informațional – O revizuire a politicilor și practicilor
(datat: 30 aprilie 2004 (RBI/2004/191 DBS.CO.OSMOS.BC/ 11 /33.01.029/2003-04)
Definirea obiectivelor și activităților de control
Obiectivele de control IT, bazate pe cadre bine cunoscute pot fi incluse în domeniu.
Materialitate
Atunci când efectuează audituri ale situațiilor financiare, auditorii interni măsoară semnificația în termeni monetari,
deoarece domeniile care sunt auditate sunt, de asemenea, măsurate și raportate în termeni monetari. Cu toate acestea,
deoarece auditorii SI efectuează audit asupra elementelor nefinanciare, sunt necesare măsuri alternative pentru a evalua
Pagină 251
semnificația. Astfel de evaluări sunt o chestiune de raționament profesional. Acestea includ luarea în considerare a
efectului său asupra unei bănci în ansamblu, a erorilor, omisiunilor, neregulilor și actelor ilegale, care s-ar fi putut
întâmpla ca urmare a „deficiențelor controlului intern” într-un domeniu auditat. ISACA IS Auditing Guideline G6:
specifică faptul că, în cazul în care se concentrează auditul SI se referă la sisteme sau operațiuni care procesează tranzacții
financiare, valoarea activelor controlate de sistem(e) sau valoarea tranzacțiilor procesate pe zi/săptămână/lună/an, ar
trebui luate în considerare la evaluarea semnificației. În cazul în care, accentul se pune pe sistemele care nu procesează
tranzacții financiare, atunci trebuie luate în considerare următoarele măsuri:
Criticitatea proceselor de afaceri susținute de sistem sau operațiune
Costul sistemului sau al operațiunii (hardware, software, personal, servicii terțe, cheltuieli generale sau o combinație
a acestora)
Costul potențial al erorilor (posibil în termeni de costuri irecuperabile de dezvoltare, costuri de publicitate necesare
pentru avertismente, costuri de rectificare, costuri pentru sănătate și siguranță, risipă mare etc.)
Numărul de accesări/tranzacții/interogări procesate pe perioadă
Natura, calendarul și amploarea rapoartelor pregătite și fișierele păstrate
Cerințe privind acordul de nivel de serviciu și costul eventualelor penalități
Sancțiuni pentru nerespectarea cerințelor legale și contractuale
Auditorii IS ar trebui să examineze următoarele domenii suplimentare care sunt critice și cu risc ridicat, cum ar fi:
Structuri și practici de guvernanță IT și securitate a informațiilor implementate de Bancă
Testarea controalelor pe noile sisteme de dezvoltare înainte de a le implementa în mediul live.
Ar trebui efectuată o revizuire înainte de implementare a controalelor aplicației, inclusiv a

caracteristicilor de securitate și a controalelor asupra procesului de management al
schimbărilor, pentru a confirma că:
Controalele din aplicația existentă nu sunt diluate, în timp ce se migrează datele către
noua aplicație
Controalele sunt concepute și implementate pentru a îndeplini cerințele politicilor și
procedurilor unei bănci, în afară de cerințele legale și de reglementare
Funcționalitatea oferită de aplicație este utilizată pentru a îndeplini obiectivele de

control adecvate
Ar trebui efectuată o revizuire ulterioară implementării controalelor aplicației pentru a

confirma dacă controalele așa cum au fost concepute sunt implementate și funcționează
eficient. Revizuirea periodică a controalelor aplicației ar trebui să facă parte din domeniul de
aplicare al auditului SI, pentru a detecta impactul modificărilor aplicației asupra controalelor.
Acest lucru ar trebui să fie cuplat cu revizuirea mediului de bază – sistem de operare, baze de
date, middleware etc. – deoarece slăbiciunile mediului de bază pot anula eficacitatea
controalelor la nivelul aplicației. Trebuie acordată atenția cuvenită pentru a se asigura că
auditorii IS au acces numai la mediul de testare pentru efectuarea procedurilor și datele
utilizate pentru testare ar trebui să fie, în măsura în care este practic, o replică a mediului live.
Ar trebui efectuat un audit detaliat al procesului SDLC pentru a confirma că caracteristicile de

securitate sunt încorporate într-un sistem nou sau în timpul modificării unui sistem existent.
Pagină 252
Ar trebui urmată o revizuire a proceselor urmată de o echipă de implementare pentru a asigura

integritatea datelor după implementarea unei noi aplicații sau a unui sistem și o revizuire a
migrării datelor de la sistemele vechi la noul sistem, acolo unde este cazul.
Auditorii IS pot valida riscurile IT (identificate de echipele de afaceri) înainte de a lansa un
produs sau serviciu. Revizuirea de către auditorul IS poate permite echipelor de afaceri să
încorporeze controale suplimentare, dacă este necesar, în sistem înainte de lansare.
Construirea perspectivei riscului de fraudă
În planificarea și efectuarea unui audit pentru a reduce riscurile la un nivel scăzut, auditorul trebuie să ia în considerare
riscul de nereguli și acte ilegale. El ar trebui să mențină scepticismul profesional în timpul unui audit, recunoscând
posibilitatea ca „declarații materiale eronate datorate neregulilor și actelor ilegale” să poată exista, indiferent de evaluarea
riscului de nereguli și acte ilegale.
Auditorii IS trebuie, de asemenea, să ia în considerare și să evalueze riscul de fraudă, în timpul efectuării unui audit.
Aceștia ar trebui să elaboreze planuri, proceduri și teste adecvate, pentru a detecta neregulile, care pot avea un efect
semnificativ fie asupra unui anumit domeniu care face obiectul unui audit, fie asupra băncii în ansamblu. Auditorii IS ar
trebui să ia în considerare dacă deficiențele controlului intern ar putea duce la nereguli semnificative, care nu sunt
prevenite sau detectate. Auditorul trebuie să elaboreze și să realizeze proceduri pentru a testa caracterul adecvat al
controlului intern și riscul de depășire a controalelor. Aceștia ar trebui să cunoască în mod rezonabil factorii și indicatorii
de risc de fraudă și să evalueze riscul de nereguli legate de domeniul auditat.
În conformitate cu înțelegerea adunată în timpul etapei de identificare a amenințărilor din procesul de evaluare a riscurilor
IT, auditorii trebuie să identifice obiectivele și activitățile de control. Acestea trebuie testate pentru a aborda riscul de
fraudă. El ar trebui să ia în considerare „evaluările vulnerabilității la fraudă” întreprinse de „Grupul de management al
riscului de fraudă”, în timp ce identifică factorii de risc de fraudă în procesul de evaluare a riscului IT. El ar trebui să fie
conștient de faptul că anumite situații pot crește vulnerabilitatea unei bănci la riscul de fraudă (de exemplu, introducerea
unei noi linii de afaceri, noi produse, noi canale de livrare și noi aplicații sau sisteme.)
În pregătirea unui domeniu de audit, auditorii trebuie să ia în considerare factorii de risc de fraudă, inclusiv aceștia:
Nereguli și acte ilegale care sunt comune industriei bancare
Etica corporativă, structura organizațională, caracterul adecvat al supravegherii, structurile de compensare și
recompensă, amploarea presiunilor asupra performanței
Comportamentul managementului cu privire la etica

Nemulțumirea angajaților rezultată din potențiale concedieri, externalizare, cesionare sau restructurare
Performanță financiară sau operațională slabă
Risc care rezultă din introducerea de noi produse și procese
Istoricul băncii de fraudă
Modificări recente în echipele de management, operațiuni sau sisteme IT
Existența activelor deținute sau a serviciilor oferite și susceptibilitatea acestora la nereguli
Puterea controalelor relevante implementate
Cerințe legale sau de reglementare aplicabile
Istoricul constatărilor din auditurile anterioare
Constatările evaluărilor efectuate în afara auditului, cum ar fi constatările de la auditori externi, consultanți, echipe de
asigurare a calității sau investigații specifice
Constatări raportate de conducere, care au apărut în cursul zilnic al activității
Complexitatea și sofisticarea tehnică a sistemului (sistemelor) informaționale care sprijină zona supusă auditului
Pagină 253
Existența unor sisteme de aplicații interne (dezvoltate sau întreținute), în comparație cu software-ul ambalat pentru
sistemele de business de bază
Cazurile de fraudă ar trebui raportate părților interesate adecvate ale băncii:
Fraudele care implică sume de Rs 1 crore (și mai mult) ar trebui raportate Comitetului Special format pentru a
monitoriza și urmări cazurile mari de fraudă
Alte cazuri de fraudă ar trebui raportate consiliilor de evaluare a fraudelor sau grupurilor independente formate pentru
a gestiona fraudele. Starea cazurilor de fraudă ar trebui raportată Comitetului de audit ca parte a revizuirii auditului SI.
Auditorii IS ar trebui, de asemenea, să acorde sprijinul necesar consiliilor de evaluare a fraudelor sau grupurilor
independente sau comitetelor speciale în investigațiile lor
Planificarea execuției
Șeful auditului SI este responsabil pentru Planul anual de audit SI, pregătit după luarea în considerare a evaluării riscurilor
și a documentului de definire a domeniului. Planul acoperă strategia generală de audit, domeniile vizate, detaliile
obiectivelor de control identificate în etapa de definire a domeniului de aplicare, dimensiunile eșantionului, frecvența sau
calendarul unui audit bazat pe evaluarea riscului, natura și amploarea auditului și disponibilitatea competențelor resurselor
IT, implementarea și necesitatea oricărui audit. expertiza externă. Un raport privind starea auditurilor planificate
comparativ cu cele reale și orice modificări ale planului anual de audit trebuie să fie prezentat periodic Comitetului de
Audit și conducerii superioare.
Există îndrumări binecunoscute cu privire la auditul IS. Institutul Contabililor Autorizați din India (ICAI), în martie 2009,
a publicat „Standard on Internal Audit (SIA) 14: Internal Audit in an Information Technology Environment” care acoperă
cerințele etapei de planificare, pe care un auditor ar trebui să le urmeze. IIA a oferit îndrumări cu privire la definirea
Universului de Audit SI, prin ghidul publicat pe „Managementul Auditului SI” în seria „Ghid de Audit Tehnologic
Global”. ITGI a oferit îndrumări privind planificarea auditului în „Ghidul său de asigurare IT folosind COBIT”.
Orientările sugerate pentru implementare de către bănci sunt următoarele:
Documentarea Planului de Audit

Planul (fie separat, fie ca parte a planului general de audit intern) ar trebui să fie un document oficial, aprobat de
Comitetul de Audit inițial și în timpul oricăror modificări majore ulterioare. Planul trebuie pregătit astfel încât să
fie în conformitate cu orice cerințe externe adecvate, în plus față de standardele de audit IS bine-cunoscute.
Componentele planului de audit includ :
Subiectul auditului intern: Numele subiectului auditului
Natura auditului: conformitatea cu legislația, reglementarea sau standardele, evaluarea parametrilor de performanță
sau testarea configurației de securitate
Program: Perioada auditului și durata preconizată a acestuia
Sisteme definite: Resursele IT identificate care se află în domeniul de aplicare pe baza procesului de evaluare a
riscurilor
Prezentare generală a sistemului: Detalii despre mediul sistemului bazate pe procesul de evaluare a riscurilor
Detalii audit: Detalii despre riscurile și controalele identificate, pe baza procesului de evaluare a riscurilor
Natura și amploarea testelor: testarea controalelor pentru eficacitatea proiectării și implementării controalelor, teste
de fond pentru eficacitatea operațională a controalelor implementate
Pagină 254
Metoda de audit intern: Abordarea și metodologia de audit pe scurt
Echipa și rolurile și responsabilitățile: abilitățile identificate și numele auditorilor IS, inclusiv rolurile și
responsabilitățile acestora
Puncte de contact: numele de contact ale departamentului auditat
Coordonare: numele conducătorului de proiect și ale oficialului superior pentru escaladarea problemelor
Informații: Raportați detaliile auditurilor anterioare pe acest subiect
Natura și amploarea testelor tipurilor de control ale

testele care pot fi efectuate sunt următoarele :
Testul de proiectare a controlului: controalele care au fost identificate sunt evaluate pentru a fi adecvate în atenuarea
riscurilor
Testarea implementării controlului: Testele sunt efectuate pentru a confirma că controlul care a fost proiectat
corespunzător este implementat și funcționează în momentul testării. Controalele de atenuare sau compensare
sunt, de asemenea, revizuite ori de câte ori este necesar
Evaluarea eficacității operaționale a controalelor: oriunde se constată că controalele proiectate sunt în funcțiune, se
efectuează teste suplimentare pentru perioada de încredere (perioada de audit) pentru a confirma dacă
funcționează eficient și consecvent
De la caz la caz, auditorul trebuie să-și exercite raționamentul profesional și să decidă natura și amploarea procedurilor
care trebuie adoptate pentru concluzii. ISA 330 oferă îndrumări cu privire la natura, momentul și amploarea procedurilor.
iii. Tehnici de eșantionare
În timpul unui audit, auditorii trebuie să obțină dovezi suficiente, fiabile și relevante pentru a-și atinge obiectivele.
Constatările și concluziile ar trebui să fie susținute de analize și interpretari adecvate. Auditorii ar trebui să ia în
considerare tehnicile de selecție a eșantioanelor, care au ca rezultat un eșantion reprezentativ bazat pe statistici pentru
efectuarea testărilor de conformitate sau de fond. Eșantionarea statistică presupune utilizarea unor tehnici din care se pot
trage concluzii construite matematic cu privire la populație. Eșantionarea non-statistică nu este bazată pe statistici.
Rezultatele sale nu trebuie extrapolate asupra populației, deoarece este puțin probabil ca un eșantion să fie reprezentativ
pentru populație. Exemplele de testare a conformității controalelor în care ar putea fi luată în considerare eșantionarea
includ drepturi de acces utilizator, proceduri de control al modificării programului, documentația procedurilor,
documentația programului, urmărirea excepțiilor, revizuirea jurnalelor și auditurile licențelor software. Exemplele de teste
de fond în care ar putea fi luată în considerare eșantionarea includ reefectuarea unui calcul complex (de exemplu, dobânda
aplicată), pe un eșantion de conturi, eșantion de tranzacții pentru a garanta documentația justificativă etc.
Proiectarea unui eșantion
Atunci când proiectează dimensiunea și structura unui eșantion de audit, auditorii pot lua în considerare următoarele linii
directoare:
– Unitate de eșantionare: unitatea va depinde de scopul eșantionului. Pentru testarea conformității controalelor,
eșantionarea cu atribute este de obicei utilizată, atunci când unitatea este un eveniment sau o tranzacție (de exemplu, un
control, cum ar fi o autorizare a tranzacției).
Pagină 255
– Obiectivele auditului: Auditorii SI ar trebui să ia în considerare obiectivele de audit care trebuie atinse și procedurile de
audit, care sunt cele mai susceptibile de a atinge acele obiective. În plus, atunci când eșantionarea este adecvată, ar trebui
să se ia în considerare natura probelor de audit căutate și posibilele condiții de eroare.
– Populație: Populația este un întreg set de date din care auditorii doresc să preleve, pentru a ajunge la o concluzie. Prin
urmare, populația din care este extras un eșantion trebuie să fie adecvată și verificată ca „complet” pentru obiectivul
auditului.
– Stratificare: Pentru a ajuta la proiectarea eficientă și eficientă a unui eșantion, stratificarea poate fi adecvată.
Stratificarea este un proces de împărțire a unei populații în „subpopulații” cu
caracteristici similare, definite în mod explicit, astfel încât fiecare unitate de probă poate aparține unui singur strat.
Selectarea unui eșantion
Auditorii IS ar trebui să utilizeze metode de eșantionare statistică. Ei pot lua în considerare utilizarea următoarelor:
– Eșantionare aleatorie: Se asigură că toate combinațiile de unități din populație au șanse egale de selecție
– Eșantionarea sistematică: presupune selectarea unităților folosind un interval fix între selecții, primul interval având un
început aleatoriu. Exemplele includ „Eșantionarea unității monetare” sau „Selecția ponderată prin valoare”, în care
fiecărei valori monetare individuale (de exemplu, 100 Rs) din populație i se oferă o șansă egală de selecție. Deoarece o
unitate monetară individuală nu poate fi examinată în mod obișnuit separat, elementul care include acea unitate monetară
este selectat pentru examinare. Această metodă cântărește sistematic selecția în favoarea sumelor mai mari, dar oferă
oricărei valori monetare șanse egale de selecție. Un alt exemplu include selectarea fiecărei „a n-a unitate de eșantionare”.
Pagină 256
Standarde și cadre
O provocare cu care se confruntă auditorii IS este să știe cu ce să auditeze ca fiind complet dezvoltat
Liniile de bază ale controlului IT pentru aplicații și tehnologii care este posibil să nu fi fost dezvoltate.
Evoluția rapidă a tehnologiei este probabil să facă inutile liniile de bază, după o perioadă de timp.
Totuși, acest lucru nu îndepărtează conceptul de obiective de control.
Obiectivele de control, prin definiție, ar trebui să rămână mai mult sau mai puțin constante (de la mediu la mediu). Luați
în considerare obiectivul ca datele și programele esențiale ale afacerii să fie susținute și recuperabile. Acum, fiecare
mediu poate face asta în mod diferit; backup-urile ar putea fi manuale sau automate sau poate fi folosit un instrument.
Acestea pot fi doar incrementale sau pot exista copii de rezervă complete ale tuturor. Backup-urile se pot face zilnic,
săptămânal sau lunar. Depozitarea copiilor de rezervă poate fi la fața locului într-un seif ignifug, în afara locației la o altă
unitate a companiei sau externalizate către o terță parte. Metoda folosită de organizație pentru a gestiona backup-urile ar
avea cu siguranță un impact asupra procedurilor de audit și bugetului, dar obiectivul de control nu se va schimba.
Auditorul IS ar trebui să poată începe cu un set de obiective de control IT și, deși nu este specific unor medii particulare,
să selecteze un cadru adecvat.
Managementul resurselor
Auditorii unei bănci joacă un rol critic în eficiența și eficacitatea auditurilor. IT cuprinde o gamă largă de tehnologie și
sofisticare — setul de abilități necesare pentru auditarea unei configurații de firewall este foarte diferit de setul de abilități
necesare pentru auditarea controalelor aplicațiilor. Este esențial să se potrivească abilitățile necesare pentru a efectua un
anumit audit IS, cu auditorul corespunzător. Auditorii IS trebuie să aibă, de asemenea, abilitățile analitice adecvate pentru
a determina și raporta cauza principală a deficiențelor. Practicile de angajare și formare ale băncii ar trebui să asigure că
are auditori IS calificați, în care educația și experiența ar trebui să fie în concordanță cu responsabilitățile postului.
Managementul auditului ar trebui să ofere, de asemenea, un program eficient de educație și dezvoltare continuă.
Principala problemă este de a avea personal cu gama necesară de abilități de audit IS, necesare pentru a audita un univers
de audit IS, în mod eficient. Dacă expertiza internă este inadecvată, Consiliul ar trebui să ia în considerare utilizarea
surselor externe calificate, cum ar fi consultanți în management, auditori independenți sau profesioniști, pentru a
suplimenta resursele interne și a sprijini obiectivele băncii.
Executarea auditului IS
După cum sa menționat mai devreme, auditorii trebuie să înțeleagă mediul de afaceri și IT, riscurile și cadrul de control
intern. În timpul auditului, auditorii trebuie să obțină dovezi, să efectueze teste
proceduri, documentează în mod corespunzător constatările și încheie un raport. Această secțiune oferă îndrumări cu
privire la aspectele pe care auditorul IS ar trebui să le ia în considerare în timpul executării Planului.
ICAI, în martie 2009, a publicat un „Standard privind auditul intern (SIA) 14: Auditul intern într-un mediu de tehnologie
a informației” care acoperă cerințele de execuție a unui plan pe care un auditor IS ar trebui să-l urmeze. În plus, IIA a
oferit, de asemenea, îndrumări în „Gestionarea auditului IS” sub „Tehnologia globală”.
Pagină 257
seria Ghid de audit”. ITGI a oferit, de asemenea, îndrumări privind execuția inițiativei de asigurare în „Ghidul de
asigurare IT folosind COBIT”.
Îndrumarea pentru executarea auditului IS implică următorii pași:
Rafinarea înțelegerii procesului de afaceri și a mediului IT
Rafinarea domeniului de aplicare și identificarea controalelor interne
Testarea designului de control
Testarea rezultatului obiectivelor de control
Colectarea probelor de audit
Documentarea rezultatelor testelor
Teste finale efectuate
Luând în considerare utilizarea acceleratoarelor de audit
Luând în considerare utilizarea instrumentelor automate asistate de computer (CAAT)
Luând în considerare munca altora
Luând în considerare evaluarea terță parte de către furnizorii de servicii
Cele de mai sus sunt acoperite în următoarele secțiuni:
(a) Rafinați înțelegerea procesului de afaceri și a mediului IT:
Primul pas al etapei de execuție este perfecționarea înțelegerii unui mediu IT, în care este planificată o revizuire. Aceasta
implică înțelegerea proceselor de afaceri ale unei bănci pentru a confirma scopul corect și obiectivele de control. Scopul
auditului IS trebuie comunicat și convenit de către părțile interesate.
Rezultatul acestui pas constă în dovezi documentate cu privire la:
– Cine îndeplinește sarcina(le), unde este îndeplinită și când
– Intrări necesare pentru îndeplinirea sarcinii și rezultate generate de aceasta
– Sarcini automate efectuate de sisteme și configurații de sistem
– Informații generate de sistem utilizate de afaceri
– Proceduri stabilite pentru îndeplinirea sarcinilor
Auditorul IS poate structura acest pas după următoarele linii:

Intervievați și utilizați listele de activități și diagramele RACI
Colectați și citiți descrierea procesului, politicile, intrările sau ieșirile, problemele, procesele verbale ale întâlnirilor,
Pagină 258
rapoartele de audit trecute, recomandările de audit trecute, rapoartele de afaceri

Pregătiți o sarcină de definire a domeniului (obiectivul procesului, obiectivele și valorile)
Construiți o înțelegere a arhitecturii IT a întreprinderii
(b) Rafinarea domeniului de aplicare și identificarea controalelor interne:
În timp ce înțelegem și evaluăm controalele interne ale unei bănci, trebuie acoperite domeniile menționate la „Scopul
auditului IS”. Cu toate acestea, natura și amploarea riscurilor de control pot varia, în funcție de natura și
caracteristicile sistemului informațional al unei bănci:
Încrederea în sisteme sau programe care prelucrează date incorecte sau prelucrează date inexacte sau ambele
Acces neautorizat la date care poate duce la distrugerea datelor sau la modificări necorespunzătoare ale datelor,
inclusiv înregistrarea tranzacțiilor neautorizate sau inexistente sau înregistrarea incorectă a tranzacțiilor
Posibilitatea ca personalul IT să obțină acces la privilegii, dincolo de cele necesare, pentru a-și îndeplini sarcinile
atribuite, eliminând astfel segregarea sarcinilor
Modificări neautorizate ale datelor din fișierele principale
Modificări neautorizate ale sistemelor sau programelor
Nerespectarea modificărilor necesare sistemelor sau programelor
Intervenție manuală necorespunzătoare
Pierderea potențială a datelor sau incapacitatea de a accesa datele
(c) Testarea designului de control:
Această secțiune listează diferitele tehnici care vor fi utilizate în pașii de audit detaliați. Testarea controalelor se
efectuează acoperind principalele obiective ale testului:
Evaluarea proiectării controlului
Confirmarea faptului că controalele sunt în vigoare în cadrul operațiunii
Evaluează eficacitatea operațională a controalelor
În plus, eficiența controlului ar putea fi testată
În faza de testare, pot fi aplicate diferite tipuri de testare. Cinci metode de testare generice includ investigarea și
confirmarea, inspectarea, compararea constatărilor reale cu cele așteptate, reefectuarea sau recalcularea și revizuirea
colectării automate a dovezilor prin analiza datei folosind tehnici de audit asistate de computer și extragerea excepțiilor
sau tranzacțiilor cheie.
Pagină 259
Pentru a evalua caracterul adecvat al proiectării controalelor ar trebui parcurși următorii pași:
– Observați, inspectați și revizuiți abordarea de control. Testați designul pentru completitudine, relevanță, actualitate și
măsurabilitate
– Întrebați dacă, sau confirmați că, responsabilitățile pentru practicile de control și responsabilitatea generală au fost
atribuite
– Verificați dacă responsabilitatea și responsabilitățile sunt înțelese și acceptate. Verificați dacă abilitățile potrivite și
resursele necesare sunt disponibile
– Întrebați prin interviuri cu personalul cheie implicat dacă înțeleg mecanismul de control, scopul acestuia și
răspunderea și responsabilitățile.
Auditorul IS trebuie să stabilească dacă:
Există procese de control documentate
Există dovezi adecvate ale proceselor de control
Responsabilitatea și responsabilitatea sunt clare și eficiente
Există controale compensatorii, acolo unde este necesar
În plus, în special în misiunile de audit intern, eficiența costurilor a unui proiect de control poate fi, de asemenea,
verificată, cu următorii pași de audit:
– Dacă proiectarea controlului este eficientă: Investigați dacă poate fi eficientizat prin optimizarea pașilor, căutând
sinergii cu alte mecanisme și reconsiderând echilibrul dintre prevenire și detecție și corecție. Luați în considerare efortul
depus în menținerea practicilor de control
– Dacă controlul funcționează eficient: Investigați dacă poate fi făcut mai eficient din punct de vedere al costurilor.
Luați în considerare analiza valorilor performanței activităților asociate, oportunităților de automatizare sau nivelului de
calificare
(d) Testați rezultatul obiectivelor de control
Etapele de audit efectuate asigură că măsurile de control stabilite funcționează conform prescripțiilor și concluzionează cu
privire la adecvarea mediului de control. Pentru a testa eficacitatea unui control, auditorul trebuie să caute dovezi directe
și indirecte ale impactului controlului asupra rezultatelor procesului. Aceasta implică fundamentarea directă și indirectă a
contribuției măsurabile a controlului la obiectivele IT, proces și activitate, înregistrând astfel dovezi directe și indirecte ale
realizării rezultatelor sau diferitelor obiective de control (pe baza celor documentate în standarde precum COBIT, după
caz) .
Auditorul trebuie să obțină dovezi directe sau indirecte pentru elementele sau perioadele selectate pentru a se asigura că
controlul analizat funcționează eficient prin aplicarea unei selecții de tehnici de testare, așa cum sunt prezentate în pasul
testului de proiectare a controlului. Auditorul SI ar trebui, de asemenea, să efectueze o evaluare limitată a adecvării
rezultatelor procesului, să determine nivelul de testare de fond și munca suplimentară necesară pentru a oferi asigurarea că
procesul IT este adecvat.
Pagină 260
Testarea de fond ar presupune efectuarea de proceduri analitice și teste de detalii, pentru a obține o asigurare în domeniile
în care se observă deficiențe de control. Se efectuează teste de fond pentru a stabili impactul real al deficiențelor de
control.
(e) Dovezi de audit
Auditorii IS trebuie să obțină probe de audit suficiente și de încredere pentru a trage concluzii rezonabile pe care să se
bazeze rezultatele auditului.
Dovezi suficiente: Dovezile pot fi considerate suficiente dacă susțin toate întrebările semnificative din obiectivul și
domeniul de aplicare al auditului. Dovezile ar trebui să fie obiective și suficiente pentru a permite unei părți independente
calificate să efectueze din nou testele și să obțină aceleași rezultate. Dovezile trebuie să fie proporționale cu materialitatea
unui element și cu riscurile implicate. În cazurile în care auditorul IS consideră că nu pot fi obținute suficiente probe de
audit, ar trebui să dezvăluie acest lucru într-o manieră compatibilă cu comunicarea rezultatelor auditului.
Dovezi adecvate: Dovezile adecvate includ următoarele criterii orientative:
Proceduri efectuate de auditorul IS

Rezultatele procedurilor efectuate de Auditorul IS
Documente sursă (electronice sau pe hârtie), înregistrări și informații de coroborare utilizate în sprijinul
auditului
Constatările și rezultatele unui audit

Atunci când obțin probe dintr-un test de proiectare a controlului, auditorii trebuie să ia în considerare caracterul complet
al probelor de audit pentru a susține nivelul evaluat de risc de control.
Dovezi de încredere: Auditorii IS ar trebui să ia notă de următoarele exemple de dovezi care sunt mai fiabile atunci când
sunt:
– Forma scrisă și nu expresii orale
– Obținut din surse independente
– Obținut de auditorii IS, mai degrabă decât de la banca auditată
– Certificat de o parte independentă
Procedurile utilizate pentru colectarea probelor pot fi aplicate prin utilizarea procedurilor manuale de audit, tehnici
asistate de calculator sau o combinație a ambelor. De exemplu: un sistem, care utilizează totaluri de control manual pentru
a echilibra operațiunile de introducere a datelor, ar putea furniza dovezi de audit că procedura de control este în vigoare
prin intermediul unui raport reconciliat și adnotat corespunzător. Auditorii IS trebuie să obțină probe de audit prin
revizuirea și testarea acestui raport. Înregistrările detaliate ale tranzacțiilor pot fi disponibile numai în format care poate fi
citit de mașină, solicitând auditorilor IS să obțină dovezi folosind tehnici asistate de computer.
Atunci când informațiile produse de o bancă sunt utilizate de auditori, aceștia ar trebui să obțină dovezi cu privire la
completitudine și acuratețe prin următoarele mijloace:
Pagină 261
Efectuarea de teste ale eficacității operaționale a controalelor asupra producerii și întreținerii informațiilor, pentru a fi
utilizate ca probe de audit
Efectuarea procedurilor de audit direct asupra informațiilor care vor fi utilizate ca probe de audit
Auditorii ar trebui să ia în considerare următoarele controale asupra producerii și întreținerii informațiilor produse de o
bancă:
– Controlează integritatea, acuratețea și caracterul complet al datelor sursă
– Controale asupra creării și modificării logicii și parametrilor de raport aplicabili
(f) Documentație
Probele de audit adunate ar trebui să fie documentate și organizate pentru a sprijini constatările și concluziile.
Documentația de audit IS este o înregistrare a muncii efectuate și dovezi care susțin constatările și concluziile.
Utilizări potențiale ale documentației:
Demonstrarea măsurii în care auditorul a respectat standardele profesionale legate de auditul SI
Asistență cu planificarea, performanța și revizuirea auditului
Facilitarea recenziilor terților
Evaluarea programului de asigurare a calității al auditorilor
Asistență în circumstanțe precum reclamații de asigurare, cazuri de fraudă și procese
Asistență în dezvoltarea profesională a personalului
Documentația ar trebui să includă, cel puțin, o înregistrare a:
– Planificarea și pregătirea domeniului și obiectivelor auditului
– Etapele de audit efectuate și probele de audit strânse
– Constatările, concluziile și recomandările auditului
– Rapoarte emise ca urmare a lucrărilor de audit
– Revizuirea de supraveghere
Amploarea documentației unui auditor IS poate depinde de nevoile unui anumit audit și ar trebui să includă lucruri
precum:
Înțelegerea de către auditorul IS a unei zone care trebuie auditată și a mediului acesteia
Înțelegerea sa asupra sistemelor de procesare a informațiilor și a mediului de control intern

Probe de audit, sursa documentației de audit și data finalizării
Răspunsul băncii la recomandări
Pagină 262
Documentația trebuie să includă informații de audit, cerute de lege, reglementări guvernamentale sau de standardele
profesionale aplicabile. Documentația trebuie să fie clară, completă și de înțeles de către un examinator. IS Audit detine
probe documentate de catre acesta, in vederea fundamentarii concluziilor asupra testelor efectuate si a observatiilor
specifice raportate conducerii si Comitetului de Audit.
(g) Concluzie asupra Testelor Efectuate
Auditorii SI trebuie să evalueze concluziile trase ca bază pentru formarea unei opinii asupra auditului. Concluziile ar
trebui să fie fundamentate prin dovezi, colectate și documentate. Echipa de audit IS poate fi solicitată să furnizeze și să
mențină dovezi cu privire la observațiile raportate de ei.
Auditorii IS pot efectua următoarele activități necesare pentru a finaliza testele efectuate pe baza naturii și cantității
defecțiunilor de control identificate și a probabilității erorilor nedetectate:
– Decideți dacă sfera auditului IS a fost suficientă pentru a permite auditorilor să tragă concluzii rezonabile pe care să
se bazeze opinia de audit
- Efectuați proceduri de audit concepute pentru a obține suficiente probe de audit adecvate: evenimentele până la
data raportului de audit pot fi incluse și identificate în raport
- Pregătiți un memorandum rezumat al auditului care să documenteze constatările și concluziile privind aspectele
importante ale auditului și raportării SI, inclusiv judecățile făcute de o echipă de audit SI
- Obțineți declarații adecvate de la conducerea băncii
- Întocmește un raport adecvat circumstanțelor și în conformitate cu standardele profesionale aplicabile și cerințele

legale și de reglementare
Comunicați, după caz, cu Comitetul de Audit sau cu conducerea superioară
Menține controale eficiente asupra procesării și distribuirii rapoartelor referitoare la auditul IS
Dacă dovezile sau informațiile de audit indică faptul că ar fi putut apărea nereguli, auditorii SI ar trebui să recomande
conducerii băncii cu privire la aspectele care necesită investigații detaliate pentru a permite conducerii să inițieze acțiunile
de investigație adecvate. De asemenea, auditorii ar trebui să ia în considerare consultarea Comitetului de Audit și a
consilierului juridic cu privire la oportunitatea și riscurile raportării constatărilor în afara Băncii.
RBI (vezi circulara sa DBS.CO.FrMC.BC.Nr.7/23.04.001/ 2009-10, din 16 septembrie 2009) cere ca cazurile de fraudă să
fie raportate agențiilor de aplicare a legii și RBI. Băncile ar trebui să includă în mod corespunzător cerințe pentru
raportarea către RBI a unor astfel de cazuri în scrisorile de angajament emise auditorilor externi IS.
(h) Acceleratoare de audit
Deoarece bugetele auditului IS pot fi dificil de estimat și gestionat, CAE-urile pot lua în considerare utilizarea
acceleratoarelor de testare - instrumente sau tehnici care ajută la susținerea procedurilor pe care auditorii SI le vor efectua
Pagină 263
- pentru a crește eficiența și eficacitatea. CAE poate folosi un accelerator pentru a efectua același audit în mai puțin timp
sau pentru a efectua proceduri de audit mai detaliate în același timp. Acceleratoarele de audit pot fi împărțite în două
categorii:
– Facilitatori de audit: instrumente care ajută la sprijinirea managementului general al unui audit (de exemplu, un
instrument electronic de gestionare a hârtiei de lucru)
– Acceleratoare de testare: Instrumente care automatizează efectuarea testelor de audit (de exemplu, instrumente de
analiză a datelor).
Facilitatori de audit
Acestea includ documente electronice de lucru, software de management de proiect, software de diagramă de flux și
software de urmărire a problemelor deschise.
Testarea acceleratoarelor
Acceleratoarele de testare pot automatiza sarcinile de audit care necesită timp, cum ar fi revizuirea unor populații mari de
date. De asemenea, utilizarea unui instrument pentru efectuarea procedurilor de audit ajută la stabilirea coerenței. De
exemplu, dacă un instrument este utilizat pentru a evalua configurația securității serverului, serverele testate cu acel
instrument vor fi evaluate de-a lungul acelorași linii de bază. Efectuarea manuală a acestor proceduri permite un anumit
grad de interpretare din partea auditorului IS. În cele din urmă, utilizarea instrumentelor le permite auditorilor IS să
testeze o întreagă populație de date, mai degrabă decât doar un eșantion de tranzacții. Acest lucru asigură un grad mult
mai ridicat de asigurare a auditului.
Software de analiză a datelor: Acestea permit unui auditor să efectueze o analiză statistică robustă a unor seturi mari de
date. Ele pot fi, de asemenea, utilizate pentru a sprijini auditurile de proces sau operaționale, cum ar fi revizuirile KYC.
Ele pot suporta tipuri de testare. O considerație atunci când utilizați un instrument de analiză a datelor este că poate fi
dificil să extrageți datele din sursa originală. Este esențial ca procedurile de audit să fie efectuate pentru a asigura
completitatea și acuratețea datelor sursă.
Instrumente de analiză a securității: acestea sunt un set larg de instrumente care pot examina o populație mare de
dispozitive sau utilizatori și pot identifica expunerile de securitate. Există diferite tipuri de instrumente de analiză a
securității. În general, acestea pot fi clasificate după cum urmează:
Instrumente de analiză a rețelei: Acestea constau în programe software care pot fi rulate într-o rețea și adună
informații despre aceasta. Auditorii IS pot folosi aceste instrumente pentru o varietate de proceduri de audit,
inclusiv:
Verificarea acurateței diagramelor de rețea prin maparea rețelei corporative Identificarea dispozitivelor de rețea cheie care
pot necesita o atenție suplimentară de audit
Colectarea de informații despre traficul permis într-o rețea (care ar sprijini direct procesul de evaluare a riscurilor IT).
Instrumente de hacking: Majoritatea tehnologiilor au o serie de vulnerabilități standard, cum ar fi existența unor ID-
uri și parole implicite sau setări implicite atunci când tehnologia este instalată imediat. Instrumentele de hacking
oferă o metodă automată de verificare a acestora. Astfel de instrumente pot fi vizate împotriva firewall-urilor,
serverelor, rețelelor și sistemelor de operare.
Pagină 264
Instrumente de analiză a securității aplicațiilor: dacă o organizație utilizează aplicații de afaceri integrate mari,
controalele interne cheie depind în mare măsură de securitate. Securitatea la nivel de aplicație trebuie să fie bine
proiectată și construită împreună cu procesele și controalele aplicației.
CAE ar trebui să fie conștient de faptul că cele mai multe dintre acestea vin cu un set de reguli preconfigurate sau „cele
mai bune practici” promovate de furnizor. Implementarea unuia va trebui să fie însoțită de un proiect de fond pentru a
crea un set de reguli care este relevant pentru organizația respectivă. Nerespectarea acestui lucru va avea ca rezultat
rapoarte de audit care conțin un număr de fals-pozitive sau fals-negative.
CAE ar trebui să fie conștienți de următoarele considerații, cu privire la acceleratorii de audit IS:
Uneltele costă bani. CAE ar trebui să se asigure că beneficiile depășesc costurile
Auditorii IS vor trebui să fie instruiți cu privire la noul instrument. Nu este neobișnuit ca un instrument să stea
neutilizat într-un departament de audit intern
Că instrumentul va avea nevoie de asistență, de gestionare a patch-urilor și de upgrade-uri. În funcție de calitate,
poate necesita și un server autonom. Pentru aceasta, orice selecție de instrumente ar trebui gestionată cu asistența
departamentului IT
Uneori, managementului IT sau furnizorilor de servicii terți nu li se permite instrumentelor să acceseze direct mediul de
producție. Li se cere în schimb să facă acest lucru dintr-o copie a datelor de pe un site alternativ sau un server de
așteptare. Orice utilizare a instrumentelor sau a scripturilor ar trebui să fie discutată în detaliu și aprobată de
managementul IT și să fie testată complet înainte de implementare.
(i) Tehnici de audit asistate de calculator (CAATS)
Auditorii IS pot utiliza o combinație adecvată de tehnici manuale și CAAT. Funcția de audit IS trebuie să îmbunătățească
utilizarea CAAT-urilor, în special pentru funcțiile sau procesele critice care au implicații financiare sau de reglementare
sau juridice. Măsura în care CAAT-urile pot fi utilizate va depinde de factori precum eficiența și eficacitatea CAAT-urilor
față de tehnicile manuale, constrângerile de timp, integritatea sistemului informațional și a mediului IT și nivelul riscului
de audit.
CAAT-urile pot fi utilizate în domenii critice (cum ar fi detectarea pierderilor de venituri, funcțiile de trezorerie,
evaluarea impactului deficiențelor de control, monitorizarea tranzacțiilor clienților conform cerințelor AML și, în general,
în zonele în care este raportat un volum mare de tranzacții).
Procesul implicat în utilizarea CAAT implică următorii pași:
Stabiliți obiectivele de audit ale CAAT
Determinați accesibilitatea și disponibilitatea facilităților, programelor, sistemelor și datelor unei bănci

Definiți procedurile care trebuie întreprinse (de exemplu, eșantionare statistică, recalculare sau confirmare)
Definiți cerințele de ieșire
Determinați cerințele de resurse: de exemplu, personal, CAAT, mediul de procesare, facilitățile IS ale băncii sau
audit
Facilități IS
Obține acces la facilitățile, programele, sistemele și date ale băncii, inclusiv la definițiile fișierelor
Pagină 265
Documentați CAAT-urile care trebuie utilizate, inclusiv obiective, diagrame de flux de nivel înalt și instrucțiuni de
rulare
CAAT-urile pot fi utilizate pentru a efectua, printre altele, următoarele proceduri de audit:
– Testarea tranzacțiilor și soldurilor, cum ar fi recalcularea dobânzii
– Proceduri de revizuire analitică, cum ar fi identificarea inconsecvențelor sau a fluctuațiilor semnificative
– Teste de conformitate a controalelor generale: testarea setarii sau configurarii sistemului de operare sau procedurile de
acces la bibliotecile de programe
– Programe de eșantionare pentru extragerea datelor pentru testarea de audit
– Teste de conformitate ale controalelor aplicației, cum ar fi testarea funcționării unui control programat
– Recalcularea intrărilor efectuate de sistemele contabile ale entității
– Testarea de penetrare
În cazurile în care CAAT-urile pot fi utilizate pentru a extrage programe sensibile, informații despre sistem sau date de
producție, auditorii IS ar trebui să protejeze programul, informațiile de sistem sau datele de producție, cu un nivel adecvat
de confidențialitate și securitate. În acest sens, auditorii IS trebuie să ia în considerare nivelul de confidențialitate și
securitate cerut de bancă, deținând datele și orice legislație relevantă. Auditorii IS ar trebui să aibă „acces la vizualizare”
la sisteme și date. În cazul în care procedurile de audit nu pot fi efectuate în mediul live, mediul de testare adecvat ar
trebui să fie pus la dispoziția auditorilor IS. Sistemele și datele aflate în mediul de testare ar trebui să fie sincronizate cu
mediul live.
Auditorii IS trebuie să utilizeze și să documenteze rezultatele procedurilor adecvate pentru a asigura integritatea,
fiabilitatea, utilitatea și securitatea CAAT-urilor continue. Exemplu: aceasta ar trebui să includă o revizuire a întreținerii
programului și a controalelor modificării asupra software-ului de audit încorporat pentru a determina că au fost făcute
doar modificări autorizate la CAAT.
În cazurile în care CAAT-urile rezidă într-un mediu care nu se află sub controlul auditorului IS, ar trebui, de fapt, plasat
un nivel adecvat de control pentru a identifica schimbările. Atunci când CAAT-urile sunt modificate, auditorii IS ar trebui
să obțină asigurarea integrității, fiabilității, utilității și securității lor, prin planificare, proiectare, testare, procesare și
revizuire adecvate a documentației, înainte de a se baza.
(j) Audit continuu
În mod tradițional, testarea controalelor efectuate de o echipă de audit intern a avut loc pe o bază retrospectivă și ciclică,
adesea la multe luni după ce activitățile de afaceri au avut loc. Procedurile de testare s-au bazat adesea pe o abordare de
eșantionare. Acestea au inclus activități precum revizuirea politicilor, procedurilor, aprobărilor și reconciliărilor. Astăzi,
totuși, se recunoaște că această abordare oferă auditorilor interni doar un domeniu de aplicare restrâns și este adesea prea
târziu pentru a avea „valoare reală” pentru performanța afacerii sau conformitatea cu reglementările.
Auditul continuu este o metodă folosită pentru a efectua automat controlul și evaluările riscurilor, pe o bază mai
Pagină 266
frecventă, folosind tehnologia care este cheia pentru a permite o astfel de abordare. Auditul continuu schimbă paradigma
de audit de la revizuiri periodice ale unui eșantion de tranzacții la testarea de audit continuă a 100% dintre tranzacții.
Devine o parte integrantă a auditului modern la mai multe niveluri. De asemenea, ar trebui să fie strâns legată de
activitățile de management, cum ar fi monitorizarea performanței, tabloul de bord sau tabloul de bord și managementul
riscului întreprinderii.
O abordare a auditului continuu permite auditorilor interni să înțeleagă pe deplin punctele critice de control, regulile și
excepțiile. Cu analize automate și frecvente ale datelor, aceștia sunt capabili să efectueze control și evaluări ale riscurilor
în timp real sau aproape în timp real. Aceștia pot analiza sistemele cheie de afaceri atât pentru anomalii la nivel de
tranzacție, cât și pentru indicatorii bazați pe date ai deficiențelor de control și a riscurilor emergente.
În sfârșit, cu auditarea continuă, rezultatele analizei sunt integrate în toate aspectele procesului de audit, de la dezvoltarea
și menținerea planului de audit al întreprinderii până la efectuarea și urmărirea auditurilor specifice. În funcţie de nivelul
de implementare şi
susținerea abordării auditului IS bazat pe risc; băncile pot explora punerea în aplicare a auditului continuu în domenii
critice într-o manieră treptată.
(k) Audit de control al aplicațiilor:
Auditurile detaliate de control al aplicațiilor înainte de implementare și auditurile de migrare a datelor cu privire la
sistemele critice trebuie supuse unui audit extern independent. Băncile trebuie, de asemenea, să efectueze un audit
detaliat de control al aplicațiilor post-implementare. În plus, băncile ar trebui să includă, de asemenea, audituri de
control al aplicațiilor într-o manieră bazată pe risc, ca parte a planurilor obișnuite de audit intern/audit SI, cu accent
pe integritatea datelor (printre alți factori). Auditorii interni generali cu cunoștințele funcționale necesare trebuie să
fie implicați împreună cu auditorii SI în exercițiul pentru a oferi expertiza în domeniu necesară.
Unele dintre considerentele în auditul de control al aplicațiilor (pe baza ghidurilor ISACA) includ :
Un auditor IS ar trebui să înțeleagă mediul SI pentru a determina dimensiunea și complexitatea sistemelor și gradul
de dependență de către bancă de sistemele de informații.
Riscurile la nivel de aplicație la nivel de sistem și de date includ riscurile de integritate a sistemului legate de
prelucrarea incompletă, inexactă, intempestivă sau neautorizată a datelor; riscuri de securitate a sistemului legate
de accesul neautorizat la sisteme sau date; riscurile de date legate de completitudinea, integritatea,
confidențialitatea și acuratețea acestora; riscurile de disponibilitate a sistemului legate de lipsa capacității
operaționale a sistemului; și riscurile de întreținere a sistemului în ceea ce privește procedurile adecvate de
control al schimbărilor.
Controalele aplicației pentru a aborda riscurile la nivel de aplicație pot fi sub formă de controale computerizate
încorporate în sistem, controale efectuate manual sau o combinație a ambelor. Riscurile controalelor manuale în
zonele critice trebuie luate în considerare. În cazul în care se ia opțiunea de a se baza pe controalele programate,
ar trebui luate în considerare controalele informatice generale relevante, precum și controalele relevante în mod
specific pentru obiectivul auditului. Obiectivele ar trebui dezvoltate pentru a aborda criterii precum integritatea,
disponibilitatea, conformitatea, fiabilitatea și confidențialitatea. Eficacitatea și eficiența pot fi, de asemenea,
Pagină 267
criterii suplimentare.
Ca parte a documentării fluxului tranzacțiilor, informațiile colectate ar trebui să includă atât aspecte computerizate,
cât și manuale ale sistemului. Accentul ar trebui să se pună pe introducerea datelor (electronică sau manuală),
prelucrarea, stocarea și ieșirea care sunt importante pentru obiectivul auditului.
De asemenea, trebuie luată în considerare documentarea interfețelor aplicațiilor cu alte sisteme. Auditorul poate
confirma documentația prin efectuarea de proceduri precum un test de trecere.
Pot fi identificate controale specifice pentru atenuarea riscurilor aplicațiilor. Dovezi de audit suficiente obținute
pentru a asigura auditorul că controalele funcționează așa cum s-a intenționat prin proceduri cum ar fi
investigarea și observarea, revizuirea documentației și testarea controalelor sistemului aplicației, în cazul în care
controalele programate sunt testate. De asemenea, trebuie luată în considerare utilizarea tehnicilor de audit
asistate de computer (CAAT).
Natura, momentul și amploarea testării ar trebui să se bazeze pe nivelul de risc pentru zona supusă revizuirii și pe
obiectivele auditului. În absența unor controale IT generale puternice, un auditor SI poate face o evaluare a
efectului acestei slăbiciuni asupra fiabilității controalelor aplicației computerizate.
Dacă un auditor SI constată deficiențe semnificative în controalele aplicației computerizate, trebuie să se obțină
asigurare (în funcție de obiectivul auditului), dacă este posibil, din controalele de prelucrare efectuate manual.
Eficacitatea controalelor computerizate depinde de controalele informatice generale. Prin urmare, dacă controalele IT
generale nu sunt revizuite, capacitatea de a se baza pe controale poate fi limitată. Apoi auditorul IS ar trebui să ia
în considerare proceduri alternative.
Unde sunt luate în considerare punctele slabe identificate în timpul revizuirii sistemelor de aplicare
pentru a fi semnificativ sau semnificativ, nivelul adecvat de management ar trebui sfătuit să întreprindă măsuri
corective imediate.
Folosind munca altora
Scopul unui standard de audit IS este de a stabili și de a oferi un ghid auditorilor care pot utiliza munca experților într-un
audit. Următoarele sunt standarde, pentru a testa fiabilitatea muncii unui expert:
Auditorii SI ar trebui, acolo unde este cazul, să ia în considerare utilizarea muncii altor experți pentru audit
Ei ar trebui să evalueze și apoi să fie mulțumiți de calificările profesionale, competențele, experiența relevantă,
resursele, independența și procesele de control al calității, înainte de angajare.
Aceștia ar trebui să evalueze, să revizuiască și să evalueze munca experților, ca parte a unui audit, și apoi să
concluzioneze gradul de utilizare și încrederea lucrării.
Aceștia ar trebui să stabilească și să concluzioneze dacă munca experților este adecvată și competentă pentru a le
permite să ajungă la concluzii cu privire la obiectivele curente de audit. O astfel de concluzie ar trebui
documentată
Aceștia ar trebui să aplice proceduri de testare suplimentare pentru a obține și a include limitarea domeniului de
aplicare, în cazul în care dovezile necesare nu sunt obținute prin proceduri de testare suplimentare
Un expert poate fi un auditor IS de la o firmă de audit externă, un consultant de management, un expert în domeniul
IT sau un expert în domeniul auditului, care a fost numit de conducere sau de echipa de audit IS
Un expert poate fi intern sau extern băncii. Dacă un expert este angajat de o altă parte a organizației, se poate baza pe
raportul băncilor. În unele cazuri, acest lucru poate reduce necesitatea unei acoperiri de audit IS, deși auditorii IS
nu au documentație justificativă și documente de lucru. Auditorii IS ar trebui să fie precauți în a oferi o opinie cu
privire la astfel de cazuri
Un auditor IS ar trebui să aibă acces la toate lucrările, documentele justificative și rapoartele altor experți, acolo unde
Pagină 268
un astfel de acces nu creează probleme juridice. Acolo unde accesul creează probleme juridice sau astfel de
lucrări nu sunt accesibile, auditorii ar trebui să stabilească și să concluzioneze cu privire la gradul de utilizare și
încrederea în munca experților.
Opiniile, relevanța și comentariile auditorului SI cu privire la adoptarea raportului expertului ar trebui să facă parte
din Raportul auditorului SI
Revizuirea de către terți a furnizorilor de servicii
O bancă poate utiliza un furnizor de servicii terță parte (organizație de servicii) pentru a obține servicii de aplicații
software împachetate și mediu tehnologic, care le permite clienților să proceseze tranzacții financiare și operaționale
(gestionarea bancomatelor, dezvoltarea și întreținerea rețelelor și a infrastructurii, imagistica și indexarea documentelor,
dezvoltare și întreținere software). RBI a emis „Orientări privind gestionarea riscurilor și codul de conduită în
externalizarea serviciilor financiare de către bănci” ( circulara nr: DBOD.NO.BP.40/21.04.158/ 2006-07 din 3 noiembrie
2006) , solicitând băncilor să adere la orientări înainte de externalizarea activităților legate de serviciile financiare.
Serviciile furnizate de o terță parte sunt relevante pentru domeniul de aplicare al auditului IS. Mai ales, atunci când acele
servicii și controale din cadrul acestora, fac parte din sistemele informaționale ale băncii. Deși este posibil ca controalele
din cadrul organizației de servicii să se refere la raportarea financiară, pot exista și alte controale care pot fi, de asemenea,
relevante pentru auditul IS (controale asupra protecției activelor sau imaginilor documentelor).
Serviciile unei organizații de servicii fac parte din sistemul de informații al unei bănci, inclusiv procesele de afaceri
aferente, relevante pentru auditul IS, dacă aceste servicii afectează oricare dintre următoarele:
Segmente ale Sistemului Informațional care sunt semnificative pentru operațiunile IS ale băncii
Proceduri din cadrul sistemului informatic, prin care se efectuează tranzacțiile unei entități utilizator
inițiat, înregistrat, procesat, corectat (când este necesar), transferat într-un registru general și raportat, în
situațiile financiare
Modul în care sunt surprinse evenimentele și condițiile, altele decât tranzacțiile, semnificative pentru Sistemul
Informațional al băncii
Auditorii IS vor trebui să înțeleagă modul în care o bancă utilizează serviciile unei organizații de servicii în cadrul băncii
Operațiuni IS, inclusiv:
Natura serviciilor furnizate de organizație și importanța acestora pentru sistemul informațional al băncii, inclusiv
efectul acestora asupra controlului intern al băncii
Natura și semnificația tranzacțiilor, conturilor sau proceselor de raportare financiară, afectate de organizația de
servicii
Gradul de interacțiune între activitățile organizației și băncii
Natura relației dintre bancă și organizație, inclusiv termenii contractuali relevanți pentru activitățile întreprinse de
organizație
În situații, serviciile furnizate de organizație pot să nu pară „materiale” pentru operațiunile IS ale băncii. Dar, natura
serviciului poate fi. Auditorii IS trebuie să stabilească că este necesară înțelegerea acelor controale în circumstanțe.
Informațiile despre natura serviciilor, furnizate de o organizație, pot fi disponibile dintr-o varietate de surse:
Pagină 269
Manual de utilizare
Prezentare generală a sistemului
Manuale tehnice
Contract sau acord de nivel de servicii între bancă și organizație
Rapoarte ale organizației de servicii, auditorilor interni sau autorităților de reglementare, cu privire la controalele
organizației de servicii Rapoarte ale unui auditor al organizației (auditor de serviciu), inclusiv scrisorile de
management
Auditorii IS pot folosi un auditor de servicii pentru a efectua proceduri precum testele controalelor la organizația de
servicii sau proceduri de fond privind operațiunile IS ale băncii, deservite de o organizație de servicii .
– ) Raportare și urmărire
Această fază implică raportarea constatărilor auditului către CAE și Comitetul de Audit. Înainte de a raporta constatările,
este imperativ ca auditorii SI să pregătească un memorandum rezumat al auditului care să ofere o imagine de ansamblu
asupra întregului proces de audit, de la planificare la constatările auditului, să discute constatările cu auditatul și să obțină
răspunsuri. În plus, este importantă revizuirea acțiunilor întreprinse de conducere pentru a atenua riscurile observate în
constatările auditului și actualizarea adecvată a memorandumului rezumat al auditului. Raportarea presupune stabilirea
naturii, calendarul și amploarea activităților de urmărire și planificarea auditurilor viitoare.
Organisme profesionale precum ISACA, IIA, ICAI au emis îndrumări în acest sens.
Raportarea și urmărirea implică următoarele activități sau pași:

– Redactarea rezumatului auditului si memorandumului
– Discutarea constatărilor cu conducerea
– Finalizarea si transmiterea rapoartelor
– Revizuirea raportului de acțiuni întreprinse
– Efectuarea procedurilor de urmărire
– Arhivarea documentelor
Acestea sunt acoperite în următoarele secțiuni:
Rezumatul auditului și memorandum: Un auditor IS trebuie să efectueze audituri sau revizuiri ale procedurilor de
control și să formeze o concluzie despre proiectarea și raportarea asupra acestora.
eficacitatea operațională a procedurilor de control pe baza criteriilor identificate. Concluzia unui audit este
exprimată ca o exprimare pozitivă a opiniei și oferă un nivel ridicat de asigurare. Concluzia unei revizuiri este
exprimată ca o declarație de asigurare negativă și oferă doar un nivel moderat de asigurare.
Pagină 270
Discutați constatările cu conducerea: conducerea băncii este responsabilă pentru a decide măsurile adecvate care
trebuie întreprinse ca răspuns la observațiile și recomandările raportate. Auditorii SI sunt responsabili pentru
evaluarea acțiunii de management în ceea ce privește corectitudinea și rezolvarea în timp util a problemelor
raportate ca observații și recomandări.
Managementul superior poate decide să accepte riscul de a nu corecta starea raportată din cauza costurilor sau a altor
considerente. Consiliul (sau Comitetul de Audit, dacă există) ar trebui să fie informat cu privire la decizia conducerii
superioare cu privire la observațiile și recomandările semnificative. Atunci când auditorii IS consideră că o
organizație a acceptat un nivel de risc rezidual care este inadecvat pentru organizație, ei ar trebui să discute problema
cu Auditul Intern și cu conducerea superioară. În cazul în care auditorii SI nu sunt de acord cu decizia privind riscul
rezidual, auditorii SI și conducerea superioară ar trebui să raporteze chestiunea Consiliului sau Comitetului de Audit
pentru rezolvare.
Uneori apar evenimente, ulterior momentului sau perioadei de timp în care subiectul este testat, dar înainte de data
raportului auditorului IS, care au un efect semnificativ asupra subiectului și, prin urmare, necesită ajustare sau
dezvăluire în prezentare. a subiectului sau a afirmației.
(c) Finalizați și trimiteți rapoarte
Auditorii SI trebuie să revizuiască și să evalueze concluziile desprinse din probele obținute ca bază pentru formarea unei
opinii cu privire la eficacitatea procedurilor de control pe baza criteriilor identificate.
Constatările majore identificate în timpul unui audit ar trebui să aibă un termen definit pentru acțiunile de remediere,
acestea ar trebui să fie urmărite intens și conformitatea ar trebui să fie confirmată.
Raportul auditorului SI despre eficacitatea procedurilor de control ar trebui să acopere aspecte precum:
– Descrierea domeniului auditului, inclusiv:
– Identificarea sau descrierea domeniului de activitate
– Criterii utilizate ca bază pentru concluzia auditorului IS
– O declarație conform căreia menținerea unei structuri eficiente de control intern, inclusiv a procedurilor de
control pentru domeniul de activitate, este responsabilitatea conducerii
– O declarație conform căreia auditorii SI au efectuat misiunea pentru a exprima o opinie cu privire la eficacitatea
controlului
(d) Examinați raportul de acțiuni întreprinse
După raportarea constatărilor și recomandărilor, auditorii SI trebuie să solicite și să evalueze informații relevante pentru a
concluziona dacă conducerea a luat măsurile adecvate în timp util. Dacă acțiunile propuse de conducere pentru
implementarea recomandărilor raportate au fost discutate cu sau furnizate auditorului IS, aceste acțiuni ar trebui
înregistrate ca răspuns al conducerii în raportul final. Natura, momentul și amploarea activităților de urmărire ar trebui să
țină cont de semnificația constatării raportate și de impactul în cazul în care nu se iau măsuri corective. Momentul
activităților de urmărire a auditului IS în raport cu raportarea inițială ar trebui să fie o chestiune de raționament
Pagină 271
profesional, care depinde de o serie de considerații, cum ar fi natura sau amploarea riscurilor și costurilor asociate pentru
entitate.
(e) Proceduri de urmărire
Ar trebui stabilite proceduri pentru activitățile ulterioare care includ:
– Înregistrarea unui interval de timp în care conducerea ar trebui să răspundă la recomandările convenite
– O evaluare a răspunsului conducerii
– O verificare a răspunsului, dacă se consideră oportun
– Lucrări ulterioare, dacă se consideră oportun
– O procedură de comunicare care escaladă răspunsurile/acțiunile restante și nesatisfăcătoare la nivelurile adecvate de

management
– Un proces pentru furnizarea unei asigurări rezonabile cu privire la asumarea de către conducere a riscurilor asociate, în
cazul în care măsurile de remediere sunt întârziate sau nu se propune să fie implementată
– Un sistem automat de urmărire sau o bază de date poate ajuta la realizarea activităților de urmărire.
(f) Actualizați Memorandumul Rezumat al Auditului
Ar trebui pregătit un memorandum de rezumat al auditului care să abordeze următoarele:

– Concluzie despre riscul specific
– Schimbări în bancă, mediul acesteia și industria bancară care intră în atenție după finalizarea memorandumului de
planificare a auditului și care au determinat modificarea planului de audit – Concluzie privind caracterul adecvat al
ipotezei continuității activității și efectul, dacă este cazul, asupra declarații
– Rezultatul revizuirilor ulterioare și concluziile privind efectul evenimentelor ulterioare asupra situațiilor financiare
Pagină 272
– Concluzie la care sa ajuns în evaluarea denaturărilor, inclusiv a deficiențelor de dezvăluire
– Dacă se observă contradicție sau inconsecvență cu concluzia finală cu privire la o chestiune semnificativă, ar trebui să
existe o documentație adecvată pentru abordarea inconsecvenței – Concluzia dacă procedurile de audit efectuate și
probele de audit obținute au fost adecvate și consecvente pentru a susține concluzia auditului
(g) Arhivarea documentelor
Băncilor li se recomandă să aibă o politică de arhivare/reținere pentru a arhiva rezultatele auditului.
Băncile să aibă o politică de arhivare care:
– Asigură integritatea datelor
– Definește drepturile de acces adecvate
– Decide asupra suportului de arhivare adecvat
- Asigură recuperarea ușoară
Revizuirea calității
Această secțiune are scopul de a sublinia calitatea activității auditorilor SI, în timp ce își exercită atribuțiile de auditor. Se
recomandă niveluri adecvate în funcția de audit SI pentru a evalua calitatea auditului prin revizuirea documentației,
asigurând o supraveghere adecvată a membrilor auditului SI și evaluând dacă membrii auditului SI au avut grijă cuvenită
în timpul îndeplinirii sarcinilor lor. Acest lucru va aduce eficiență, control și îmbunătăți calitatea auditului IS.
Dovezi și documentație
Auditorii IS pot efectua următoarele revizuiri progresive ale dovezilor și documentației :
– O revizuire detaliată a fiecărui document de lucru pregătit de un membru mai puțin experimentat al echipei de audit IS,
de către un membru mai experimentat, care nu a participat la pregătirea unui astfel de document de lucru
– O revizuire primară a dovezilor și documentației de către Manager sau Șeful auditului SI. În cazul în care managerul
efectuează o evaluare primară, aceasta nu necesită ca fiecare document de lucru să fie revizuit în detaliu de către manager,
deoarece fiecare document de lucru a fost deja revizuit în detaliu de către persoana care a efectuat revizuirea detaliată.
– O revizuire primordială a documentelor de lucru de către CAE, după caz
Supraveghere
Personalul de audit IS ar trebui să fie supravegheat pentru a oferi o asigurare rezonabilă că obiectivele auditului sunt
îndeplinite și că sunt îndeplinite standardele profesionale de audit aplicabile.
Diligență
Pagină 273
Standardul de „diligență cuvenită” este acel nivel de diligență pe care o persoană prudentă și competentă l-ar exercita într-
un anumit set de circumstanțe. „Îngrijirea profesională cuvenită” se aplică unei persoane care pretinde că își exercită o
abilitate specială, cum ar fi auditarea SI. Grija profesională cuvenită necesită ca individul să-și exercite această abilitate la
un nivel deținut în mod obișnuit de auditorii cu specialitatea respectivă.
Se aplică grija profesională cuvenită exercitării raționamentului profesional în desfășurarea muncii prestate. Aceasta
implică faptul că profesionistul abordează problemele care necesită raționament profesional cu diligența corespunzătoare.
În ciuda exercitării diligentei profesionale și a raționamentului profesional cuvenite, pot apărea situații în care se poate
trage o concluzie incorectă dintr-o analiză diligentă a faptelor și circumstanțelor disponibile. Prin urmare, descoperirea
ulterioară a concluziilor incorecte nu indică, prin ea însăși, raționament profesional inadecvat sau lipsă de diligență din
partea auditorului IS.
Grija profesională cuvenită ar trebui să se extindă asupra fiecărui aspect al auditului, inclusiv evaluarea riscului de audit,
formularea obiectivelor auditului, stabilirea domeniului auditului, selectarea testelor de audit și evaluarea rezultatelor
testelor.
În acest sens, auditorii IS trebuie să determine sau să evalueze:
Tipul și nivelul resurselor de audit necesare pentru îndeplinirea obiectivelor de audit
Semnificația riscurilor identificate și efectul potențial al acestor riscuri asupra auditului
Dovezi de audit adunate
Competența, integritatea și concluziile altora pe munca cărora auditorii IS se bazează
Destinatarii vizați ai rapoartelor de audit au o așteptare adecvată că auditorii SI au exercitat grija profesională cuvenită pe
parcursul auditului. Auditorii IS nu ar trebui să accepte o misiune decât dacă abilitățile, cunoștințele și alte resurse
adecvate sunt disponibile pentru a finaliza munca în modul așteptat de la un profesionist. Auditorii SI trebuie să efectueze
auditul cu diligență, respectând în același timp standardele profesionale. Auditorii IS trebuie să dezvăluie circumstanțele
oricărei nerespectări cu standardele profesionale într-o manieră compatibilă cu comunicarea rezultatelor auditului.
Asigurarea independentă a funcției de audit
În scopul de a oferi asigurări conducerii băncii și autorităților de reglementare, băncile sunt obligate să efectueze o
asigurare a calității, cel puțin o dată la trei ani, a auditului intern al băncii, inclusiv a funcției de audit IS, pentru a valida
abordarea și practicile adoptate de acestea în descărcarea de gestiune. responsabilitățile sale, astfel cum sunt prevăzute în
Politica de audit.
Obiectivele efectuării unei evaluări a calității sunt:
Evaluați eficiența și eficacitatea unui audit intern pentru obiectivele de afaceri actuale și viitoare
Determinați valoarea adăugată din Auditul Intern către unitățile de afaceri
Evaluați, identificați și recomandați, practici de succes de Audit Intern
Evaluează conformitatea cu standardele pentru practica profesională a Auditului Intern
Pagină 274
Alții:
Dintr-o chestiune de prudență, băncile ar trebui să rotească auditorii SI într-un anumit domeniu în mod periodic,
Un audit al sistemului informatic (IS) sau un audit al tehnologiei informației (IT) este o examinare a controalelor din
cadrul infrastructurii tehnologiei informației a unei entități. Aceste revizuiri pot fi efectuate împreună cu un audit al
situațiilor financiare, audit intern sau altă formă de misiune de atestare. Este procesul de colectare și evaluare a dovezilor
privind sistemele informaționale, practicile și operațiunile unei organizații. Evaluarea dovezilor obținute poate asigura
dacă sistemele informaționale ale organizației protejează activele, mențin integritatea datelor și funcționează eficient și
eficient pentru a atinge scopurile sau obiectivele organizației.
Un audit IS nu este în întregime similar cu un audit al situațiilor financiare. O evaluare a controalelor interne poate sau nu
să aibă loc într-un audit IS. Încrederea pe controalele interne este o caracteristică unică a unui audit financiar. O evaluare
a controalelor interne este necesară într-un audit financiar, pentru a permite auditorului să se bazeze pe controalele interne
și, prin urmare, pentru a reduce substanțial volumul de teste necesare pentru a forma o opinie cu privire la situațiile
financiare ale companiei. Un audit IS, pe de altă parte, tinde să se concentreze pe determinarea riscurilor care sunt
relevante pentru activele informaționale și pe evaluarea controalelor pentru a reduce sau atenua aceste riscuri. Un audit IT
poate lua forma unei „evaluări generale de control” sau a unei „evaluări a controlului specific”. În ceea ce privește
protecția activelor informaționale, un scop al unui audit IS este de a revizui și evalua disponibilitatea, confidențialitatea și
integritatea sistemului informațional al unei organizații, răspunzând la următoarele întrebări:
1. Sistemele computerizate ale organizației vor fi disponibile pentru afacere în orice moment când este necesar?
(Disponibilitate)
2. Informațiile din sisteme vor fi dezvăluite numai utilizatorilor autorizați? (Confidentialitate)
3. Informațiile furnizate de sistem vor fi întotdeauna exacte, de încredere și la timp? (Integritate).

Efectuarea unui audit IS acoperă mai multe fațete ale funcțiilor financiare și organizaționale ale clienților noștri.
Diagrama din dreapta vă oferă o imagine de ansamblu asupra fluxului de audit al sistemelor informaționale: de la situațiile
financiare la mediul de control și platformele sistemelor informaționale.
Metodologia Auditului Sistemelor Informaţionale

Metodologia noastră a fost dezvoltată în conformitate cu Standardele Internaționale de Audit ale Sistemelor
Informaționale, de exemplu Standardele și Ghidurile de Audit ale Sistemelor Informaționale ISACA și Standardul COSO
Sabarne Oxley. Punctul de început al acestei metodologii este realizarea activităților de planificare care sunt orientate spre
integrarea unei abordări de audit bazate pe risc în auditul IS.
FAZA 1: Planificarea auditului
În această fază planificăm acoperirea sistemului informațional pentru a respecta obiectivele de audit specificate de Client
și pentru a asigura conformitatea cu toate Legile și Standardele Profesionale. Primul lucru este de a obține de la Client o
Cartă de Audit care să detalieze scopul auditului, responsabilitatea managementului, autoritatea și responsabilitatea
funcției de Audit al Sistemelor Informaționale, după cum urmează:
1. Responsabilitate: Carta de audit ar trebui să definească misiunea, scopurile, scopurile și obiectivele auditului
sistemului informațional. În această etapă definim, de asemenea, Indicatorii Cheie de Performanță și un proces de
Evaluare de Audit;
Pagină 275
2. Autoritate: Carta de audit ar trebui să specifice în mod clar Autoritatea atribuită auditorilor sistemelor informaționale
în legătură cu activitatea de evaluare a riscurilor care va fi efectuată, dreptul de acces la informațiile clientului, sfera de
aplicare și/sau limitările sferei de aplicare, funcțiile clientului la fi auditat și așteptările auditatului; și
3. Responsabilitate: Carta de audit ar trebui să definească în mod clar liniile de raportare, evaluările, evaluarea
conformității și acțiunile convenite.
Carta de audit ar trebui să fie aprobată și agreată de un nivel corespunzător din cadrul Organizației Clientului.
Consultați șablonul pentru o carte de audit/scrisoare de angajament aici.
În plus față de Carta de audit, ar trebui să putem obține o declarație scrisă („Scrisoare de reprezentare”) din partea
conducerii clientului, care confirmă:
1. Responsabilitatea acestora pentru proiectarea și implementarea sistemelor de control intern care afectează sistemele
și procesele IT
2. Disponibilitatea acestora de a dezvălui auditorului sistemelor informaționale cunoștințele lor despre neregulile și/sau
actele ilegale care le afectează organizația referitoare la conducere și angajații cu roluri semnificative în cadrul
departamentului de audit intern.
3. Disponibilitatea lor de a dezvălui auditorului IS rezultatele oricărei evaluări a riscului conform căreia s-ar fi putut
produce o denaturare semnificativă
Vedeți un șablon pentru o scrisoare de reprezentare aici.
FAZA 2 – Evaluarea riscurilor și analiza procesului de afaceri
Riscul este posibilitatea producerii unui act sau eveniment care ar avea un efect negativ asupra organizației și sistemelor
sale informaționale. Riscul poate fi, de asemenea, potențialul ca o anumită amenințare să exploateze vulnerabilitățile unui
activ sau grup de active pentru a cauza pierderea sau deteriorarea activelor. Este de obicei măsurată printr-o combinație de
efect și probabilitatea de apariție.
Tot mai multe organizații trec la o abordare de audit bazată pe risc, care poate fi adaptată pentru a dezvolta și îmbunătăți
procesul de audit continuu. Această abordare este utilizată pentru a evalua riscul și pentru a sprijini decizia auditorului SI
de a face fie teste de conformitate, fie teste de fond. Într-o abordare de audit bazată pe risc, auditorii SI nu se bazează doar
pe risc. De asemenea, se bazează pe controale interne și operaționale, precum și pe cunoștințele despre organizație. Acest
tip de decizie de evaluare a riscurilor poate ajuta la corelarea analizei cost/beneficiu a controlului cu riscul cunoscut,
permițând alegeri practice.
Procesul de cuantificare a riscului se numește evaluarea riscului. Evaluarea riscurilor este utilă în luarea unor decizii
precum:
1. Zona/funcția de afaceri care urmează să fie auditată
2. Natura, amploarea și momentul procedurilor de audit
3. Cantitatea de resurse care trebuie alocată unui audit

Trebuie luate în considerare următoarele tipuri de riscuri:
Riscul inerent: Riscul inerent este susceptibilitatea unei zone de audit la erori care ar putea fi semnificative, individual sau
în combinație cu alte erori, presupunând că nu au existat controale interne aferente. În evaluarea riscului inerent, auditorul
SI trebuie să ia în considerare atât controalele IS generale, cât și cele detaliate. Acest lucru nu se aplică circumstanțelor în
Pagină 276
care misiunea auditorului SI este legată doar de controale IS pervazive. Un control IS pervaziv sunt controale generale
care sunt concepute pentru a gestiona și monitoriza mediul IS și, prin urmare, afectează toate activitățile legate de IS.
Unele dintre controalele IS omniprezente pe care un auditor le poate lua în considerare includ:
• Integritatea managementului SI și a experienței și cunoștințelor în managementul SI
• Schimbări în managementul IS
• Presiuni asupra managementului IS care îi poate predispune să ascundă sau să denatureze informații (de exemplu,
depășiri mari de proiecte critice pentru afaceri și activitate de hackeri)
• Natura activității și sistemelor organizației (de exemplu, planurile pentru comerțul electronic, complexitatea
sistemelor și lipsa sistemelor integrate)
•personalului
Factori care afectează industria organizației în ansamblu (de exemplu, schimbări în tehnologie și disponibilitatea
IS)
• Nivelul influenței terților asupra controlului sistemelor auditate (de exemplu, din cauza integrării lanțului de
aprovizionare, a proceselor IS externalizate, a asociațiilor comerciale în comun și a accesului direct al clienților)
• Constatări de la și data auditurilor anterioare

Un control IS detaliat este un control asupra achiziției, implementării, livrării și suportului sistemelor și serviciilor IS.
Auditorul SI trebuie să ia în considerare, la nivelul adecvat domeniului de audit în cauză:
• Constatările și data auditurilor anterioare în acest domeniu
• Complexitatea sistemelor implicate
• Nivelul de intervenție manuală necesar
• Susceptibilitatea la pierderea sau deturnarea activelor controlate de sistem (de exemplu, inventar și salarizare)
• Probabilitatea de activitate atinge vârfuri în anumite momente din perioada de audit
• Activități în afara rutinei de zi cu zi a prelucrării IS (de exemplu, utilizarea utilităților sistemului de operare pentru a
modifica datele)
• Integritatea, experiența și abilitățile conducerii și ale personalului implicat în aplicarea controalelor IS

Riscul de control: Riscul de control este riscul ca o eroare care ar putea apărea într-o zonă de audit și care ar putea fi
semnificativă, individual sau în combinație cu alte erori, să nu fie prevenită sau detectată și corectată în timp util de către
sistemul de control intern. . De exemplu, riscul de control asociat cu revizuirile manuale ale jurnalelor computerului poate
fi mare, deoarece activitățile care necesită investigare sunt adesea ratate cu ușurință din cauza volumului de informații
înregistrate. Riscul de control asociat cu procedurile computerizate de validare a datelor este de obicei scăzut deoarece
procesele sunt aplicate în mod consecvent. Auditorul SI trebuie să evalueze riscul de control ca fiind ridicat, cu excepția
cazului în care controalele interne relevante sunt:
• Identificat
• Evaluat ca eficient
• Testat și dovedit că funcționează corespunzător

Riscul de detectare: Riscul de detectare este riscul ca procedurile de fond ale auditorului SI să nu detecteze o eroare care
ar putea fi semnificativă, individual sau în combinație cu alte erori. Pentru a determina nivelul de testare de fond necesar,
Pagină 277
auditorul SI trebuie să ia în considerare ambele:
• Evaluarea riscului inerent
• Concluzia la care sa ajuns asupra riscului de control în urma testării de conformitate

Cu cât evaluarea riscului inerent și de control este mai mare, cu atât auditorul SI ar trebui să obțină în mod normal mai
multe probe de audit din efectuarea procedurilor de audit de fond.
Abordarea noastră de audit a sistemelor informaționale bazată pe risc
O abordare bazată pe risc a unui audit al sistemelor informaționale ne va permite să dezvoltăm un plan global și eficient
de audit IS, care va lua în considerare toate potențialele deficiențe și/sau absența controalelor și va determina dacă acest
lucru ar putea duce la o deficiență semnificativă sau o slăbiciune semnificativă.
Pentru a efectua o evaluare eficientă a riscurilor, va trebui să înțelegem mediul de afaceri și operațiunile clientului. De
obicei, prima fază în realizarea unui audit IS bazat pe risc este de a obține o înțelegere a Universului de audit. În
înțelegerea Universului de Audit, efectuăm următoarele:
• Identificați zonele în care riscul este inacceptabil de mare
• Identificați sistemele de control critice care abordează riscurile inerente ridicate
• Evaluează incertitudinea care există în legătură cu sistemele critice de control

În efectuarea analizei procesului de afaceri:
Pagină 278
• Obține o înțelegere a proceselor de afaceri ale clientului
• Harta mediul de control intern
• Identificați zonele cu puncte slabe de control

Chatul din dreapta rezumă faza de analiză a procesului de afaceri.
Șablonul xxx vă va oferi un ghid pentru a documenta subprocesele de afaceri ale organizațiilor identificate în timpul fazei
de analiză a riscului. Pentru fiecare dintre sub-procese, identificăm o listă de Ce ar putea merge greșit (WCGW). Acest
WCGW reprezintă amenințarea existentă asupra unui anumit proces. Un singur proces ar avea mai multe WCGW. Pentru
fiecare dintre WCGW-urile identificate în faza anterioară, vom determina Activitățile cheie din acel proces. Pentru fiecare
activitate cheie:
1. Vom identifica controalele Sistemelor Informaționale
2. Pentru fiecare dintre controalele identificate, am evalua impactul/efectul lipsei acelui control (pe un rating de 1 -
5, cu 5 indicând cel mai mare impact), vom determina apoi probabilitatea de apariție a amenințării (de asemenea, pe un
rating de 1 - 5, cu 5 reprezentând cea mai mare probabilitate).
<< Descrieți aici metodologia specifică de evaluare a riscurilor >>
Pagină 279
FAZA 3 – Efectuarea lucrărilor de audit
GenecalfPerxaseceCantraReviEa
Ealuate oontrala pervazivă în aocordamce mith cadrul OEIT (vezi

secțiunea despre ODBIT} Unele dintre contola pervase indudei
« Reviem o IT Strategrand cther poicg dncument

■ Programul Appicalion IDrwelopmen!
Metodokogv
« Metoda de implementare a sistemului
* BusnesEontinuitp Planning and Dsaster RecowerF
În realizarea lucrărilor de audit,

standardele de audit ale sistemelor
informaționale ne cer să asigurăm supraveghere, să colectăm probe de audit și să ne documentăm activitatea de audit.
Atingem acest obiectiv prin:
• Stabilirea unui proces de evaluare internă în care munca unei persoane este revizuită de o altă persoană, de preferință
o persoană mai în vârstă.
• Obținem dovezi suficiente, de încredere și relevante pentru a fi obținute prin inspecție, observare, anchetă,
Confirmarea și recalcularea calculelor
• Ne documentăm munca prin descrierea activității de audit efectuate și a probelor de audit adunate pentru a susține
constatările auditorilor.
Pe baza evaluării noastre de risc și pe baza identificării zonelor riscante, mergem mai departe pentru a dezvolta un plan de
audit și un program de audit. Planul de audit va detalia natura, obiectivele, calendarul și amploarea resurselor necesare
auditului.
Consultați șablonul pentru un exemplu de plan de audit.
Pe baza testelor de conformitate efectuate în faza anterioară, dezvoltăm un program de audit care detaliază natura,
momentul și amploarea procedurilor de audit. În Planul de Audit se pot face diverse Teste de Control și Revizuiri.
Acestea sunt subdivizate în:
1. Controale generale/pervazive
2. Controale specifice
Pagină 280
Chatul de mai jos în stânga arată testele de revizuire a controlului care pot fi efectuate în cele două teste de control de mai
sus.
Obiective de control pentru tehnologia informației și aferente (COBIT)
Obiectivele de control pentru tehnologia informației și aferente (COBIT) este un set de bune practici (cadru) pentru
managementul informațiilor (IT) creat de Asociația de Audit și Control al Sistemelor Informaționale (ISACA) și Institutul
de Guvernare IT (ITGI) în 1992.
COBIT oferă managerilor, auditorilor și utilizatorilor IT un set de măsuri, indicatori, procese și bune practici general
acceptate pentru a-i ajuta în maximizarea beneficiilor obținute prin utilizarea tehnologiei informației și dezvoltarea unei
guvernanțe și control IT adecvate într-o companie.
Pagină 281
PROCESELE COBIT IT DEFINITE ÎN CADRUL CELOR PATRU DOMENII
OBIECTIVELE AFACERII
GUVERNANȚA FT
Ml moritcf the procme Pul defire 4 turaimgu It plan

M2 mcin irderml €onirol adoqunc P02 defirn theinlormakonarcheecrc
M3 cbinin independleni nnruranee Mi proridofor PDJ determine hhe bechmologie m dircerion
idirperidont nudi P04 definește ergamtaon și relauerehip IT
PC'S minnge ihe R irmemkrem
PCe5 Eerrmunicaie mrinjemned inlimmn si chreekiem
POT mnnee uman tebuce
POe eraaic cespbarewth eqiernd iteuitomain
P09 assereks
PO1C mnage peejeei
Trage mrngecalry
MONITORIZAREA
TION
051 052 defire and manage serwce levek mansg=

DS3 05a ihedparty sevces marine perlormance and
D55 DS6 capacify eneule corruots serice
057 DSE enule ay-eme iecurity iderfy and allocoi cos
039 educam and wai LeH aris arid adike cudlfm
0S10 mannge the congu ancn nanage pobee and
DSII irwcidene manag= Jana monnge locilies
Al 1 k5a iiy nubomaind xcliom
512 mansge operains Toate nequfe și maininin appleamot bomwaie
0513 A13 aequire ene maninin iechrelogsinfrairucture
AM deeeop ard mnirea in piccedure
AIE imainl nevoie de ntetedit nhemn
AIB rnamage chkgm
COBIT ajută la satisfacerea nevoilor multiple ale managementului prin reducerea decalajelor dintre riscurile de afaceri,
nevoile de control și problemele tehnice. Acesta oferă un cadru de bune practici pentru gestionarea resurselor IT și
prezintă activitățile de control al managementului într-o structură gestionabilă și logică. Acest cadru va ajuta la
optimizarea investițiilor în informații tehnologice și va oferi o măsură de referință adecvată.
Cadrul cuprinde un set de 34 de obiective de control la nivel înalt, câte unul pentru fiecare dintre procesele IT enumerate
în cadru. Acestea sunt apoi grupate în patru domenii: planificare și organizare, achiziție și implementare, livrare și suport
și monitorizare. Această structură acoperă toate aspectele procesării și stocării informațiilor și tehnologia care o susține.
Pagină 282
Prin abordarea acestor 34 de obiective de control la nivel înalt, ne vom asigura că este asigurat un sistem de control
adecvat pentru mediul IT. O reprezentare schematică a cadrului este prezentată mai jos.
Vom aplica cadrul COBIT în planificarea, executarea și raportarea rezultatelor auditului. Acest lucru ne va permite să
revizuim controalele generale asociate problemelor de guvernanță IT. Analiza noastră va acoperi următoarele domenii;
• Planificarea și organizarea resurselor informaționale;
• Planificarea si achizitia sistemelor si modelul de crestere in stadii a sistemelor informatice;
• Furnizarea și suportul IS/IT, inclusiv facilități, operațiuni, utilizare și acces;
• Monitorizarea proceselor din jurul sistemelor informatice;
• Nivelul de eficacitate, eficiență, confidențialitate, integritate, disponibilitate, conformitate și fiabilitate asociate cu

informațiile deținute; și
• Nivelul de utilizare a resurselor IT disponibile în mediul SI, inclusiv oamenii, sistemele de aplicație de interfață,
tehnologie, facilități și date.
Obiectivele de control de mai sus vor fi corelate cu obiectivele de control al afacerii pentru a aplica proceduri specifice de
audit care vor oferi informații despre controalele construite în aplicație, indicând zonele de îmbunătățire pe care trebuie să
ne concentrăm asupra realizării.
Revizuirea controlului aplicației
O revizuire a controlului aplicației va oferi conducerii o asigurare rezonabilă că tranzacțiile sunt procesate conform
intenției și că informațiile din sistem sunt exacte, complete și la timp. O examinare a comenzilor aplicației va verifica
dacă:
• Controlează eficacitatea și eficiența
• Securitatea aplicațiilor
• Dacă aplicația funcționează conform așteptărilor

O revizuire a controalelor aplicației va acoperi o evaluare a ciclului de viață al tranzacției de la originea, pregătirea,
intrarea, transmiterea, procesarea și ieșirea datelor, după cum urmează:
1. Controalele de origine a datelor sunt controale stabilite pentru a pregăti și a autoriza introducerea datelor într-o
aplicație. Evaluarea va implica o revizuire a designului și stocării documentului sursă, a procedurilor și manualelor
utilizatorului, a formularelor cu scop special, a codurilor de identificare a tranzacțiilor, a indicilor de referință încrucișată
și a documentelor alternative, acolo unde este cazul. De asemenea, va implica o revizuire a procedurilor de autorizare și
separarea sarcinilor în procesul de captare a datelor.
2. Controalele de pregătire a intrărilor sunt controale referitoare la numerotarea tranzacțiilor, numerotarea seriei
loturilor, procesarea, analiza jurnalelor și o revizuire a documentelor de transmitere și de livrare
3. Controalele transmisiei implică verificarea și echilibrarea loturilor, programele de procesare, revizuirea mesajelor de
eroare, monitorizarea corecțiilor și securitatea tranzacțiilor
4. Controalele de prelucrare asigură integritatea datelor pe măsură ce acestea sunt supuse fazei de prelucrare, inclusiv
Relaționale
Pagină 283
Controale baze de date, stocare și regăsire a datelor
5. Procedurile de control al ieșirilor implică proceduri referitoare la distribuirea rapoartelor, reconcilierea, procesarea
erorilor de ieșire, păstrarea înregistrărilor.
Utilizarea tehnicilor de audit asistate de computer (CAATS) în realizarea unui audit IS
Standardele de audit al sistemelor informaționale ne cer ca, pe parcursul unui audit, auditorul SI să obțină dovezi
suficiente, fiabile și relevante pentru a atinge obiectivele auditului. Constatările și concluziile auditului trebuie să fie
susținute de analiza și interpretarea adecvată a acestor probe. CAAT-urile sunt utile în atingerea acestui obiectiv.
Tehnicile de audit asistate de calculator (CAAT) sunt instrumente importante pentru auditorul SI în efectuarea auditurilor.
Acestea includ multe tipuri de instrumente și tehnici, cum ar fi software-ul de audit generalizat, software-ul utilitar, datele
de testare, urmărirea și maparea software-ului de aplicație și sisteme expert de audit. Pentru noi, CAAT-urile noastre
includ software-ul de analiză a datelor ACL și setul de instrumente de audit al sistemelor informaționale (ISAT).
CAAT-urile pot fi utilizate în realizarea diferitelor proceduri de audit, inclusiv:
• Teste ale detaliilor tranzacțiilor și soldurilor (Teste de fond)
• Proceduri de revizuire analitică
• Teste de conformitate ale controalelor generale IS
• Teste de conformitate ale controalelor aplicației IS

CAAT-urile pot produce o mare parte din probele de audit dezvoltate cu privire la auditurile SI și, în consecință, auditorul
SI trebuie să planifice cu atenție și să dea dovadă de grija profesională cuvenită în utilizarea CAAT-urilor. pentru
aplicarea CAAT-urilor selectate sunt:
• Stabiliți obiectivele de audit ale CAAT-urilor
• Determinați accesibilitatea și disponibilitatea facilităților, programelor/sistemului și datelor IS ale organizației
• Definiți procedurile care trebuie întreprinse (de exemplu, eșantionare statistică, recalculare, confirmare etc.)
• Definiți cerințele de ieșire
• Determinați cerințele de resurse, de exemplu, personalul, CAAT-urile, mediul de procesare (facilitățile SI ale
organizației sau instalațiile SI de auditare)
• Obține acces la facilitățile IS ale clienților, programe/sistem și date, inclusiv definițiile fișierelor
•rulareDocumentați CAAT-urile care trebuie utilizate, inclusiv obiective, diagrame de flux de nivel înalt și instrucțiuni de
• Faceți aranjamentele adecvate cu auditatul și asigurați-vă că:
1. Fișierele de date, cum ar fi fișierele detaliate ale tranzacțiilor, sunt păstrate și puse la dispoziție înainte de începerea
auditului.
2. Ați obținut drepturi suficiente la facilitățile, programele/sistemul și datele clientului IS
3. Testele au fost programate corespunzător pentru a minimiza efectul asupra mediului de producție al organizației.
4. Efectul că modificările aduse programelor/sistemului de producție au fost luate în considerare în mod corespunzător.
Pagină 284
Consultați șablonul aici pentru exemple de teste pe care le puteți efectua cu ACL
FAZA 4: Raportare
La efectuarea testului de audit, Auditorul Sistemelor Informaționale este obligat să elaboreze și un raport corespunzător
care să comunice rezultatele auditului SI. Un raport de audit IS ar trebui:
1. Identificați o organizație, destinatarii vizați și orice restricții privind circulația
2. Indicați domeniul de aplicare, obiectivele, perioada de acoperire, natura, momentul și extinderea activității de audit
3. Prezentați constatările, concluziile, recomandările și orice rezerve, calificări și limitări
4. Furnizați probe de audit
Grupul de audit al Sistemelor Informaționale (IS) evaluează sistemele critice, arhitectura tehnologică și procesele
Universității pentru a se asigura că activele informaționale sunt protejate, fiabile, disponibile și conforme cu politicile și
procedurile Universității, precum și cu legile și reglementările aplicabile. Subliniem importanța atenuării riscurilor de
securitate în timpul acoperirii auditului nostru asupra aplicațiilor, sistemelor de operare și de rețea ale Universității. Prin
auditurile noastre integrate și de guvernanță IT, evaluăm impactul tehnologiei informației asupra proceselor Universității
și abilităților acesteia de a-și atinge scopurile și obiectivele. Evaluările noastre sunt obiective și profesionale, utilizând
cadrul COBIT (Control Objectives for Information and related Technology), un standard internațional pentru bunele
practici de control IT.
ISA oferă următoarele servicii de audit:
• Guvernanța IT - Auditurile de guvernanță IT includ analize ale responsabilității fiduciare a organizației în

satisfacerea calității serviciilor de livrare IT, aliniind în același timp la obiectivele de afaceri și stabilind un sistem adecvat
de controale interne.
• Sisteme informatice - Auditurile sistemelor informatice se concentrează pe controalele de securitate ale securității
fizice și logice a serverului, inclusiv controlul modificărilor, administrarea conturilor de server, înregistrarea și
monitorizarea sistemului, gestionarea incidentelor, backup-ul sistemului și recuperarea în caz de dezastru.
• Audituri integrate - Auditurile integrate includ revizuiri ale operațiunilor de afaceri și dependența acestora de
sistemele automate pentru a sprijini procesul de afaceri. Considerăm tehnologia informației și procesele financiare și
operaționale ca fiind dependente reciproc pentru stabilirea unui mediu de control eficient și eficient. Din perspectiva
tehnologiei, auditul se concentrează pe controalele aplicațiilor, administrarea accesului utilizatorilor, controlul
modificărilor aplicației și backup și recuperare pentru a asigura fiabilitatea, integritatea și disponibilitatea datelor.
• Autoevaluări de control - Autoevaluările de control sunt concepute pentru departamentul care gestionează și
operează un mediu tehnologic. Aceste instrumente de autoevaluare pot fi utilizate pentru a identifica potențiale zone de
slăbiciune a controlului în managementul mediului tehnologic.
• Conformitate - Auditurile de conformitate includ politicile și procedurile universitare, industria cardurilor de plată
(PCI), Legea privind portabilitatea și responsabilitatea asigurărilor de sănătate (HIPAA) , Legea privind drepturile și
confidențialitatea la educația familiei (FERPA) și orice alte legi și reglementări aplicabile.
Pagină 285
IT & PROBLEME JURIDICE
Introducere
Comitetul de Supraveghere Bancară de la Basel, în „Documentul său consultativ privind riscul operațional”,
definește „riscul operațional” ca riscul de pierdere directă sau indirectă care rezultă din procese, oameni și sisteme
interne inadecvate sau eșuate sau din evenimente externe. Această definiție include riscul juridic .1
Legea privind tehnologia informației, 2000 (Legea IT, 2000) a fost adoptată pentru a gestiona anumite probleme
legate de tehnologia informației. Legea de modificare a IT din 2008 a adus modificări suplimentare pentru a aborda
mai multe probleme, cum ar fi infracțiunile cibernetice. Este esențial ca băncile să ia în considerare impactul legilor
cibernetice pentru a evita orice risc care decurge din acestea.
A. Ghid pentru bănci
Roluri și responsabilități și structura organizațională
Pagină 286
Consiliul de administrație: Comitetul de gestionare a riscurilor la nivel de consiliu trebuie să pună în aplicare
procesele pentru a se asigura că riscurile juridice care decurg din legile cibernetice sunt identificate și abordate.
De asemenea, trebuie să se asigure că funcțiile în cauză dispun de personal adecvat și că resursele umane sunt
pregătite pentru a îndeplini sarcinile relevante în acest sens.
Grupul de risc operațional: Acest grup trebuie să încorporeze riscurile legale ca parte a cadrului de risc
operațional și să ia măsuri pentru a atenua riscurile implicate în consultare cu funcțiile sale juridice în cadrul
băncii.
Departamentul Juridic: Funcția juridică din cadrul băncii trebuie să consilieze grupurile de afaceri cu privire la
problemele juridice care decurg din utilizarea tehnologiei informației cu privire la riscul juridic identificat și
înaintat acestuia de către Grupul de Risc Operațional.
Infracțiuni legate de computer și pedeapsă/pedeapsă
Legea IT din 2000, astfel cum a fost modificată, expune băncile atât răspunderii civile , cât și penale .
2 3
Răspunderea civilă ar putea consta în expunerea la plata daunelor sub formă de despăgubiri de până la 5 milioane
K în conformitate cu Legea tehnologia informației modificată în fața ofițerului de adjudecare și peste K 5
milioane într-o instanță de jurisdicție competentă. Ar putea exista, de asemenea, expunerea la răspunderea penală
față de conducerea de vârf a băncilor, având în vedere prevederile capitolului XI din Legea IT modificată , iar 4
expunerea la răspunderea penală ar putea consta în închisoare pe un termen care se poate extinde de la trei ani la
închisoare pe viață, deoarece De-asemenea bine. În plus, în prevederile menționate mai sus sunt enumerate
diverse infracțiuni legate de calculator.
Aspecte critice
Riscul juridic și riscul operațional sunt aceleași. Cele mai multe riscuri sunt căutate să fie
acoperite de documentație, în special acolo unde legea tace. Acordul Basel-II
http://www.bis.org/publ/bcbsca07.pdf
Secțiunile 43-45
Secțiunile 65-74
Secțiunea 85
acoperă „riscul legal” la „riscul operațional”. Documentația reprezintă o parte importantă a

sectorului bancar și financiar. Pentru mulți, documentarea este un panaceu pentru riscurile juridice
care pot apărea în activitățile bancare. Dar apoi, a fost, de asemenea, realizat și recunoscut pe scară
Pagină 287
largă că există lacune în documentare.
Riscurile juridice trebuie să fie încorporate ca parte a riscurilor operaționale, iar poziția trebuie
comunicată periodic conducerii de vârf și Consiliului/Comitetului de management al riscurilor din
cadrul Consiliului.
Întrucât legea privind protecția datelor și confidențialitatea, în contextul indian se află într-o etapă
de evoluție, băncile trebuie să țină seama de prevederile specifice ale IT Act, 2000 (modificată în
2008), diferite hotărâri judiciare și cvasijudiciare și evoluții conexe în legile cibernetice din India ca
parte a măsurilor legale de reducere a riscurilor. Băncilor li se cere, de asemenea, să se țină la
curent cu cele mai recente evoluții din Legea IT din 2000 și cu regulile, reglementările, notificările
și ordinele emise acolo în temeiul tranzacțiilor bancare și cu standardele legale emergente privind
semnătura digitală, semnătura electronică, protecția datelor, trunchierea cecurilor, transferul de
fonduri etc. ca parte a procesului general de management al riscului operațional.
Legea privind tehnologia informației (modificare), 2008

Principalul act indian care abordează provocările juridice în special în ceea ce privește internetul este Legea privind
tehnologia informației (amendament) din 2008 sau, pe scurt, Legea IT. Subliniem secțiunile care au cea mai mare
relevanță pentru internet și democrație. Aceasta include secțiuni referitoare la ridicările guvernamentale,
monitorizarea și interceptarea comunicării și răspunderea intermediarului.
Secțiunea 69A și regulile de blocare: Permiterea guvernului să blocheze conținutul în anumite circumstanțe
Secțiunea 69A din Legea IT (modificare) din 2008, permite guvernului central să blocheze conținutul în cazul în care
consideră că acest conținut amenință securitatea statului; suveranitatea, integritatea sau apărarea Indiei; relații de
prietenie cu statele străine; ordine publică; sau pentru a preveni incitarea la comiterea unei infracțiuni identificabile
referitoare la oricare dintre cele de mai sus. Un set de proceduri și garanții la care guvernul trebuie să adere atunci
când face acest lucru au fost stabilite în ceea ce au devenit cunoscute sub numele de Reguli de blocare.
• Secțiunea 79 și regulile IT: Privatizarea cenzurii în India
Secțiunea 79 din Legea privind tehnologia informației (modificare) din 2008 reglementează răspunderea unei game
largi de intermediari din India. Secțiunea a ajuns în lumina reflectoarelor în principal din cauza infamelor Reguli de
ghidare intermediare, sau Reguli IT, care au fost făcute în baza acesteia. Regulile IT constituie o mișcare importantă
și îngrijorătoare către privatizarea cenzurii în India.
• Secțiunile 67 și 67A: Fără nuditate, vă rog
Cantitățile mari de material „obscen” care circulă pe internet au atras mult timp comentarii în India. Nu este
surprinzător, așadar, la fel cum obscenitatea este interzisă offline în țară, deci este și online. Cele mai importante
instrumente pentru a o reduce sunt secțiunile 67 și 67A din Legea IT, care interzic materialele obscene și, respectiv,
sexual explicite.
• Secțiunea 66A: Nu trimiteți mesaje jignitoare
Secțiunea 66A din Legea privind tehnologia informației (modificare) din 2008 interzice trimiterea de mesaje
jignitoare printr-un dispozitiv de comunicare (adică printr-un mediu online). Tipurile de informații pe care le acoperă
sunt mesaje ofensive cu caracter amenințător sau un mesaj despre care expeditorul știe că este fals, dar este trimis în
Pagină 288
scopul de a
„care provoacă supărare, neplăcere, pericol, obstrucție, insultă, vătămare, intimidare criminală, dușmănie, ură sau rea
voință”. Dacă sunteți rezervat în temeiul Secțiunii 66A, puteți risca până la 3 ani de închisoare împreună cu o
amendă.
• Libertate de exprimare
A echilibra libertatea de exprimare cu alte drepturi ale omului este, uneori, o sarcină dificilă și delicată. De la
discursul instigator la ură la răspunderea intermediară, dezvăluim și aruncăm mai multă lumină asupra diferitelor
provocări care fac această sarcină deosebit de complicată, propunând căi de urmat care pot consolida și promova și
mai mult dreptul la libertatea de exprimare, în India și nu numai.
• Securitate cibernetică, supraveghere și drepturile omului
Odată cu apariția noii tehnologii, au apărut noi amenințări de securitate pentru oameni, companii și state. Adesea,
răspunsurile la astfel de amenințări, inclusiv exercitarea de către statele a puterii lor fără precedent de a-și
supraveghea populațiile, au fost criticate pentru impactul lor negativ asupra drepturilor omului. Securitatea și
drepturile omului nu mai pot fi reconciliate în era internetului?
Legea privind tehnologia informației (modificare) din 2008, un act de modificare a Legii IT din 2000, a primit
acordul președintelui la februarie 2009. Mai mulți experți în domeniul juridic și în securitate sunt în proces de
5
analiză a conținutului și a posibilelor efecte ale modificărilor. Obiectivul acestei note este de a încerca să studieze
posibilele implicații și impacturi asupra companiilor indiene. Această notă nu intenționează să fie o analiză
cuprinzătoare a modificărilor, ci doar anumite puncte cheie care ar putea avea un impact asupra companiilor indiene
Protejarea datelor
Legea IT din 2000 nu avea nicio referire specifică la protecția datelor, dulapul fiind o prevedere pentru a trata
vandalismul datelor ca o infracțiune. Guvernul a introdus un proiect de lege separat numit „Legea din 2006 privind
protecția datelor cu caracter personal”, care este în curs în Parlament și este probabil să cadă. ITA 2008 a introdus
două secțiuni care abordează aspectele privind protecția datelor într-o anumită măsură, ceea ce dă naștere la anumite
considerații cheie pentru sector.
Secțiunile luate în considerare sunt:
Secțiunea 43A: Despăgubiri pentru neprotecția datelor
Secțiunea 72A: Pedeapsa pentru dezvăluirea de informații cu încălcarea contractului legal
Secțiunea 43A prevede
În cazul în care o persoană juridică, care deține, manipulează sau manipulează date sau informații personale sensibile
dintr-o resursă informatică pe care o deține, o controlează sau o operează, este neglijentă în implementarea și
menținerea practicilor și procedurilor rezonabile de securitate și, prin urmare, cauzează pierderi sau câștiguri
necorespunzătoare oricărei persoane , această persoană juridică va fi obligată să plătească despăgubiri, cu titlu de
despăgubire, persoanei astfel afectate.
Cu titlu de explicație: „Corporație înseamnă companii indiene”
„Practicile rezonabile de securitate înseamnă un contract reciproc între client și furnizorul de servicii SAU conform
legii specificate. În absența ambelor, atunci așa cum a specificat Guvernul Central
Prin urmare, ar fi important ca companiile indiene să analizeze în mod serios SLA-urile și acordurile care au fost
semnate cu clienții pentru a înțelege implicațiile privind protecția datelor. Același lucru este valabil și pentru
înțelegerea legilor aplicabile.
Pagină 289
O modificare majoră este că această clauză nu menționează limita de compensare de Rs. 1 Crore care a fost acolo ca
parte a secțiunii 43 din ITA 2000. Aceasta înseamnă că nu există o limită superioară pentru daune care pot fi
solicitate. Aceasta este, în esență, „răspundere nelimitată” pentru companiile indiene, care ar putea provoca implicații
grave de afaceri.
Secțiunea 72A:
Conform acestei secțiuni, dezvăluirea fără consimțământ expune o persoană, inclusiv un „intermediar”, la trei ani de
închisoare cu amendă de până la Rs. Cinci lacs sau ambele.
Această secțiune folosește termenul „informații personale” și nu „informații personale sensibile” ca în secțiunea 43A.
Prin urmare, s-ar putea aplica oricărei informații obținute pentru a furniza servicii. Prin urmare, în anumite privințe,
lărgește definiția informațiilor.
2. Păstrarea informațiilor
În cadrul amendamentelor există mai multe referiri la „furnizori de servicii” sau „intermediari”, care, într-o anumită
formă, s-ar aplica tuturor companiilor indiene.
de exemplu, Secțiunea 67C: Păstrarea și păstrarea informațiilor de către intermediari.
Intermediarul va păstra și reține informațiile care pot fi specificate pe durata și în modul și formatul pe care guvernul
central le poate prescrie”. Orice intermediar care încalcă în mod intenționat sau cu bună știință prevederile se
pedepsește cu închisoare pe o perioadă de până la 3 ani și se pedepsește și cu amendă.
Notificările la timp pentru conservare etc. nu sunt încă lansate. Cu toate acestea, deoarece aceasta este o infracțiune
„cognoscibilă”, orice inspector de poliție poate începe investigații împotriva CEO-ului unei companii.
În afară de cele două aspecte discutate în această notă, există și alte domenii care ar putea fi, de asemenea,
considerații pentru Ex
Sec. 69: Puterea de a emite instrucțiuni pentru interceptarea sau monitorizarea sau decriptarea oricărei informații prin
orice resursă computerizată.
Sec. 69B: Puterea de a autoriza monitorizarea și colectarea de date sau informații de trafic prin orice resursă de
computer pentru Cyber Security.etc.
În rezumat, managementul riscului IT și răspunsul trebuie să fie analizate de către toate companiile din diverse
motive, inclusiv asigurarea clienților, conformitatea, reglementările clienților, protecția activelor informaționale etc.
Amendamentele ITA 2008 ne oferă câțiva factori suplimentari pentru considerente care ar putea avea un impact
semnificativ asupra afacerii. Reglementările și legile privind tehnologia informației ar deveni mai stricte și mai
definite; prin urmare, este imperativ ca organizațiile să fie conștiente și pregătite
MCQ-uri:
Secure Socket Layer – II”.
1. Numărul de faze în protocolul de strângere de mână?
Pagină 290
a) 2
Pagină 291
b) 3
c) 4
d) 5
2. În protocolul de înregistrare SSL, operațiunea pad_2 este –
a) este octetul 0x36 repetat de 40 de ori pentru MD5
b) este octetul 0x5C repetat de 48 de ori pentru MD5
c) este octetul 0x5C repetat de 48 de ori pentru SHA-1
d) este octetul 0x36 repetat de 48 de ori pentru MD5
Raspuns: b
Explicație: pad_2 = este octetul 0x5C repetat de 48 de ori pentru MD5.
3.1 n pad-ul de operare al protocolului de înregistrare SSL_1 este –
a) este octetul 0x36 repetat de 40 de ori pentru MD5
b) este octetul 0x5C repetat de 40 de ori pentru MD5
c) este octetul 0x5C repetat de 48 de ori pentru SHA-1
d) este octetul 0x36 repetat de 48 de ori pentru MD5.
4. În acțiunea protocolului Handshake, care este ultimul pas al Fazei 2: Autentificarea serverului și Schimbul de
chei?
a) server_terminat
b) server_key_change
c) cerere_certificat
d) crtificate_verify
5. Care este algoritmul de schimb de chei utilizat în parametrul CipherSuite?
a) RSA
Pagină 292
b) S-a rezolvat Diffie-Hellman
c) Diffie-Hellman efemer
d) Oricare dintre cele menționate.
Raspuns: d
Explicație: putem folosi oricare dintre următoarele pentru schimbul de chei CipherSuite:
i) RSA
ii) S-a rezolvat Diffie-Hellman
iii) Diffie-Hellman efemer
iv) Anonim Diffie-Hellman
v) Fortezza.
6.Mesajul certificatului este necesar pentru orice metodă de schimb de chei convenită, cu excepția _____
a) Diffie-Hellman efemer
b) Anonim Diffie-Hellman
c) S-a rezolvat Diffie-Hellman
d) RSA .
Raspuns: b
Explicație: Mesajul de certificat este necesar pentru orice metodă de schimb de chei convenită, cu excepția Anonymous
Diffie-Hellman.
7. În faza 2 a acțiunii protocolului Handshake, pasul server_key_exchange nu este necesar pentru care dintre
următoarele sisteme de cifrare?
a) Fortezza
b) Anonim Diffie-Hellman
c) S-a rezolvat Diffie-Hellman
d) RSA .
8. Semnătura DSS folosește ce algoritm hash?
Pagină 293
a) MD5
b) SHA-2
c) SHA-1
d) Nu folosește algoritmul hash
Răspuns: c
Explicație: Semnătura DSS utilizează SHA-1.
9. Semnătura RSA folosește ce algoritm hash?
a) MD5
b) SHA-1
c) MD5 și SHA-1
d) Niciuna dintre cele menționate.
Răspuns: c
Explicație: Hash-ul MD5 și SHA-1 este concatenat împreună și apoi criptat cu cheia privată a serverului.
10. Care este dimensiunea hash-ului semnăturii RSA după procesarea MD5 și SHA-1?
a) 42 de octeți
b) 32 de octeți
c) 36 de octeți
d) 48 de octeți
Răspuns: c
Explicație: Mărimea este de 36 de octeți după procesarea MD5 și SHA-1.
11. Masajul certificate_request include doi parametri, dintre care unul este
a) extensie_certificat
b) crearea_certificat
c) schimb_certificat
d) tip_certificat
Pagină 294
Raspuns: d
Explicație: Masajul certificate_request include doi parametri: certificate_type și certificate_authorities.
12. Mesajul client_key_exchange folosește o cheie pre-master de dimensiune –
a) 48 de octeți
b) 56 de octeți
c) 64 de octeți
d) 32 de octeți
Raspuns: a
Explicație: Mesajul client_key_exchange folosește o pre cheie principală de dimensiunea de 48 de octeți.
13. Mesajul certificate_verify implică procesul definit de pseudo-cod (în termeni de MD5) –
CertificateVerify.signature.md5_hash = MD5(master_secret || pad_2 || MD5(handshake_messages || master_secret ||

pad_1).
Există vreo eroare? Dacă da, ce este?
a) Da. pad_1 și pad_2 ar trebui să fie schimbate
b) Da. pad-urile ar trebui să fie prezente spre sfârșit
c) Da. master_key nu trebuie folosită, trebuie folosită pre_master key
d) Nicio eroare .
Raspuns: d
Explicație: Codul este corect, fără erori.
14. În protocolul de strângere de mână, care este primul tip de mesaj trimis între client și server?
a) server_hello
Pagină 295
b) client_hello
c) salut_cerere
d) cerere_certificat .
Raspuns: b
Explicație: Interacțiunea dintre client și server începe prin mesajul client_hello
MCQ-uri 2
Securitate în Internet”.
1. IPSec este conceput pentru a oferi securitatea la
a) strat de transport
b) stratul de rețea
c) strat de aplicație
d) stratul de sesiune.
Raspuns: b
Explicație: Niciuna.
2. În modul tunel, IPsec protejează
a) Întregul pachet IP
b) antet IP
c) Sarcina utilă IP
d) Nici unul dintre cele menționate
Pagină 296
Raspuns: a
3. Firewall stratul de rețea funcționează ca un
a) filtru cadru
b) filtru de pachete
c) atât filtru cadru cât și filtru pachet
d) niciuna dintre cele menționate
Raspuns: b
4. Firewall stratul de rețea are două subcategorii ca
a) firewall cu stare și firewall fără stat
b) firewall orientat pe biți și firewall orientat pe octeți
c) firewall cadru și firewall de pachete
d) niciuna dintre cele

menționate
Raspuns: a
5. WPA2 este folosit pentru securitate în
a) ethernet
b) bluetooth
c) Wifi
Pagină 297
Răspuns: c
6. Este apelată o încercare de a face o resursă de computer indisponibilă pentru utilizatorii săi
a) atac de refuzare a serviciului
b) atac de virus
c) ataca viermii
d) proces botnet.
Raspuns: a
7. Protocolul de autentificare extensibil este un cadru de autentificare folosit frecvent
a) rețea personală cu fir
b) rețele fără fir
c) rețea locală cu fir
d) niciuna dintre cele menționate.
8. Este folosită confidențialitatea destul de bună (PGP).
a) securitatea browserului
b) securitatea e-mailului
c) Securitate FTP
d) niciuna dintre cele menționate.
Raspuns: b
9. PGP criptează datele utilizând un cifru bloc numit
Pagină 298
a) algoritm internațional de criptare a datelor
b) algoritm de criptare a datelor private
c) algoritm de criptare a datelor intrenet
Raspuns: a
10. Când un server DNS acceptă și folosește informații incorecte de la o gazdă care nu are nicio autoritate să ofere
aceste informații, atunci se numește
a) Căutare DNS
b) Deturnarea DNS
c) Falsificarea DNS
d) Niciuna dintre cele menționate
Răspuns: c
Î1. Cea mai devastatoare pierdere pentru o companie este
pierderea hardware-ului
pierderi de date
pierderea software-ului
pierderea tipăritelor*
Pagină 299
Q2. Protecția de securitate pentru computerele

personale include
componente interne
încuietori și
cabluri
software
toate
acestea*
Q3. Cuvinte sau numere secrete utilizate pentru protecția

dispozitivelor sunt numite
date biometrice
backup
parole*
cuvinte
private
Î4. Toate următoarele sunt tehnici biometrice, cu

excepția
insign
a
retină
față
amprenta
palmei*
Î5. Un exemplu de parolă bună este numele unui partener sau al soțului sau al unui copil sau al unui animal de companie
cuvânt legat de un loc de muncă sau hobby cuvintele care conțin mai multe cifre aleatorii*
Pagină 300
MCQ-uri 4
Î1. Cea mai devastatoare pierdere pentru o companie este
pierderea hardware-ului
pierderi de date
pierderea software-ului
pierderea tipăritelor
Răspuns
Q2. Protecția de securitate pentru computerele personale include
componente interne
încuietori și cabluri
software
toate acestea
Răspuns
Q3. Cuvinte sau numere secrete utilizate pentru protecția dispozitivelor sunt numite
date biometrice
backup
parolele
cuvinte private
Răspuns
Î4. Toate următoarele sunt tehnici biometrice, cu excepția
Pagină 301
insigna
retină
față
amprenta palmei
Răspuns
Î5. Un exemplu de parolă bună este
numele unui partener sau al soțului
numele unui copil sau al animalului de companie
cuvânt legat de un loc de muncă sau hobby
cuvintele conțin mai multe cifre aleatorii
MCQ 5:
1) Cheia secretă între membri trebuie creată ca a _______________ cheie când doi membri
contactați KDC.
A) public
B) sesiune
C) gratuit
D) niciuna dintre cele de mai sus
2)IKE creează SA-uri pentru .
A) SSL
B) PGP
C)IPSec
D) VP
3) ______ oferă fie autentificare, fie criptare, sau ambele, pentru pachetele la nivel IP.
A) AH
B) ESP
C) PGP
Pagină 302
D) SSL
4) Un protocol de securitate pentru sistemul de e-mail este _.
A)IPSec
B) SSL
C) PGP
5) IPSec definește două protocoale: ___ și __________.
A) AH; SSL
B) PGP; ESP
C) AH; ESP
D) toate cele de mai sus
6) Un cifr modern este de obicei un complex _cifru format dintr-o combinație de diferite cifre
simple.
În jurul
B) cerc
C) pătrat
7) este protocolul conceput pentru a crea asociații de securitate, atât de intrare cât și de ieșire.
CA
B) CA
C) KDC
DIG
8) Autoritățile de internet au adrese rezervate pentru _________.
A) intranet
B) interneturile
C) extranet
9) Un ________ este o rețea care permite accesul autorizat de la utilizatori externi.
a) intranet
b) internetul
c) extranet
10) ________ este o colecție de protocoale concepute de IETF (Internet Engineering Task Force)
pentru a oferi securitate pentru un pachet la nivel de rețea.
A)IPSec
B) SSL
C) PGP
11) În _____, există o singură cale de la autoritatea de încredere până la orice certificat.
A)X509
B) PGP
C) KDC
12) A _______ oferă confidențialitate pentru rețelele LAN care trebuie să comunice prin internetul
global.
A) VPP
B) VNP
C) VNN
D) VPN
13)IPSec în _________ modul nu protejează antetul IP.
a) transportul
B) tunel
C) fie (a) fie (b)
D) nici (a) nici (b)
Pagină 303
14) În _______, algoritmii criptografici si secretele sunt trimise impreuna cu mesajul.
Pagină 304
A)IPSec
B) SSL
C) TLS
D) PGP
15) A _______ protocolul de securitate layer oferă servicii de securitate end-to-end pentru aplicații.
A) legătura de date B) rețea C) transport
16) În PGP, pentru a schimba mesaje de e-mail, un utilizator are nevoie de un inel de chei.
A)secret B)public C)fie (a) fie (b) D) ambele (a) și (b)
17)The ________ Metoda oferă o cheie de sesiune unică pentru două părți.
A)Di e-Hellman B)RSA C)DES D)AES
18)_______ este un cifr rotund bazat pe algoritmul Rijndael care un bloc de date pe 128
A)AEE foloseste de biți.
B)AED
C)AER
D)AES
19)AES are diferite con gurații.
A) doi
B) trei
C) patru
D)ve
20) DES folosește un generator de chei şaispre rundă
chei
pentru a genera zece rotunde
A) 32 de biți
B) 48 de biți
C) 54 de biți
D) 42 de biți pentru QCM 5 este 1)b
Răspunsurile
2)c
3)b
4)c
5)c
6)a
7)d 8)d
9)c
10)a 11)a
12)d 13)a
14)d 15)c
16)b17)a 18)d
19)b
Pagină 305
20)b
2. LEGI CYBER
Context introductiv pentru Cyberlaws:
Inca de la inceputurile civilizatiei, omul a fost intotdeauna motivat de nevoia de a

progresa si de a imbunatati tehnologiile existente. Acest lucru a condus la o dezvoltare
extraordinară și un progres care a fost o rampă de lansare pentru dezvoltarea ulterioară. Dintre toate
progresele semnificative făcute de omenire de la început până în prezent, probabil cea mai
importantă dintre ele este dezvoltarea Internetului. Pentru a pune în limbajul unui om obișnuit,
Internetul este o rețea globală de computere, toate vorbind aceeași limbă. În 1969, Departamentul
de Apărare al Americii a comandat construirea unei Super rețele numite ARPANET. Rețeaua
Agenției pentru Proiecte Avansate de Cercetare (ARPANET), concepută în principiu ca o rețea
militară de 40 de computere conectate printr-o rețea de legături și linii. Această rețea a crescut încet
și s-a născut Internetul. Până în 1981, peste 200 de computere erau conectate din întreaga lume.
Acum cifra se ridică la milioane.
Adevărata putere a internetului de astăzi este că este disponibil pentru oricine are un computer și o
linie telefonică. Internetul pune în mâinile unui individ imensa și neprețuită putere a informației și
comunicării.
Utilizarea internetului a crescut semnificativ în ultimii ani. Numărul de pachete de date care au
trecut prin Internet a crescut dramatic. Potrivit International Data Corporation („IDC”), aproximativ
163 de milioane de persoane sau entități vor folosi internetul până la sfârșitul acestui an, față de
16,1 milioane în 1995. Dacă este lăsată la propria măsură, este foarte puțin probabil ca o astfel de
tendință să se poată inversa. Având în vedere această stare actuală a Internetului, necesitatea legilor
cibernetice devine cu atât mai importantă.
Nevoia legii cibernetice:
Când a fost dezvoltat Internetul, părinții fondatori ai Internetului nu aveau nicio înclinație ca
Internetul să se transforme într-o revoluție atotcuprinzătoare care ar putea fi folosită greșit pentru
activități criminale și care necesita reglementare. Astăzi, se întâmplă multe lucruri tulburătoare în
spațiul cibernetic. Datorită naturii anonime a Internetului, este posibil să se angajeze într-o varietate
de activități criminale cu impunitate, iar persoanele cu inteligență au folosit în mod abuziv acest
aspect al Internetului pentru a perpetua activități criminale în spațiul cibernetic. De aici și nevoia de
Cyberlaws.
Ce este legea cibernetică:
Se crede că Internetul este plin de anarhie și un sistem de lege și reglementări în acesta pare
contradictoriu. Cu toate acestea, spațiul cibernetic este guvernat de un sistem de legi și reglementări
numit Cyberlaw. Nu există o definiție exhaustivă a termenului „Cyberlaw”. Pur și simplu vorbind,
Cyberlaw este un termen generic care se referă la toate aspectele legale și de reglementare ale
Internetului și World Wide Web. Orice lucru care are legătură cu sau este legat de sau emană din
orice aspecte legale sau probleme legate de orice activitate a internauților și a altora, în spațiul
cibernetic intră în domeniul de aplicare al legii cibernetice. Creșterea comerțului electronic a
propulsat nevoia unor mecanisme de reglementare vibrante și eficiente, care să consolideze și mai
mult infrastructura juridică, atât de crucială pentru succesul comerțului electronic. Toate aceste
mecanisme de reglementare și infrastructuri legale intră în domeniul Cyberlaw.
Pagină 306
Importanța legii cibernetice
Legislația cibernetică este importantă deoarece atinge aproape toate aspectele tranzacțiilor și
activităților de pe Internet, World Wide Web și spațiul cibernetic. Inițial, poate părea că Cyberlaws
este un domeniu foarte tehnic și că nu are nicio legătură cu majoritatea activităților din Cyberspace.
Dar adevărul real este că nimic nu poate fi mai departe de adevăr. Indiferent dacă ne dăm seama
sau nu, fiecare acțiune și fiecare reacție în spațiul cibernetic are niște perspective juridice și juridice
cibernetice.
Crimele cibernetice reprezintă o nouă clasă de infracțiuni care

cresc zi de zi datorită utilizării pe scară largă a internetului în aceste zile. Pentru combaterea
infracțiunilor legate de internet Legea privind Tehnologia Informației din 2000 a fost adoptată
cu obiectivul primordial de a crea un mediu propice pentru utilizarea comercială a IT Legea IT
specifică faptele care au fost pedepsite. Codul penal indian din 1860 a fost, de asemenea,
modificat pentru a include infracțiunile cibernetice.
Diferitele infracțiuni legate de internet care au fost sancționate conform Legii IT și IPC sunt
enumerate mai jos:
2.1. Infracțiuni cibernetice conform Legii IT :
• Modificarea documentelor sursă computer - Sec.65

• Hacking cu sisteme informatice, Modificarea datelor - Sec.66
• Publicarea de informații obscene - Sec.67
• Acces neautorizat la sistemul protejat Sec.70 Încălcarea confidențialității și
confidențialității - Sec.72
• Publicarea certificatelor de semnătură digitală falsă - Sec.73
2.2. Crime cibernetice conform IPC și legi speciale :
• Trimiterea de mesaje de amenințare prin e-mail - Sec. 503 IPC

• Trimiterea de mesaje defăimătoare prin e-mail - Sec. 499 IPC
• Falsificarea înregistrărilor electronice - Sec 463 IPC
• Site-uri web false, fraude cibernetice - Sec 420 IPC
• Falsificarea e-mailului - Sec. 463 IPC
• Web-Jacking - Sec. 383 IPC
• Abuz de e-mail - Sec.500 IPC
2.3. Crime cibernetice în temeiul actelor speciale :
• Vânzarea online de droguri conform Legii privind drogurile și substanțele psihotrope

• Vânzarea online a Arms Arms Act
Pagină 307
Act asupra criminalității cibernetice în India:
1. Modificarea sursei computerului Documente Sec.65
2. Hacking cu sisteme informatice , Modificarea datelor Sec.66

3. Trimiterea de mesaje jignitoare prin serviciul de comunicare etc. Sec.66A
4. Primirea în mod necinstit de resursă de computer sau dispozitiv de comunicare furat
Sec.66B
5. Furtul de identitate Sec.66C
6. Trișare prin personalizare folosind resursa computerizată Sec.66D
7. Încălcarea vieții private Sec.66E
8. Terorismul cibernetic Sec.66F
9. Publicarea sau transmiterea de materiale obscene în formă electronică Sec .67
10. Publicarea sau transmiterea de materiale care conțin act sexual explicit etc. în formă
electronică Sec.67A
11. Pedeapsa pentru publicarea sau transmiterea de materiale care prezintă copii în acte
sexuale explicite etc.
în formă electronică Sec.67B
12. Păstrarea și păstrarea informațiilor de către intermediari Sec.67C
13. Puterile de a emite instrucțiuni pentru interceptarea sau monitorizarea sau decriptarea
oricărei informații prin intermediul
orice resursă informatică Sec.69
14. Puterea de a emite instrucțiuni pentru blocarea accesului public al oricărei informații prin
orice resursă informatică Sec.69A
15. Puterea de a autoriza monitorizarea și colectarea de date sau informații de trafic prin orice
resursă informatică pentru securitatea cibernetică Sec.69B
16. Acces neautorizat la sistemul protejat Sec.70
17. Pedeapsa pentru denaturare Sec.71
18. Încălcarea confidențialității și confidențialității Sec.72
19. Publicarea certificatelor de semnătură digitală falsă Sec.73
20. Publicare în scop fraudulos Sec.74
29. Act pentru a aplica pentru infracțiuni sau contravenții comise în afara Indiei Sec.75
21. Despăgubiri, sancțiuni sau confiscare pentru a nu interfera cu alte pedepse Sec.77
22. Compunerea infracțiunilor Sec.77A
23. Infracțiuni cu trei ani închisoare să fie cognoscibile Sec.77B
24. Scutirea de răspundere a intermediarului în anumite cazuri Sec.79
25. Pedeapsa pentru favorizarea infracțiunilor Sec.84B
26. Pedeapsa pentru tentativa la savarsirea infractiunilor Sec.84C
Notă: Secțiunea 78 din Legea IT dă putere inspectorului de poliție să investigheze cazurile care
intră sub incidența prezentei legi
27. Infracţiuni ale societăţilor comerciale Sec.85
28. Trimiterea de mesaje amenințătoare prin e-mail Sec .503 IPC
29. Cuvânt, gest sau faptă menite să insulte modestia unei femei Sec.509 IPC
30. Trimiterea de mesaje defăimătoare prin e-mail Sec .499 IPC
31. Site-uri web false, fraude cibernetice Sec .420 IPC
32. Spoofing e-mail Sec .463 IPC
33. Realizarea unui document fals Sec.464 IPC
34. Fals în scopul înșelăciunii Sec.468 IPC
35. Fals în scopul dăunării reputației Sec.469 IPC
36. Web-Jacking Sec .383 IPC
37. Abuz de e-mail Sec .500 IPC
38. Pedeapsa intimidare penala Sec.506 IPC
39. Intimidare penală printr-o comunicare anonimă Sec.507 IPC
40. Când drepturile de autor sunt încălcate: - Dreptul de autor asupra unei lucrări va fi
considerat a fi încălcat Sec.51
Pagină 308
41. Infracțiune de încălcare a drepturilor de autor sau a altor drepturi conferite de prezenta
lege. Orice persoană care încalcă cu bună știință sau încurajează încălcarea Sec.63
42. Pedeapsa sporita pentru a doua condamnare si ulterioare Sec.63A
43. Cunoașterea utilizării copiei care încalcă drepturile de autor a programului de calculator
reprezintă o infracțiune Sec.63B
44. Obscenitate Sec. 292 IPC
45. Tipărirea etc. a unor materiale extrem de indecente sau slăbitoare sau destinate șantajului
Sec.292A IPC
46. Vânzarea, etc., de obiecte obscene către tânăr Sec .293 IPC
47. Acte și cântece obscene Sec.294 IPC
48. Furt de hardware de calculator Sec. 378
49. Pedeapsa pentru furt Sec.379
50. Legea privind vânzarea online de droguri NDPS
51. Legea privind vânzarea online a armelor.
GLOSOR
Controlul accesului
Controlează cine are acces la un computer sau serviciu online și informațiile pe care le
stochează.
Atu
Ceva de valoare pentru o persoană, o afacere sau o organizație.
Autentificare
Procesul de verificare că cineva este cine pretinde că este atunci când încearcă să acceseze un
computer sau un serviciu online.
Făcând înapoi
Pentru a face o copie a datelor stocate pe un computer sau pe un server pentru a reduce
impactul potențial al eșecului sau pierderii.
Aduceți-vă propriul dispozitiv (BYOD)

Utilizarea autorizată a dispozitivelor mobile deținute personal, cum ar fi smartphone-uri sau
tablete, la locul de muncă.
În bandă largă
Sistem de transmisie de date de mare viteză în care circuitul de comunicații este partajat între
mai mulți utilizatori.
Managementul continuității activității

Pregătirea și menținerea continuării operațiunilor de afaceri după întreruperi sau crize.
Certificare
Declarație conform căreia cerințele specificate au fost îndeplinite.
Organism de certificare
O organizație independentă care oferă servicii de certificare.
Pagină 309
Returnarea plății
O tranzacție cu cardul de plată în care furnizorul primește inițial plata, dar tranzacția este
ulterior respinsă de deținătorul cardului sau de compania emitentă a cardului. Contul
furnizorului este apoi debitat cu suma în litigiu.
Cloud computing
Livrarea serviciilor de stocare sau de calcul de la servere la distanță online (adică prin
internet).
Text comun
O structură și o serie de cerințe definite de Organizația Internațională pentru Standardizare,
care sunt încorporate în toate standardele internaționale ale sistemului de management pe
măsură ce sunt revizuite.
Server de date
Un computer sau un program care oferă altor computere acces la fișiere partajate printr-o rețea.
Declaratie de conformitate
Confirmarea emisă de furnizorul unui produs conform căreia cerințele specificate au fost
îndeplinite.
DMZ
Segment al unei rețele în care serverele accesate de utilizatori mai puțin de încredere sunt
izolate. Numele este derivat din termenul „zonă demilitarizată”.
Criptare
Transformarea datelor pentru a-și ascunde conținutul informațional.
Ethernet
Arhitectură de comunicații pentru rețele locale cu fir, bazată pe standardele IEEE 802.3 .
Firewall
Hardware sau software conceput pentru a preveni accesul neautorizat la un computer sau o
rețea de la un alt computer sau rețea.
Analiza decalaj
Compararea performanței reale cu performanța așteptată sau cerută.
Hacker
Cineva care încalcă securitatea computerului din motive rău intenționate, felicitări sau câștig
personal.
Hard disk
Mediul de stocare permanent în interiorul unui computer folosit pentru a stoca programe și
date.
Identificare
Procesul de recunoaștere a unui anumit utilizator al unui computer sau al unui serviciu online.
Infrastructură ca serviciu (IaaS)

Furnizarea infrastructurii de calcul (cum ar fi serverul sau capacitatea de stocare) ca un
serviciu furnizat de la distanță accesat online (adică prin internet).
Pagină 310
Certificat de inspecție
O declarație emisă de către o parte interesată prin care au fost îndeplinite cerințele specificate.
Mesagerie instanta
Conversații prin chat între două sau mai multe persoane prin tastarea pe computere sau
dispozitive portabile.
Furnizor de servicii de internet (ISP)

Companie care oferă acces la internet și servicii conexe.
Sistem de detectare a intruziunilor (IDS)

Program sau dispozitiv folosit pentru a detecta că un atacator este sau a încercat acces
neautorizat la resursele computerului.
Sistem de prevenire a intruziunilor (IPS)

Sistem de detectare a intruziunilor care blochează și accesul neautorizat atunci când este
detectat.
Fabricare „just la timp”.

Fabricare pentru a satisface o cerință imediată, nu în surplus sau înainte de necesitate.
Logger cu tastatură
Un virus sau un dispozitiv fizic care înregistrează apăsările de taste pentru a captura în secret
informații private, cum ar fi parolele sau detaliile cardului de credit.
Circuit închiriat
Legătura de comunicații între două locații utilizate exclusiv de o organizație. În comunicațiile
moderne, lățime de bandă dedicată pe o legătură partajată rezervată utilizatorului respectiv.
Rețea locală (LAN)

Rețea de comunicații care conectează mai multe computere într-o locație definită, cum ar fi o
clădire de birouri.
Virus macro
Programe malware (adică software rău intenționat) care utilizează capabilitățile macro ale
aplicațiilor obișnuite, cum ar fi foile de calcul și procesoarele de text pentru a infecta datele.
Programe malware
Software destinat să se infiltreze și să deterioreze sau să dezactiveze computerele. Forma
scurtată de software rău intenționat.
Sistem de management
Un set de procese utilizate de o organizație pentru a îndeplini politicile și obiectivele
organizației respective.
Firewall de rețea
Dispozitiv care controlează traficul către și dinspre o rețea.
externalizarea
Obținerea de servicii prin utilizarea resurselor altcuiva.
Trecând
A face declarații false că bunurile sau serviciile sunt cele ale unei alte afaceri.
Pagină 311
Parola
O serie secretă de personaje folosite pentru a autentifica identitatea unei persoane.
Firewall personal
Software care rulează pe un computer care controlează traficul de rețea către și de la acel
computer.
Informații personale
Date personale referitoare la o persoană în viață identificabilă.
phishing
Metodă folosită de infractorii pentru a încerca să obțină informații financiare sau alte
informații confidențiale (inclusiv nume de utilizator și parole) de la utilizatorii de internet, de
obicei prin trimiterea unui e-mail care pare că ar fi fost trimis de o organizație legitimă (adesea
o bancă). E-mailul conține de obicei un link către un site web fals care pare autentic.
Platform-as-a-service (PaaS)
Furnizarea infrastructurii de la distanță care să permită dezvoltarea și implementarea de noi

aplicații software pe internet.
Dispozitiv portabil
Un dispozitiv de calcul mic, ușor de transportat, cum ar fi un smartphone, laptop sau tabletă.
Server proxy
Server care acționează ca intermediar între utilizatori și alte servere, validând cererile
utilizatorilor.
Restabili
Recuperarea datelor în urma defecțiunii sau pierderii computerului.
Risc
Ceva care ar putea determina o organizație să nu-și atingă unul dintre obiectivele sale.
Procesul de identificare, analiză și evaluare a riscului.
Router
Dispozitiv care direcționează mesajele în interiorul sau între rețele.
Racleta ecran
Un virus sau un dispozitiv fizic care înregistrează informații trimise pe un afișaj vizual pentru a
captura informații private sau personale.
Controlul securitatii
Pagină 312
Ceva care modifică sau reduce unul sau mai multe riscuri de securitate.
Informații de securitate și managementul evenimentelor (SIEM)
Proces în care informațiile din rețea sunt agregate, sortate și corelate pentru a detecta activități
suspecte.
Perimetrul de securitate
O graniță bine definită în care sunt aplicate controalele de securitate.
Server
Computer care furnizează date sau servicii altor computere printr-o rețea.
Smartphone
Un telefon mobil construit pe o platformă de calcul mobilă care oferă abilități de calcul și
conectivitate mai avansate decât un telefon mobil standard.
Software-as-a-service (SaaS)
Livrarea de aplicații software de la distanță de către un furnizor prin internet; poate printr-o
interfață web.
Spyware
Program malware care transmite informații despre activitățile unui utilizator de computer către
o parte externă.
Lanț de aprovizionare
Un set de organizații cu resurse și procese conectate implicate în producția unui produs.
Comprimat
Un computer ultra-portabil, cu ecran tactil, care împărtășește o mare parte din funcționalitatea
și sistemul de operare al smartphone-urilor, dar are în general o putere de calcul mai mare.
Amenințare
Ceva care ar putea dăuna unui sistem sau organizație.
actor de amenințare
O persoană care efectuează un atac cibernetic sau provoacă un accident.
Autentificare cu doi factori
Obținerea dovezilor de identitate prin două mijloace independente, cum ar fi cunoașterea unei
parole și finalizarea cu succes a unei tranzacții cu smartcard.
Nume de utilizator
Pagină 313
Numele scurt, de obicei semnificativ într-un anumit fel, asociat cu un anumit utilizator de
computer.
Contul utilizatorului
Evidența unui utilizator păstrată de un computer pentru a controla accesul acestuia la fișiere și
programe.
Rețea privată virtuală (VPN)
Legături între computere sau rețele locale din diferite locații utilizând o rețea extinsă care nu
poate accesa sau nu poate fi accesată de alți utilizatori ai rețelei extinse.
Virus
Programul malware care este încărcat pe un computer și apoi rulat fără știrea utilizatorului sau
fără știrea efectelor sale complete.
Vulnerabilitate
Un defect sau o slăbiciune care poate fi folosită pentru a ataca un sistem sau o organizație.
Rețea extinsă (WAN)
Rețea de comunicații care conectează computere sau rețele locale din diferite locații.
Wifi
Rețea locală wireless bazată pe standardele IEEE 802.11 .
Vierme
Programe malware care se replic, astfel încât să se poată răspândi și să se infiltreze în alte
computere.
Întrebări rememorate de securitate IT 15-07-18
Nerefuzie, privilegii de acces, 2FA, CISO, IT corporative

Securitate, DRM, amenințări, vulnerabilități, apetit pentru risc, guvernare sec, rfid, ips, id-uri, coduri de bare, detectoare de
metale, stingătoare de incendiu, metodologii de testare 2-3 întrebări, cloud computing 2-3 întrebări, cdr, iso 27001, cobit, etsi tc
cyber,Sox,sas 70,apărare în profunzime,server verde,renovare,conducere tomberon,eng social,schemă baze de date,securitate
atm,jackpotting,aranjament escrow 2 întrebări,spf,vlans,mpls,ftp,firewalls,siem,s /w modele,big data,buffer
overflow,stuxnet,botnet,fast flux,rootkit,San,drsite,Indian fin sys,puterile rbi
Cele mai multe dintre d întrebările wr de tipul (ce nu este), (ceea ce este greșit)
Întrebări amintite de securitate IT
Pagină 314
Actul IT definește datele ca
Informațiile sunt clasificate în funcție de criticitate, confidențialitate, disponibilitate și scop
Securitatea informațiilor este protecția activelor informaționale
Definiția nerepudierii
Care dintre următoarele nu este o metodă de securitate perimetrală
Securitatea IT este responsabilitatea tuturor angajaților dintr-o organizație
CISO nu va raporta CIO
Prealabil acces: personalul de birou nu poate efectua plata împrumutului
Ce este destul de bună confidențialitate
Managementul digital al drepturilor implică dreptul de copiere și tehnologia antipiraterie
Diferența dintre amenințare și vulnerabilitate
Definiții ale impactului și riscului vulnerabilității amenințărilor
Crima nu se datorează nevoii, oportunității și raționalizării. O variantă greșită
2 întrebări despre detectoare de metale
Care dintre următoarele nu este un sistem de detectare a intruziunilor - instrumente biometrice
Ingineria socială este realizată de
Definiția injecției SQL
Definirea depășirii tamponului
Prima armă digitală folosită în PLC - stuxnet
Care dintre următoarele nu este adevărată în ceea ce privește terorismul cibernetic
Programe malware care vizează echipamente industriale și software - stuxnet
Pagină 315
Definirea fluxului rapid
Întrebare legată de rootkit
Ce înțelegeți prin termenul hijacker
Care este preocuparea cu care se confruntă managerii de securitate în tehnologia BYOD
Întrebare de tip studiu de caz despre eșecul unui singur punct
Pagină 316
Caracteristicile sistemului tolerant la erori-2 întrebări
Una dintre următoarele nu este o cerință pentru toleranța la erori
Una dintre următoarele nu este adevărată în ceea ce privește disponibilitatea ridicată - latență, raid,
Întrebări despre testarea cutiei albe și testarea neagră
Metodele de toleranță la erori software includ blocuri de recuperare, programare n, teste de acceptare
Obiectiv timp de recuperare, obiectiv punct de recuperare
Backup robot
Amplasarea locației DR în zona seismică
Site fierbinte, site cald
Site secundar situat în același oraș cu centrul de date principal
Audit în jurul computerului, auditare prin computer, auditare cu computer
COBIT nu este un standard de securitate
Cea mai recentă versiune a COBIT este COBIT 5
Definirea riscului de audit
RBI, sebi, tria și irda reglementează (se potrivesc cu următoarele)
Unul dintre următoarele nu este rolul RBI
Înregistrarea datelor apelului include
Una dintre următoarele nu este inclusă în actul IT
Pagină 317
Controlul versiunii
Aranjament escrow
Cloud computing și big data
**MULT NOROC **
Disclaimer
Deși am depus toate eforturile pentru a evita erorile sau omisiunile din această publicație, orice
eroare sau discrepanță observată îmi poate fi adusă la cunoștință prin e-mail la adresa
Srinivaskante4u@gmail.com de care se va ocupa în edițiile ulterioare. De asemenea, se
sugerează că, pentru a clarifica orice îndoială, colegii ar trebui să verifice încrucișat faptele,
legile și conținutul acestei publicații cu Guvernul original. / RBI /
Manuale/Circulare/Notificări/Memo/Spl Comm. a băncii noastre.
Pagină 318

Securitate PDF

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Securitate PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Compilat de Srinivas Kante Email: srinivaskante4u@gmail.

IIBF & NISM Adda

Despre examenul de certificat în SECURITATE IT

Examinarea certificatului IIBF

b) Examen de certificat în prevenirea infracțiunilor cibernetice și managementul fraudei (programa revizuită)

c) Examen de certificat în Bancher în Sistemul Informațional (Programa revizuită)

ii) Orice absolvent al unei universități recunoscute sau echivalentul acesteia.

EXAMEN Pentru Membri Pentru Nemembri încercare

1.000 Rs/- * 1.500 Rs./-

(ii) Examenul se va desfășura numai în modul online

(iii) NU va exista notare negativă pentru răspunsurile greșite.

CENTRE DE PERIODICITATE ȘI DE EXAMINARE:

PROCEDURA DE APLICARE LA EXAMEN

4) I / Cardul alegătorului electoral sau 5) Pașaport 6) Cardul Aadhaar

MATERIAL DE STUDIU / CURS

Tabelul de mai jos clarifică în Data limită a liniilor

5. Securitate fizică și de mediu

Modulul - B: Controale de securitate IT

10. Controale de securitate fizică și de mediu

11. Controale de securitate hardware/software

• Aplicații software și sisteme de operare

12. Rețele și dispozitive de calculatoare (tehnologii cu fir și fără fir)

• Soluții de securitate (IDS, IPS, Fire Wall, VPN etc.)

13. Dezvoltare și întreținere software

Modulul - C: Amenințări de securitate IT

• Non tehnic / intern

• Terorismul cibernetic etc

15. Prezentare generală a malware-urilor computerizate

16. Detectarea și prevenirea malware-urilor computerizate

17. Gestionarea incidentelor

18. Sisteme tolerante la erori

19. Continuitatea afacerii și recuperarea în caz de dezastru

f. Constatări de audit și proceduri de închidere

21. Conformitatea cu reglementările

b. Identificarea conformităților aplicabile

S.nr Cuprins Pagina nr

INTRODUCERE ÎN SECURITATEA INFORMAȚIILOR

Securitatea informațiilor este un set de strategii de gestionare a proceselor, instrumentelor și

Multe întreprinderi mari angajează un grup de securitate dedicat pentru implementarea și

PILERS DE SECURITATE A INFORMAȚIILOR

Asigurarea informațiilor (IA) se referă la pașii implicați în protejarea sistemelor informaționale,

IA este un domeniu în sine. Poate fi considerată o specialitate a tehnologiei informației (IT),

Un proces de autentificare, care asigură că utilizatorilor autorizați li se atribuie o identificare și

Controalele accesului asigură că acțiunile utilizatorului rămân în rolurile lor. De exemplu,

1. Integritatea, în contextul sistemelor informatice, se referă la metodele de asigurare a faptului că

Menținerea integrității datelor este o cerință de securitate a informațiilor. Integritatea este o

Confidențialitatea împiedică dezvăluirea

Informațiile ar trebui să fie

4 Nerepudierea este o metodă de garantare a transmiterii mesajelor între părți prin

Nerepudierea este adesea folosită pentru contractele digitale, semnăturile și mesajele de e-

5. În contextul sistemelor informatice, autentificarea este un proces care asigură și confirmă

hackerilor în sistemele informatice.

Există două faze de securitate fizică:

• Descurajare: metode și măsuri menite să descurajeze atacatorii și intrușii sau să prevină

Securitatea fizică se referă la măsurile preventive utilizate pentru a împiedica intrușii să

• Profiluri de utilizator – Furnizarea persoanelor autorizate de acces la conturi la sistem

by Srinivas Kante Email: srinivaskante4u@gmail.com

Politica de securitate IT corporativă

Progresele tehnologice semnificative au schimbat modul în care facem afaceri. Adică,

În timp ce utilizarea internetului vine cu numeroase avantaje, cum ar fi viteza de comunicare și

Prin urmare, elaborarea unei politici corporative de securitate IT va ajuta la atenuarea

„Piulițele și șuruburile” unei politici de securitate IT

• confidențialitatea informațiilor sensibile critice pentru misiune

• disponibilitatea acestor informații