Copii de siguranta si evenimente neprevazute

Copii de siguranta si evenimente neprevazute

Auditorul trebuie sa verifice daca la nivelul organizatiei exista:

Proceduri prin care sa se asigure functionarea sistemului in cazul

caderii alimentarii cu energie electrica sau a liniilor de comunicatii.

Exista sectoare 'sensibile' - bancar, bursier, securitatea statului, energetic etc. care impun asigurarea functionarii continue a sistemelor informatice ceea ce implica existenta unor surse alternative de energie si/sau comunicatii.

Planuri bine testate si documentate, actualizate periodic prin care sa se asigure operationalitatea sistemului informatic in conditiile producerii unor evenimente neprevazute.

Proceduri si controlul aplicarii acestora, privind realizarea copiilor de siguranta si refacerea starii sistemului in cazul 'caderii' acestuia ca urmare a unor cauze hardware sau software.

Existenta unui contract de asigurare a organizatiei pentru evenimente neprevazute.

Nivelul de instruire a personalului cu privire la procedurile aplicabile pentru realizarea periodica a copiilor de siguranta sau executarii procedurilor de criza in cazul producerii dezastrelor.

Dezastrele:

Reprezinta:

Actiuni cu scop distructiv produse intentionat sau nu, inclusiv virusi.

Dezastre naturale.

Conceptul de Business Continuity Management (BCM) se refera la anticiparea incidentelor care pot afecta functiile critice si procesele organizatiei asigurand ca organizatia va raspunde oricarui incident conform planurilor elaborate pana la revenirea activitatii la o desfasurare normala.

Functia IT este una din functiile critice ale organizatiei. De aceea auditorul va trebui sa verifice daca exista elaborat un plan de actiune care cuprinde proceduri si persoanele responsabile cu punerea in practica a actiunilor de limitare a distrugerilor si refacerea sistemului in cazul produceii unor dezastre. Aceste planuri trebuie sa cuprinda:

Stabilirea echipei responsabile cu realizarea unui plan
de refacere a sistemului formata din personalul din compartimentul de specialitate, auditorul sistemului informatic, utilizatori.

Elaborarea procedurilor de verificare a principalelor componente ale sistemului (date, soft, hard, documentatii) in cazul producerii evenimentelor distructive si stabilirea responsabilitatilor.

Stabilirea locatiilor in care vor fi pastrate copiile de siguranta, documentatiile si componente hardware.

Stabilirea prioritatilor privind procedurile ce trebuie efectuate.

Stabilirea locatiei in care se vor executa procedurile.

Stabilirea disponibilitatii care trebuie asigurata pe fiecare clasa si grup de informatii si masura in care personalul IT asigura aceasta disponibilitate inclusiv
prin procedurile prevazute in BCM.

Testarea planului pe elemente componente.

Documentarea planului

Nu toate incidentele (evenimentele distructive) pot fi anticipate prin BCM. Planificarea continuitatii activitatii in cadrul organizatiei implica aspectele functiei IT. Auditorul va trebui sa evalueze:

Ce a facut managementul privitor la riscul de 'cadere' a sistemului si fata de scenariul de dezastre.

Cum sunt testate si actualizate planurile de continuitate a activitatii:

Revederea planurilor existente

Sunt clar precizate responsabilitatile?

Care este nivelul de instruire a personalului implicat?

Daca un atac sau dezastru serios se produce vor trebui initiate urmatoarele masuri:

Echipa Firewall isi realizeaza atributiile.

Hardware-ul afectat va trebui deconectat de la retea.

Se va proceda la documentarea cu privire la actiuni, evenimente produse, probe colectate. Informatiile privind momentul producerii atacului, momentul depistarii atacului sunt de asemenea importante.

Analiza sistemului: ce fisiere au fost afectate? Ce programe/conturi utilizator au fost modlficaTe sau adaugate ? Daca modificarile au fost identificate se recomanda verificarea daca modificari similare nu au fost facute si pe sisteme similare.

Informarea administratorilor, managementului si dupa caz autoritatile.

Furnizarea informatiilor colectate despre atac prin e-mail se va face doar daca se cripteaza mesajul.

Refacerea in cazul esecului operational

Auditorul verifica:

Daca sunt stabilite proceduri adecvate in cazul producerii unor esecuri operationale;

Daca aceste proceduri sunt verificate si aprobate de conducerea departamentului IT;

