1. Kaj je izziv pri dajanju zagotovil pri projektih za razvoj rešitev?
Boža Javornik, CISA, CISM, PRIS

2. Kaj so pričakovanja? Kaj je lahko problem?
Revizor mora podati zagotovilo da so prakse za pridobivanje, razvoj, testiranje in uvajanje rešitev informacijskega sistema zagotavljajo doseganje strategije podjetja in zagotavljajo skladnost delovanja.
Možne težave:
spremembe v okolju poslovanja in IKT:
Pritisk števila in hitrosti uvajanja sprememb,
24x7 delovanje,
nove tehnologije, viri za pridobivanje ustreznih znanj in hitrost izgube le teh,
čas, ki je na razpolago za izvedbo,
Lean pristopi, ki ne priznavajo nujnosti nekaterih aktivnosti.
Konferenca za izzive vodenja, tveganj, varnosti in revizije IKT 2016
: Kaj je izziv pri dajanju zagotovil pri projektih za razvoj rešitev

3. Kaj to pomeni? Revizor mora:
Oceniti poslovni primer predlaganega nakupa, razvoja, vzdrževanja in posledično ukinitve z namenom podajanja zagotovila, da to izolnjuje doseganje ciljev strategije podjetja.
Oceniti postopek izbora dobaviteljev in upravljanja pogodb z namenom podajanja zagotovila, da bodo zahteve podjetja glede nivoja njegovih storitev izpolnjene in nadzorovane.
Oceniti metodologijo podjetja za vodenje projektov z vidika upravljalnih kontrol, ki zagotavljajo, da bodo poslovne zahteve dosežene na poslovno učinkovit način in bodo tveganja sprejemljiva in obvladovana.
Izvesti pregled napredka na projektu z namenom ocenitve doseganja dogovorjenega plana izvedbe in je to podprto z ustreznimi dokazili / dokumentacijo in je bilo poročanje pravočasno in točno.
Konferenca za izzive vodenja, tveganj, varnosti in revizije IKT 2016
: : Kaj je izziv pri dajanju zagotovil pri projektih za razvoj rešitev

4. Kaj to pomeni? - 2
Oceniti uspešnost delovanja control za informacijske sisteme v procesih oblikovanja zahtev (poslovnih in ostalih), nabave, razvoja in testiranja in skladnost control s politikami, standardi podjetja in zunanjimi zahtevami (predpisov in pogodb).
Oceniti dejansko pripravljenost rešitve za uvedbo v produkcijo (uporabo) in obstoj dokazil za izpolnitev zahtevanih pogojev za uvedbo in delovanje na nivoju zahtevanega nivoja storitev skladno z zahtevami kontrolnega okolja organizacije.
Ugotoviti ali je bil ustrezno izveden pouvedbeni pregled in je bilo ocenjeno ali so bile realizirane vse zahteve in rešitev deluje skladno s pričakovanji v vseh elementih delovanja in uporaba rešitve potrjuje doseganje učinkov ovrednotenih v poslovnem primeru.
Konferenca za izzive vodenja, tveganj, varnosti in revizije IKT 2016
: : Kaj je izziv pri dajanju zagotovil pri projektih za razvoj rešitev

5. Kaj je potrebno proučiti?
Projekt za novo rešitev
Rezultati projektnega vodenja
Komunikacijski plan
Plan kakovosti
Določitev vsebine projekta
Plan upravljanja tveganj
Časovni projektni plan
Rezultati realizacije projektne naloge
Zagotovitev potrebne infrastrukture
Poslovne zahteve
Zahteve za podsisteme
Arhitekturo /načrt rešitve
Specifikacije /design dokumenti
Specifikacije za konverzijo podatkov
Razvoj
aplikacije
Programska koda/paketi
Rešitve za konverzijo
Rešitve za integracijo & varnost
Testni primeri in poročila
Plan uvedbe spremembe

6. Kaj mora revizor pregledati in ovrednotiti z vidka vodenja projekta?
Revizor mora pregledati ustreznost aktivnosti vodenja projekta:
Nivo dejanskega nadzora nadzorne skupine projekta
Metode identifikacije in upravljanja s tveganji
Upravljanje problemov
Upravljanje stroškov
Proces načrtovanja rešitev, integracije in konverzije, identifikacije soodvisnosti in njihovo upravljanje,
Sistem poročanja
Kontrole za uvajanje sprememb & celovit QA
Vključenosti vseh (zainteresiranih) deležnikov
Postopke odločanja in odobritev
Konferenca za izzive vodenja, tveganj, varnosti in revizije IKT 2016
: : Kaj je izziv pri dajanju zagotovil pri projektih za razvoj rešitev

