Premise

Despre folosirea incorectă a termenului “audit” am mai scris în postarea Audit sau asigurare. De unde apare însă la noi cererea de astfel de servicii? Pe de o parte pot exista cerințe legale cu privire la auditul sistemelor informaționale (legi, ordine de ministru, cerințe contractuale), pe de altă parte pot exista cerinţe din partea auditatului cu privire la sistemele acestuia. Aceste două situații afectează scopul şi obiectivele auditului!

Când semnează Codul Etic, CISA se angajează să respecte standardele ISACA.  Ghidurile vin în completarea standardelor ca un instrument ce îl ajută pe auditor să asigure conformitatea cu standardele:

• Trebuie să ţii cont de ele pentru a asigura respectarea standardelor
• Este o problemă de raționament profesional aplicarea ghidurilor în cazul unor misiuni specifice
• Să fii capabil să justifici diferența dintre abordarea ta şi recomandările ghidurilor

Cu altă ocazie spuneam că principala diferență dintre misiuni este dată de tipul de asigurare oferită de auditor sub forma concluziilor.

Studiu de caz

 În Ghidul solicitantului pentru Programul Operaţional Sectorial „Creşterea Competitivităţii Economice” 2007-2013, apar două afirmaţii:

• „Auditarea parțială şi finală a proiectului, inclusiv auditarea din punctul de vedere al securității aplicației”
• „Cheltuieli cu servicii de auditare intermediară şi finală pentru proiect, inclusiv auditarea securității rețelei şi aplicației informatice”

Emitentul acestui ghid este MINISTERUL COMUNICAŢIILOR ŞI SOCIETĂŢII INFORMAŢIONALE. Prin urmare ne aflăm în situația unei cerințe mandatare din partea unui reglementator.

În cazul unei Cereri de “Servicii de auditare tehnică a securității sistemului informatic” am întâlnit mai multe exprimări/cerințe din partea “auditatului”, exprimări ce denotă din punctul meu de vedere o înțelegere incorectă a ceea ce înseamnă “audit”, atât din partea auditatului cât şi din partea reglementatorului. Teoretic este vorba de o  misiune de tip “atestare”: fie auditez declarațiile managementului cu privire la subiect, fie auditez direct subiectul. Deoarece sistemul este dezvoltat/achiziționat de la un terţ nu putem obține  “declarații” din partea managementului cu privire la subiectul auditat. Prin urmare misiunea va fi de atestare a “securității (rețelei şi) aplicației informatice” şi se va finaliza cu o opinie asupra subiectului auditat. Asta este însă teorie.

Ceea ce sare de la bun început în ochi în cazul acestei Cereri de servicii este existența unei secțiuni denumită “Proceduri de lucru”. Auditatul, prin cererea de servicii, îi impune auditorului ce “trebuie să facă” astfel încât, la final, să emită şi o opinie!

Atât timp cât auditatul impune/stabileşte procedurile de lucru nu ne mai aflăm în situaţia unei misiuni de tip audit sau revizie ci discutăm de proceduri agreate:

“An agreed-upon procedures engagement does not result in the expression of any assurance by the IT audit and assurance professional. The IT audit and assurance professional is engaged to carry out specific procedures to meet the information needs of those parties who have agreed to the procedures to be performed. The IT audit and assurance professional issues a report of factual findings to those parties that have agreed to the procedures. The recipients form their own conclusions from this report because the IT audit and assurance professional has not determined the nature, timing and extent of procedures to be able to express any assurance.” (vezi ITAF sau G20)

Este firesc să existe astfel de situații. Dar în acest caz, partea responsabilă îşi asumă responsabilitatea asupra suficienței controalelor implementate şi a procedurilor solicitate iar auditorul nu emite nici o concluzie! Auditorul execută procedurile şi îşi prezintă constatările. Concluziile aparțin auditatului şi celorlalte părţi nominalizate prin raport.

În cazul Programului Operaţional Regional, Ministerul Dezvoltării Regionale şi Turismului menţionează că Raportul de audit va trebui să menționeze “scopul şi procedurile agreate ale angajamentului”, fiind referenţiat ISRS 4400!

Asupra unora din cerințele cu privire la procedurile de lucru cerute de auditat voi insista în continuare, fără a avea pretenţia că voi acoperi tot ce se poate discuta chiar şi despre acestea.

“Serviciile de auditare vor fi asigurate pentru analiza şi evaluarea riscurilor pentru sistemul IT implementat în conjuncţie cu toate sistemele care vor fi necesare a fi luate în considerare”

Într-o postare de pe la începuturile acestui blog am scris câteva rânduri despre ce presupune riscul auditării (a se vedea şi S5 Planning , G13 Use of Risk Assessment in Audit Planning). Cerinţa de mai sus se referă însă la altceva: auditorul trebuie să “analizeze şi evalueze” riscurile sistemului implementat”. Punem stop şi facem putină teorie.

Trebuie “auditată” “securitatea unui sistem informatic”. Acest lucru implică revizia şi testarea controalelor existente! Controalele din cadrul sistemului informatic auditat ar trebui să aibă la bază o evaluare a riscurilor şi cerințele legale existente (condițiile minimale ale programelor financiar contabile; protecția datelor cu caracter personal etc). Implementatorul/dezvoltatorul sistemului ar fi trebuit să lucreze după o metodologie de management proiecte. Orice metodologie de management proiecte impune şi evaluarea riscurilor proiectului. Mai mult, printre cerințele auditatului se menţionează că “în cadrul auditului se vor lua în considerare normele de securitate fizică şi logică conforme standardelor ISO 27001 şi BS7799 sau echivalente” (SIC!). De la ce pornesc “normele” ISO 27001? De la risk management!