Daca aceste esecuri operationale sunt identificate, rezolvate la timp, comsemnate si raportate;

În ce masura echipamentele sunt adecvat plasate si protejate pentru a se preveni riscul distrugerii accidentale (foc, fum, praf, vibratii, radiatii electromagnetice etc).

În ce masura echipamentele sunt corect intretinute.

Ce controale exista pentru prevenirea esecurilor operationale produse din :

o       cauze hardware

o       neaplicarea corecta a procedurilor de operare

o       erori software.

Care sunt procedurile de RESTART si REFACERE (Recovery) pentru refacerea starii sistemului in urma unui esec operational.

În caz de incidente sunt evaluate actiunile operatorilor pentru a se vedea daca prin actiunile lor nu au afectat calitatea prelucrarilor sau structurile de date.

Backup

Actualizarile folosind backup-urile datelor (fisierelor), aplicatiilor si software-lui de sistem trebuie sa fie posibile in caz de urgenta. De aceea audiorul va trebui sa raspunda la umatoarele intrebari:

Sunt procedurile de backup (pentru date si soft) cele potrivite?

Sunt backup-urile corect jurnalizate si stocate in locatii sigure?

Exista siguranta ca backup-urile si procedurile recovery vor lucra la nevoie?

Datele din fisierele copii sunt acoperitoare pentru refacerea fisierelor operationale? Auditorul va verifica daca frecventa realizarii copiilor este direct proportionala cu volumul tranzactiilor si importanta datelor pentru organizatie.

Conform procedurilor backup copiile pot fi :

partiale

totale.

Cea mai populara tehnica de backup este GFS (bunic-tata-fiu) care presupun urmatoarea desfasurare :

Se fac copii zilnice

Copia zilnica se va rescrie in saptamana urmatoare

La sfarsitul saptamanii se realizeaza 'copia saptamanii' (corespunde ultimei copii zilnice)

Copia saptamanii se reface in luna urmatoare

La sfarsitul fiecarei luni se realizeaza 'copia lunii'.

Aceasta se reface in trimestrul sau anul urmator.

Software backup

Acesta presupune:

- Realizarea de copii ale sistemului de operare si ale aplicatiilor
(se realizeaza in masura in care licenta permite acest lucru).

Copiile trebuie pastrate in loc sigur (chiar alte locatii decat sediul firmei).

Hardware backup

Presupune:

Achizitionarea unui al doilea sistem care poate fi:

Un sistem Standby Hot care poate prelua imediat functia
sistemului operational.

Un sistem Standby Cold, stocat separat si la nevoie conectat pentru a

putea fi folosit.

Încheierea unui contract cu o firma al carei sistem de procesare a datelor are aceleasi facilitati si poate sa suporte prelucrarile firmei al carui sistem nu mai este operational.

Apelarea la o firma care ofera servicii in acest domeniu.

Contractele de service cu furnizorul hardware sa prevada furnizarea, pe timp limitat, a echipamentelor care vor inlocui pe cele avariate.

. SISTEME DUPLICATE:

- Specifice domeniilor cu risc mare: banci, burse, etc.

Prezinta locatii geografice separate pentru minimalizarea riscului de mediu.

- Actualizarea simultana, prin tranzactiile curente atat a sistemului operational cat si pe cel duplicat.

În cadrul organizatiei trebuie sa existe o politica de backup pentru fiecare sistem sau grup de sisteme care trebuie sa cuprinda:

Cand si cum (partial sau total) se realizeaza copiile, unde se pastreaza aceste copii si pentru cat timp?

Frecventa realizarii copiilor si cine este responsabil pentru verificarea corectitudinii lor?

Cum se realizeaza evidenta copiilor in arhiva si cum pot fi recuperate copiile din arhiva (persoane autorizate sa depuna/ridice copii, inregistrarea datei depunerii/ridicarii copiilor, data returnarii copiilor la arhiva si persoana care a facut reidicarea/returnarea copiilor etc).

În egala masura, in cadrul organizatiei trebuie sa existe o politica de restore care va trebui sa cuprinda:

Persoana responsabila cu verificarea corectei operari.

O descriere detaliata a modului de restaurare a datelor pentru toate aplicatiile.

În mod distinct, o descriere detaliata a modului de
restaurare a sistemului de operare.

Momentele realizarii restaurarilor in cazul diferitelor
scenarii de deuastre.

Obligativitatea testarii anuale a politicii de restore.