Am citit Notă de fundamentare a proiectului Instrucțiunii Adecvarea Sistemelor Informatice utilizate de entitățile reglementate, autorizate/avizate și supravegheate de A.S.F.. Mi-aș fi dorit să citesc și Instrucțiunea în sine, dar nu am dat de ea pe nicăieri.
Citez din Contextul proiectului
eliminarea abordării tehnicistea auditării IT, orientarea către o abordare de business din perspectiva managementului riscurilor,a stabilității pieței și a protecției consumatorilor
După cum spuneam, mi-aș fi dorit să citesc altceva. Pentru moment, auditul este destul de bine reglementat de către ISACA fiind foarte business.
Având în vedere observațiile referitoare la instrucțiunea suspendată, discuțiile cu entitățile supravegheate de către sectoarele A.S.F. și cu asociațiile profesionale, s-a urmărit:
(…)prevederea de forme alternative de auditare:
- prin testări;
Nu știu să fi apărut schimbări de fundament în cazul auditului în ultimele 24 de ore. Acesta este motivul pentru care nu am auzit de “testare” ca fiind o formă alternativă de auditare. Știu că orice audit se bazează pe teste: de conformitate, respectiv de fond. Știu că nu poți afirma că auditezi fără să testezi.
Ajung cu lectura la Principiile urmărite de către proiectul Instrucțiunii:
În vederea asigurării stabilității financiare și pentru diminuarea efectelor incidentelor de funcţionare a entităţilor supravegheate de ASF, trebuie aplicate reguli pentru analizarea, identificarea, prevenirea și reducerea impactului potențial negativ al materializării vulnerabilităților generate de utilizarea tehnologiei informației și a comunicațiilorla nivel de oameni, procese, sisteme și mediu extern.
Vulnerabilitățile se materializează? În acest caz, amenințările ce mai fac? Se concretizează? Lipsa unui control este o vulnerabilitate sau o amenințare?
rapoartele de evaluare internă a riscurilor și registrul de riscuri elaborate de către entități, prin definirea riscurilor, vulnerabilităților identificate și a măsurilor luate pentru diminuare si încadrare in profilul de risc, cu periodicitate anuală;
Îmi permit să afirm că cele de mai sus se vor cumpăra de la colțul străzii. Elementul de bază în managementul riscurilor IT în practică, nu în teorie, îl reprezintă SCENARIILE!
Îmbunătățirea mediului de control intern, a creșterii gradului de maturitate a organizării entităților se va realiza prin luarea de către entități a unor măsuri diferențiate în funcție de categoria de risc a entității:
Nu știu ce reprezintă gradul de maturitate al organizării entității și nici cum se cuantifică acesta. Există vreun model/referențial/benchmark? Au fost definite anterior grade diferite de maturitate a organizării??
Demersul merită a fi apreciat. Cîteodată însă cred că nimic este preferabil lui puțin și inconsistent.
ADRIAN B. MUNTEANU 
So Adi, what’s the catch? E Calin Rangu in spatele reglementarii, mi-e imposibil sa nu cred ca are un interes direct in treaba asta
ApreciazăApreciază
Mă interesează mai puțin cine.
După cum spuneam, decît să faci ceva prost, mai bine nu faci nimic. Impresia mea generală: cei care au lucrat au făcut un melanj din ITIL, COBIT și ISO 27001 (am regăsit și o definiție Basel III legată de riscul IT ca parte a riscului operațional) fără să înțeleagă esența lucrurilor.
Un standard are cerințe mandatare în timp ce un framework nu!
Cum poți să pui în aceeași propoziție și standarde și framework?
ApreciazăApreciază
Ok my bet; cred ca smecheria este legata de faptul ca vrea sa scaleze risk management pe tot lantul, de la asigurator pana la clientul final: a cautionat auditul ca tot nu are interes, dar a generat un segment semnificativ in zona de risk unde banuiesc ca tinteste, (are ceva articole in ultima vreme legat de risk operational bla bla)
ApreciazăApreciază
Posibil.partea cu articolele am remarcat-o si eu…dar lucrurile sint amestecate tare de tot si sub umbrela complexitatii dau impresia de neintelegere Voi detalia in zilele urmatoare, dar nu poti sa faci referire la COBIT 5 si sa vrei evaluare maturitate procese dupa subiectivismul din COBIT 4.1; cum se poate sa nu stii ca pentru auditul furnizorilor de servicii ai la dispozitie SOC; cum poti limita disponibilitatea unui serviciu numai la data center…lista-i lunga…
La audit? Un exemplu facil de stupizenie: se cere copie legalizata dupa CISA! Stiu oare domnii de au lucrat la acest document ca legalizarea unui document din limba engleza presupune mai intii traducere autorizata? Si ca traducerea autorizata este o foaie A4 fara nici un insemn ISACA? ca verificarea calitatii se poate face on line pe situl ISACA?
Daca s-ar fi dorit ceva simplu si concis se putea:
– mentiona COBIT 5 si publicatiile conexe ca cerinte de guvernare si management IT pentru entitatile supravegheate. In plus, prelunind cerinta SOX, o declaratie a managementului cu privire la responsabilitatile legate de controlul intern!
– mentiona ITAF 2 ca framework pentru audit respectiv COBIT 5 for Assurance ca referintial!
ApreciazăApreciază
Titlul blogului este foarte inspirat. Cum se naste o instructiune noua? Plecand de la ce vrei sa rezolvi. Iar un supraveghetor reglementeaza ce considera ca trebuie sa monitorizeze din perspectiva riscurilor pe care le-a identificat, nu de dragul unor standarde. Aici este vorba de o abordare diferita deoarece incercam sa facem ceva care sa le fie util si entitatilor supravegheate . Nu trebuie sa priviti din perspectiva IT. Pe nimeni (din businessul non-IT) nu intereseaza IT-ul in sine, ci ce se poate face cu IT-ul pentru a-si atinge obiectivele de business, intr-un mod cat mai sigur si eficient. Pe entitatile financiare nu le intereseaza sa fie certificate pe un standard IT, nici sa fie auditate IT, le intereseaza sa introduca niste procese care sa le reduca riscurile. Iar riscuri scazute, implica capital mai putin adus de actionari sa acopere riscurile. Pentru prima data apare o instructiune pe noile principii soolicitate de Basel III/ Solvency II de risk-based-supervision, in loc de rules-based supervision. Instructiunea nu se vrea un alt standard, ci cauta sa identifice ce le-ar fi util din standardele/frameworkurile relevante. De exemplu nu vorbim de managementul de proiect, care e f important intr-o organizatie, dar ca impact, din perspectiva supravegherii, poti sa ii lasi sa il faca cum doresc. Un management de proiect prost se vede in alti indicatori solicitati (intarzieri, incidente etc). Obiectivele reglementarilor sunt sa asigure stabilitate financiara si sa protejeze consumatorii. Acestea sunt interesele din spatele instructiunii si nu altele. Se vorbeste de diiponibilitate. Instructiunea solicita a pune la punct un proces dand exemplu referetialul din ISO20.000, ca exemplu suport, sa stie unde sa caute, fara a solicita o certificare expresa de conformitate. Pe noi ne intereseaza disponibilitatea serviciilor catre clienti, conform contractelor intre firmele fianciare si acestia, pt a proteja clientii de servicii neconforme. Iar un punct important, credem noi, este ca data centerul sa nu fie intr-un apartament. Ar fi multe de discutat. Suntem in consultare publica si va invit, si pe tine si pe Coco si pe cine este interesat, la o discutie pe aceasta tema. Poate e momentul sa gandim, pe baza exerientei practice a fiecaruia, a celor care s-au lovit de aceste probleme in mod concret, sa adunam niste best practice-uri din experientele proprii si sa nu ne uitam numai la textele si defintiile date de altii. Sunt importante, dar sa trecem si printr-un filtru propriu. Din acest motiv va stau la dispozitie cu reala placere, indiferent de diferentele de abordare. Va asiguram ca singurul interes este sa aducem niste elemente utile, un ghid, celor pe care nu ii intereseaza IT-ul sau standardele IT, ci doresc sa isi faca meseria, fie ca furnizor de servicii financiare, fie ca supraveghetor.
ApreciazăApreciază
Multumesc pentru comentarii.
Stiu ca exprimarea on line lasa loc la multe interpretari. Tocmai asta doream sa scot in evidenta.
Auditul sistemelor informationale, asa dupa cum este definit si reglementat de catre ISACA vizeaza in primul rind obiectivele economice in conjunctie cu IT-ul. Ca cei mai multi de pe la noi pun semn de egalitate cu „audit IT” si folosesc aceasta sintagma este doar o problema de intelegere. Corect sint misiuni de asigurare, auditul fiind un caz particular al unei astfel de misiuni. Diferenta principala tine de gradul de asigurare pe care il ofera auditorul.
La fel si COBIT. NU este despre IT ci este despre business. In ce mod contribuie IT-ul la atingerea obiectivelor economice ale unei organizatii.
In Intelegerea mea (si voi mai scrie argumentindu-mi cu probe opinia) ceea ce a rezultat este pe linga scopul enuntat in comentariul dvs. (si in Basel II si in normele BNR riscul IT este categorie a riscului operational).
ApreciazăApreciază
Intru-totul de acord, riscul generat de utilizarea IT-ul este parte a riscului operational, care se refera la oameni, procese, sisteme si mediu extern (mai sunt si alte componente ale riscului operational dar nu ne ocupam aici de ele). Pentru a fi la obiect, interesul fiind de clarificare si eventuala imbunatatire a instructiunii (dupa aceea putem dezbate termeni si concepte cat dorim…), daca prezinta interes, va rog a-mi trimite observatii pe textul propunerii de instructiune.
ApreciazăApreciază
În măsura timpului disponbil unei astfel de activități voi da curs.
ApreciazăApreciază
Am fost putin corectat de Adi, prin faptul ca am gresit putin in estimari legat de audit; in fapt si auditul creste, in zone in care nu era inainte, cautionat spuneam poate de faptul ca poate fi si intern si eventual odata la 3 ani.
@Calin: ca sa fie spus, o sa mentionez ca atat Adi cat si eu stim destul de clar care e treaba cu IT: am facut tehnical networking la nivel inalt dar am si condus echipe care erau business enablers atat in tara cat si in afara
Legat de subiectul in sine si de multe aspecte putin cam ciudate pentru gustul meu (de ex celebrul registru, in care se pare se vor invarti o groaza de tranzactii si care banuiesc va fi o sursa finaciara pentru unii si un instrument de manevra pentru altii), ideea in sine e generoasa, este poate singura instructiune in care apare cuvantul process si nu giga de RAM sau HDD, Nu o sa comentez tehnicalitatile, Adi a acoperit multe din ideei si nu o sa fac decat sa ma repet. Ce mi-as fi dorit sa vad in schimb o abordare mult mai profunda care incepe de la un layer putin mai sus, de la peoples si in mod special de la business peoples. Exemplu curent cu Astra, un Caritas modern daca vrei, trebuia prins de ani de zile, pentru ca legislatia curenta asa cum era, era suficienta sa-i opreasca; faptul ca monitorizam numarul de incidente la diversi brokeri nu o sa ne protejeze de asemenea gainarii, trebuia sa va faceti treaba acolo unde era riscul mai mare 🙂
PS: eu am o parere diferita de activitatile de management de proiect, guess what, difera radical de modul cum le privesti tu, Un exemplu, si am vazut multi PMs, atat in afara cat si in Romania, nu i-am auzit vorbind de „incidente” niciodata!!! Ei au issues, changes, off-specifications dar niciodata incidents
ApreciazăApreciază
Ca sa nu amestecam lucrurile, Astra a avut probleme cu indicatorii de solvabilitate si lichiditate, care sunt gestionati de catre zona de riscuri specifice (solvabilitate si lichiditate). Noi vorbim de alte riscuri aici, de fapt o categorie a riscurilor operationale. Deci sa nu amesteacam prea mult ca nu se mai intelege nimic. Un exemplu util ar fi Harinvest, daca e sa dam exemple concrete. Exemplu care a si sustinut o parte a instructiunii. fiind un caz in lucru imi permit sa nu dau exemple, care le pot da intr-o intalnire directa. Legat de registru lucrurile sunt simple, anterior ASF, preluat de ASF, avem o structura de registre, de la auditori pana la firmele de elearning. Acolo companiile doar se inregistreaza. Nu vad de ce tot vezi scenarii ascunse si mari invarteli. Este tipicul romanesc de a vedea lucrile ascunse, probabil datorita mediului in care traiesc unii si trebuie sa se adapteze, dar daca fiecare incercam sa mai indreptam lucrurile cred ca putem sa si construim, nu doar sa daramama ce incearca altii sa faca. in acest sens este si propunenrea mea catre voi si catre oricine doreste sa puna umarul. Deci registrul este doar un ajutor pt entitati sa stie ca firmele respective satisfac criteriile minime de incredere. Decat sa ceara fiecare entitate documentele unui furnizor, nu e mai simplu ca acestea sa fie date si prezentate o data si restul sa stie ca acel furnizor respecta cerintele? Noi doar inregistram, nu aprobam, diferenta e f mare.
Referitor la abordare profunda, astept o propunere, dar care sa fie practica, nu ne intereseaza sa facem mai multa teorie decat este cazul. Cine doreste teorie sa mearga la cursuri. Noi trebuie sa le dam elemente cat mai concrete in aplicare. Repet inca o data, totul trebuie privind din nevoile de supraveghere.
ApreciazăApreciază
Răspund luînd în calcul doar ultima parte a mesajului. Este posibil să fie teorie și nu aplicabilitate practică așa cum afirmați dvs. deși nu prea îmi este clar cum pot oferi o soluție practică la o problemă al cărui fundament teoretic nu îl cunosc/înțeleg.
Din perspectiva practicii auditului voi încerca să vă răspund. Sau cel puțin așa cred…
ITAF™: A Professional Practices Framework for IS Audit/ Assurance, 2ndEdition reglementează misiunile CISA. Cred că acceptați că acel ‘practices’ din titlu nu are în vedere teoria. Standardele sînt obligatorii în timp ce ghidurile de lucru sînt facultative dar CISA trebuie să justifice de ce nu folosește anumite ghiduri.
The standards are mandatory in all cases. The term “shall” indicates “must”. Any deviations must be addressed prior to completion of the IS audit or assurance engagement.
The guidelines are not mandatory—but adhering to them is strongly recommended. Although they do allow IS audit and assurance professionals a degree of application freedom, professionals must be able to defend and justify any significant deviation from the guidelines or the omission of relevant sections of the guidance in the conduct of IS audit and assurance engagements. This is particularly true ifthe engagement is more at the IS audit level. Not all guidelines will be applicable in all situations, but they should always be considered.
Tools and techniques represent supplementary material and information that supports the guidance. In some cases, the techniques present alternatives or even a range of techniques, many of which may be applicable. Techniques should be selected only if they are suitable and appropriate and result in the IS audit and assurance professional obtaining appropriate, relevant, objective and unbiased information.
În momentul în care 3 din aceste standarde impun:
„IS audit and assurance professionals shall have reasonable expectation that the engagement can be completed in accordance with the IS audit and assurance standards and, where required, other appropriate professional or industry standards or applicable regulations and result in a professional opinion or conclusion”.
IS audit and assurance professionals shall select criteria, against which the subject matter will be assessed, that are objective, complete, relevant, measureable, understandable, widely recognised, authoritative and understood by, or available to, all readers and users of the report.
IS audit and assurance professionals shall consider the source of the criteria and focus on those issued by relevant authoritative bodies before accepting lesser-known criteria.
iar proiectul de instrucțiuni îmi indică 3-4 referențiale la care trebuie să ma raportez dar, în același timp, prin afirmațiile făcute Instrucțiunea intră în conflict cu referențialele indicate, ce criterii vor fi folosite în timpul misiunii?
Dacă nu greșesc raportările financiar contabile intră nu de mult timp sub incidența standardelor internaționale. Tot dacă nu greșesc, în 2011 SAS 70 a fost retras și a fost emis Service Organization Control. SOC 2 și SOC 3 vizează exact controalele operaționale în cazul furnizorilor de servicii, aplicabilitatea fiind exact în zona: securității, disponibilității, integrității, integrității procesărilor și vieții private (ultim aspect care nici măcar nu este menționat în proiectul în discuție deși entitățile vizate manipulează date personal și există un risc asociat acestora. fie el și numai de natură juridică).
ApreciazăApreciază
Well, tocmai asta e; ASF (respectiv precursorul) nu a fost in stare sa opresca o stare de fapt pe niste metrice fundamentale, la nivel strategic, iar acum tu ne sugerezi cum e timpul sa ne rafinam, chiar sa depasim zona operationala, la cei care sunt implicati pe lant pentru ca de acolo sunt problemele majore. Eu personal nu cumpar asta, mai mult, o vad ca o posibila scuza penibila pe care o sa le-o serviti acestor „oameni de business” sa-si ascunda incapacitatea si imoralitatea in spatele unor departamente de IT, in marea majoritate dedicate si oneste organizatiilor din care fac parte.
Da, cunosc teoria din spatele multor framework-uri, multe din lucrurile alea le aplic in afacerea proprie, clar nu pe toata, ca nu suntem inca multinationala, eu zic ca avem un echilibru rezonabil de pragmatism imbinat cu teorie. ASF (si precursorul) a ratat tocmai la aspectul practic, si nu ma refer la aspectul IT ci la aspectul fundamental de protectie al consumatorilor de asigurari.
However, ce nu stiii tu e ca am o doza asa de mare de lipsa de respect fata de ledership-ul current (nu personal cu tine dar fata de multi experti practicieni) incat mi-e foarte greu sa vin sa fac knowledge sharing (asta ca sa nu spun dezgustat), si nu mai am rabdare sa ascult prelegeri cum ca tre sa fim pragmatici. Faptul ca vii si ne spui in fata ca suntem teoreticieni, ca si cum am fi niste papagali de mana a doua, nu te ajuta in discutia cu noi. Uita-te bine la ce a scris Adi. noi vorbim din perspectiva unor experiente triste a unor certificari si norme (legate de audituri obligatorii in sectorul bancar, ISO27K sau ISO20K) pe care tu le numesti in instructiune. Pragmatismul cu care a fost interpretate aceste standarde in Romania, ne-a dus in situatia in care orice norma a devenit un simplu exercitiu de semnat un document si marcat banul cat mai ieftin, si nu ca un instrument de improvement.
ApreciazăApreciază
Interesanta discutia si subiectul. Ma bag si eu in seama si va spun urmatoarele:
– dezgustul fata de stat si leadershipul actual ne tine departe de decizii ale statului care ne afecteaza pe toti, inclusivi in zona de business – a sta deoparte nu e o solutie pentru nimeni
– ISACA nu reglementeaza nimic, este o asociatie profesionala din SUA, recunoscuta in piata si chiar la nivelul anumitor autoritati din SUA si alte state de prin UE – in fapt, sunt recunoscute competentele castigate prin certificarile emise, iar COBIT nu este un standard….
– sunt de acord ca implementarea by the book pentru standarde ISO 27 family nu este un business real in Romania deoarece se vand certificate pentru participarea la licitatii cu statul, iar de implementari pe bune au nevoie foarte putine organizatii, de regula care presteaza pentru extern
– de acord asupra faptului ca e mai bine sa folosim referinte functionale decat sa facem ceva prost, insa eu tare mi-as dori reglementari nationale – chiar si copiate dupa OBIT, ITIL, SOX, BASEL etc. deoarece am avea referinte comune si multe alte beneficii la nivel de comunitate profesionala, evident tinzand catre o maturitate a unei piete (auditori de toate felurile si implementatori de toate felurile) in care sa avem standarde profesionale minime si nu in ultimul rand am plati traineri romani, taxe de membership la asociatii din Romania (atentie – nu la stat), cursuri etc.
Deci…..nimeni nu detine adevarul si demersuri din categoria asta trebuie sustinute….prin contributii si nu neaparat doar prin critici de pe marginea…strazii , fie ea si virtuala
ApreciazăApreciază
Faptul că, ori de cîte ori mi-am spus punctul de vedere in urma solicitărilor de ‘consultare’ publică, s-a soldat cu o formă lipsită de orice urmă de fond, mă face să fiu mai puțin optimist. Consultarea publică se face doar ca să nu existe acuze de nerespectare a cerințelor legale. Nu detaliez aici pentru că nu are sens. Dar aș dori să mă credeți că nu fac parte din categoria celor care stau pe margine și comentează :). Am constat doar că nimic din ceea ce a fost transmis (nu neapărat de către subsemnatul…) nu a fost luat în considerare. Nu a existat nici un feedback. Prin urmare, spun lucrurilor pe nume într-un amfiteatru; în practică respect angajamentele și nu fac compromisuri mioritice; cind timpul îmi permite sau subiectul este prea fierbinte, reacționez pe blog.Am spus de nenumărate ori că nu mă erijez în…Stăpînul inelelor….Exprim opinii/interpretări, cu argumente, așa după cum am experimentat eu lucrurile.
Împărtășesc aceeași opinie cu dvs:
– ori acte normative în care nu se menționează nici un standard/framework și se definesc termenii în sensul dorit de reglementator
– ori un act normativ în care se referențiază astfel de documente, caz în care nu se deviază de la litera și spiritul lor.
(Nota bene:
Da, ISACA și altele asemenea sînt organisme profesionale. Reglementează nu activitatea membrilor ci pe a celor care sînt recunoscuți ca profesie. Discuția este ceva mai lungă și complicată și ține de profesiunile liberale așa cum funcționează în USA. Probabil dacă în România ar fi corp profesional recunscut prin lege lucrurile ar sta ceva mai diferit…Chiar nu știu cîte din companiile de asigurări de la noi oferă asigurare de răspundere civilă profesională pentru o profesie lipsită de reglementări naționale :P)
ApreciazăApreciază
Stimați Domni, poate că e mai bine să se renunțe la auditul IT, au mai făcut-o și alte instituții. Decât audit IT după o rețetă originală mai bine lipsă. Apoi dacă se presupune că trebuie să ne măsurăm mărimea și culoarea (instrucțiunea prevede sa fie … și de o culoare adecvată), din păcate, mă văd eliminat din faza de selecție, căci o am cam mică și necolorată. Să fii auditor IT, pe langă profesie este și o calitate, cu care nu intri în anumite cluburi și pe care nu o demonstrezi cu anumite diplome sau certificate. O instrucțiune, oricum ar fi ea, e bine să fie asumată și semnată. Eu îmi semnez, în clar, toate părerile iar cu această ocazie spun că deși ASF nu se introduce în perimetrul de audit este cea care introduce vulnerabilități și amenințări la adresa sistemului pe care doreste să-l creeze. Banii atrag ca un magnet fraudele, iar azi fraudele nu se mai fac cu creionul chimic. La un moment dat o fraudă se va produce, va rezulta că intrucțiunea nu a putut opri frauda ba chiar a favorizat-o. In acest moment ASF are probleme mai mari decât această instrucțiune, care poate fi rescrisă și îmbunătățită. Calitatea auditului este un concept pe care nu l-am regăsit în instrucțiune sau poate că nu e important sau poate că nu este despre audit. Domnilor, când îmi este foame gândesc prost și încet, de aceea vă rog, dacă nu mă invitați și pe mine la masa dvs., poate lăsați ușa deschisă să-mi gasesc și eu un loc.
ApreciazăApreciază
Documentul in sine este o surpriza proasta, dupa cum arata nu a fost generat intern (dar pe bani ai contribuabilului), merge la un nivel absurd de jos ca si indicatori de raportare ceea ce indica o lipsa de viziune manageriala asupra procesului si mai degraba una de control intern.
Pacat de munca depusa, avand in vedere ca nu va mai ramane aproape nimic din el.
ApreciazăApreciază
Pingback: Cum legiferăm în domeniul IT&C? | ADRIAN B. MUNTEANU