OMCTI 389/2007 Al doilea exemplu: planul de securitate.

 

“Planul de securitate se va intocmi respectandu-se urmatoarea structura:

1.informatii de identificare:

a)emitentul instrumentului de plata cu acces la distanta;

b)denumirea instrumentului de plata cu acces la distanta;

c)provenienta instrumentului de plata cu acces la distanta;

d)categoria (Internet, home sau mobile-banking);

e)statutul operational al sistemului prin intermediul caruia este oferit instrumentul de plata cu acces la distanta si anul intrarii in productie;

f)descrierea generala a solutiei tehnice;

g)consideratii specifice;

h)interconectarea sistemului;

i)aria geografica in care instrumentul de plata cu acces la distanta poate fi utilizat;

j)datele de contact ale persoanelor responsabile;

2.senzitivitatea sistemului:

a)legislatia aplicabila;

b)descrierea generala a senzitivitatii informatiilor gestionate de catre sistem;

3.masuri pentru securitatea sistemului:

a)evaluarea si managementul riscurilor potentiale;

b)codurile de conduita/conditiile de utilizare/contractul prin care instrumentul de plata cu acces la distanta este oferit;

c)rapoarte de testare;

d)masurile tehnice de securitate implementate;

e)procedurile operationale de exploatare;

f)masurile aplicate pentru asigurarea securitatii fizice;

g)instruirea personalului propriu al emitentului in legatura cu administrarea sistemului informatic;

h)instructiunile de utilizare a instrumentului de plata cu acces la distanta (manual de utilizare oferit clientilor);

i)suportul tehnic oferit de catre emitent clientilor care utilizeaza instrumentul de plata cu acces la distanta;

4.orice alte informatii relevante legate de masurile luate de catre emitent pentru a asigura exploatarea in siguranta a instrumentului de plata cu acces la distanta.

 

 

Exprimarea din actul normativ denotă că cei care l-au conceput (şi nu mă refer aici la emitent….) au, cel puţin, cunoştinţe destul de subţiri pe marginea subiectului.

 

Care sînt dilemele ce apar în momentul în care te pui pe muncă şi vrei să dezvolţi un astfel de “Plan”?

Aşa cum învăţăm de prin cărţi, standarde şi best practice, un “plan” nu este altceva decît un instrument prin care managementul unei organizaţii pune în practică politicile adoptate! De obicei spune CE se face/doreşte, nu şi CUM se face, pentru că nu este un document operaţional. Poate fi o colecţie de “politici” sau enunţuri ce descriu abordarea organizaţiei în ceea ce priveşte securitatea informaţiilor. Îi ajută, ghidează, pe cei care vor dezvolta procedurile de securitate! Dacă nu este integrat la nivel operaţional prin indicarea resurselor implicate, este doar….un document fără corespondenţă practică.

Chiar şi în aceste condiţii, să acceptăm exprimarea “plan” şi să spunem că sînt eu prea pricinos…… Va fi un document sau mai multe? Dat fiind că se întocmeşte după o anumită structură, va fi un singur document…:(

 

Care este legislaţia aplicabilă? Cîteva exemple:

 

“d) comunicare – orice informatie schimbata sau transmisa intre un numar determinat de participanti prin intermediul unui serviciu de comunicatii electronice destinat publicului; aceasta nu include informatia transmisa publicului printr-o retea de comunicatii electronice ca parte a unui serviciu de programe audiovizuale, in masura in care nu poate fi stabilita o legatura intre informatia in cauza si abonatul sau utilizatorul identificabil care o primeste;” – L 506/2004

 

instrument de platã cu acces la distantã – instrument de platã electronicã prin intermediul cãruia titularul sãu poate sã îsi acceseze fondurile detinute într-un cont la o institutie financiarã si sã autorizeze efectuarea unei plãti, utilizând un cod personal de identificare sau un alt mijloc de identificare similar” – L 365/2002

vs

 “a) instrument de platã cu acces la distanţã – soluţia informaticã ce permite deţinãtorului sã aibã acces la distanţã la fondurile aflate în contul sãu, în scopul obþinerii de informaţii privind situaţia conturilor şi operaţiunilor efectuate, efectuãrii de plãţi sau transferuri de fonduri cãtre un beneficiar, prin intermediul unei aplicaţii informatice, al unei metode de autentificare şi al unui mediu de comunicaþie; OMCTI 389/2007

 

Operatorul este obligat sa aplice masurile tehnice si organizatorice adecvate pentru protejarea datelor cu caracter personal impotriva distrugerii accidentale sau ilegale, pierderii, modificarii, dezvaluirii sau accesului neautorizat, in special daca prelucrarea respectiva comporta transmisii de date in cadrul unei retele, precum si impotriva oricarei alte forme de prelucrare ilegala.” L 677 /2001

 

Dacă s-a realizat “evaluarea si managementul riscurilor potentiale”, atunci:

  • Care este raţiunea pentru care trebuie inclus un “raport de testare” (care se presupune că este preponderent tehnic) într-un astfel de document?
  • Care este raţiunea pentru care trebuie inclusă “instruirea angajaţilor”?
  • Care este raţiunea pentru care trebuie inclus “manualul de utilizare”?

 

Sublimul este atins însă cu ultima cerinţă: “orice alte informatii relevante legate de masurile luate…..”  Cine stabileşte relevanţa?

 

În loc de concluzie: cu un ochi la ISO 27001/27002, ISO31000, Risk Practioner, COBIT se pot dezvolta lucrurile aşa cum trebuie. Şi cu siguranţă vor acoperi şi cerinţele ambigue ale Ordinului.

 

PS: remarcaţi că în “structura” prezentată şi care trebuie respectată  nu se mai faci nici o referire la BCP/DRP?🙂

Un gând despre “OMCTI 389/2007 Al doilea exemplu: planul de securitate.

  1. Pingback: COBIT 5 For Information Security şi Planul de securitate « ADRIAN MUNTEANU

Mulţumesc.

Completează mai jos detaliile despre tine sau dă clic pe un icon pentru autentificare:

Logo WordPress.com

Comentezi folosind contul tău WordPress.com. Dezautentificare / Schimbă )

Poză Twitter

Comentezi folosind contul tău Twitter. Dezautentificare / Schimbă )

Fotografie Facebook

Comentezi folosind contul tău Facebook. Dezautentificare / Schimbă )

Fotografie Google+

Comentezi folosind contul tău Google+. Dezautentificare / Schimbă )

Conectare la %s