Manual de Audit TI
Manual de Audit TI
Manual de Audit TI
TEHNOLOGIILOR INFORMAŢIONALE
Chişinău
2010
1
Prefaţă
Societatea determină o creştere dinamică a dependenţei tuturor domeniilor
vieţii economico-sociale de tehnologiile informaţionale. Valorificarea posibilităţilor
oferite de TI presupune acceptarea unor riscuri specifice, cum ar fi: securitatea
informaţională, dependenţa prea mare de gradul de calificare a persoanelor
responsabile, veridicitatea datelor, costurile mari de întreţinere, nedorinţa unor
angajaţi de a accepta schimbările etc. Luând în considerare consumul de resurse
umane şi financiare la dezvoltarea unui sistem informaţional automatizat, este
necesar să se desfăşoare anumite activităţi care să ducă la atingerea obiectivului
propus la timp, cu nivelul de calitate stabilit şi în limita bugetului alocat. Una din
aceste activităţi, deosebit de importantă pentru realizatori, dar mai ales pentru
utilizatori, este auditul tehnologiilor informaţionale.
Auditul sistemelor şi tehnologiilor informaţionale are scopul de a oferi
certitudine rezonabilă managementului de vârf precum că riscurile generate de
utilizarea TI în cadrul organizaţiei sunt adecvat conştientizate şi gestionate
corespunzător.
Anume din aceste considerente Curtea de Conturi, ca instituţia supremă de
audit din RM, începând cu anul 2009 a început realizarea auditului Sistemele IT şi
Tehnologiile Informaţionale în paralel cu auditul regularităţii şi cel al performanţei.
În acest scop, prin Hotărârea Curţii de Conturi nr. 54 din 22.12.2009, au fost
aprobate standardele de audit al TI.
Auditul TI poate avea şi obiectivul de a determina nivelul de corespundere
anumitor reglementări şi standarde în domeniu, precum: standardele de audit TI a
ISACA şi Cadrul CoBIT; Rapoartele IIA; Standarde elaborate de organizaţii de
specialitate, cum ar fi ISACF sau IFAC, COSO; Pentru ramuri separate ale TI sunt
elaborate standarde internaţionale ISO.
În acest scop, Curtea de Conturi, prin intermediul auditului Tehnologiilor
Informaţionale, v-a analiza sistemele TI, mediul lor de funcţionare, procesele de
business aferente, v-a colecta probe de audit şi v-a evalua eficienţa şi suficienţa
mijloacelor de control ale riscurilor TI. De asemenea, în cazul în care v-a constata
situaţii ce implică riscuri inacceptabile pentru organizaţie sau neconformări la cadrul
de reglementare, v-a oferi recomandări pentru remedierea situaţiei.
Prezentul manual cuprinde un ansamblu de proceduri şi orientări stabilite de către
Curtea de Conturi în baza standardelor şi practicilor internaţionale.
Obiectivul manualului este de a contribui la atingerea unei calităţi înalte a
activităţilor de audit al sistemelor IT şi tehnologiilor informaţionale şi de a
consolida competenţele profesionale ale auditorilor în acest domeniu.
2
Cuprins
Prefaţă ...................................................................................................................... 2
Cuprins .................................................................................................................... 3
Glosar şi abrevieri ................................................................................................ 8
CAAT (Computer Assisted Auditing Techniques) – tehnici de audit asistate de
calculator............................................................................................................ 8
Capitolul I. Procesul auditului IT .................................................................... 12
1. Introducere în auditul IT ............................................................................. 12
1.1. Definiţia auditului IT ............................................................................ 12
1.2. Obiectivele Auditului TI ....................................................................... 14
1.3. Misiunea Curţii de Conturi .................................................................. 15
2. Etapele auditului TI ..................................................................................... 16
2.1. Planificarea pentru auditul IT ............................................................. 17
2.1.1. Privire generală ..................................................................................... 17
2.1.2. Planul strategic ...................................................................................... 17
2.1.3. Planul anual ........................................................................................... 18
2.1.4. Micro-planul /Programul de audit ......................................................... 18
2.2. Planificarea tehnică ............................................................................. 18
2.3. Planificarea logistică ........................................................................... 19
2.4. Cerinţe de resurse ................................................................................ 19
2.4.1. Resurse de personal ............................................................................... 19
2.4.2. Fonduri ................................................................................................... 20
2.4.3. Resurse tehnice ....................................................................................... 20
3. Studiul preliminar şi colectarea informaţiei despre entitate ...................... 21
3.1. Cunoaşterea entităţii ............................................................................ 21
3.1.1. Mediul organizaţional ....................................................................... 21
3.1.2. Structura organizatorică ................................................................... 22
3.1.3. Aprecierea importanţei Sistemului ................................................... 22
3.1.4. Natura echipamentului şi a aplicaţiilor utilizate .............................. 23
4. Evaluarea riscurilor pentru a defini scopul şi obiectivele auditului ......... 23
4.1. Paşi în analiza riscurilor...................................................................... 24
4.2. Riscul inerent ........................................................................................ 24
4.3. Riscul de control................................................................................... 24
4.4. Identificarea domeniilor de control ale managementului riscului ...... 26
4.5. Domeniul de aplicare şi scopul auditului intern .................................. 26
4.6. Riscul de nedetectare ........................................................................... 27
4.7. Obiectivele şi domeniul de aplicabilitate a auditului .......................... 27
5. Şedinţa de deschidere ................................................................................... 28
6. Colectarea şi evaluarea probelor ................................................................. 28
6.1. Tipuri de probe de audit ....................................................................... 29
6.1.1. Probele fizice ..................................................................................... 29
6.1.2. Interviul ............................................................................................. 30
6.1.3. Chestionarele .................................................................................... 30
3
6.1.4. Diagramele de flux ............................................................................ 31
6.1.5. Procedurile analitice......................................................................... 32
6.2. Instrumente de colectare a probelor .................................................... 32
6.2.1. Software generalizat de audit ........................................................... 32
6.2.2. Software-ul de audit specific unei ramuri ......................................... 32
6.2.3. Software-ul specializat de audit ........................................................ 33
6.2.4. Instrumente de auditare concomitentă.............................................. 33
6.3. Teste de audit........................................................................................ 34
6.4. Eşantionarea ........................................................................................ 34
6.5. Evaluarea probelor .............................................................................. 35
7. Şedinţa de închidere ..................................................................................... 37
8. Documentarea procesului de audit şi raportarea ....................................... 37
8.1. Importanţa documentării...................................................................... 37
8.2. Forma, conţinutul şi domeniul de aplicare a documentaţiei de audit . 37
8.3. Feedback-ul (comentariile) managementului entităţii auditate .......... 38
8.4. Raportarea............................................................................................ 38
8.5. Structura raportului Auditului TI ......................................................... 39
8.6. Limitările întâlnite pe parcursul efectuării auditului .......................... 40
Capitolul II. Metodologia de Audit ................................................................. 41
9. Controalele TI .............................................................................................. 41
9.1. Controale generale & ale aplicaţiilor.................................................. 41
9.1.1. Controale IT generale ....................................................................... 42
9.1.2. Controalele aplicaţiei........................................................................ 42
9.2. Relaţia dintre controalele generale şi controalele aplicaţiei .............. 43
9.2.1. Controale IT tip “ceapa” .................................................................. 43
10. Evaluarea controalelor generale............................................................... 46
10.1. Controalele organizaţionale şi de management (politicile şi standardele
IT) 46
10.1.1. Riscurile asociate cu controalele inadecvate ................................... 47
10.1.2. Organizaţia şi structura IT ............................................................... 48
10.1.2.1. Controlul şi implicarea managementului superior........................ 48
10.1.3. Strategia IT........................................................................................ 49
10.1.4. Personalul şi instruirea ..................................................................... 50
10.1.4.1. Structurile organizaţionale /organigrame/ .................................... 50
10.1.4.2. Fişele de post ................................................................................. 50
10.1.4.3. Planificarea personalului .............................................................. 51
10.1.4.4. Instruirea şi pregătirea personalului ............................................. 51
10.1.4.5. Politicile de recrutare/eliberare din funcţie şi coduri de conduită 51
10.1.4.6. Evaluarea personalului, inclusiv promovarea şi retrogradarea ... 52
10.1.4.7. Contracte speciale.......................................................................... 52
10.1.4.8. Rotaţia personalului....................................................................... 52
10.1.4.9. Concediile obligatorii .................................................................... 53
10.1.5. Politicile de documentare şi păstrare ............................................... 53
10.1.5.1. Politica de documentare a sistemelor ............................................ 53
10.1.5.2. Politicile de păstrare a documentelor ........................................... 53
4
10.1.6. Politica de externalizare a serviciilor............................................... 54
10.1.7. Implicarea auditului intern ............................................................... 54
10.1.8. Politica de securitate IT .................................................................... 55
10.1.9. Conformitatea legală şi de reglementare ......................................... 56
10.1.10. Segregarea sarcinilor .................................................................... 57
10.2. Operaţiuni TI ........................................................................................ 59
10.2.1. Rolurile şi responsabilităţile operaţiunilor IT .................................. 59
10.2.2. Riscurile asociate cu operaţiunile computerizate slab controlate ... 60
10.2.3. Controlul operaţiunilor IT ................................................................ 60
10.2.3.1. Acorduri privind nivelul serviciilor ............................................... 60
10.2.3.2. Controlul, revizuirea şi supravegherea din partea managementului
61
10.2.3.3. Instruirea şi experienţa .................................................................. 61
10.2.3.4. Întreţinerea calculatoarelor........................................................... 62
10.2.3.5. Documentarea operaţiunilor ......................................................... 62
10.2.3.6. Managementul problemelor ........................................................... 63
10.2.3.7. Managementul şi controlul reţelei ................................................. 63
10.3. Controale fizice şi de mediu ................................................................. 63
10.3.1. Introducere ........................................................................................ 63
10.3.2. Riscuri asociate cu controale fizice sau de mediu insuficiente/absente
64
10.3.2.1. Fizice .............................................................................................. 64
10.3.2.2. De mediu ........................................................................................ 64
10.3.3. Abordarea clientului faţă de riscurile fizice şi de mediu .................. 65
10.3.4. Controale fizice şi de mediu specifice ............................................... 65
10.3.4.1. Controlul fizic al zonelor sigure .................................................... 65
10.3.4.2. Controale administrative: .............................................................. 65
10.3.4.3. Controale de mediu ........................................................................ 68
10.4. Controale de acces logic ...................................................................... 70
10.4.1. Introducere ........................................................................................ 70
10.4.1.1. Riscul asociat cu controale de acces logic inadecvate.................. 71
10.4.1.2. Atacatorii ....................................................................................... 72
10.4.1.3. Consecinţele unei breşe în securitatea accesului logic ................. 72
10.4.2. Resurse, fişiere şi instalaţii care necesită protecţie ......................... 73
10.4.2.1. Fişiere de date................................................................................ 73
10.4.2.2. Aplicaţii .......................................................................................... 73
10.4.2.3. Fişiere cu parole ............................................................................ 73
10.4.2.4. Programe informatice şi instrumente de sistem (system tools) ..... 73
10.4.2.5. Fişiere jurnal.................................................................................. 74
10.4.2.6. Fişierele gata pentru imprimare şi cele temporare ....................... 74
10.4.3. Cadrul de securitate a accesului ....................................................... 74
10.4.4. Sistemul de operare şi controalele de acces la aplicaţii .................. 75
10.4.5. Controalele de acces logic la nivel de instalare ............................... 75
10.4.5.1. Gestiunea conturilor ...................................................................... 75
10.4.5.2. Proceduri de conectare la sistem................................................... 76
5
10.4.5.3. Identificarea şi autentificarea utilizatorului .................................. 77
10.4.5.4. Autentificarea ................................................................................. 77
10.4.5.5. Protecţia resurselor ....................................................................... 80
10.4.5.6. Securizarea fişierelor şi programelor............................................ 80
10.4.5.7. Alte controale de acces logic ......................................................... 81
10.4.6. Evidenţa jurnalelor ........................................................................... 82
10.5. Planul de Continuitate în Afaceri şi Planul de Recuperare în caz de
Dezastru............................................................................................................ 83
10.5.1. Obiectivele de audit........................................................................... 83
10.5.2. Zonele de risc .................................................................................... 83
10.5.3. Proceduri de audit............................................................................. 83
10.6. Controalele sistemelor orientate pe utilizator ..................................... 85
10.6.1. Ce înseamnă sisteme orientate pe utilizator (End-User Computing)?
85
10.6.2. Riscurile asociate cu sistemele orientate pe utilizator ..................... 85
10.6.2.1. Elaborarea sistemelor .................................................................... 85
10.6.2.2. Dublarea efortului.......................................................................... 86
10.6.2.3. Neconcordanţa datelor .................................................................. 87
10.6.2.4. Utilizarea sporită a resurselor şi costurilor .................................. 87
10.6.2.5. Ştergerea informaţiei centrale ....................................................... 87
10.6.2.6. Conformitatea cu legislaţia............................................................ 87
10.6.2.7. Pierderile de date ........................................................................... 88
10.6.2.8. Securitatea accesului logic şi fizic ................................................. 88
10.6.3. Viruşi de calculator ........................................................................... 89
10.6.4. Controalele sistemelor orientate pe utilizator .................................. 89
10.6.4.1. Controalele proceselor de elaborare a sistemelor ........................ 89
10.6.4.2. Dublarea efortului.......................................................................... 90
10.6.4.3. Neconcordanţa datelor .................................................................. 90
10.6.4.4. Legislaţia ........................................................................................ 90
10.6.4.5. Pierderile de date ........................................................................... 90
10.6.4.6. Acces logic şi fizic .......................................................................... 91
10.6.4.7. Asistenţă/suport pentru utilizatorii finali ....................................... 91
10.7. Controlul schimbărilor......................................................................... 92
10.7.1. Obiectivele de audit........................................................................... 92
10.7.2. Necesităţile de schimbări în sisteme ................................................. 92
10.7.3. Domeniile de risc .............................................................................. 93
10.7.4. Proceduri de audit............................................................................. 93
11. Controalele aplicaţiei ................................................................................. 94
11.1. Tipuri de aplicaţie ................................................................................ 94
11.1.1. Sisteme de introducere a datelor pe loturi (batch processing)......... 94
11.1.2. Sisteme ce operează în timp real (on-line processing) ..................... 94
11.2. Utilizatorii, administratorii şi proprietarii aplicaţiei .......................... 94
11.2.1. Proprietarul aplicaţiei ...................................................................... 94
11.2.2. Administratorul de aplicaţie ............................................................. 95
11.2.3. Utilizatorii ordinari ai sistemului ..................................................... 95
6
11.3. Definirea controalelor intrării, procesării & ieşirii datelor ............... 95
11.4. Controalele introducerii datelor (Input controls)................................ 96
11.4.1. Autorizarea introducerii datelor ....................................................... 97
11.4.2. Plenitudinea introducerii datelor...................................................... 98
11.4.3. Validarea datelor introduse .............................................................. 99
11.4.4. Verificările duble ............................................................................ 102
11.4.5. Concordanţa (Matching)................................................................. 103
11.4.6. Gestiunea intrărilor refuzate .......................................................... 103
11.5. Controale procesării datelor (processing controls) .......................... 103
11.5.1. Controalele run to run .................................................................... 104
11.5.2. Controalele de reconciliere a fişierelor .......................................... 105
11.5.3. Controalele de validate a tranzacţiilor ........................................... 105
11.5.4. Procedurile de gestionare a discrepanţelor ................................... 105
11.6. Controalele ieşirii datelor .................................................................. 105
11.6.1. Prezicerea rezultatului .................................................................... 106
11.6.2. Plenitudinea datelor-rezultat .......................................................... 106
11.6.3. Protecţia fişierelor - rezultat ale aplicaţiei .................................... 106
11.6.4. Raţionalitatea datelor-rezultat ........................................................ 107
11.6.5. Producerea datelor-rezultat în timp util ......................................... 107
11.6.6. Distribuirea datelor – rezultat (output) .......................................... 107
11.6.7. Utilizarea generatoarelor de rapoarte de către utilizatorii sistemului
107
11.6.8. Sistemele ce operează în timp real.................................................. 109
11.6.8.1. Pierderea mecanismelor de control convenţional ....................... 109
11.6.8.2. Controale preventive în sistemele ce operează în timp real ........ 110
11.6.8.3. Controalele detective a sistemelor ce operează în timp real....... 110
11.6.9. Sistemele de baze de date ................................................................ 111
11.6.9.1. Problemele de control specifice bazelor de date ......................... 111
11.6.9.2. Căile de compensare a punctelor slabe în control ...................... 112
11.6.10. Sisteme distribuite ........................................................................ 113
11.6.10.1. Controlul schimbului de date ...................................................... 113
11.6.10.2. Controalele privind accesul la funcţiile sistemului .................... 113
11.6.10.3. Controlul consistenţei datelor ..................................................... 114
11.7. Controalele pentru fişierele master şi datele invariabile .................. 114
11.7.1. Importanţa fişierelor master şi a datelor invariabile ..................... 115
11.7.2. Controalele fişierului master .......................................................... 115
Anexa nr.1 Exemplu de program de audit. ...................................................... 117
Anexa nr.2 Chestionar de determinare a criticismului SI. ............................. 124
Bibliografia........................................................................................................... 130
7
Glosar şi abrevieri
TI – Tehnologii Informaţionale.
8
NetScreen şi Cyberquard. (Deşi conţin anumite funcţii ale paravanelor de protecţie,
rutere nu se includ în această definiţie.).
RAM (Random Access Memory) – Memorie cu acces aleatoriu. O formă (un tip)
de memorie a computatorului.
9
Crack - un program destinat spargerii protecţiei unu soft sau sistem de operare.
ID – date de identificare.
Dummy data – date de test sau false, introduse în mediul de producţie a sistemului
pentru a verifica dacă acesta lucrează în modul stabilit.
reţea de tip WAN (Wide Area Network) – reţea de calcul de mare extindere
geografică, de exemplu între 2 oraşe, pe o ţară, un continent sau chiar pe întreaga
lume.
Centru de asistenţă (help desk) – unitate structurală sau persoană care asigură
interacţiunea dintre utilizatori şi specialiştii TI, direcţionând solicitările reieşind din
specificul acestora. În cazul problemelor mai simple pot asigura consultanţă directă
sau pot soluţiona problemele personal.
EUC (End User Computing) – Din perspectiva unui audit, sistemele orientate pe
utilizatori (de exemplu, foi de calcul tabelar) sunt definite ca un instrument conceput
în scopul extragerii informaţiei şi manipulare de date înainte de transfer şi / sau
generare de rezultate către o fişă electronică a sistemului de evidenţă financiară. În
plus, drept EUC pot fi privite fişierele în programele software independente, cum ar
fi Excel şi MS Access, care sunt create şi menţinute la nivel local de către utilizatorii
finali, şi nu beneficiază în mod oficial de sprijin de către personalul TI.
11
Capitolul I. Procesul auditului IT
1. Introducere în auditul IT
Tehnologiile informaţionale sînt parte indispensabilă a vieţii contemporane.
Posibilităţile şi avantajele pe care le oferă sînt principalele premise care fac ca ele
să-şi găsească o aplicare largă în cadrul sectorului guvernamental. În limita
resurselor disponibile, autorităţile publice implementează diferite soluţii ale
tehnologiilor informaţionale pentru a-şi eficientiza procesele de lucru.
În acest context, Curtea de Conturi, ca instituţie supremă de audit a ţării este
obligată să-şi creeze şi să-şi menţină capacităţile corespunzătoare în domeniul
auditului sistemelor informaţionale. Auditul sistemelor informaţionale reprezintă o
provocare la care aceasta trebuie să facă faţă.
1.1. Definiţia auditului IT
Auditul IT poate fi descris în general ca un proces de obţinere şi evaluare a
probelor pentru a determina dacă un sistem IT protejează activele organizaţiei,
utilizează eficient resursele, menţine securitatea şi integritatea datelor şi realizează
obiectivele business-ului în mod eficace.
Unele din varietatea de tipuri de audite IT includ următoarele:
Analiza controalelor O analiză detaliată a controalelor manuale şi celor
automatizate într-un sistem IT, cu obiectivul de a
estima gradul de încredere asupra tranzacţiilor
procesate şi rapoartelor generate de sistem
Auditul sistemelor Auditul rapoartelor financiare procesate /generate de
financiare un sistem IT, în vederea exprimării unei opinii de
audit
Auditul performanţei Examinarea unui sistem IT pentru a estima dacă
sau VPB a sistemelor obiectivele preconizate pentru implementarea
IT sistemului au fost realizate în mod eficace, cu atenţia
cuvenită asupra economicităţii şi eficacităţii
12
Auditul sistemelor în Auditul sistemelor IT în proces de elaborare pentru a
proces de elaborare estima dacă:
• planificarea, design-ul şi elaborarea sistemelor
este făcută într-un mod structurat într-un mediu
controlat, şi în conformitate cu metodologia
specificată;
• controalele adecvate şi eficace sunt luate în
considerare la fiecare etapă a procesului de
elaborare a sistemului; şi
• sistemul prevede o pistă adecvată de audit
Auditul judiciar În cazuri de suspectări de fraudă, acte ilegale sau
încălcări ale politicilor şi procedurilor companiei, o
anchetă pentru a colecta probe de audit, prin
utilizarea instrumentelor / dispozitivelor
corespunzătoare pentru restabilirea datelor într-un
mod fundamentat din punct de vedere juridic din
dispozitive de calculator (inclusiv computatoare de
buzunar, telefoane mobile, etc.) utilizate de către
suspect; şi
analizarea datelor colectate pentru a determina
proporţia actelor ilegale şi culpabilitatea persoanelor
implicate
Audit al securităţii Auditele controalelor de securitate în sistemele TI
informaţionale pentru a estima gradul în care sunt menţinute
confidenţialitatea, integritatea şi disponibilitatea
datelor şi sistemelor, proporţional cu profilul riscului
sistemului IT şi organizaţiei
Tehnici de audit Utilizarea instrumentelor automatizate şi software de
asistate de calculator audit pentru:
(CAAT)
• Descărcarea datelor din sistemele TI ale
entităţii auditate;
• Analiza şi verificarea datelor entităţii auditate
pentru realizarea obiectivelor de audit
tradiţionale.
13
1.2. Obiectivele Auditului TI
În baza evaluării riscurilor şi a controalelor aplicaţiei /sistemului selectat
pentru audit sunt stabilite obiectivele de audit. La formularea obiectivelor de audit
trebuie să se ia în considerare obiectivele managementului pentru acel sistem. În
mod normal, dacă sistemul satisface obiectivele managementului şi serveşte
intereselor afacerii în cel mai bun mod posibil devine obiectivul general al auditului.
După cum este descris în definiţia auditului TI, obiectivul general al auditului
IT cuprinde o evaluare a procesului pentru a asigura protecţia bunurilor, securităţii
datelor, eficacitatea sistemului şi eficienţa şi conformarea la reguli şi regulamente.
Deşi este esenţial de a stabili clar obiectivele auditului pentru iniţierea unui
audit detaliat, este necesar de a înţelege că pe parcursul auditului aceste obiective ar
putea suferi modificări sau formulări ulterioare.
Obiectivele auditului TI includ evaluarea şi aprecierea, proceselor care:
(a) Asigură securitatea activelor. Se disting următoarele cinci tipuri de active:
• Date
Tipuri de date în sensul cel mai larg, de exemplu: interne şi externe; structurate şi
nestructurate; grafice; sunete; imagini; documentaţie de system; ş.a.
• Aplicaţiile
Aplicaţiile reprezintă un sumar de proceduri atît manual, cît şi programate.
• Tehnologii
Tehnologiile se referă la: echipament, sisteme de operare, sisteme de management a
bazelor de date, reţele de calcul, multimedia, etc.
• Resurse
Resursele care găzduesc şi suportă SI, consumabile, etc.
• Personalul
Competenţele personalului de conştientizare şi productivitate necesare pentru a
planifica, organiza, achiziţiona, furniza, a menţine şi monitoriza SI şi serviciile.
(b) Asigură că următoarele 7 atribute a datelor ori informaţiei sînt menţinute:
• Eficacitate – asigură că informaţia este relevantă şi pertenentă pentru procesul de
afaceri şi poate fi livrată în timp, correct şi într-o manieră uşor de utilizat.
Deasemenea asigură că SI corespunde obiectivelor generale ale top
managementuliu şi utilizatorilot finali.
• Eficienţă – asigură, că informaţia este furnizată prin utilizarea optimă a resurselor
(cu o productivitate şi economicitate maximă). Asigură că SI utilizează resursele
optimal pentru a atinge obiectivele necesare.
• Confidenţialitatea - asigură că informaţia sensibilă este protejată de acces
neautorizat şi de divulgare.
14
• Integritatea – asigură acurateţea şi completitudinea informaţiei astfel încît validarea
acesteea să fie efectuată în conformitate cu principiile şi aşteptările bussinesului.
• Disponibilitatea – asigură că informaţia este disponibilă la momentul solicitării de
bussines-procese şi deasemenea se referă la protejarea resurselor.
• Conformitatea – asigură corespunederea cu cadrul legal şi normativ, precum şi cu
condiţiile contractual al căror subiect este bussines procesul.
• Fiabilitatea informaţiei – asigură că managementului îi este furnizată informaţie
adecvată şi fiabilă pentru luare de decizii.
Astfel Auditul TI examinează dacă procesele TI şi resursele TI sînt combinate
pentru a atinge obiectile propuse ale organizaţiei fără a compromite eficacitatea, eficienţa
şi economicitatea activităţii acesteia, concomitant respectînd şi nomele existente. Acest
lucru poate fi descries schematic în modul următor:
Figura nr.1
Resurse TI Procese TI
Obiectivele
Organizaţiei
15
2. Etapele auditului TI
Figura nr.2: Procesul de audit
Începu
Identificarea SI/
aplicaţiile supuse
Şedinţa de deschidere
Nu
Sînt controalele
fiabile?
Da
Testarea controalelor
Da Nu
Testare independentă Ne putem baza pe Testare independentă
controale în
restrînsă continuare? exstinsă
Evaluarea probelor
Şedinţa de închidere
Stop
16
Procesul auditului IT cuprinde în mod obişnuit următorii paşi:
• Planificarea
• Definirea obiectivelor
• Evaluarea controalelor
• Colectarea şi evaluarea probelor
• Raportarea şi urmărirea (monitorizarea executării implementării
recomandărilor)
2.1. Planificarea pentru auditul IT
17
2.1.3. Planul anual
Acesta transformă planul pe termen lung într-un program de lucru pentru anul următor.
Planificarea aici defineşte scopurile şi obiectivele fiecărui audit major ce urmează a fi
întreprins pe parcursul anului, cu resursele disponibile în cadrul Curţii de Conturi.
1
Anexa nr.1 Exemplu de program de audit
18
• tipurilor principale şi volumelor tranzacţiilor procesate de sisteme
• mărimii şi domeniului de aplicabilitate a auditului intern;
Detaliile de mai sus pot fi colectate de ISA prin:
• efectuarea unui tur al spaţiilor principale ale organizaţiei
• citirea materialului de ordin general inclusiv publicaţiile organizaţiei, rapoartele
anuale şi rapoartele independente de audit /analitice
• examinarea planurilor strategice pe termen lung
• intervievarea personalului cheie pentru a înţelege problemele legate de afacere
• examinarea rapoartelor precedente de audit
Colectarea acestei informaţii va face posibil ca CCRM să aibă o idee clară despre tipul
sistemelor ce urmează a fi auditate, indice domeniile prioritare pentru audit şi ofere un
punct de pornire pentru audit.
19
• disponibilitatea personalului. Pentru efectuarea auditului TI este necesar de a
“rezerva” personalul din timp pentru a se asigura disponibilitatea lui; şi
• bugetele de timp. Unele ISA ar putea avea sisteme complexe de înregistrare a
timpului şi de bugetare, utilizate pentru a controla resursele de personal alocate
pentru fiecare activitate.
Auditorul trebuie de asemenea să ia în considerare ce resurse de personal ale
clientului sunt necesare şi disponibilitatea acestora.
2.4.2. Fonduri
Auditorul IT ar putea avea nevoie să facă bugetul pentru cheltuieli, în special dacă
examinarea IT include şi elementul deplasări.
20
3. Studiul preliminar şi colectarea informaţiei despre entitate
Deşi planificarea este concentrată preponderent pentru etapa iniţială a auditului, ea
trebuieşte efectuată şi pe parcursul întregului audit. Acest lucru se datorează faptului că
rezultatele evaluărilor preliminare oferă baza pentru a determina durata şi tipul testărilor
ulterioare. În cazul în care auditorii obţin dovezi că procedurile specifice de control sunt
ineficiente, ei pot considera că este necesar să reevalueze concluziile lor anterioare şi a
altor decizii de planificare bazate pe acele concluzii.
21
Unele aspecte esenţiale despre organizaţie, necesare de a fi înţelese sunt:
• Funcţiile de bază (ce face şi cum face), obiectivele strategice şi sarcinile,
• Principalele tipuri de tranzacţii şi volumele lor implicate pentru efectuarea business
proceselor.
• Subdiviziunile şi funcţiile cheie necesare pentru realizarea activităţii.
• Numărul şi dislocarea teritorială a unităţilor operaţionale.
• Aplicaţiile informaţionale utilizate pentru gestiunea activităţilor de bază.
• Proiectele şi programe existente sau în proces de implementare aferente SI şi
echipamentului.
• Tipurile de risc cu care se confruntă organizaţia.
• Cadrul normativ în care entitatea îşi desfăşoară activitatea.
2
Anexa nr.2 Chestionar de determinare a criticismului SI.
22
Prin urmare, la planificarea auditului, auditor trebuie să ia în consideraţie natura
aplicaţiilor, funcţiile acesteia şi impactul lor asupra entităţii şi societăţii.
23
La etapa de planificare este necesar să se studieze procesul de management al riscului
pentru a înţelege ameninţările aşa cum sunt percepute de către management, impactul
acestora asupra sistemelor şi să se evalueze în mod independent dacă aceste ameninţări au
fost contracarate sau preîntâmpinate cu eficacitate şi în mod econom.
O analiză independentă a riscului de către auditor ajută nu doar la identificarea domeniilor
ce trebuie examinate, dar şi la determinarea obiectivelor auditului şi sprijinirea deciziilor
de audit bazate pe risc.
Controalele IT sunt grupate ca: controale generale, controale ale aplicaţiilor şi controale
specifice. La etapa de planificare ar fi suficient ca auditorul să-şi formeze o opinie generală
privind natura şi caracterul adecvat a controalelor desfăşurate într-un sistem IT şi, de
asemenea, în domeniile unde controalele sunt slabe şi vulnerabile. Aceasta formează baza
pentru cuprinderea, domeniile şi profunzimea testărilor necesare. De asemenea este
esenţial ca paşii să fie înregistraţi în mod detaliat pentru a servi drept indicatoare.
Activităţile de control intern şi procesele de suport sunt fie manuale sau acţionate de resurse
informaţionale automatizate computerizate. Elementele controalelor care trebuie luate în
considerare la evaluarea puterii controlului sunt clasificate ca Preventive, Detective (de
depistare) şi Corective cu următoarele caracteristici.
25
Corective • Minimizează impactul unei ameninţări
• Rezolvă problemele descoperite de controalele detective
• Identifică cauza problemei
• Corectează erorile care apar din cauza vreunei probleme
• Modifică sistemele de procesare pentru a minimaliza
apariţia problemei pe viitor
Cu cât mai înaltă este estimarea riscului inerent şi de control cu atât mai multe probe de
audit urmează să obţină auditorul IT din efectuarea procedurilor de fond în cadrul auditului.
27
• Examinarea securităţii sistemelor IT;
• Examinarea procesului de elaborare a sistemului şi a procedurilor urmate la diferite
etape ale acestuia.
Obiectivele de audit şi domeniul de aplicabilitate ar putea cuprinde mai mult decât doar un
singur aspect al domeniilor menţionate mai sus. De exemplu, examinarea securităţii
sistemului ar putea cuprinde doar unul din următoarele aspecte sau o combinaţie a
acestora:
• Securitatea paravanului de protecţie (Firewall-ului )
• Securitatea accesului fizic
• Parolele
• Securitatea setărilor
• Politicile conturilor de utilizatori
• Drepturile utilizatorului, etc.
Domeniul de aplicabilitate defineşte limitele auditului. Determinarea domeniului de
aplicabilitate al auditului reprezintă o parte a planificării auditului. Aceasta abordează
astfel de aspecte ca perioada şi numărul de locaţii ce vor fi cuprinse şi volumul de testări
de fond în dependenţă de nivelurile de risc şi punctele slabe ale controlului. Nu mai este
nevoie de spus că domeniul de aplicabilitate al auditului va suferi schimbări în procesul de
desfăşurare al auditului.
5. Şedinţa de deschidere
Este necesară o şedinţă formală de începere a auditului, organizată cu managementul
superior responsabil pentru domeniului ce urmează a fi auditat, pentru a finaliza domeniul
de aplicare, înţelege îngrijorările speciale, dacă sunt, planifica datele şi explica
metodologia pentru audit. Această şedinţă ajută la ajustarea obiectivelor în baza
percepţiilor manageriale despre sistemul IT. Astfel de şedinţe implică managementul
superior, permit persoanelor să se întâlnească, să clarifice problemele şi îngrijorările de
bază ale companiei, şi ajută ca auditul să fie desfăşurat fără probleme în afară de prevenirea
entităţii despre datele, informaţia şi documentele care vor fi solicitate de echipa de audit.
Pe parcursul conferinţei de deschidere, reprezentanţii entităţii auditate pot fi informaţi
despre obiectivele generale ale auditului, planul de audit preliminar propus, domeniile
posibile de interes în baza constatărilor de audit anterioare sau constatărilor de audit în
domenii de afaceri similare. Aceştia sunt provocaţi să-şi împărtăşească îngrijorările cu
privire la sistemul IT, care sunt luate în considerare de auditori.
28
„Pentru a susţine deciziile şi concluziile auditorilor, privind organizarea, programul,
activităţile şi funcţiile din cadrul auditului trebuie obţinute probe competente pertinente şi
relevante”
Standardele stabilesc că:
a) Selectarea şi eşantionarea datelor trebuie efectuate cu atenţie,
b) Auditorii trebuie să aibă o înţelegere clară a tehnicilor şi procedurilor precum:
inspectarea, observaţiile, investigaţiile şi confirmaţiile pentru colectarea probelor de
audit,
c) Probele trebuie să fie competente, relevante, rezonabile şi concrete.
Verificarea fizică este inspecţia sau numărarea de către auditor a valorilor materiale.
Auditorul poate inspecta fizic prezenţa calculatoarelor, terminalelor, imprimantelor, etc.
Camera de servere (data centrul) va trebui vizitat pentru verificarea vizuală a prezenţei
detectoarelor de apă şi de fum, stingătoarelor de incendiu, etc. De asemenea, amplasarea
dispozitivelor trebuie marcată clar şi să fie vizibilă. Controalele accesului fizic sunt
destinate pentru a proteja organizaţia de accesul neautorizat.
• Identifica acel personal din cadrul unei organizaţii care poate furniza cea mai bună
informaţie pentru un subiect al interviului. Structurile organizaţionale deseori
reprezintă o primă sursă de informare privind respondenţii adecvaţi pentru
intervievare.
6.1.3. Chestionarele
Chestionarele au fost folosite în mod tradiţional pentru evaluarea controalelor din cadrul
sistemelor. Auditorii pot de asemenea folosi chestionare pentru a evidenţia părţile slabe ale
30
unui sistem pe parcursul colectării probelor. De exemplu, auditorii pot utiliza chestionare
pentru a estima opinia generală a utilizatorilor despre un sistem informaţional ca indicator
al eficacităţii sistemului. Similar, chestionarele pot fi folosite pentru a identifica domeniile
cu un sistem informaţional unde există potenţiale ineficienţe. Întrebările trebuie să fie
formulate clar, termenii trebuie definiţi şi instrucţiunile pentru completarea chestionarelor
trebuie să fie clare. Unele recomandări generale cu privire la chestionare, de care trebuie
de ţinut cont sunt de a:
întrebările ambigue
întrebările prezumtive
întrebările ipotetice
întrebările jenante
• Evaluare – auditorii experimentaţi pot utiliza diagrame de flux ale controlului pentru
a recunoaşte modelele care manifestă fie puncte forte ale controlului fie puncte slabe
ale controlului într-un sistem;
31
• Selectarea nivelului adecvat de detaliu la care auditorii să lucreze în aşa fel ca să nu
fie supraîncărcaţi cu conţinutul, dar cu toate acestea să nu piardă punctele forte sau
punctele slabe importante ale controlului;
Software-ul generalizat de audit este discutat mai detaliat în modulul privind CAAT.
Există nişte limite privind utilizarea Software-ului generalizat de audit cum ar fi capacitatea
limitată pentru verificarea logicii de procesare şi o abilitate limitată de a determina
predispunerea la erori.
• Capcane de audit,
33
6.3. Teste de audit
Auditorii utilizează de obicei două tipuri de teste – teste de ‘conformitate’ şi teste ‘de
fond’.
Câteva exemple de teste de conformitate după cum sunt relaţionate cu mediul IT includ:
Câteva exemple de teste de fond după cum sunt relaţionate cu mediul IT includ:
6.4. Eşantionarea
Eficienţa auditului se bazează pe obţinerea minimului de probe de audit, suficiente pentru
a forma opinia de audit. Utilizarea eşantionării de audit, în misiunile de audit, oferă
auditorilor beneficii nenumărate. Acestea includ:
34
• clarificării abordării de audit pentru a determina modul în care vor fi realizate
obiectivele de audit,
Eşantionarea pentru audit este testarea elementelor selectate din cadrul unui masiv pentru
a obţine şi evalua probele despre unele caracteristici ale acestui masiv, în scopul de a forma
o concluzie cu privire la tot masivul.
Sunt două metode primare de eşantionare utilizate de auditorii IT. Acestea sunt
Eşantionarea Atributivă şi Eşantionarea Variabilă. Eşantionarea atributivă este în
general utilizată în situaţiile de testare de conformitate şi vizează prezenţa sau absenţa
atributelor şi oferă concluzii exprimate în rate de incidenţă. Eşantionarea variabilă este în
general aplicată în situaţiile de testare de fond şi se axează pe caracteristicile masivelor de
date, care variază şi oferă concluzii legate de devierile de la normă.
Eşantionarea poate fi utilizată în diferite situaţii de auditare. Există diferite căi în care poate
fi selectată o eşantionare statistică. Cel mai frecvent utilizate metode sunt selectarea
aleatorie unde fiecare element din masivul de date are şansă egală de a fi selectat.
Eşantionarea aleatorie simplă asigură faptul că fiece număr din masiv are o şansă egală de
a fi selectat. Este utilă pentru testarea controalelor interne. De exemplu, auditorul poate
decide dacă sunt erori peste o anumită limită atunci sistemele de control sunt ineficiente.
Eşantionul poate selecta folosind numere aleatorii prin intermediul calculatoarelor.
Software de audit, cum este IDEA poate fi folosit pentru selectarea eşantionului. Odată ce
eşantionul este selectat, testele de audit identificate se vor aplica asupra eşantionului.
35
siguranţă pentru a asigura că sistemul protejează bunurile şi integritatea datelor, realizează
eficace obiectivele organizaţionale şi consumă resursele în mod eficient.
36
7. Şedinţa de închidere
După ce cercetarea de audit a fost finalizată, constatările de audit şi sugestiile pentru acţiuni
de corectare pentru managementul superior pot fi comunicate într-o şedinţă formală.
Aceasta va asigura o înţelegere mai bună şi spori susţinerea recomandărilor de audit.
Aceasta de asemenea oferă organizaţiei auditate o oportunitate de a-şi exprima punctele de
vedere privind problemele puse în discuţie. Scrierea raportului după o astfel de şedinţă,
unde se ajunge la o înţelegere cu privire la toate problemele de audit poate spori puternic
eficacitatea auditului. Conferinţa finală de asemenea ajută la finalizarea recomandărilor
practice şi fezabile.
• programul de audit,
• punctele discutate în interviuri care atestă în mod clar subiectul discuţiei, persoana
intervievată, poziţia şi funcţia, ora şi locul,
• rapoartele şi datele obţinute de către auditor direct din SI sau primite de la personalul
entităţii. Auditorul trebuie să se asigure că rapoartele respective indică sursa, data,
timpul şi scopul obţinerii lor.
• în cazul în care activitatea de audit este revizuită de către un coleg sau un superior,
comentariile care reiese din revizuirea respectivă, de asemenea, ar trebui să fie
înregistrate în documentaţia de audit.
Proiectul şi rapoartele finale ale auditului ar trebui să facă parte din documentaţia de audit.
8.4. Raportarea
Formatul rapoartelor de audit TI este similar cu formatul rapoartelor altor tipuri de audit.
Cu toate acestea, de cîte ori este utilizat cadrul CoBIT nu numai pentru îndrumare, dar şi
ca cadru de referinţă, raportarea trebuie să fie bazată pe structura cadrului respectiv. În
acelaşi timp, urmează a ţine cont de posibilul cititor. Cu toate aceste, conţinutul raportului
trebuie să fie orientat spre posibilului cititor.
38
Efectuarea auditului TI, trebuie să se bazeze pe examinarea unui SI. Un astfel de sistem
poate rula într-o singură unitate structurală a entităţii, sau într-un număr mare de unităţi, în
care să fie utilizate diferite funcţionalităţi ale acestuia. De exemplu un SI financiar din
cadrul Trezoreriei, poate fi utilizat în mai multe unităţi teritoriale şi chiar alte instituţii. Pe
de altă parte un sistem de facturare poate fi utilizat doar într-o ramură de activitate a unei
entităţi. În cazul utilizării SI în mai multe unităţi ale instituţiei, examinările de audit trebuie
repartizată în aş mod încât concluziile să devină reprezentative.
• Introducere
• Constatările auditului
• Concluziile auditului
• Recomandările
39
8.6. Limitările întâlnite pe parcursul efectuării auditului
În raportul de audit urmează a fi menţionat despre limitările care au fost întâmpinate de
audit. De exemplu, în cazul în care datele nu au fost utilizate din mediul de producţie. În
mod similar, dacă auditul nu a putut utiliza date de test (dummy data) pentru a evalua
controalele de intrare complet.
40
Capitolul II. Metodologia de Audit
9. Controalele TI
Capacităţile sistemelor informaţionale au avansat rapid în ultimele decenii.
În multe organizaţii, majoritatea proceselor au fost computerizate şi toate
informaţiile sunt disponibile doar în mediul digital. În această situaţie, auditorii
urmează să adapteze metodologia lor la circumstanţele schimbate. Chiar dacă
obiectivele generale de control nu se modifică intr-un mediu informatizat, punerea
lor în aplicare se schimbă. În consecinţă abordarea auditorilor de a evalua controalele
interne va suferi schimbări.
Controalele TI dintr-un sistem informaţional sunt toate metodele manuale şi
programate, politicile şi procedurile care asigură protecţia activelor entităţii,
acurateţea şi fiabilitatea înregistrărilor, şi orientarea operaţională la
standardele managementului.
Prezenţa controalelor într-un sistem informaţional este semnificativă din punctul de
vedere a auditului, deoarece aceste sisteme pot permite dublarea intrărilor sau
prelucrărilor, sau invizibilitatea unor procese, iar în cazul unor organizaţii a căror
sisteme informaţionale sunt operate de furnizori terţi de servicii, care utilizează
propriile standarde şi controale, fac aceste sisteme vulnerabile la acces neautorizat
şi de la distanţă.
La efectuarea auditul TI este preferabil de utilizat ambele tipuri de teste – de
conformitate şi de fond. Testul de conformitate, determină dacă controalele sunt
aplicate în modul descris în documentaţia entităţii. Cu alte cuvinte, un test de
conformitate determină dacă controalele sunt aplicate în conformitate cu politicile şi
procedurile organizaţiei. Auditul de fond "fundamentează" corespunderea
controalelor existente pentru protejarea organizaţiei de la activităţi frauduloase şi
cuprinde rezultatele raportate asupra procesării tranzacţiilor şi activităţilor.
9.1. Controale generale & ale aplicaţiilor
În cadrul mediului IT pot fi identificate două nivele de control:
• Controale IT generale; şi
La cel mai jos nivel, există controale generale, care sunt axate pe mediul general în
care sistemele IT sunt elaborate, exploatate, gestionate şi întreţinute. Controalele IT
generale creează un cadru al controlului general pentru activităţile IT şi oferă unele
asigurări precum că obiectivele generale ale controlului sunt îndeplinite. În esenţă
acestea acţionează ca o fundaţie, pe care pot fi elaborate controale ale aplicaţiilor
specifice.
Celălalt nivel de control constă din controale ale aplicaţiei. Acestea sunt proceduri
specifice de control asupra aplicaţiilor care pot să garanteze că toate tranzacţiile sunt
41
autorizate şi înregistrate, procesate complet, corecte şi efectuate în timp. Controalele
aplicaţiei ar putea consta din proceduri manuale efectuate de utilizatori (controale
ale utilizatorilor) şi proceduri automatizate sau controale efectuate de software de
calculator.
• controalele operaţionale;
• segregarea sarcinilor;
Deoarece controalele aplicaţiei sunt strâns legate de tranzacţiile individuale este mai
uşor de a vedea de ce testarea controalelor va oferi auditorului o asigurare în ceea ce
priveşte exactitatea unui anumit sold de cont. De exemplu, testarea controalelor într-
o aplicaţie de salarizare va oferi asigurarea cu privire la cifra salarizării în conturile
unui client şi invers, testarea controalelor IT generale ale clientului (de ex.,
schimbarea procedurilor de control) nu va oferi un grad similar de asigurare pentru
acelaşi sold de cont.
După cum sunt legate de fluxurile de tranzacţii, controalele aplicaţiilor includ de
obicei:
42
• introducerea tranzacţiilor (controale de intrare);
• controalele de procesare;
• „master-files”.
Multe controale ale aplicaţiilor sunt pur şi simplu versiuni computerizate ale
controalelor manuale, de ex., autorizarea computerizată de către un supraveghetor
folosind mai degrabă un cod de acces decât punând o semnătură pe o foaie de hârtie.
9.2. Relaţia dintre controalele generale şi controalele aplicaţiei
O modalitate de a privi relaţia dintre controalele generale şi ale aplicaţiilor este de a
distribui controalele generale pentru protejarea aplicaţiilor şi bazelor de date ale
tranzacţiilor. Controalele generale oferă aplicaţiilor resursele de care au nevoie
pentru a opera şi de a asigura faptul că modificările neautorizate nu pot fi făcute la
nici una din aplicaţii (adică, sunt protejate de reprogramare) sau baze de date de bază
(colecţia mare de date privind tranzacţiile).
În acelaşi timp, controalele aplicaţiilor funcţionează în baza tranzacţiilor individuale
şi asigură că acestea sunt corect introduse, procesate şi produse.
43
Toate aceste controale s-au referit până la moment la aplicaţie. Am presupus că
persoana care introduce tranzacţia este un angajat competent, sârguincios şi onest.
Acest lucru ar putea fi şi altfel. După cum progresăm către stratul exterior al cepei,
identificăm mai multe controale IT generale care se axează pe prevenirea accesului
neautorizat al unei persoane la sistem, ceea ce devine din ce în ce mai important
odată cu creşterea reţelelor de arie largă şi conexiunii la Internet. Auditorul trebuie
să aibă asigurarea precum că clientul a folosit versiunea corectă a pachetului contabil
şi nu versiunea netestată care ar putea conţine erori de programare.
• Sistemul de operare: acestea pot controla cine din personal şi ce aplicaţii pot
accesa. De exemplu, aplicaţiile financiare sunt de obicei rulate pe un sistem
computerizat central al clientului împreună cu multe alte programe, aşa ca sisteme
de control pentru personal, procesarea textelor, producere, etc. Sistemul de operare
trebuie să aibă controale pentru a se asigura că numai cei cu acces legitim la
sistemele financiare să poată utiliza acele aplicaţii. Acest lucru se face prin
securitatea accesului logic.
• Fizic şi de mediu: calculatoarele sunt atât sensibile la mediul lor cât şi atractive
pentru infractori (în ceea ce priveşte valoarea lor inerentă a diferitor componente şi
resurselor financiare pe care le controlează). Calculatoarele trebuie să fie protejate
fizic de aceste riscuri.
44
Controlul de tip ceapă
Network Access
Controls
Operating System
Controls
Application
Controls
Applicati
Input Process Output
Transa Accou
ti t
Aud Sta
45
10. Evaluarea controalelor generale
În acest capitol vor fi analizate controalele de nivel înalt adoptate de management pentru a
asigura că sistemele computerizate funcţionează corect şi că acestea satisfac obiectivele
afacerii. Scopul nostru, ca auditori externi, este de a determina dacă controalele pe care le-a
pus clientul în aplicare sunt suficiente pentru a asigura controlul adecvat al activităţilor TI.
Politicile de nivel înalt sunt importante deoarece acestea stabilesc un cadru în baza căruia
clientul îşi poate dezvolta controalele detaliate la nivel inferior.
Există o regulă generală precum controalele merg din vârful unei organizaţii în jos (după
toate, controalele sunt responsabilitatea conducerii de vârf).
Management
(Approve Policies)
IT Standards
Detailed Procedures
(e.g.: desk instructions)
46
Conducerea stabileşte şi aprobă politicile. Politicile sunt de obicei declaraţii de intenţie de
nivel înalt. Politicile se utilizează pentru a stabili standarde. Procedurile detaliate (şi
controalele) reiese din standarde.
Auditor ar pierde credibilitate dacă ar fi făcut critici doar teoretice fără a acorda vreo
atenţie la circumstanţele clientului. De exemplu, recomandând clientului să
angajeze mai mult personal pentru a creşte segregarea sarcinilor din cadrul
departamentului IT.
Notă: la examinarea politicilor şi standardelor IT a unui client, auditorul trebuie să ţină cont
de probabilitatea că fiecare client poate fi diferit şi poate avea diferite cerinţe organizaţionale
şi manageriale. Auditorul poate evalua dacă structura organizaţională a clientului şi locul IT
în structură este corespunzător.
• structurile slabe de raportare pot conduce la luarea unor decizii neadecvate. Acest
lucru poate afecta capacitatea clientului de a-şi livra serviciile sale şi poate afecta
viitorul acestuia;
• personal ineficient care nu-şi înţeleg funcţiile lor (fie din cauza politicilor inadecvate
de recrutare sau fie din cauza lipsei de instruire a personalului sau supraveghere).
Acest lucru sporeşte riscul ca personalul să comită greşeli şi erori;
47
• spargeri a securităţii care duc la pierderea datelor, fraudă şi erori.
În continuare, trecem mai departe să vedem modul în care departamentul IT al unui client
se încadrează în structura organizaţională globală, inclusiv legăturile cu alte părţi ale
afacerii.
Un client mare poate avea un Comitet pentru securitate care raportează directorului
executiv. Funcţionarul pentru securitatea IT va raporta Comisiei pentru securitate.
48
Pentru a fi eficace, Comitetul de supraveghere IT ar trebui să-şi selecteze membrii săi din
managementul superior şi mediu. Calitatea de membru ar trebui să fie atrasă din toate
departamentele de utilizatori din cadrul unei organizaţii. Locul managementului superior
este deosebit de important, deoarece prezenţa lor oferă deciziile luate de către comitet o
pondere mai mare.
10.1.3. Strategia IT
Odată ce Comitetul de supraveghere stabileşte direcţia ulterioară a IT, deciziile ar putea fi
formalizate şi documentate într-un plan. Direcţia ulterioară a Comitetul de supraveghere IT
este în mod normal stabilit într-un document cunoscut sub denumirea de strategia IT.
!!!! Strategia IT este de fapt punctul de plecare pentru orice investiţii în IT deoarece
aici se identifică schimbările ulterioare care trebuie să fie bugetate.
Deşi este probabil ca strategia IT să aibă un efect minim asupra auditului din anul curent,
aceasta poate avea un efect semnificativ asupra auditelor din anii ce urmează. O examinare
a strategiei IT a unui client ar putea pune în gardă auditorul IT referitor la problemele care
pot apărea în anii viitori. De exemplu, strategia IT poate menţiona că organizaţia va înlocui
sistemul său financiar într-o perioadă de doi ani. Acest lucru poate avea impact asupra
activităţii auditorului.
Din punctul de vedere al clientului, riscul principal asociat cu o strategie IT slabă sau absentă
este dezvoltarea unor sisteme care nu satisfac necesităţilor afacerii.
• devine din ce în ce mai obişnuit ca IT să fie privit ca cheltuieli de business care trebuie
să se justifice. În consecinţă, toate cheltuielile majore legate de IT sunt examinate
îndeaproape şi se fac investiţii doar atunci când este un caz necesar pentru afacere;
• strategia IT ar trebui să fie orientată spre viitor. De obicei, acestea vizează o perioadă
de 3 ani înainte. Este dificil de a prezice cu precizie o perioadă mai mare din
cauza ritmului schimbărilor tehnologice;
49
• strategia ar trebui aprobată de managementul superior.
Erorile şi omisiunile reprezintă cea mai mare sursă de probleme. Prin urmare, este
important ca clientul să aibă controale şi proceduri pentru a reduce riscul de a comite greşeli.
Acest lucru poate fi realizat prin adoptarea unor politici şi proceduri de personal adecvate,
de exemplu:
• o structură organizaţională clară sprijinită de linii de raportare/ diagrame;
• fişe de post;
• planificarea personalului;
• instruiri şi pregătirea personalului;
• politici de angajare/eliberare din funcţie (inclusiv, coduri de conduită);
• evaluările de personal (promovare/retrogradare);
• contracte speciale;
• rotaţia personalului; şi
• concediile personalului.
• atunci când se instalează sisteme noi, competenţele tehnice necesare pentru rularea
sistemelor noi ar putea să nu fie disponibile. Managementul ar putea avea nevoie să
identifice competenţele necesare din timp şi să trimită personalul la cursuri de
instruire, recruteze personal nou sau să angajeze consultanţi pentru o perioadă.
Pentru a reduce dependenţa de câţiva angajaţi cheie, clientul poate folosi o formă de
instruire încrucişată, adică instruirea membrilor personalului pentru a efectua activităţile
colegilor lor, în caz de absenţă. Acest lucru prevede, de asemenea, o formă de planificare de
succesiune. Clientul ar trebui să fie conştient de faptul că instruirea personalului pentru a
suplini un alt membru al personalului creşte riscul că acest personal să posede o cunoaştere
mai detaliată a întregului sistem, inclusiv existenţa unor controale compensatoare.
La angajarea unor noi membri de personal IT, clientul, ar fi de aşteptat, să ţină cont de:
• verificările de fond: inclusiv solicitarea scrisorilor de referinţă (în unele ţări ar putea
fi posibil de a verifica dacă persoana nu a avut antecedente penale);
51
• codurile de conduită, inclusiv relaţiile contractuale cu rudele, acceptarea de cadouri,
conflicte de interese, etc.
Politicile cu privire la eliberarea din funcţie ar trebui să definească măsurile care trebuie
întreprinse atunci când serviciile unui angajat nu mai sunt necesare. Este important ca aceste
politici şi proceduri să fie aplicate deoarece pagubele care pot fi cauzate de un angajat
nemulţămit asupra unui sistem computerizat pot fi considerabile. Politicile cu privire la
eliberarea din funcţie ar trebui să abordeze:
• eliberarea din funcţie din motive voluntare ale angajatului (demisia, pensionarea);
• eliberarea din funcţie din motive voluntare ale angajatului: adică concediat;
• eliberarea imediată din funcţie, de ex., din cauza unor încălcări serioase;
• măsuri de securitate: care ar putea include:
o returnarea cheilor de acces, cardurilor şi ecusoanelor de identitate;
o ştergerea sau dezactivarea privilegiilor de acces logic, adică parola acestora.
• alte proceduri:
o notificarea altor angajaţi. Alţi angajaţi ar trebui să fie la curent cu rezilierea
contractului şi aceştia vor fi conştienţi de orice activităţi neautorizate pe care
aceşti angajaţi ar putea încerca să le efectueze;
o aranjarea rutinelor de plată finale pentru a se asigura că acea persoană este
exclusă din statul de plată;
o realizarea interviurilor înainte de plecare ar putea fi utile pentru a determina
sentimentele angajatului faţă de organizaţie;
o întoarcerea bunurilor proprietate a companiei, inclusiv laptop-urilor personale,
pagerelor, cartelelor inteligente (smartcard-uri) etc.; şi
o escortarea în afara incintei (dacă este necesar).
52
10.1.4.9. Concediile obligatorii
Personalul ar trebui să fie obligat să îşi ia concedii regulate, cel puţin o dată pe an. Acest lucru
ar trebui să reducă riscul ca acţiunile neautorizate sau ilegale să rămână nedepistate.
Concediile obligatorii ar putea fi o condiţie de asigurare, în unele întreprinderi, de exemplu,
industria bancară. Au existat cazuri în care personalul nu a mers în concediu pentru mai
mulţi ani şi au fost efectuate fraude care implică procesul numit teeming and lading (prin
care deficienţele de numerar (furt de numerar) sunt ascunse pentru o perioadă de timp, fiind
acoperite de la un alt creditor, apoi de la altul). Fraudele lor au fost descoperite numai atunci
când s-au îmbolnăvit, şi activitatea lor a fost preluată de către un alt angajat.
În final, dacă clientul nu păstrează probe suficiente, adecvate, atunci auditorul va avea
dificultăţi în a fi capabil să ofere opinie de audit.
53
Abordări de audit bazate pe controale: auditorul ar avea nevoie de probe ale
controalelor în funcţiune pe parcursul perioadei contabile. Aceste probe ar putea consta
din reconcilieri, semnături, jurnale de audit examinate, etc.
Ar mai putea fi alte cerinţe, ne-asociate cu auditul, care solicită clientului să păstreze
documentaţia referitor la tranzacţii, de exemplu:
• regulamente cu privire la import;
• regulamente cu privire la impozitare; şi
• cerinţe ale companiei cu privire la legislaţie.
Politicile clientului de păstrare a documentaţiei ar trebui să ţină cont de toate aceste cerinţe.
• personalul implicat în auditul intern poate fi utilizat pentru a oferi asistenţă directă
în cadrul auditului, dacă este necesar sub supravegherea auditorului extern. De
exemplu, auditorul extern ar putea cere auditorilor interni să-i acorde asistenţă la
verificarea existenţei activelor fixe.
Politicile de securitate IT sunt, în mod normal, exprimate sub formă de naraţiune concisă,
55
adică în câteva pagini de text. Politica necesită aprobarea managementului superior în cazul
în care se doreşte ca aceasta să aibă vreo influenţă, şi, prin urmare, ar trebui să fie aprobată
la nivel de consiliu de administraţie sau echivalentul acestuia şi ar trebui susţinut de
managementul superior. În cele din urmă, ar trebui să fie disponibilă tuturor angajaţilor,
responsabili de securitatea informaţională. Acolo unde clientul dispune de personal care are
acces la un sistem computerizat, aceasta va include astfel de personal.
Unii clienţi creează forumuri pentru securitate informaţională pentru a analiza şi coordona
politicile de securitate IT.
56
• legislaţie privind protecţia şi confidenţialitatea datelor pentru a proteja datele cu
caracter personal la indivizi, de ex., informaţia salarială a acestora;
Clientul ar trebui să fie la curent cu cerinţele locale şi să întreprindă măsuri adecvate pentru
a asigura conformitatea.
Neconformitatea ar putea rezulta în acţiuni, variind de la os scrisoare de avertizare la
urmărire penală sau chiar închiderea afacerii.
Sarcinile segregate pot de asemenea oferi o formă de verificare a erorilor şi control al calităţii
şi includ atât:
Separarea sarcinilor se aplică atât pentru mediul controalelor generale cât şi pentru aplicaţii
sau programe specifice.
57
Personalul nu ar trebui să aibă sarcini care să se încadreze în ambele tipuri de activitate.
Programatorii nu ar trebui să dispună de acces la fişiere şi programe cu date reale.
Cu presiunea de a reduce costurile funcţiilor IT, numărul personalului este adesea redus.
Aceasta limitează domeniul de aplicare pentru sarcinile segregate. Dacă acesta este cazul,
atunci auditorul trebuie să adopte o abordare pragmatică pentru identificarea punctelor
slabe şi oferirea recomandărilor. În cazul în care domeniul de aplicare pentru sarcinile
segregate este limitat, auditorul ar trebui să caute existenţa unor controale compensatoare,
cum ar fi securitatea bună a calculatoarelor şi reconcilierea între utilizatorii finali.
58
10.2. Operaţiuni TI
59
10.2.2. Riscurile asociate cu operaţiunile computerizate slab controlate
Riscurile includ:
• aplicaţii neexecutate corect (rularea unor aplicaţii greşite sau versiuni incorecte
sau parametri de o configurare greşită introduse de personalul operativ, de ex., ora
şi data sistemului fiind incorecte, ceea ce ar putea duce la procente ale dobânzii
eronate, calcule salariale eronate, etc.);
Fără un acord privind nivelul serviciilor, următorul proverb devine relevant: "Dacă ţinteşti
către nicăieri, de obicei acolo ajungi.", Structura şi nivelul de servicii specificat într-un
SLA va depinde de practicile de lucru şi cerinţele fiecărei organizaţii. Un SLA tipic ar putea
să conţină următoarele:
60
• ore de serviciu (program normal de lucru şi ocazii speciale precum week-end-
urile);
• disponibilitatea serviciului (procentajul disponibilităţii, numărul maxim de erori
al serviciului şi timpul maxim de neoperare per defecţiune);
• nivelele de sprijin pentru utilizatori (detalii help desk);
• performanţa (timp de răspuns, durata ciclului de prelucrare (turnaround time);
• situaţii neprevăzute (detalii succinte ale planurilor);
• securitate (inclusiv conformarea cu politica de securitate IT a organizaţiei); şi
• restricţii (numărul maxim de tranzacţii, utilizatori);
Auditorul ar trebui să examineze orice SLA pentru a determina că aceste sprijină procesarea
corectă şi consecventă a datelor financiare.
Sistemele IT ale clientului ar putea avea incluse utilităţi software care ar putea fi utilizate, să
presupunem, pentru a face modificări neautorizate la fişierele de date. Personalul operativ
cu acces la astfel de software ar trebui supravegheat pentru a se asigura că aceştia utilizează
utilităţile în scopuri autorizate.
Supravegherea eficace asupra personalului operativ IT este deseori dificilă de realizat, din
cauza nivelului înalt de cunoştinţe tehnice. Aceştia ar putea face sistemului ceva ce
conducerea nu ar putea depista sau chiar recunoaşte importanţa, dacă se depistează o
schimbare. Din acest motiv, într-o oarecare măsură conducerea trebuie să acorde un grad
înalt de încredere personalului operativ TI, iar încrederea să se bazeze pe selectarea
adecvată a personalului şi proceduri de validare (conform controalelor organizaţionale şi de
management discutate în capitolul precedent, {capitolul 10.1}).
61
Strâns legată de instruire este dezvoltarea carierei personalului. Dacă operaţiunile IT se
consideră că se află într-un punct mort cu puţin progres, moralul acestora ar putea fi la un
nivel redus şi este mai puţin probabil ca să-şi desfăşoare activitatea la un standard înalt
(aceştia chiar ar putea fi tentaţi să ocolească regulile şi să efectueze activităţi neautorizate).
Documentaţia poate fi utilizată de personalul operativ TI atunci când nu sunt siguri cum să
desfăşoare o procedură. Acestea sunt utile şi pentru instruire personalului nou.
62
care-şi rulează software-le de automatizare a oficiului vor avea probabil documentaţie mai
puţin detaliată şi extensivă.
10.3.1. Introducere
Obiectivul controalelor fizice şi de mediu este de a preveni accesul şi intervenţia
neautorizată la serviciile IT. În acest scop, echipamentele informatice şi informaţiile pe care
acestea le conţin şi le controlează trebuie protejate de utilizatori neautorizaţi. Ele trebuie
protejate şi de deteriorarea produsă de mediul înconjurător, cauzată de foc, apă (fie sub
formă concretă, fie ca umiditate în exces), cutremure, incendii de pădure, alunecări de teren,
supratensiuni de curent electric sau întreruperi ale acestuia.
63
Conform Asociaţiei de Control şi Audit al Sistemelor Informatice (ISACA), a doua cauză
generatoare de erori o reprezintă dezastrele naturale (prima fiind eroarea de utilizator, a treia
fiind frauda, iar a patra - defecţiunea hardware).
Există două moduri de a restricţiona accesul la sistemele informatice, accesul fizic şi accesul
logic. Acest capitol examinează accesul fizic şi măsurile de protecţie pentru a proteja fizic un
sistem informatic. Accesul logic este analizat în capitolul 10.4.
10.3.2.1. Fizice
• daune accidentale sau intenţionate produse de către personal:
o angajaţi IT;
o personal de curăţenie, agenţi de pază;
o alţi angajaţi.
• furtul de calculatoare sau componente individuale ale acestora (furtul de
calculatoare este în creştere şi este probabil să continue. Luaţi în considerare
faptul că, bucată cu bucată, cipurile de calculator valorează mai mult decât aurul
şi sunt foarte atractive pentru hoţi);
• pana de curent sau supratensiunea, care poate cauza deteriorarea componentelor
şi pierderea sau deteriorarea datelor;
• evitarea controalelor de acces logic: de ex., accesul fizic la un server de fişiere
poate fi exploatat pentru a ocoli controalele logice, cum ar fi parolele; şi
• copierea sau vizualizarea de informaţii sensibile sau confidenţiale, de ex.,
politicile de stabilire a preţurilor, rezultatele înaintea publicării, politicile
guvernamentale.
10.3.2.2. De mediu
• daune produse de incendiu / apă (sau daune produse de alte dezastre naturale);
• energie electrică: întreruperi, ceea ce duce la pierderea datelor din memoria
volatilă (RAM);
o Pene: duc la căderi de sistem, erori de prelucrare;
• deteriorarea echipamentului din cauza temperaturii sau umidităţii extreme (sau
doar cu câteva grade în afara valorilor normale);
• explozia cauzată de bombe. Terorismul pare a fi în creştere în întreaga lume.
Centrele informatice par a fi uşor de atacat, iar distrugerea lor ar putea avea
repercusiuni semnificative asupra guvernului;
• electricitatea statică: poate deteriora componentele electrice sensibile fixate în
calculator (ROM, RAM şi procesorul). Acestea pot fi uşor deteriorate de şocuri de
electricitate statică;
• altele: de ex. trăsnet.
De asemenea, unele dintre aceste riscuri sunt tratate mai profund în capitolul despre
planificarea continuităţii afacerii. {în Capitolul 10.5}.
Punerea în aplicare a unor controale poate fi costisitoare şi ar fi justificată doar într-un mediu
cu grad ridicat de risc. Alte controale pot fi considerate a fi de bază, de ex. încuietorile uşilor,
şi vor fi găsite la majoritatea clienţilor. Politica de securitate IT a clientului ar trebuie să ia în
considerare a riscurilor fizice şi de mediu.
Măsurile de combatere, sau controalele pe care clientul le introduce, vor varia de la un client
la altul. De exemplu, un departament guvernamental mare, având propriul său centru de
date, va avea de obicei un grad mai mare de control asupra echipamentelor sale de IT, decât
o organizaţie mică care utilizează sisteme informatice de birou, cum ar fi procesare de text
şi foi de calcul.
Accesul la locul şi zonele sigure ale clientului trebuie controlat prin straturi de controale,
începând de la gardul perimetrului şi acţionând prin intrarea în clădire, până la sala cu
calculatoare şi terminale. Controalele fizice pot fi explicite, cum ar fi un sistem de blocare a
uşii; sau implicite, de exemplu, fişa postului unui angajat implică necesitatea de a intra în
zona de operaţiuni IT.
• Încuierea uşilor - încuietorile fizice de la uşi necesită unul din două lucruri pentru
a avea acces. Ceea ce cineva are, sau ceea ce cineva ştie. Indiferent de metoda
utilizată, "cheia" pentru fiecare tip de încuietoare trebuie bine controlată, de
exemplu, cui trebuie să i se dea o cheie sau cui trebuie să i se spună combinaţia de
taste. Încuietorile frecvent întâlnite includ:
o chei mecanice: cheia de la uşă trebuie marcată "a nu se reproduce", iar cheile
nu trebuie să indice numărul biroului la care permit accesul;
o încuietori cu combinaţie sau cu cifru: acestea sunt în general tastaturi cu
butoane numerotate. Personalului autorizat i se dă combinaţia pentru a avea
acces. Combinaţiile variază între 3-6 numere şi trebuie schimbate în mod
regulat, sau atunci când un membru al personalului IT pleacă sau se mută în
altă parte a organizaţiei;
o încuietori electronice: Acestea utilizează în general carduri de plastic cu o
bandă magnetică pe partea din spate. Banda magnetică este folosită pentru a
reţine un cod special, care este citit de un cititor de carduri. În cazul în care
codul este corect, mecanismul de închidere se pune în funcţiune şi permite
intrarea.
Încuietorile electronice oferă avantaje faţă de încuietorile manuale, deoarece acestea:
pot fi setate pentru a identifica persoanele şi a înregistra mişcările lor;
restricţionează accesul la anumite zone ale organizaţiei în funcţie de
necesitatea utilizatorului (sau ora din zi);
pot fi dificil de reprodus, mai ales dacă sunt de tip Smart Card cu un
microcip încorporat;
pot fi uşor de controlat de la o consolă centrală, de ex. în cazul în care
un angajat pleacă, e nevoie de doar câteva secunde pentru a anula
dreptul de acces al acelui utilizator; şi
pot fi conectate la sistemele de alarmă silenţioasă, care activează într-
o cameră de control atunci când se încearcă accesul persoanelor
neautorizate.
o încuietori biometrice: aceste încuietori sunt programate să recunoască
caracteristicile biometrice ale utilizatorilor autorizaţi. Caracteristicile
biometrice care pot fi utilizate includ amprenta palmei, modelul vocii,
amprentele digitale, scanarea retinei sau o semnătură. Sistemele biometrice
tind să fie mai scumpe si sunt de obicei utilizate numai în unităţile informatice
foarte sensibile.
66
• agenţi de securitate: agenţii de securitate pot fi dispuşi la intrările în sediul
clientului. Ei pot fi folosiţi pentru a verifica identitatea tuturor celor care intră în
sediu. De asemenea, pot fi utilizaţi pentru a efectua patrule în afara orelor de
lucru;
• controlul angajaţilor în afara programului: pentru cei mai mulţi clienţi aceasta
include personalul de întreţinere, agenţii de securitate şi sub-contractanţii. Nu
este neobişnuit să găsim că clienţii au un control puternic asupra mişcărilor
personalului, dar un control slab asupra furnizorilor de servicii în afara
programului de lucru. De exemplu, un agent de securitate poate avea acces la cele
mai multe părţi ale sediului clientului şi, de asemenea, poate să vină şi să iasă în
afara programului de lucru, fără a fi supus procedurilor normale de securitate. Au
fost multe cazuri în care personalul de serviciu nu erau doar personal de serviciu,
ci aveau o altă ordine de zi (de ex. de a culege informaţii pentru presă, spionaj,
furt);
• uşi securizate: uşile securizate pot fi găsite la intrările în zone sensibile, cum ar
fi sala cu calculatoare. Ele constau din două uşi, dintre care numai una poate fi
deschisă în orice moment. Ele sunt utile în a împiedica persoanele neautorizate să
urmeze o persoană autorizată în incintă, adică ajută la prevenirea “luării în
spinare”. Alte controale similare cu uşile securizate sunt uşile rotative şi tuburile
pentru o persoană;
În cazul în care a fost identificat un risc ridicat de furt de calculatoare sau vandalism, există
mai multe controale pe care clientul le poate lua în considerare;
• apă inteligentă: aceasta constă din apă cu o semnătură chimică unică. Atunci
când sediul clientului este forţat, se activează un sistem de detectare a intruşilor
care pulverizează apă "inteligentă" prin duzele de la nivelul plafonului. Toate
persoanele (hoţi, etc.) şi echipamentele care vin în contact cu apa pot fi apoi
urmărite până la locul infracţiunii;
67
• "ecrane de ceaţă": aceste dispozitive se activează atunci când este detectat un
intrus şi pulverizează aburi în cameră, care creează o ceaţă deasă. Acest lucru
reduce vizibilitatea, în măsura în care este foarte dificil pentru un infractor să vadă
ceea ce face.
Aceste sisteme sunt proiectate pentru a preveni izbucnirea unui incendiu în primul rând, şi
în cazul când un incendiu se produce, asigură stingerea acestuia într-un mod eficient.
Din moment ce curgerea apei se face sub influenţa gravitaţiei, riscul de deteriorare din cauza
apei poate fi redus prin amplasarea echipamentelor informatice la o înălţime mai mare,
adică nu în subsol. Este normal ca instalaţiile informatice să fie situate la etajele trei-şase
ale clădirilor.
Detectoarele de apă trebuie amplasate sub pardoseli supraînălţate. Ele trebuie conectate
la alarme vizuale şi auditive.
Chiar şi în cazul în care instalaţiile informatice sunt situate deasupra nivelului solului, poate
încă exista un risc de deteriorare din cauza apei provenite din conducte sparte sau scurgere
de pe acoperişuri. Acoperişurile plate au reputaţia de a avea scurgeri.
Sistemele clientului trebuie să aibă introduse controale, pentru a reduce la minimum efectul
unei întreruperi de energie electrică sau abateri în furnizare (vârfuri sau căderi de tensiune).
Acest lucru este realizat în mod normal prin instalarea de:
Cerinţele UPS pot varia în funcţie de nevoile locale, de ex. frecvenţa şi durata întreruperilor
de energie electrică.
69
• cablare alternativă de energie electrică: în unele cazuri clienţii pot simţi nevoia
de a-şi conecta instalaţiile informatice la două staţii de energie electrică, în
speranţa că o întrerupere la o sursă de alimentare nu o va afecta pe cealaltă.
Întreţinerea şi gospodărirea
Clientul poate avea controale care să asigure că sistemele de calculatoare şi zonele în care
acestea se află sunt curate şi fără resturi (deşeuri de hârtie, praf, fum, etc.).
10.4.1. Introducere
Zilele, când informaţiile erau scrise pe hârtie şi depozitate în dulapuri cu dosare,au rămas în
mare măsură în trecutul îndepărtat şi neclar. Astăzi, majoritatea sistemelor financiare
întâlnite de către auditori vor fi informatizate.
Sistemele informatice sunt de aşa natură încât să nu poată fi uşor controlate prin controale
cu acces fizic, cum ar fi dulapuri închise. Acest lucru este adevărat îndeosebi atunci când
calculatoarele unui client sunt conectate la reţele locale sau extinse.
Spre exemplu
Un sistem financiar este conectat la o reţea extinsă utilizând linii de comunicare telefonică,
cum ar fi modemurile dial-up. Încuietorile de la uşi, alarmele, agenţii de pază, etc., nu vor fi
capabile să oprească pe cineva să acceseze sistemul informatic prin reţea. Este necesară o
altă metodă de protecţie a sistemelor şi a datelor pe care acestea le procesează. Aici intră în
joc controalele de acces logic.
70
“un sistem de măsuri şi proceduri, atât în cadrul unei organizaţii cât şi în programele
informatice, care vizează protejarea resurselor informatice (date, programe şi terminale)
împotriva tentativelor de acces neautorizat.”
Acest lucru implică în mod normal un utilizator care se identifică la calculator cu un nume
de utilizator sau ID de înregistrare, etc.
Calculatorul necesită confirmarea faptului că utilizatorul este cine spune că este. Acest lucru
este realizat prin ceva ce utilizatorul are sau ştie. Parolele sunt o formă obişnuită de
autentificare. Alte forme de autentificare includ codurile PIN (utilizate pentru autentificare
după introducerea cardului bancar într-un bancomat), o semnătură sau elementele
biometrice integrate, cum ar fi amprenta mâinii.
Auditorul trebuie să aibă în vedere faptul că unele sisteme de operare şi opţiunile de control
al accesului logic asociate, parametri de fişiere, etc. au natură foarte tehnică. În cazul în care
sistemele clientului sunt complexe din punct de vedere tehnic şi auditorul nu are cunoştinţe
privind sistemele specifice ale clientului, auditorul IT poate avea nevoie de suport şi
asistenţă suplimentară de la un auditor IT cu competenţele şi experienţa necesară.
Este puţin probabil ca un auditor IT extern să aibă o cunoaştere aprofundată despre mai mult
de câteva sisteme (de ex. cele mai întâlnite sisteme de operare, cum ar fi Unix, Novell şi
Windows NT).
Posibilul impact al unei încălcări într-un control de acces logic este mai mare în cazul în care
calculatoarele sunt folosite pentru a iniţia, precum şi a înregistra tranzacţiile. În sistemele
manuale, personalul din finanţe era atent în folosirea cecurilor şi altor documente financiare.
În cazul în care un client are un sistem computerizat, se aplică aceleaşi principii iar clientul
trebuie să aibă controale pentru a împiedica persoanele neautorizate să obţină acces la
71
înregistrările şi documentele electronice financiare (de ex. un fişier de plată electronică,
înainte de transmiterea acestuia la bancă).
În cazul în care sistemele clientului sunt conectate la o reţea extinsă, cum ar fi Internetul,
atunci riscurile sunt chiar mai mari. Caracterul înregistrărilor electronice este de aşa natură
încât nu poate fi evident faptul că cineva a făcut o modificare neautorizată.
Acest lucru ar trebui să aducă în atenţie importanţa controalelor de acces logic pentru a
asigura integritatea, disponibilitatea şi confidenţialitatea sistemelor financiare ale clientului.
10.4.1.2. Atacatorii
Sistemele informatice pot fi atacate din mai multe direcţii. Atacatorul care ne vine primul în
minte este hacker-ul informatic.
Hackerii sunt în general persoane extrem de pregătite în domeniul informatic, care încearcă
să obţină acces la un sistem, din simplu motiv, pentru a dovedi că pot. Ei privesc această
acţiune ca pe o provocare personală. Cu toate că intenţia lor principală este doar accesul, pot
provoca din greşeală daune sistemelor sau datelor.
Angajaţi: aceştia pot fi personal din departamentul IT sau utilizatorii normali de sistem.
Auditorul trebuie să ia notă de controalele asupra personalului temporar şi personalului
angajat pe jumătate de normă.
Foştii angajaţi: foştii angajaţi, în special cei cu resentimente, pot încerca să acceseze
sistemul pentru a manifesta o anumită formă de răzbunare.
Părţi externe: pot include concurenţi, puteri străine (spionaj), crima organizată.
Furnizori şi consultanţi: Sunt adesea persoane care au introdus un sistem sau cei care îl
întreţin.
Pierderi financiare: Pierderile pot fi pierderi directe ca urmare a fraudei, sau pierderi
indirecte, care rezultă din costul de modificare a sistemului şi de corectare a datelor.
Obligaţiile legale: Clientul poate avea anumite obligaţii legale privind stocarea şi divulgarea
datelor, de ex. în cazul în care există o legislaţie care solicită clientului să păstreze
confidenţialitatea cu privire la orice date cu caracter personal. Într-un mediu bancar, o
pierdere de integritate ar putea duce la încălcarea reglementărilor bancare şi la măsuri
disciplinare.
Pierderea cotei de piaţă şi / sau credibilităţii: Acest lucru este important în special în
sectorul serviciilor financiare, de ex. bănci şi societăţi de investiţii şi titluri de valoare. O
breşă de securitate poate duce la o pierdere de credibilitate şi, eventual, la o pierdere în
afaceri.
72
Întreruperi ale activităţilor întreprinderii: de exemplu, în cazul în care un hacker a avut
acces la un sistem informatic şi a schimbat toate dimensiunile produsului într-un sistem
industrial de fabricaţie.
10.4.2.2. Aplicaţii
Accesul nerestricţionat creşte riscul ca aplicaţiile financiare să fie supuse unor modificări
neautorizate care duc la fraudă, pierderi şi denaturări de date. Accesul neautorizat la codul
sursă al unei aplicaţii ar putea fi folosit pentru a face modificări în logica de programare, de
ex. rotunjirea plăţilor către cea mai apropiată unitate (bănuţi, cenţi, etc.) şi introducerea
fracţiunii rotunjite în contul de rambursare a cheltuielilor programatorului.
Chiar şi în cazul în care datele de identificare şi parola unui utilizator normal sunt obţinute,
principiul prin care utilizatorii sunt traşi la răspundere pentru acţiunile lor este ocolit.
Utilizatorul neautorizat ar putea folosi identificarea "furată" pentru a aduce modificări care
nu pot fi urmărite până la agresor.
73
10.4.2.5. Fişiere jurnal
Fişierele jurnal sunt utilizate pentru a înregistra acţiunile utilizatorilor şi, prin urmare, oferă
administratorilor de sistem şi conducerii clientului o formă de responsabilitate. Un jurnal de
sistem poate înregistra cine s-a autentificat în sistem şi ce aplicaţii, fişiere de date sau
instrumente a folosit în acest timp. Un jurnal de aplicaţie poate fi folosit pentru a înregistra
modificări aduse datelor financiare (cine ce date a schimbat, de la ce la ce, şi când). Dacă
fişierele jurnal sunt insuficient protejate, un hacker, o persoană necinstită, etc. le-ar putea
şterge sau edita pentru a-şi ascunde acţiunile.
Politicile de securitate ale companiei sunt în mod normal documente relativ scurte. Ele pot
să conţină:
• definiţii: de ex. ce se înţelege prin securitate şi în mod special termenii de
confidenţialitate, integritate şi disponibilitate;
• declaraţii de securitate de ex.
o fiecare sistem şi fişierele conexe trebuie să aibă un proprietar şi trebuie să fie
clasificate în funcţie de importanţa confidenţialităţii, integrităţii şi
disponibilităţii;
o accesul la informaţiile conţinute în sisteme va fi acordat numai pe baza
necesităţii de a le cunoaşte. Necesitatea de cunoaştere va depinde de funcţia
(rolurile, responsabilităţile şi îndatoririle) fiecărui utilizator de sistem şi
funcţia sistemului informatic; şi
o nivelul de protecţie va fi proporţional cu nivelul de risc şi valoarea activului;
• responsabilităţi: trebui să fie definite responsabilităţile tuturor utilizatorilor.
Acest lucru se face în mod normal prin gruparea utilizatorilor în "utilizatori
normali", proprietarul sistemului, managementul de securitate şi auditul
sistemelor informatice / IT.
Detaliile controalelor de acces logic se vor baza pe declaraţiile la nivel înalt din cadrul
politicii corporative de securitate IT.
74
10.4.4. Sistemul de operare şi controalele de acces la aplicaţii
Controalele de acces logic pot exista de obicei, în sistemele financiare, pe două niveluri,
nivelul de instalare şi nivelul aplicaţiei. Prin urmare, controalele de acces pot fi incluse în:
• sistemul de operare (sau instrumente încorporate) şi/ sau
• fiecare aplicaţie.
Controalele de acces logic la fiecare nivel sunt în mod normal controlate de către diferiţi
administratori. Cineva din unitatea IT va fi responsabil pentru persoanele care se pot conecta
în reţea şi, odată ce acestea sunt conectate, pentru aplicaţiile şi fişierele de date la care pot
avea acces. Această persoană controlează accesul la nivel de instalare.
• numele organizaţiei trebuie afişat doar după ce utilizatorul s-a conectat cu succes.
Aceasta limitează indiciile pe care sistemul le poate da unui utilizator neautorizat.
De exemplu, în cazul în care o organizaţie naţională de cercetare spaţială a afişat
un mesaj de conectare cu numele organizaţiei, un utilizator neautorizat ar avea un
indiciu atunci când încearcă să ghicească parolele. Acesta ar încerca parole
precum nebuloasă, quasar, solar, etc.;
• conectarea nu trebuie să ureze "bun venit" nimănui. Există un caz celebru prin
care un hacker a avut acces la un sistem informatic care avea un ecran de bun
venit. Hacker-ul a scăpat de urmărirea penală, deoarece ecranul de bun venit
a fost considerat a fi o invitaţie la încercarea de a accesa sistemul;
După ce utilizatorii s-au conectat cu succes, sistemul poate fi capabil să afişeze ora şi data
ultimei conectări a utilizatorului, precum şi detalii cu privire la orice încercări nereuşite de
conectare. Acest lucru ar trebui să aducă la cunoştinţa utilizatorului orice tentative de acces.
De exemplu, dacă un utilizator se conectează la sistem dimineaţa şi apare un mesaj care
arată ultima autentificare la 04.30 a.m., el va şti că ceva nu este în regulă.
76
10.4.5.3. Identificarea şi autentificarea utilizatorului
Identificarea utilizatorului este realizată în mod normal de către utilizatori, prin
introducerea unui identificator de conectare. Clientul trebuie să aibă o politică pentru
compunerea codurilor de identificare la conectare, de exemplu primele trei litere din numele
de familie ale utilizatorilor, iniţiala prenumelui şi un număr din două cifre.
Oricare ar fi politica pe care clientul decide să o adopte, aceasta trebuie să asigure că ID-urile
de conectare ale fiecărui utilizator sunt unice. Unicitatea este importantă, deoarece permite
identificarea fiecărei persoane. Aceasta, la rândul său, susţine responsabilitatea, în special în
cazul în care ID-urile autentificate de conectare ale utilizatorilor sunt înregistrate faţă de
activităţile pe care aceştia le exercită asupra sistemului.
Alte sisteme pot utiliza un simbol ca formă de identificare, de ex. un card cu o bandă
magnetică pe partea din spate.
10.4.5.4. Autentificarea
După ce un utilizator s-a identificat în sistemul informatic, calculatorul trebuie să confirme
faptul că această persoană este cine se pretinde a fi. Acest lucru este cunoscut sub numele de
autentificare.
Autentificarea se realizează de către utilizator prin a şti ceva, a poseda ceva sau dintr-o
comparaţie a caracteristicilor fizice. Factorii de autentificare pot fi în general clasificaţi în
trei categorii:
• Ceva caracteristic utilizatorului (de ex. amprenta digitală, structura retinei,
structura vocii, recunoaşterea semnăturii, etc.)
• Ceva ce utilizatorul posedă (de ex. buletin de identitate, simbol de securitate,
simbol software sau telefon mobil)
• Ceva ce utilizatorul ştie (de ex. parola, sintagma de control sau codul PIN)
10.4.5.4.1. Parole
• istoricul parolei: unele sisteme de parole ţin o evidenţă a ultimelor câteva parole
şi împiedică utilizatorul să reutilizeze una veche. Acest lucru îi împiedică pe
utilizatori să reactiveze câteva dintre parolele lor favorite;
Unele sisteme aplică un algoritm pentru parola utilizatorului şi stochează rezultatul într-un
fişier de parole. Când acest utilizator se conectează, parola pe care o introduce este criptată
folosind aceleaşi algoritm şi comparată cu parola criptată din fişierul de parole. În cazul în
care acestea se potrivesc, accesul este permis.
Alte sisteme stochează parolele criptate într-un fişier ascuns, care nu poate fi văzut de către
utilizatori. Acest lucru împiedică hackerii să obţină copii ale fişierelor de parole criptate şi
rularea de programe de tip "crack" pe acestea. Crack este un program Unix care criptează
cuvintele şi le compară cu parolele criptate. În cazul în care se obţin concordanţe, se va şti
care este parola:
78
acesta să fie ultimul care ştie că un membru al personalului a fost sancţionat, dar
cazurile când “nimeni nu ne-a spus să-i eliminăm autentificarea!" ar trebui să fie
evitate;
• parole implicite şi pentru furnizori: atunci când sunt instalate noi sisteme, în
mod normal acestea au conturi de utilizator stabilite pentru inginerii care le
instalează, furnizori şi consultanţi. Aceste conturi au în mod normal niveluri
ridicate de acces şi privilegiu. Ele trebuie să fie strict controlate, şi dezactivate
dacă este necesar. De exemplu, pachete de contabilitate pot avea un cont de
utilizator standard, pentru a permite testarea sistemului. Acest cont poate avea
ID-ul "test", precum şi o parolă asociată "test";
Nivelul 1 - Acesta oferă asigurarea că acelaşi solicitant accesează datele protejate ale
tranzacţiei. Nu necesită "demonstrarea identităţii", nici nu sunt necesare metode
criptografice. Deoarece parole necriptate sau secrete nu sunt transmise printr-o reţea de
nivelul 1, sunt permise protocoalele simple de parole chemare-răspuns.
Nivelul 2 - Acesta oferă autentificare de la distanţă într-o reţea printr-un singur factor cu
solicitarea verificării identităţii. Autentificarea cu succes impune ca solicitantul să
demonstreze, printr-un protocol de autentificare sigur, că el controlează simbolul de
autentificare.
Nivelul 3 - Acesta oferă autentificare de la distanţă într-o reţea, prin mai mulţi factori, cu un
minim de doi factori de autentificare, precum şi proba implicită de posesie a unei chei sau
unei parole de un singur uz, printr-un protocol criptografic. Autentificarea cu succes
presupune ca solicitantul să demonstreze printr-un protocol securizat de autentificare că el
controlează simbolul, şi trebuie mai întâi să deblocheze simbolul printr-o parolă sau date
biometrice, sau trebuie să utilizeze şi o parolă în protocolul de autentificare securizat, pentru
a stabili o autentificare cu doi factori.
Nivelul 4 - Acesta oferă cea mai înaltă asigurare practică de autentificare de la distanţă în
reţea şi este similar cu nivelul 3, cu excepţia faptului că doar simbolurile criptografice "grele"
sunt permise.
79
10.4.5.5. Protecţia resurselor
A avea acces la un calculator şi a fi capabil de conectare nu implică faptul că un utilizator
poate avea acces nelimitat la toate aplicaţiile şi fişierele de date. Un nivel suplimentar de
control este necesar pentru a restricţiona utilizatorii numai la acele aplicaţii, fişiere de date
sau resurse de sistem (de ex. imprimante pentru facturi, imprimante pentru cecuri, unităţi
cu bandă pentru copiere), pentru care le-a fost acordate acces specific.
Administratorul de sistem poate seta sistemul astfel încât operatorul de vânzări are acces
doar la sistemul de vânzări, celelalte opţiuni de meniu, cum ar fi procesarea comenzilor de
achiziţii, de gestionare a stocurilor şi de personal ar fi "colorate în gri" şi, prin urmare,
indisponibile.
• autorizarea de a utiliza funcţii specifice (de ex. utilite (tools), elemente de meniu
şi programele lor de bază, etc.);
Limite privind orele de muncă: unele sisteme de operare (de ex. Novell şi Windows NT),
pot restricţiona accesul utilizatorului la perioade de timp predefinite. De ex., în cazul în care
conducerea a crezut că nici un membru al departamentului financiar nu va avea nevoie de
acces la sistem în timpul nopţii (de ex. de la 9 seara la 6 dimineaţa), sistemul ar putea fi
configurat astfel încât aceştia să nu se poată conecta pe timpul acestor ore specificate.
Jurnalele trebuie protejate pentru a asigura că acestea nu pot fi supra-scrise sau şterse de
către cineva care încearcă să-şi acopere urmele.
În cazul în care o cantitate mare de date este înscrisă într-un fişier jurnal, clientul poate folosi
instrumente de selecţie a raportării, care scanează fişierele jurnal şi evidenţiază acele
evenimente care necesită o atenţie suplimentară.
Al doilea tip de jurnal, jurnalul de tranzacţii este utilizat pentru a înregistra derularea
tranzacţiilor, pe măsură ce acestea sunt prelucrate de către sistem.
82
10.5. Planul de Continuitate în Afaceri şi Planul de Recuperare în caz de Dezastru
83
• evalueze dispozitivele de stocare din afara oficiului (unde se păstrează copiile de
rezervă), prin inspectarea localului şi echipamentului, dacă acestea sunt adecvate,
revizuind conţinutul, securitatea şi corespunderea controalelor fizice şi de mediu.
Poate fi constatat că chiar dacă copiile de rezervă sun efectuate regulat, ele nu au
fost testate prin recuperarea datelor sau nu a fost efectuată validarea lor,
• evalueze abilitatea organizaţiei de a reacţiona eficient în situaţii de urgenţă, prin
revizuirea procedurilor aferente, instruirea personalului şi rezultatele testării
acestora.
84
10.6. Controalele sistemelor orientate pe utilizator
Acest mediu necontrolat poate determina, şi chiar, a dus la o irosire de timp, efort şi finanţe
pentru client. De asemenea, nedirijarea sistemelor orientate pe Utilizator a determinat unele
îngrijorări din partea auditorilor, în special în cazurile în care utilizatorii finali procesau
tranzacţii financiare.
3 Utilizarea calculatoarele personale este cauza dezvoltării sistemelor orientate pe utilizator. În 1995 s-au
estimat a fi 120 mln. calculatoare compatibile PC IBM în toată lumea. Nu este departe timpul în care se va
considera normal ca toţi utilizatorii să posede un calculator personal pe masa sa de lucru. Calculatoarele
personale sunt utilizate în mare parte pentru automatizarea activităţii de birou (procesoare Word şi Excel),
interogarea bazei de date, activitatea prin email şi în grup. Acestea de asemenea sunt folosite pentru a accesa
sistemele informaţionale centrale, de ex. sistemul financiar.
4
este aplicarea ştiinţifică a unui set de instrumente şi metode la un sistem software care are menirea de a
transforma în produse de o înaltă calitate, lipsite de defecte şi uşoare de întreţinut.
85
• standardele aplicate în elaborarea sistemelor;
• documentaţia necesară;
• ce instrumente trebuie incluse în noul sistem; şi
• testarea necesară pentru a asigura că sistemul exercită sarcinile şi acţiunile pentru
care este destinat.
Sistemele orientate pe Utilizator le-au permis utilizatorilor finali să-şi elaboreze aplicaţiile
proprii fără a recurge la asistenţa unităţilor TI centrale. Utilizatorii finali elaborându-şi
sistemele proprii o fac fără a avea competenţele şi instruirea relevantă.
Atunci când sistemele sunt elaborate fără a se baza pe standarde, de către persoane fără
experienţă sau instruire, desigur, apar probleme. De regulă, acestea presupun următoarele:
• sisteme nesigure care nu procesează datele după cum se intenţionează, de ex. cadrul
logic de bază al aplicaţiilor nu a fost bine-gândit sau codificat corect;
• sisteme care nu sunt testate şi sunt imprevizibile. De exemplu, dacă sistemul nu este
testat pentru a se asigura că acesta poate opera cu intrările de date incorecte, acesta
(sistemul) poate să se oprească accidental să-şi îşi încetinească lucrul atunci când un
utilizator introduce asemenea date;
Neconcordanţele de date pot cauza probleme auditorului, dacă diferite părţi ale unei
organizaţii utilizează diferite date invariabile sau fişiere master în calculările sale, de ex.
ratele de plată pentru personalul subcontractat, sau unitatea de preţ pentru facturile de
comercializare.
87
Atunci când utilizatorii dispun de calculatoare personale la locul de muncă, există tentaţia de
a copia şi utiliza aplicaţii ilegale. Atitudinea că “nimeni nu va şti dacă utilizez această
aplicaţie” este comună printre utilizatorii.
Puţin probabil ca o organizaţie, sau chiar şi angajaţi individuali să scape de urmărire penală
recurgând la scuza că “Eu nu am ştiut ce stipulează legea, nimeni nu mi-a spus.”
O altă problemă legată de pierderile de date este creşterea cazurilor de furt de calculatoare.
Calculatoarele, şi în special calculatoarele personale de performanţă, sunt echipamente
valoroase. Valoarea lor înaltă le-a transformat în ţinta hoţilor de calculatoare. La furtul
calculatorului, în mod evident, se pierde şi toată informaţia de pe el.
Este relativ uşor de a ocoli orice instrumente de securitate utilizate de aceste sisteme de
operare. Oricare persoană cu cunoştinţe suficiente despre sistemele de operare ar fi apt să
acceseze orice fişier de date sau aplicaţie dorită.
Accesul fizic la calculatoarele-staţii de lucru este, de regulă, mai puţin controlat. Data centrul
şi staţiile de lucru de tip „terminal” sunt, de regulă, localizate într-un mediu controlat cu
acces restricţionat de uşi încuiate, blocări prin combinaţii de taste şi camere video cu circuit
închis. Acelaşi lucru este rareori real, în cazul, computerelor utilizatorilor finali. De regulă,
acestea sunt localizate pe masă într-un mediu de oficiu normal.
Dispunând de acces fizic la computator, acesta poate fi exploatat pentru a ocoli instrumentele
de acces logic simple, de ex. parolele elementare ale utilizatorului de tip Windows. Datele pot
fi păstrate de asemenea şi pe Flash-Drive care poate fi uşor copiat. De asemenea, datele pot
fi redactate sau şterse de utilizatori neautorizaţi.
5
DEFINITIE????????????????????????????????????
88
10.6.3. Viruşi de calculator
În realitate, viruşii de calculator sunt programe mici care sunt proiectate pentru a se replica
şi răspândi de la un calculator la altul anexându-se fie la un program, fişier sau sectorul de
încărcare (boot) a unui disc.
Viruşii de calculator se activează şi se copiază atunci când fişierul la care sunt ataşaţi este
operat sau atunci când calculatorul foloseşte un disc infectat. Odată activaţi, viruşii pot
rămâne activi în memoria calculatorului aşteptând să mai infecteze ceva.
Problemele asociate cu sistemele incompatibile pot fi reduse dacă clientul dispune de politici
şi proceduri pentru achiziţionarea echipamentului şi aplicaţiilor software. Politicile ar putea
include, de asemenea, proceduri pentru realizarea procurărilor de bunuri şi înregistrare a
locaţiei bunurilor într-un jurnal.
89
10.6.4.2. Dublarea efortului
Utilizatorii vor dispune obligatoriu de un mecanism prin care aceştia ar avea posibilitatea de
a comunica eforturile sale celorlalţi angajaţi din organizaţie. Acest fapt poate fi realizat prin
organizarea unor şedinţe/întruniri regulate între nivelul mediu şi inferior de management.
Dezvoltările locale în sistemele TI ar putea fi una din subiectele de discuţie din agenda
şedinţei.
În situaţiile în care utilizatorii au acces la informaţia dintr-o bază de date centrală, este
necesar de a stabili permise de acces astfel încât doar persoanele autorizate să poată
actualiza datele centrale.
10.6.4.4. Legislaţia
Clientul va stabili obligatoriu politici pentru a asigura ca utilizatorii finali o să cunoască şi
acţioneze în conformitate cu legislaţia în vigoare. Programul de sensibilizare ar putea
acoperi următoarele:
• furtul de aplicaţii soft: ceea ce înseamnă, copierea neautorizată a unei software sau a
datelor organizaţiei pentru utilizare în scopuri de profit sau cu caracter personal;
• respectarea legislaţiei cu privire la securitatea la locul de lucru;
• utilizarea aplicaţiilor soft piratate şi ilegale; şi
• colectarea, utilizarea şi stocarea informaţiei cu caracter personal.
• stocarea datelor pe un server de fişiere în loc de a o păstra pe discul local sau pe flash-
drive. Serverele vor fi, de regulă, administrate de către unitatea TI şi vor fi stabilite
obligatoriu proceduri de efectuare regulată a copiilor de rezervă pentru date.
90
10.6.4.6. Acces logic şi fizic
Utilizatorii vor fi obligatoriu încurajaţi să adopte cel puţin măsurile de precauţie de bază
pentru asigurarea securităţii accesului logic pe calculatorul individual, de exemplu, stabilirea
unei parole pe BIOS.
Dacă este posibil, datele se vor stoca pe un server de reţea. În general, sistemele de operare
de reţea vor asigura gradul necesar de protecţie împotriva accesului neautorizat prin
intermediul reţelei.
În cazul în care utilizatorul foloseşte calculator portabil, este necesar de a stabili politici care
ar stipula păstrarea lor în mediu securizat în timpul nopţii, de ex. într-un sertar sau dulap
încuiat cu lacăt.
În cazul în care clientul consideră că riscul este mare, este necesar de a lua în considerare
opţiunea de instalare a aplicaţiilor soft de securizare pe calculatoarele utilizatorilor finali.
Acestea vor avea obligatoriu controale de acces logic mai robuste şi ar putea cripta datele
vulnerabile de importanţă înaltă.
Asistenţa pentru utilizatorii finali este furnizată, de regulă, prin intermediul unei funcţii de
suport tehnic (help-desk). Serviciul de suport tehnic activează în calitate de interfaţă între
specialiştii din unitatea TI şi utilizatorii finali. Cererea de suport a utilizatorului va fi atribuită
specialistului TI cu competenţe şi cunoştinţe corespunzătoare în problema dată.
91
10.7. Controlul schimbărilor
Amploarea schimbărilor poate varia considerabil, de la ajustarea orei dintr-un sistem intern,
până la instalarea unei noi versiuni a aplicaţiei sau sistemului de operare. Efectul unei
schimbări asupra funcţionării sistemului poate fi de proporţii diferite cu mărimea sau nivelul
modificării efectuate.
92
• Actualizarea de rutină: dezvoltatorii sistemului pot actualiza sau îmbunătăţi
aplicaţiile de sistem. Astfel de cazuri pot necesita schimbări în caz dacă furnizorul
insistă asupra necesităţii trecerii la versiuni noi.
• Modificări în cerinţe: schimbări ale legislaţiei, în cerinţele sau direcţiile de activitate,
pot rezulta în necesităţi de schimbări semnificative ale sistemelor.
93
Trebuie să existe proceduri de înregistrare a tuturor cererilor de schimbare (RFC), de
preferinţă într-un format standard şi / sau cu şabloane de prezentare. Cererile de modificare
ar trebui să fie autentificate şi să primească un număr unic de referinţă cronologică. Pentru
fiecare RFC-uri ar trebui să fie alocat un indice de prioritate pentru a indica urgenţa cu care
schimbarea ar trebui să fie luată în considerare sau operată. Sarcina atribuirii priorităţilor,
în mod normal, este prerogativa, unei comisii de gestionare a controlului schimbărilor din
cadrul comitetului coordonator al TI (dacă există astfel de structuri). Analizele şi deciziile
comisiei şi comitetului se fac cunoscute prin intermediul unei persoane, responsabile de
managementul schimbărilor.
Priorităţile modificărilor sunt determinate, reieşind din evaluarea costurilor şi
beneficiilor.
În esenţă, utilizatorii ordinari trebuie să se asigure că ştiu cum să utilizeze părţile sistemului
pentru care sunt autorizaţi. Aceştia cunosc foarte puţin despre responsabilităţile de
administrare a sistemului.
95
Acest capitol descrie controalele aplicate, fie manual de utilizatorii aplicaţiei, fie automatizat
de sistemul informatic tranzacţiilor în cadrul unui sistem iformaţional.
Obiectivul de bază al unui sistem de control al oricărui sistem contabil este de a asigura
plenitudinea, acurateţea şi credibilitatea înregistrărilor contabile. Este necesar de reţinut
faptul că obiectivele controlului vor fi identice pentru toate sistemele contabile, de la
operaţiunile manuale simple la sistemele complexe de baze de date în timp real (complex
real-time database systems). Totodată, metodele de realizare a gradului de control vizat va
varia conform circumstanţelor individuale.
Indiferent dacă sistemul financiar este manual sau în baza unui sistem informatic, validitatea
înregistrărilor/intrărilor este asigurată cel mai bine prin metoda autorizaţiei.
Auditorul va acorda credibilitate mai mare autorizării ieşirii(output) dintr-un sistem decât
autorizării intrării(input), deoarece aceasta înseamnă mai curând autorizarea a ceea ce de
fapt a fost procesat decât autorizarea a ceea ce urmează a fi procesat.
Actele financiare sunt produsul unui sistem contabil şi obiectivele principale de control sunt
realizate dacă există proceduri de realizare a controlului plenitudinii şi acurateţei:
96
• toate tranzacţiile sunt introduse cu acurateţe;
• toate tranzacţiile sunt introduse;
• toate tranzacţiile sunt valide;
• toate tranzacţiile au fost autorizate;
• toate tranzacţiile au fost introduse în perioada contabilă corespunzătoare; şi
• toate tranzacţiile au fost înregistrate conform clasificaţiei.
Autorizarea tranzacţiilor de valoare redusă, de rutină uneori poate lua forma unei autorizări
invariabile, de ex. funcţionarul pe vânzări poate avea autorizare invariabilă (permanentă)
pentru introducerea tranzacţiilor ce ţin de cheltuielile de regie precum cheltuielile de
electricitate şi telefon până la o limită prestabilită.
Examinarea gestiunii este un alt control pe care clientul l-ar putea utiliza la verificarea
faptului dacă tranzacţia a fost autorizată. Sistemul ar putea afişa lista tuturor tranzacţiilor
(pe suport de hârtie(imprimat) sau pe monitor). Managerul sau supraveghetorul ar putea
verifica lista şi selecta un eşantion de tranzacţii pentru verificarea corectitudinii autorizării
acestora.
• crearea unei acţiuni de rutină sau presupuneri de intrări de date. De ex. dacă
personalul responsabil de intrarea datelor presupune recepţionarea
documentelor de intrare de la toate 10 departamente vinerea şi ei au recepţionat
doar 9 seturi, ei ar urmări/cerceta setul de documente de intrare ce lipseşte.
98
Un lot este o colecţie de documente de intrare care sunt tratate ca un grup. Existenţa loturilor
este utilă la stabilirea controalelor pentru a asigura plenitudinea intrării datelor în sistem.
Totalul tranzacţiilor individuale va corespunde totalului calculat manual înregistrat pentru
intrare pe documentul titlu al lotului.
Sistemul pe loturi solicită ca tranzacţiile să fie introduse pe loturi. Dacă un lot este necomplet,
de exemplu dacă se anulează o tranzacţie, sistemul ar refuza lotul de date pentru intrare
deoarece totalul lotului calculat de calculator nu va corespunde cu totalul calculat de
persoana care a pregătit lotul şi a completat titlul lotului.
Totalul lotului (Batch totals) va fi obligatoriu înregistrat la cel mai primar punct posibil în
ciclul de procesare şi totalurile din rapoartele de actualizare vor fi acordate conform acestei
înregistrări iniţiale, ceea ce înseamnă că primul total de lot serveşte drept referinţă pentru
verificarea inversă a tranzacţiilor în ciclul său de procesare în sistem.
Este necesar de a exercita un control de către utilizatori pentru a asigura ca toate loturile să
fie procesare, precum şi pentru a asigura acceptarea valorii corecte pentru fiecare lot. Prin
urmare, este esenţial de a menţine un jurnal complet al tuturor loturilor expediate pentru
procesare. Acesta, de regulă, este un act de înregistrări completat de operatori şi verificat şi
semnat de supraveghetor.
La pregătirea loturilor şi expedierea lor pentru introducerea datelor, acestea sunt însoţite de
un document–titlu de lot (batch header document). De regulă, titlul lotului va conţine
informaţia următoare:
• numărul lotului şi data;
• totalul controlului de lot;
• totalurile documentului.
Acurateţea datelor introduse în sistem poate fi controlată prin impunerea unui număr de
verificări electronice a validităţii asupra datelor prezentate sistemului.
Verificări automate a validităţii vor fi obligatoriu în număr suficient, pentru a asigura ca toate
datele acceptate în sistem vor fi acceptate de toate procesele subsecvente, inclusiv de alte
sisteme care prevăd un transfer electronic de date. Acceptarea este importantă în special
99
atunci când se utilizează sisteme de alimentare /sisteme operative (feeder system). De
exemplu, documentul de ieşire (rezultatul) unui sistem de salarizare individual ar putea
furniza date de intrare pentru un sistem financiar general.
Validarea verificărilor poate reduce riscul de prăbuşire a aplicaţiei din cauza erorilor logice
apărute la încercarea procesării datelor introduse cu valori ce nu se încadrează în limitele
pre-definite.
Există multe tipuri de controale programate pentru aplicaţii cu care se poate confrunta un
auditor TI. De exemplu, controlul formatului, controlul validităţii, controlul şirului/seriei,
controlul limitelor, caractere de control, controlul compatibilităţii, etc.
Controlul formatului
Controlul formatului este exercitat pentru a asigura ca datele introduse sunt conforme unui
format pre-definit. De exemplu, un anumit câmp acceptă o combinaţie specifică de caractere
alfanumerice. Controlul formatului este aplicat deseori în câmpurile de tipul următor:
Sumă: unde se acceptă doar caracterele numerice, de ex. preţul bunurilor sau serviciilor, sau
numărul de ore lucrate de către angajaţi.
Dată: unde data obligatoriu va fi în ordinea ZZ/LL/AA opus ordinii LL/ZZ/AA. Formatul
datei poate fi important deoarece acesta poate fi utilizat pentru a determina valoarea
datoriilor din conturi la sfârşit de an. De exemplu, 11/12/96 înseamnă 11 decembrie 1996
sau 12 noiembrie 1996. Răspunsul ar putea depinde de ţara în care a fost elaborat aplicaţia
soft.
Codurile de conturi: codul de conturi poate fi valoare numerică, de ex. 668531. Dacă un
funcţionar responsabil de introducerea datelor în departamentul de finanţe a introdus
668S31 sistemul ar defini codul contului ca ne-valid.
Controalele limitei sunt frecvent utilizate pentru prevenirea erorilor mari. De exemplu, s-ar
putea seta o limită la numărul orelor de lucru pe săptămână pentru un angajat. Dacă limita
este setată la 80 ore şi un utilizator a introdus incorect 800, sistemul ar refuza tranzacţia şi
afişa un mesaj de eroare.
Similar, se poate seta o limită pentru valoarea ordinelor de remunerare şi alte tranzacţii ce
pot fi procesate de fiecare angajat.
100
De exemplu, aplicaţiile financiare pot fi configurate să permită personalului gestiunii
financiare să înregistreze/opereze cu cheltuieli de până la £10,000, pe când personalul
superior ar putea opera cu cheltuieli între £10,000 şi £100,000.
Chiar dacă controalele limitei examinează corectitudinea datelor, acestea pot fi utilizate
pentru a asigura certitudinea că cifrele sunt rezonabile. Limitele vor fi setate astfel încât
toate datele corecte să fie acceptate şi cele eronate să fie refuzate. Clientul decide ce limite
să aplice ţinând cont de tipurile de cheltuieli.
1*7=7
2 * 5 = 10
3*1=3
4 * 7 = 28
5 * 5 = 15
Total = 63
Prin urmare, caracterul de control este 8 şi numărul introdus de către utilizatori ar fi 123458.
Unele sisteme folosesc puterea lui 2 ca serie de control, prin urmare în loc de 7, 5, 1 din
exemplul anterior, ar fi folosită seria 2, 4, 8, 16, 32.
101
utilizator în baza unui tabel de conturi pre-definit. Dacă codul de cont nu se încadrează în
tabelul de conturi, tranzacţia este refuzată.
Verificarea validităţii codurilor de conturi reduce riscul localizării eronate sau amplasarea
în final a tranzacţiilor în contul de aşteptare (ceea ce înseamnă că nu sunt incluse în balanţa
de verificare sau conturi).
Auditorul va lua în considerare faptul că în unele aplicaţii, când sistemul nu este apt să
valideze datele, în loc, acesta poate adăuga date noi în tabel. De exemplu, dacă un sistem nu
a recunoscut un cod de cont pentru o tranzacţie, sistemul ar anunţa utilizatorul despre acest
fapt afişându-i un mesaj “cod de cont neidentificat” şi apoi să întrebe utilizatorul dacă
doreşte să adauge codul de cont în tabelul de coduri de cont. Acest fapt poate cauza probleme
atunci când aceste coduri de cont noi nu sunt preluate de către sistemele de raportare. În
acest exemplu noile coduri de cont ar putea fi omise din documentele de lucru care pregătesc
balanţa de verificare şi conturile rezumate.
Verificarea/controlul compatibilităţii
Controlul compatibilităţii este utilizat atunci când există o interrelaţie ce poate fi identificată
între două seturi sau domenii de date. Relaţia dintre două domenii trebuie identificată şi
înregistrată (de regulă, într-un tabel). La introducerea seturilor de date, acestea sunt
comparate aplicând relaţia din tabel. De exemplu, dacă un utilizator introduce într-un
sistem de state, ziua de naştere, urmată de vârsta angajatului, aplicând valorile 1 aprilie 1968
urmată de vârsta 78, aplicaţia va respinge datele (vârsta corectă trebuie să fie aproximativ
28).
Pentru a aborda acest risc, unele aplicaţii ar putea depista tranzacţiile duble, de ex.
comparând tranzacţiile noi cu cele atribuite aceluiaşi cont anterior. Alte sisteme marchează
tranzacţiile cu un steguleţ după ce s-a lucrat cu ele. De exemplu, facturile în contul
furnizorului ar fi bifate odată ce se efectuează plata.
Alte sisteme pot să accepte doar un număr de tranzacţii pe un cont, unitate sau individual.
De exemplu, un sistem de înregistrare a timpului care ar permite doar o foaie de pontaj
introdusă per angajat.
102
11.4.5. Concordanţa (Matching)
Acest control verifică şi compară o înregistrare a tranzacţiei cu datele incluse în altă
tranzacţie relevantă. Atunci când datele diferă, se produce un raport de excepţie. De
exemplu, datele introduse la recepţia bunurilor şi automat comparate cu facturile
furnizorului şi datele comenzii de procurare din sistem. Când se identifică o discordanţă,
sistemul produce un raport de excepţie. Clientul va exercita unii paşi pentru identificarea
cauzei discrepanţei.
Refuzul sistemului – atunci când tranzacţiile sunt refuzate direct, clientul va stabili
obligatoriu proceduri de setare a controlului asupra acestor refuzuri şi asigura ca toate
datele refuzate să fie ulterior corectate, reintroduse şi acceptate de sistem . Regulile
sistemului vor identifica dacă este necesar de a refuza tranzacţii individuale sau loturile
integral.
Atunci când articolele sunt plasate într-un cont de aşteptare, auditorul va examina
obligatoriu procedurile de identificare, corectare şi deblocare a acestor tranzacţii.
103
11.5.1. Controalele run to run
Atunci când este posibil de a identifica un total derivat dintr-un fişier ce urmează a fi
procesat, dar care obligatoriu va rămâne intact pe parcursul şi după procesarea datelor,
concordarea acestui total ‘iniţial’ la fişierul cu datele procesate, totalul final’, este un mijloc
foarte eficient de control al plenitudinii procesării informaţiei.
Atunci când un număr de procesări sunt exercitate cu succes, ar putea fi posibil de extins
acest principiu pentru a concorda totalul derivat din datele înainte de prima procesare cu
totalul fişierului după exercitarea procesării finale. Acest fapt este posibil doar atunci când
poate fi identificată unitatea de control care va supravieţui pe parcursul tuturor procesărilor,
însă chiar şi atunci când aceasta nu este posibil, se poate realiza un control run prin utilizarea
totalului (rezultantei) pivot sau totalului (rezultantei) punctului de control.
Atunci când controalele run to run se schimbă de la un proces la altul, acest fapt poate servi
drept indicaţie de pierdere sau adăugare a datelor în timpul procesării. La identificarea
totalurilor (rezultantelor) run to run neegalate, acestea vor fi raportate obligatoriu
departamentului TI pentru a fi cercetate.
Tehnologia hash reprezintă aplicarea unor algoritmi matematici, pentru identificarea unică
a unui şir de simboluri (date sau fişiere) prin calcularea unei valori (sume de control) de
lungime fixă (diferă pentru fiecare metodă). Această procedură permite depistarea oricăror
modificări în şirul de simboluri iniţial prin contrapunerea sumelor de control obţinute.
Există numeroase metode (algoritmi) de calcularea a valorii hash, care pot fi utilizate separat
sau pot fi contrapuse. Cele mai răspândiţi algoritmi sunt: MD2, MD4, MD5, SHA-1, SHA-256,
SHA-384, SHA-512 (aici în regim online pot fi calculate valorile hash pentru date sau fişiere).
Metodele moderne oferă posibilitatea de criptare (encryption) a datelor prin utilizarea unei
„chei” care face parte din algoritm. Astfel unele date importante pot fi păstrate numai în
formă criptată, iar la necesitate utilizării lor se va folosi aceiaşi cheie pentru transformarea
datelor în forma iniţială (vezi figura de mai jos). Sistemele informaţionale moderne au
incorporate instrumente de calculare a sumelor de control hash şi de criptare a datelor,
pentru excluderea posibilităţii de accesare a datelor ocolind instrumentele de securitate a
sistemului (un exemplu de astfel de sistem este ASYCUDA World).
104
11.5.2. Controalele de reconciliere a fişierelor
În cadrul unei aplicaţii, controale de procesare ar trebui să asigure că sunt utilizate numai
date şi fişierele de program valide şi că procesarea este completă şi efectuată cu acurateţe,
iar datele procesate au fost înregistrate în fişierele corespunzătoare. Asigurarea că
prelucrarea a fost corectă şi completă poate fi obţinută prin efectuarea unei reconcilieri a
totalurilor derivate din operaţiunile de intrare la schimbările în fişierele de date utilizate de
procesul respectiv. Auditorul trebuie să se asigure că sunt efectuate controale pentru a
detecta prelucrările incomplete sau inexacte a datelor de intrare.
Cu unele rapoarte este imposibil de a concorda totalul de articole incluse sau reconcilia la
datele introduse sau totalul evidenţiat anterior.
Atunci când utilizatorul face o cerere de raport, dar nu se extrage nici un jurnal sau date,
aplicaţia va fi programată să tipărească cuvintele “RAPORT NUL”.
Atunci când datele-rezultat sunt plasate într-o locaţie temporară, auditorul se va asigura
obligatoriu că există controale de acces logic corespunzătoare în vederea anulării oricărei
acţiuni neautorizate de modificare a datelor.
106
11.6.4. Raţionalitatea datelor-rezultat
Datele-rezultat produse de un sistem informatic vor fi obligatoriu rezonabile şi vor satisface
aşteptările utilizatorului.
În cele din urmă, sistemele sunt proiectate pentru a prelucra datele utilizatorilor şi aceştia
poartă responsabilitatea finală de a asigura că datele-rezultat sunt rezonabile. În fine, este
informaţia lor, resursele lor şi ei sunt cei care trebuia să ia decizii în baza informaţiei
recepţionate.
Utilizatorii pot folosi generatoarele de rapoarte pentru a specifica ce date solicită de la baza
de date. Multe din modulele de generare a rapoartelor dispun de o interfaţă favorabilă
pentru utilizator şi un limbaj de interpelări la baza de date, precum SQL (Structured Query
Language - Limbaj Structurat de Interogare). Odată ce rapoartele utilizatorilor au fost
procesate, acestea pot fi descărcate în seturi de foi de lucru gata (off the shelf spreadsheet
packages) precum Excel sau Lotus.
Există un număr de probleme de control care apar atunci când utilizatorii produc rapoarte
proprii conform logicii proprii şi cadrului temporal. Atunci când clientul utilizează un raport
definit de utilizator în scopuri de raportare financiară, auditorul va examina utilizarea
107
facilităţilor respective şi identifica riscurile specifice acestor circumstanţe şi care necesită a
fi luate în considerare adiţional la punctele menţionate anterior în acest capitol.
Există o mai mare probabilitate ca rapoartele definite de către utilizator să conţină erori, în
special în contextul în care acestea nu sunt subiectul aceloraşi testări riguroase precum
rapoartele specificate în prealabil la etapele iniţiale ale dezvoltării sistemului.
Logica extragerii, ca în cazul utilizării SQL, folosită pentru producerea unui raport va fi
tipărită pe prima foaie a raportului. Acest fapt determină crearea unei piste de audit şi
permite atât utilizatorilor cât şi auditorilor să întreprindă verificări şi examinări ulterioare,
la necesitate.
108
vor include cel puţin ora şi data când a fost extrasă informaţia şi, de preferinţă, ultima
dată când a fost actualizat fişierul de date de fiecare sistem de intrare/sistem operativ
cu care lucrează.
Atunci când fişierul în baza căruia utilizatorul creează raportul, este static de ex. de la
sfârşitul lunii precedente, acesta va fi în mod raţional credibil şi la subiect. Atunci când
fişierul în baza căruia utilizatorul generează raportul, este dinamic, de ex. datele de la
mijlocul lunii, atunci indicaţii privind statutul datelor ar putea fi crucială.
În final, vor fi incluse obligatoriu indicaţii privind faptul că programul a accesat toate
înregistrările relevante din fişier. Din nou, acest fapt va fi examinat pentru fiecare aplicaţie
individual. De exemplu, atunci când un raport derivă dintr-un fişier “static”, totalul
înregistrărilor citite pot fi tipărite şi acceptate pentru rapoartele de control sugerate
anterior. În mod alternativ, într-un fişier “dinamic”, ar putea include unele mesaje ce
confirmă faptul că totalul de înregistrări citite corespund unui jurnal de control pentru
fişierul date. Acest jurnal de control va fi la rândul său reconciliat, în mod regulat, la totalurile
externe.
Un aspect foarte important în toate cele expuse anterior este recunoaşterea de către
utilizator a necesităţii unor asemenea controale şi definirii clare a circumstanţelor în care
este necesară exercitarea unor asemenea controale şi cine ar fi executorul potenţial/exact.
Consecinţele de control al procesării în timp real pot fi rezumate după cum urmează:
• Totalurile de control nu sunt generate de nici o funcţie din sistem şi deci, controlul
asupra procesării run-to-run nu poate fi stabilit prin aceste mijloace;
109
• Informaţia este introdusă şi accesată în sistem la cerere şi deseori, lipseşte o
raportare a fişierelor de date complete pregătire pentru procesare. De exemplu,
introducerea modificărilor privind salarizarea angajaţilor înainte de calculările în
salarizare de la sfârşitul lunii, personalul din resurse umane ar putea să nu ştie
când au fost efectuate toate modificările; şi
• Fişierele jurnale (log files) pot fi utilizate pentru înregistra acţiunile din sistem.
Atunci când fişierele jurnale înregistrează incidente de securitate, precum
încercări de accesare eşuate, acestea acţionează ca protecţie împotriva tentaţiei
de experimentare. Dacă utilizatorii ştiu că sistemul înregistrează încercările lor
eşuate de accesare, aceştia vor fi mai puţin tentaţi să încerce;
• Verificarea una câte una – acceptarea fiecărei tranzacţii în sistem este confirmată
individual de către iniţiator. Această alternativă este aplicabilă atunci când este
disponibil un jurnal complet al tuturor tranzacţiilor introduse la un moment
ulterior intrării datelor. Această tehnică de control este cea mai potrivită pentru
aplicaţiile care au un volum de tranzacţii pentru procesare relativ scăzut;
110
• Operarea pe loturi retrospectivă – loturile de informaţie identificate sunt
constituite retrospectiv din tranzacţiile introduse în sistem şi conforme cu
informaţia acceptată într-un mod similar abordării adoptate pentru sistemele de
procesare în loturi. Pentru a permite operarea acestei metode de control, sistemul
va avea obligatoriu capacitatea de a colecta informaţia şi de a o trata totodată ca
lot în scopuri de raportare;
Deseori, câteva tehnici enumerate anterior sunt antrenate concomitent pentru a realiza un
control al sistemului. Controalele pot fi utilizate pentru a exercita controlul asupra diferitor
părţi ale sistemului şi acestea vor fi obligatoriu proiectate să se suporte unul pe altul. În
general, este necesar de a adopta structura de control optimă pentru aplicaţie.
Aceasta se datorează faptului că, puţin probabil, ca controalele aplicaţiei, izolate, să fie
capabile să asigure plenitudinea şi acurateţea procesării exercitate de sistemele de baze de
date. Controalele aplicaţiei sunt eficace/eficiente în controlul asupra datelor introduse prin
intermediul instrumentelor de monitorizare a datelor de intrare ale aplicaţiei, totodată,
acestea, de regulă, nu sunt apte să prevină defectările în baza de date subordonată. Auditorul
va examina obligatoriu controalele generale pentru a evalua controalele care reduc riscul ca
utilizatorii să editeze direct baza de date.
În vederea exercitării rolului său în mod eficient, administratorului bazei de date i se acordă
o mare putere de decizie şi i se acordă acces la toată informaţia din baza de date.
111
Administratorul va avea privilegii de acces de nivel înalt şi va fi capabil să exercite mult mai
multe funcţii decât un utilizator de sistem ordinar.
Relaţiile dintre elementele de date în cadrul unei baze de date pot fi foarte complexe şi prin
urmare, este dificil de a stabili o integritate continuă a bazei de date şi concordanţa relaţiilor
între date. Există programe-utilite de verificare disponibile pentru majoritatea bazelor de
date, care pot fi operate periodic pentru a asigura integritatea, totodată, ar putea fi dificil de
a identifica cauza şi sursa erorilor survenite.
Plenitudinea raportării într-o bază de date depinde mai curând de acurateţea referinţelor
(pointer) între elementele de date, decât de abilitatea aplicaţiei de a citi cu succes fişierul pe
diagonală. Din acest motiv, este necesar de a trata toate rapoartele din sistemele de baze de
date ca rapoarte de excepţie a căror plenitudine necesită mai curând a fi dovedită, decât a fi
acceptată fără dubii.
Dacă o bază de date este actualizată în timp real, atunci starea datelor incluse în copiile de
rezervă a bazei de date sunt variabile, în dependenţă de poziţia datelor în secvenţa copiilor
de rezervă. Dacă un client necesită să recupereze o bază de date dintr-o sursă a copiilor de
rezervă (back-up), auditorul va examina obligatoriu procedurile adoptate pentru asigurarea
ca tranzacţiile depuse în timpul procesului efectuării copiilor de rezervă(back-up) să fie
incluse.
112
Auditorul va determina obligatoriu dacă descrierea bazei de date (un set separat de
tabele care conţin descrierea detaliată a structurii bazei de date şi tabelelor acesteia)
este actualizată. Dicţionarul datelor este o descriere a bazei de date, care include denumiri şi
stricturi a tuturor tipurilor de date, precum şi orice restricţii şi care aplicaţii utilizează datele.
Există unele aspecte de control specifice controlului asupra sistemelor distribuite. Acestea
sunt adiţionale celor descrise anterior în acest capitol şi sunt rezultatul tehnologiei aplicate
şi distribuirea fizică şi logică a datelor în cadrul sistemelor distribuite.
113
Ca precauţie iniţială, este necesar de a întreprinde paşi pentru fiecare locaţie de distribuţie
care are acces la resursele (instrumentele, echipamentul) de procesare, pentru a restricţiona
accesul doar persoanelor autorizate.
Fişierele master sunt fişiere de date care conţin date financiare sau de referinţă semi-
permanente ce pot fi utilizate de câteva aplicaţii la procesare. Datele stocate în fişierele master
sunt denumite date invariabile.
Aplicaţiile vor interpela datele de referinţă din fişierele master pentru procesarea
tranzacţiilor sale.
De exemplu, un fişier master poate conţine date invariabile cu privire la preţul bunurilor
pentru vânzare. La efectuarea unei vânzări, aplicaţia cere utilizatorului să introducă datele
variabile ale tranzacţiei precum cantitatea bunurilor comercializate. Ulterior, aplicaţia
interpelează datele invariabile pentru preţ din fişierul master şi combină unitatea de preţ cu
cantitatea pentru a obţine valoarea totală a vânzării.
114
Datele invariabile pot includ următoarele:
• rate de plată pentru fiecare categorie;
• detalii privind furnizorul (numărul de referinţă, adresa, numărul de telefon,
termenii de creditare);
• detalii privind clientul (numele, adresa, numărul de telefon, limita de creditare);
• numărul de cont bancar al angajatului (pentru transferurile salariale
automatizate);
• rata inflaţiei şi indicele (pentru evidenţa contabilă a costurilor curente);
• datele de administrare a sistemului, precum fişierele cu parole sau permisiunile
de control al accesului; şi
• codurile conturilor.
Prin urmare, este foarte important ca datele invariabile să fie corecte. Auditorul va fi
obligatoriu interesat de datele invariabile deoarece o eroare în datele invariabile, combinat
cu caracterul sistematic al sistemelor informatice va rezulta în mari erori în conturile
clientului.
Având în vedere că erorile în datele invariabile produc un efect extins, este normal ca
controalele asupra lor să fie mai stricte decât controalele asupra tranzacţiilor individuale.
Aceste controale vor asigura obligatoriu ca doar utilizatorii autorizaţi să poată accesa, crea,
modifica sau şterge datele permanente.
Un alt control aplicat de client ar putea fi pentru segregarea responsabilităţilor, şi anume cei
responsabili pentru introducerea datelor tranzacţionale să nu poată face modificări la datele
tranzacţionale. În exemplele de fraudă, au survenit pierderi de date deoarece utilizatorii
115
aveau posibilitatea de a modifica datele permanente şi ulterior iniţiau tranzacţia bazată pe
datele permanente.
Având în vedere că datele permanente sunt foarte importante, clientul va asigura ca acestora
să li se facă copii de rezervă în mod regulat, în special după modificarea lor.
Atunci când utilizatorii solicită modificarea fişierului master, de regulă se tipăresc rapoarte
cu modificările fişierelor master. Documentele tipărite vor fi expediate înapoi la solicitant
pentru verificare.
116
Anexa nr.1 Exemplu de program de audit.
Aprobat:
Directorul Departamentului de audit
Valentina MADAN
01 octombrie 2010
Programul de audit
1. Prezentare generală
Auditul se efectuează în baza Programului activităţii de audit a Curţii de Conturi expus în redacţie
nouă prin HCC nr. 29 din 07.05.2010 şi art. 28 şi 31 din Legea privind Curtea de Conturi nr. 261-XVI din
05.12.2008 şi în conformitate cu materialele instructive în domeniul auditului de revizuire a controalelor
sistemelor informaţionale, documentele şi procedeele de audit standardizate în manualele regularităţii şi
performanţei.
Scopul auditului este realizarea Programului activităţii de audit a Curţii de Conturi pe anul 2010,
exercitarea calitativă a atribuţiilor de audit TI ale Curţii de Conturi, întocmirea unui raport calitativ de audit.
Auditului este supus Sistemul Informaţional Integrat Vamal al Serviciului Vamal atît la
aparatul central, cît şi la birourile vamale.
2. Informaţie generală despre entitate şi sistemul informaţional
Serviciul Vamal al Republicii Moldova este organul administraţiei publice, subordonat
Ministerului Finanţelor, care asigură securitatea economică a statului, implementează politica
vamală şi conduce nemijlocit activitatea vamală în Republica Moldova.
Serviciul Vamal este un organ de drept, cu statut de persoană juridică, dispune de ştampilă
cu Stema de Stat a Republicii Moldova, activează conform principiului de instituţie bugetară,
finanţată de la buget, dispune de mijloace (fonduri) speciale, precum şi de resurse obţinute de la
activitatea unităţilor din subordine aflate la autogestiune.
Structura aparatului central al Serviciului Vamal este aprobată prin Hotărîrea Guvernului nr.
4 din 02.01.20076. Astfel, SV este constituit din aparatul central (2 departamente şi 16 secţii) şi 8
birouri vamale.
În conformitate cu planul de acţiuni strategice, adoptat anual în cadrul Serviciului Vamal se
efectuează o modernizare esenţială a sistemului informaţional, se întreprind măsurile necesare
pentru aducerea lui în conformitate cu volumul sporit al informaţiei, adaptarea la normele admise
în practica internaţională.
Sistemul Informaţional Integrat Vamal se bazează pe ASYCUDA World (ASYCUDA:
Automated SYstem for CUstoms DAta) - produsul de program elaborat de către Conferinţa
Naţiunilor Unite pentru Comerţ şi Dezvoltare în scopul susţinerii reformelor în organele vamale,
precum şi acordarea suportului la facilitarea comerţului şi controlului vamal. Reieşind din
informaţia prezentată de V. Bagrin (inspector principal al Secţiei Sisteme Informaţionale Vamale),
în activitatea Serviciului Vamal sînt utilizate 28 sisteme informaţionale şi 7 SOFTuri licenţiate.
În scopul administrării, menţinerii şi asigurării funcţionării S.I. al Serviciului Vamal şi
subdiviziunilor lui a fost creată Întreprinderea de Stat “Vamtehinform” 7. Pentru atingerea
scopurilor, întreprinderea desfăşoară următoarele genuri de activitate:
- participă la elaborarea şi promovarea politicii unice a Serviciului Vamal în domeniul
informatizării, creării şi implementării noilor tehnologii informaţionale, sistemelor şi
reţelelor informaţionale, necesare activităţii organelor vamale;
- implementarea concepţiei elaborate de Serviciul Vamal privind informatizarea şi
automatizarea activităţii organelor vamale ale Republicii Moldova;
6
Hotărîrea Guvernului nr.4 din 02.01.2007 ”Privind aprobarea structurii, efectivului-limită şi a Regulamentului Serviciului Vamal”.
7
Hotărîrea Guvernului Republicii Moldova nr. 346 din 28.03.2007.
117
- implementarea, exploatarea şi menţinerea continuă a sistemelor de informatizare şi
automatizare a activităţii organelor vamale la comanda Serviciului Vamal;
- realizarea strategiei Serviciului Vamal cu privire la îmbunătăţirea în continuu a pregătirii
profesionale a colaboratorilor vamali în domeniul tehnologiilor informaţionale;
- elaborarea proiectelor de documente ce vizează asigurarea informaţională şi tehnologică
de proiectare, implementare şi exploatare a sistemelor informaţionale automatizate,
necesare activităţii Serviciului Vamal;
- asigurarea funcţionării echipamentelor informaţionale şi de comunicaţii ale organelor
vamale în modul stabilit de Serviciul Vamal;
- analiza şi argumentarea propunerilor privind cadrul legislativ, instituţional, metodologic al
procesului de informatizare şi automatizare a Serviciului Vamal;
- menţinerea şi dezvoltarea Web site-ului şi a serverului poştal ale Serviciului Vamal în
modul stabilit de acesta;
- implementarea proiectelor şi sarcinilor tehnice pentru echipamentele şi utilajele necesare
organelor vamale întru asigurarea compatibilităţii acestora cu sistemele informaţionale şi
echipamentele existente în modul stabilit de Serviciul Vamal;
- elaborarea la comandă a aplicaţiilor software pentru instituţiile publice, agenţi economici
şi/sau persoane fizice cu acordul Serviciului Vamal;
- prestarea serviciilor de menţinere şi dezvoltare a aplicaţiilor elaborate;
- alte genuri de activitate în bază de contract ce nu contravin legislaţiei Republcii Moldova
cu acordul Serviciului Vamal.
Concepţia Sistemului Informaţional Integrat Vamal 8 (în continuare SIIV) formulează cerinţele
de bază pentru implementarea noilor tehnologii informaţionale în activitatea vamală.
Informatizarea organelor vamale este o direcţie strategică şi prioritară a activităţii Serviciului
Vamal şi reprezintă procesul de introducere a tehnologiilor informaţionale moderne în activitatea
vamală.
Concepţia Sistemului Informaţional Asycuda Word este elaborată în conformitate cu planul
de acţiuni strategice, adoptat anual în cadrul Serviciului Vamal şi cu Conceptul General al
sistemului informaţional ASYCUDA World (Legea nr.301-XV din 11 iulie 2003 privind
ratificarea Acordului de credit pentru dezvoltare (Proiectul “Facilitarea Comerţului şi
Transportului în Europa de Sud-Est”) dintre Republica Moldova şi Asociaţia Internaţională pentru
Dezvoltare). Concepţia SIIV stabileşte scopurile, sarcinile, funcţiile, precum şi totalitatea
sintezelor privind dezvoltarea Sistemului Informaţional Integrat Vamal şi implementarea noilor
tehnologii informaţionale în activitatea vamală. Ea prezintă baza metodică pentru crearea unui
sistem informaţional complex, în scopul asigurării activităţii organelor vamale.
Obiectivele de bază ale SIIV:
• asigurarea introducerii tehnologiilor moderne în activitatea organelor vamale pentru
perfecţionarea procedurilor de perfectare vamală şi creşterea eficacităţii controlului
vamal;
• asigurarea utilizării eficiente la nivel optim a tuturor resurselor existente în sistem
(hardware, software, dispozitive de comunicaţii, personal tehnic de specialitate etc.);
• asigurarea creşterii calităţii operaţiunilor de control şi urmărire de toate tipurile
(înainte, în timpul sau după vămuire), prin furnizarea inspectorului vamal a datelor
consolidate necesare, prezentîndu-i, astfel, în mod optim şi concludent, informaţiile
cele mai utile;
• asigurarea disponibilităţii elementelor de evaluare a operaţiunilor de vămuire şi
control efectuate de colaboratorii vamali, cu scopul de a evidenţia eficient şi operativ
punctele slabe în fluxul de procesare a diferitelor documente vamale;
8
Concepţia Sistemului Informaţional Integrat Vamal, aprobată prin Hotarîrea Guvernului nr. 561 din 18.05.2007.
118
• perfecţionarea organizării schimbului de informaţii cu structurile externe, inclusiv de
peste hotare, dezvoltarea colaborării cu aceste structuri în domeniul tehnologiilor
informaţionale;
• asigurarea unui sistem unic de securitate a informaţiei organelor vamale ale
Republicii Moldova.
Pericolele de bază SIIV
6. Metodologia auditului
La executarea auditului se vor petrece următoarele activităţi şi se vor utiliza următoarele metode de
colectare a probelor precum şi va fi aplicată metodologia:
Activităţi de audit:
120
- Analiza: datelor de intrare (procesul de introducere/import/acumulare a datelor); procesării datelor
în cadrul Sistemelor Informaţionale; datelor de ieşire (raportarea, schimbul de date, integrarea în
alte structuri şi asigurarea accesului). Identificarea operaţiunilor manuale şi automatizate.
Procedurile de autorizare şi asigurarea accesului restricţionat;
- Descrierea procedeelor şi posibilităţilor de restabilire a prejudiciilor aduse sistemului în caz de
calamitate. Efectuarea, testarea, validarea şi păstrarea în siguranţă a copiilor de rezervă. Asigurarea
continuităţii activităţii instituţiei;
- Testarea funcţionalităţii aplicaţiei la 4 posturi vamale.
- Întrunirea de generalizare a echipei de audit, analiza informaţiei obţinute în teritorii şi pe parcursul
auditului la SIIV. Sistematizarea documentaţiei şi probelor obţinute pe parcursul procesului de
audit.
Compararea şi analiza celor observate şi constatate de auditori. Revizuirea constatărilor şi formularea
concluziilor. Structurarea proiectului raportului cu expedierea entităţii auditate pentru obiecţii şi propuneri.
Metode de colectare a probelor:
- Documentarea interviurilor;
- Completarea chestionarelor;
- Observările directe (documentarea constatărilor, imagini foto, imprimarea interfeţelor, imprimarea
registrelor electronice);
- Testele de control (CoBIT) cu imprimarea ecranelor (screen-urilor);
- Efectuarea de copii ale documentelor necesare;
- Analiza documentelor (completarea tabelelor de date, diagrame).
7. Testarea controalelor
Pe parcursul auditului se vor testa următoarele controale generale sub aspectul riscurilor legate de:
• Administrarea sistemului. Riscuri implicate de utilizarea practicilor inadecvate de administrare a
sistemului: gestiune conturi utilizatori, proceduri de back-up, configurare sistem, instruire
administratori (identificat ca risc de grad înalt).
• Acces utilizatori. Riscurile implicate de compromiterea securităţii informaţionale pe staţiile
utilizator sau de către utilizatorii sistemului informaţional (virusare, acces nesancţionat,
compromiterea parolelor, utilizarea inadecvată a resurselor disponibile ş.a.) (identificat ca risc de
grad înalt).
• Proceduri operaţionale. Riscuri implicate de lipsa documentării detaliate şi adecvate a utilizării
tuturor resurselor critice (identificat ca risc de grad mediu).
• Dependenţe externe. Riscuri implicate de dependenţa de anumiţi furnizori în vederea menţinerii
sistemului, operarea de modificări de program (deţinerea codului sursă), produselor program, alte
servicii (identificat ca risc de grad înalt).
• Personalul critic. Existenţa unei singure persoane în vederea efectuării procedurilor critice
(administrare sisteme şi reţele) poate să compromită activitatea normală curentă (identificat ca risc
de grad înalt).
• Parole vulnerabile. Riscuri implicate de utilizarea parolelor vulnerabile, în special pentru conturile
de administrare a sistemului şi pentru conturile utilizatorilor critici (identificat ca risc de grad
mediu).
• Accesul la date. Riscuri implicate de gestionarea inadecvată a drepturilor de acces la resursele
informaţionale, modul în care se pot accesa resursele şi informaţia din sistem (identificat ca risc de
grad mediu).
• Securitatea fizică. Riscuri implicate de controlul inadecvat al accesului fizic la resursele
informaţionale atât intern cât şi extern (identificat ca risc de grad mediu).
• Dezastre de scară mare. Riscurile legate de dezastrele naturale ca incendii, inundaţii, căderi de
durată a curentului electric ş.a. pot avea impacturi considerabile asupra activităţii operaţionale
(identificat ca risc de grad necunoscut).
• Construcţii. Riscul legat de afectarea sediului companiei şi distrugerea serverului cu baza de date
în caz de lipsa unui server de rezervă cu BD a SIA amplasat la distanţă în altă localitate (identificat
ca risc de grad necunoscut).
8. Termenii de realizare a auditului
121
Membrul echipei Titlul Începutul Finalul Orele preconizate ale
utilizării personalului
Etapa de planificare
Etapa de executare
Etapa de raportare
Punctele de reper în timp Data ţintă iniţială Data revizuită Data de facto
122
Prezentarea raportului pentru revizuirea finală 28.12.2010
în şedinţa CC
Fricăţel Roman
Adrian Varatic
Raportul de audit TI pilot se va prezenta spre examinare în şedinţa Plenului Curţii de Conturi pînă la data
de „____” _______________2010.
123
Anexa nr.2 Chestionar de determinare a criticismului SI.
În cadrul entităţii pot fi utilizate multiple sisteme informaţionale şi aplicaţii. Curtea de Conturi poate să nu
fie interesată în auditarea tuturor acestora. Mai mult ca atît, careva aplicaţii pot fi aplicaţii de importanţă
strategică, neajunsurile cărora pot avea consecinţe cu efecte de rezonanţă. În astfel de cazuri Curtea de
Conturi, pentru efectuarea auditului, poate selecta metode şi instrumente stricte de evaluare (ex: CoBIT).
Curtea de Conturi poate să nu fie interesată în audite exhaustive a unor SI de management, ce nu sînt
utilizate de entitate pentru luare de decizii sau efectuare de operaţiuni financiare. Instrumentul prezentat
poate reprezenta o evaluare subiectivă a timpului, resurselor şi metodelor alocate, dar totuşi reprezintă
o metodă sigură de evaluare a riscurilor.
Informaţie preliminară
A. Numele entităţii
Oficiu regional
Oficiu teritorial
Oficiu al subdiviziunii
Altele
C. Denumirea sistemului
D. Descrierea sistemului
124
Se referă oare sistemul la careva din următoarele
Numele oficiului:
Informaţie preliminară
E-Governare (30)
2 Investiţii în sistem
< 10 (5)
da
nu
125
Web bazată /domen public? (30)
Informaţia de ieşire este utilizată pentru operaţii critice activităţii sau (30)
formare de venituri
Informaţia de ieşire este utilizată pentru plăţi sau cumulare de venituri. (0)
8 Chiar dacă sistema nu efectuează funcţii financiare, ea procesează date de interes public.
Natura datelor este aşa încît, date eronate şi greşite pot aduce la:
9 Pot oare persoane fizice avea acces la astfel de date prin internet sau prin oricare alte căi?
10 Permite oare sistemul utilizarea linkurilor directe părţilor terţe. (ex: schimb electronic de date)
Da (20)
Nu (0)
Nu (0)
< 10 (10)
126
> 10, < 30 (20)
> 70 (30)
<5 (0)
14 Sistema e bazată pe
Da (0)
Nu (20)
Da (5)
Nu (20)
127
Are, dar nu este suficient documentată (15)
Da (5)
Nu (20)
Da (5)
Nu (10)
Informaţie preliminară despre persoana menţionată (funcţia, gradul, data angajării, studii,
diplome, certificate, cursuri, etc.)
Da (0)
Nu (20)
> 10 GB (25)
< 1 GB (5)
Total Score
Reieşind din acestui instrument de evaluare a riscului, conform punctelor acumulate, entitatea
reprezintă un nivel de risc:
128
Puncte acumulate Clasificarea gradului de risc
129
Bibliografia
• Information Systems Audit and Control Association Standards and Guidelines (ISCA)
• National Audit Office (UK), Financial Audit Manual – Module T9 – Audit in an IT environment
• CoBIT.
Application
130