7. Kaj mora revizor pregledati in ovrednotiti z vidka vodenja projekta
Kaj mora revizor pregledati in ovrednotiti z vidka vodenja projekta? - IZZIVI
Projektne metodologije z vidika upravljanja projektov – malo sprememb; z vidika razvoja rešitev - veliko sprememb
Spremenjene metodologije razvoja rešitev (SDLC vs. AGILE)
Postopnost /(ne)celovitost nastajanja zahtev in specifikacij (iterativnost)
Uporaba “modulov” tretjih
Ustreznost tradicionalnih kontrol uvajanja sprememb
Nova orodja za skupinsko delo
Testiranje – kaj sploh predstavlja “regresijo”
Konferenca za izzive vodenja, tveganj, varnosti in revizije IKT 2016
: : Kaj je izziv pri dajanju zagotovil pri projektih za razvoj rešitev

8. SDLC

9. Iterativni razvoj – osnovni glavni poslovni tok, kompleksneše zahteve, izjeme

10. Agilni pristop (business, market driven)

11. Razlike med SDLC in Agile pomembne za revizorja?
SDLC – zaključene predhodne faze, natančne opredelitve zahtev (tudi integracije), visoka dokumentiranost, čiste vloge…
Agilne:
Bolj opredeljeno: “kaj ni kot kaj je” glede funkcionalnosti; poslovne kontrole, integracije, računovodstvo praviloma na koncu razen, kar je nujno – torej realizacija “na obroke”
Kompromisi glede dokumentacije – kaj je že dovolj dobro
Mešane ekipe in slaba delitev (razmejitev) vlog
Ključno, kako se odziva na spremembe (statistika več kot polovica elementov (features) ni dejansko uporabljena
Ohlapni kriteriji sprejema spremembe (razvoj varne programske opreme mora biti kultura, ne zahteva metodologije)
Razvijalci se poslužujejo “test takoj po razvoju”
Testira se funkcionalnost z vidika “zgodbe” uporabnikov
Težava revizorja: zanašanje na jamstva kako dobro deluje agilni pristop
Konferenca za izzive vodenja, tveganj, varnosti in revizije IKT 2016
: : Kaj je izziv pri dajanju zagotovil pri projektih za razvoj rešitev

12. Lean pristopi
Bistvo Lean metode – izločanje aktivnosti, ki odnašajo vrednost:
Defects – odprava napak v produktih in podatkih
Overproduction – izdelava več/boljše produkte, kot je potrebno
Waiting – oprema ali izvajalci čakajo
Not Utilized Talent – neučinkovita raba znanj
Transportation – premiki materialov, polizdelkov, ki ne prinašajo dodane vrednosti
Inventory – delo na rezervo - stvari, ki jih stranke niso naročile
Motion – premiki ljudi in opreme, ki nima dodane vrednosti
Excess processing – vsako procesiranje, ki ne prinaša vrednosti
Konferenca za izzive vodenja, tveganj, varnosti in revizije IKT 2016
: : Kaj je izziv pri dajanju zagotovil pri projektih za razvoj rešitev

13. Kaj dodaja vrednost na projektih?
Načrtovanje
Analiza zahtevkov
Načrtovanje / design rešitev za zahtevke
IS Arhitektura in podrobni načrti
Pregledi arhitekture in načrtov
Kodiranje
Pregled kode
Testiranje
Neprenehna integracija
Uvedbe v produkcijo in uporabo
Prenosi znanja k strankam
Konferenca za izzive vodenja, tveganj, varnosti in revizije IKT 2016
: : Kaj je izziv pri dajanju zagotovil pri projektih za razvoj rešitev

14. Kaj ne dodaja vrednosti?
Projektno vodenje (primeroma): neučinkovita prioritizacija, preveč paralelnih aktivnosti/projektov, ne uporaba razpoložljivih kadrov in čakanje na “zvezde”, zahteve z malo ali nič dodane vrednosti – nice to have, zamude pri odločanju, nezadostni viri, ekipe na različnih lokacijah, nepotrebno administriranje in sestanki brez dnevnega reda (zaključkov), preveč managementa – premalo izvajalcev na “delivery” aktivnostih, odlašanje z opredelitvijo integracije, ….
V razvoju rešitve (primeroma): pomanjkljivo komuniciranje med lastnikom zahteve /projekta in izvajalci, dodatno kodiranje, ki ni naročeno, nekompletne zahteve/specifikacije, prekinjanje aktivnosti v teku, čakanje na dokončane soodvisnega razvoja, prepozna vključitev testerjev in premajhne testne ekipe, odpoved funkcionalnosti, ko je že delno kodirana, nestrukturiran sistem za zagotavljanje kakovosti (QA), Preveč ekstenzivni pregledi skladnosti in regulatorjev, pomanjkljiva analiza, ki vodi k večkratnemu razvoju istih funkcionalnosti, preveč / premalo regresije
Konferenca za izzive vodenja, tveganj, varnosti in revizije IKT 2016
: : Kaj je izziv pri dajanju zagotovil pri projektih za razvoj rešitev

15. Pristopi k zagotavljanju kakovosti rešitev
Pregledi vključevanja v arhitekturo IS, načrtov rešitev in integracije, podatkovnih modelov – preprečevanje redundantnih rešitev, odvečnega procesiranja zaradi neustrezne integracije, optimizacije testnih scenarijev
Pregled kode, pregled SQL – navzkrižno razvijalci z namenom preprečevanja varnostnih lukenj, neučinkovite izrabe virov in pritiska na kapacitete na sploh
Učenje na napakah, promocija dobrih praks
Standardi, orodja za skupinsko delo zagotavljanje transparentnosti – omogočanje vzdrževanja in revidiranja
Kombinacija profesionalnih testerjev in testerjev lastnika produkta
QA – standardiziran proces
Konferenca za izzive vodenja, tveganj, varnosti in revizije IKT 2016
: : Kaj je izziv pri dajanju zagotovil pri projektih za razvoj rešitev

16. Pristop pri revidiranju rešitev
Kaj in zakaj kot del splošnih kontrol?
Uvajanje sprememb – rigoroznost pristopa
Pregled designa, kode – lesson learned
Testiranje – sistematičnost, attittude
Možno definirati slučajnostne vzorce, ukrepi za izboljšave so sistemski;
Kaj in zakaj kot revizija rešitve?
Pregled poslovne zahteve in BCE – preventiva za preprečevanje aktivnosti brez dodane vrednosti kasneje
Post-mortum in po-implementacija – zahteve vs. rezultati, scenariji in dejanski učinki za BCE so konkretni
Ukrepi za izboljšave so zahteve za spremembe / izboljšave rešitev in poslovnega obnašanja – konkretne in vezane na rešitev
Konferenca za izzive vodenja, tveganj, varnosti in revizije IKT 2016
: : Kaj je izziv pri dajanju zagotovil pri projektih za razvoj rešitev

17. Ali je pristop odvisen od metodologije: SDLC vs. AGILE
Pregledi, ki so del splošnih kontrol so praviloma neodvisni od metodologije, saj “v metodologijah postavljene splošne kontrole” morajo že upoštevati razliko, če je to NUJNO
Pregledi kot revizije rešitve so odvisni od metodologije, pri agilnih pristopih je smiselno je revizije opraviti zgodaj, da se zagotovi cikel izboljšav
Oba pristopa: testiranje (ranljivosti – sistemski pristopi in uporaba orodij na pravi način), funkcionalnosti – uporabniški scenariji), testi konverzije, stres testi;
ključna aktivnost revizorja: pregled sledljivosti izvedbe testnih scenarijev, odprave defktov, odobritev sprememb
Neodvisno testiranje – revizor ne dela več, pogosti najem etičnega hackinga
Konferenca za izzive vodenja, tveganj, varnosti in revizije IKT 2016
: : Kaj je izziv pri dajanju zagotovil pri projektih za razvoj rešitev

