Svaka faza razvoja softvera predstavlja priliku umanjiti ranjivosti i očvrsnuti sigurnost proizvoda.
Jedna od mnogih posljedica sigurnosnih incidenata je i razvoj svijesti poslovnog subjekta da se u sigurnost vjerojatno trebalo ulagati više resursa.
Ozbiljnost ulaganja u sigurnost tada se gotovo samostalno stavlja na agendu jer postaje jasno da se nevolje, u obliku malicioznih radnji, ne događaju samo drugima.
Nažalost, tada može biti i prekasno za reakciju, jer određeni sigurnosni incidenti mogu donijeti štetu tolikog razmjera da dovedu i do kraja poslovanja unutar par godina zbog nemogućnosti oporavka.
Do takvih kritičnih trenutaka, ulaganje u sigurnost često djeluje kao dodatni napor i trošak čija dodana vrijednost nije lako uočiva na samom proizvodu ili usluzi. Softver je dobar primjer toga, jer iz korisničkih očiju, siguran i nesiguran softver ponašaju se isto. Štoviše, nesiguran softver često je i lakši za korištenje jer u komunikaciji s korisnikom automatski pretpostavlja da je on legitiman i dobronamjeran te nema dodatnih prepreka kod izvršavanja onoga što mu je zadano.
Baš zbog toga što nesigurnost nije pametno izbaciti iz računice te činjenice da su popravci ranjivosti skuplji što ih se kasnije uvodi u sustav, potrebno je na sigurnost misliti prije nego postane nužno.
Kod softvera, to prije idealno znači u svakom segmentu razvoja i implementacije [1].
U teoriji, klasični životni ciklus softvera (SDLC, Software development lifecycle) prati 6 koraka koji od početne ideje proizvoda ili usluge dovode do konačne pozicije održavanja softvera kroz feedback korisnika.
Taj SDLC sastoji se od: planiranja, analize, dizajna, implementacije, testiranja te održavanja.
Granice faza nisu uvijek jasne ili navedenim redoslijedom, ali svaki proizvod ih sigurno sadrži.
Ideja je u svakom koraku promisliti o sigurnosti i izvršiti kontrolne radnje koje bi onemogućile uvođenje ranjivosti u krajnji proizvod.
Slika 1. Sigurnost po fazama SDLC-a. [2]
Vodeći se tom idejom, već kod inicijalne faze stvaranja ideja i potencijalnih opcija aplikativnog rješenja, potrebno je uzeti u obzir sigurnosne zahtjeve.
U najširem smislu, sigurnosni incident je događaj u kojem neki od sigurnosnih zahtjeva više nije zadovoljen.
Temeljni sigurnosni zahtjevi/ kriteriji su često spominjana trijada povjerljivost-cjelovitost-raspoloživost (eng. CIA), kojima se zna nadodati neporecivost te autentičnost.
Svi navedeni zahtjevi nisu primjenjivi u svim situacijama te je zato potrebno u početnim stadijima planiranja i analize dokučiti koji od sigurnosnih zahtjeva su primjenjivi i u kakvom su odnosu sa zahtjevima korisnika.
Određivanje sigurnosnih zahtjeva koje aplikacija mora ispuniti, odredit će generalni smjer potrebnih sigurnosnih kontrola.
U sljedećem koraku, dizajnu, modeliranje prijetnji prirodan je dodatak procesu dizajniranja. Kako je ishod dizajna često popraćen dijagramom arhitekture budućeg sustava, upravo taj diagram je dalje potreban za kreiranje modela prijetnji. Modeliranje prijetnji sastoji se od analize interakcija elemenata unutar sustava s ciljem određivanja potencijalnih vektora napada i mogućih ostvarivanja prijetnji. Za to je potrebno odrediti koji elementi si smiju vjerovati, a za koje interakcije je potrebno uspostaviti dodatne sigurnosne kontrole. Na temelju dijagrama arhitekture sustava moguće je odrediti tok kritičnih informacija te kojim sigurnosnim kontrolama će se omogućiti da taj tok ostane zaštićen od neautoriziranog presretanja, izmjenjivanja ili prekidanja.
Slika 2. Tok informacija prilikom prijave korisnika. [3]
Kod implementacije programskih rješenja dolazimo i do sljedećeg koraka ostvarivanja sigurnog softvera, a to je praksa sigurnog koda. Zadnjih desetak godina došlo je do proliferacije smjernica pisanja sigurnog koda za većinu programskih jezika. Postoji mnoštvo smjernica i uputa kako pisati siguran kod [4], što je generalno ohrabrujuće za sigurnost, ali u praksi predstavlja još jedno u nizu pravila kojih se razvojni programeri trebaju držati. Među drugim pravilima su i pravilo čistog/jasnog koda, neponavljanje, dokumentiranje, dogovoreno formatiranje na određenom projektu i slično. Ta pravila se u načelu podrazumijevaju i očekuju od programera, ali pisanje sigurnog koda još uvijek nije standard.
Na programeru je odgovornost usvajanja dobrih sigurnosnih praksi, dok se u fazi testiranja te prakse validiraju. Rješenje koje može odteretiti programera i dijelom automatizirati rješavanje brige, statičke su analize pisanog koda. Postoje razni alati koji uz uobičajenu statičku provjeru uzimaju u obzir potencijalnu zloupotrebu implementacije te daju upozorenja ako se naznake mogu pronaći u kodu projekta. Fazi razvoja je ovdje u bliskom odnosu faza testiranja, koja može isto tako pružiti drugu instancu sigurnosnog feedbacka kroz eventualni review koda ili statičku analizu.
Na kraju dolazimo do faze održavanja samog rješenja gdje ponovno imamo priliku očvrsnuti sigurnost aplikacije, ovog puta provođenjem penetracijskog testiranje. Pen testovi znaju odnijeti puno resursa, posebno vremena, ali u konačnici iluzorno mogu pokazati što bi vanjski napadač morao napraviti da uđe u sustav. Svrha pen testa je pronaći ranjivosti u aplikaciji i njihovim iskorištavanjem dokazati slabe točke sigurnosti. Danas se to najčešće provodi poluautomatski i navođeno korištenjem alata za pen test. U slučaju web aplikacija, Zap je jedan open-source primjer takvog alata [5]. Zap se koristi tako da ga se navodi gdje su točke unosa i slanja podataka da bi zatim odabrali koje vrste napada izvršiti. U načelu, sve što je vidljivo na grafičkom sučelju web aplikacije može se zaobići te modificirati pozive koji se šalju prema serveru. Zap i slični alati imaju mogućnost razotkriti ranjivosti koje nastaju tek u produkcijskim uvjetima, te bi tako inicijalni i zatim povremeni pen test bio poželjan za očvršćivanje aplikacija.
Sigurnost je potrebno ispreplesti u samu srž sustava koji se gradi. Od planiranja, dizajna, implementacije i održavanja, svaki korak može unijeti ranjivosti u sustav te je tako za siguran softver vjerodostojna uzrečica “bolje spriječiti nego liječiti”, jer je lijek za softver u većini slučajeva prekasan ili preskup.
Autor:
Tin Potz, Softverski inženjer
Reference
[1] Dobre prakse sigurnosti u SDLC-u, https://vulcan.io/blog/secure-sdlc-best-practices/
[2] Sigurnost po fazama SDLC-a, Hudaib, A., AlShraideh, M., Surakhi, O., & Khanafseh, M. (2017). A survey on design methods for secure software development. Int. J. Comput. Technol, 16(7).
[3] Tok informacija prilikom prijave korisnika, https://owasp.org/www-community/Threat_Modeling_Process
[4] Generalni popis dobre prakse sigurnog koda, https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/stable-en/02-checklist/05-checklist
[5] Zap, open-source alat za penetracijsko testiranje web aplikacija, https://www.zaproxy.org/