Analiza riscurilor (şi nu estimarea/evaluarea) pe care o realizează auditorul în timpul misiunii este parte componentă a planului de audit şi se referă la capacitatea auditorului de a identifica riscurile pe care controalele implementate le tratează (reduc/elimină/transferă). Auditorul trebuie să fie capabil să evalueze tehnicile de estimare şi management al riscurilor dezvoltate/aplicate/asumate de către conducerea auditatului!

“Analiza documentaţie va consta în:

• Evaluarea conformităţii documentaţiei sistemului informatic cu toate documentele de referinţă (ex: cerere de finanţare, proiect tehnic, caiet de sarcini)”

 

Că auditorul trebuie să revizuiască documentații nu este nici o noutate. Prima cerință vizează însă “conformitatea” nu şi “completitudinea” prin raportare la cele trei referenţiale. În cazul proiectelor cu care am avut contact, cererea de finanțare (care nu vizează tehnicisme ci partea financiară) se finaliza cu următorul text:

“Confirm că informaţiile incluse în această cerere şi detaliile prezentate în documentele anexate sunt corecte şi asistenţa financiară pe care o solicit este necesară proiectului conform descrierii.

De asemenea, confirm că nu am luat la cunoştinţă de nici un motiv pentru care proiectul ar putea să nu se deruleze sau ar putea fi întârziat.

Înţeleg că dacă cererea de finanţare nu este completă cu privire la toate detaliile şi aspectele solicitate, inclusiv această secţiune, ar putea fi respinsă.

Prezenta cerere a fost completată în conformitate cu prevederile art. 292 din Codul Penal cu privire la fals în declaraţii.”

În instituțiile publice, viza de control financiar preventiv este dreptul şi obligația persoanelor cărora li s-a creat prin act administrativ dreptul de acordare a acestei vize. Există o ștampilă tip, unică la nivelul instituției şi semnătura persoanei responsabilă sub menţiunea : „Confirm oportunitatea, necesitatea realitatea, valabilitatea, legalitatea”.

Nu ştiu ce implică deci evaluarea conformității documentației sistemului prin raportare la cererea de finanțare. CISA va evalua eligibilitatea cheltuielilor? În baza căror competenţe atît timp cît deja există probe concludente cu privire la asumarea conformității cu legislaţia?

 “Evaluarea securităţii reţelei – Pentru realizarea unui audit la nivel de reţea se au în vedere mai multe niveluri, şi anume

audit primar – arhitectură şi design, tehnologie, vechime, segmentare, redundanţă, elemente pasive şi active, conexiuni, servicii;

audit secundar – prin analiza traficului suportat, fie trafic normal, existent în modul normal de lucru, fie trafic generat artificial, prin testarea la nivelul porturilor active de reţea, diverse tipuri de scanări de reţea, teste de stress pentru elemente de reţea, simulare de atacuri interne, externe sau virale, folosind echipamente dedicate şi sisteme expert dedicate acestui tip de utilizare”

Ne  aflăm în situaţia unui proiect finalizat. La baza sa există cerinţele din partea clientului (proiectul pentru care s-a obţinut finanţarea) şi oferta celui care a analizat/dezvoltat/implementat/testat. Există procese verbale de recepţie (cu menţionarea criteriilor cantitative şi calitative de recepţie) şi aprobarea clientului.

Să reformulez: un client doreşte să îşi cumpere un autoturism Dacia Logan. Banca îi oferă un credit în acest scop. Poate să vină “un terţ” şi să îi spună clientului că nu e bun Loganul şi că trebuia să îşi cumpere Honda Accord pe motivele x,y,z ? Poate însă “terţul” (de exemplu asiguratorul) să verifice dacă Loganul achiziţionat are aceleaşi caracteristici cu cel pentru care s-a primit creditul? Altfel spus, “auditul primar” nu este cerut înaintea semnării recepţiei ci ulterior acceptării livrabilelor! Care livrabile sunt asumate de management ca fiind corespunzătoare obiectivelor stabilite!

Mă opresc aici cu dilemele nu înainte de a arăta şi care este forma “raportului de audit”

 

 

Dacă sunteţi de acord cu argumentele mele, atunci raportul ar trebui să fie întocmit conform G20:

„The report on agreed-upon procedures should be in the form of procedures and findings. The report should contain the following elements:

• A title that includes the word independent
• Identification of the specified parties
• Identification of the subject matter (or the written assertion related thereto) and the type of engagement
• Identification of the responsible party
• A statement that the subject matter is the responsibility of the responsible party
• A statement that the procedures performed were those agreed to by the parties identified in the report
• A statement that the sufficiency of the procedures is solely the responsibility of the specified parties and a disclaimer of responsibility for the sufficiency of those procedures
• A list of the procedures performed (or reference thereto) and related findings
• A statement that the IT audit and assurance professional was not engaged in and did not conduct an examination of the subject matter
• A statement that if the IT audit and assurance professional had performed additional procedures, other matters might have come to the IT audit and assurance professional’s attention and would have been reported
• A statement of restrictions on the use of the report because it is intended to be used solely by the specified parties

„

––––––––––––––––––––––––––-

“Audit’, in the context of this publication, refers to a specific type of assurance engagement in which an IT audit and assurance professional conducts a formal, independent and systematic inspection or examination of subject matter against a recognised and appropriate standard or against management’ s assertions that must meet specific criteria. Audit engagements require a formal approach, adherence to specific standards and guidance, and adoption of specific reporting formats. Audit engagements could include support of the audit of financial statements, opinions of regulatory compliance and other formal expressions of opinion.”