18. Testiranje: Najboljše prakse so kombinirane tehnike:
nulto testiranje navskrižno razvijalci,
regresijsko s tehnikami avtomatskega testiranja,
orodji za Hacking,
uporabniki s pravimi scenariji
Konferenca za izzive vodenja, tveganj, varnosti in revizije IKT 2016
: : Kaj je izziv pri dajanju zagotovil pri projektih za razvoj rešitev

19. Primer: Ranljivost na SQL vrivanje pri NoSQL bazah
Rangi uporabe baz: 1. Oracle, 2.MYSQL, 3 MS SQL server, 4.MongoDB, 5.PostgresSQL, 6.DB2, 7. MS Access, 8. Cassandra, 9. SQLite, 10.Redis
Vrste napadov, ki so izvedljivi tudi za NoSQL:
Tautologies – obhajanje avtorizacije z vedno pravilnimi izrazi ($ne)
SQL z unijo pogojev (OR, empty )
JavaScript
Piggybacked (CRLF)
Origin violation (HTTP REST APIs)
Konferenca za izzive vodenja, tveganj, varnosti in revizije IKT 2016
: : Kaj je izziv pri dajanju zagotovil pri projektih za razvoj rešitev

20. Tehnike preprečevanja
Testiranje vrivanja – interni QA proces
Povečanje zavedanja, povečanje znanj: “greh se pove, grešnika zamolči”, učenje na napakah
Design – varnostna vprašanja morajo biti obravnavana, kompleksnejši SQL obravnavani
Najboljše prakse kodiranja kot interni standardi, navzkrižni pregledi kode razvijalcev
Pooblastila – minimum pooblastil, tehnike izolacije kritičnih funkcij
Varnostni pregledi z metodo vdiranja
Varno nameščanje in zaščita API-jev
Konferenca za izzive vodenja, tveganj, varnosti in revizije IKT 2016
: : Kaj je izziv pri dajanju zagotovil pri projektih za razvoj rešitev

21. Zaupanje sebi pri dajanju zagotovil je nekaj tega
Učenje, seznanjanje, analiziranje in ovrednotenje tveganja, prava mera panike in ignorance, primerna mera samozavesti
Vprašanja?
Hvala!
Konferenca za izzive vodenja, tveganj, varnosti in revizije IKT 2016
: Naslov prispevka…