Sigurno kodiranje - Izazovi u informacijskoj sigurnosti

• Sigurnosna ranjivost u kodovima
• Otvoreni kôd i napadi na lanac opskrbe
• Kontrola informacijske sigurnosti 8.28 za sigurno kodiranje
• Načela sigurnog kodiranja
• Zaključak
• Revizija ISO 27001: Što ažuriranje znači za vašu certifikaciju?
• DQS - Simply leveraging Security.

Sigurnosna ranjivost u kodovima

Temeljne komponente svih digitalnih infrastruktura su softveri operacijskih sustava, aplikacija ili ugrađeni programi (firmware). No, ubrzanost i pritisak zbog rokova u digitalizacijskim projektima često vode do zanemarivanja nužnih aspekata informacijske sigurnosti. Zahtjevi za razvoj softvera obično se temelje na funkcionalnosti i naglašavaju konstruktivne aspekte, pa je štetnost sigurnosne ranjivosti u suprotnosti sa stvarnim razvojnim ciljevima: mnogi programeri nemaju dovoljno jasno i strukturirano znanje o kibernetičkoj sigurnosti.

U ovakvim situacijama razvojnim je timovima vrlo zahtjevno neprekidno pregledavati i osiguravati kodove svojih softvera, čemu svjedoče mnoge ranjivosti koje objavljuje neprofitna organizacija MITRE na svojoj CVE (Common Vulnerabilities and Exposures) listi ranjivosti i izloženosti. Sigurnosne zakrpe čak i poznatih proizvođača softvera pokušavaju zatvoriti sigurnosne propuste i to se čini kao Sizifov posao, a da ne govorimo tek o prepoznavanju istih prije nego što su objavljeni na tržištu.

Otvoreni kôd - zaseban slučaj

Pri kodiranju samostalnog softvera, programeri rado koriste biblioteke i module otvorenog koda. Praktične prednosti su očigledne: ako ne morate otkrivati toplu vodu, koristit će vam ovakva tehnologija, brzi razvoj, niži troškovi, transparentnost koju pruža otvoreni kôd, te veća interoperabilnost dobivena kroz otvorene standarde i sučelja. 

Također, često se priča o tome da je otvoreni kôd puno sigurniji jer ga je potvrdio velik broj korisnika, a gomilanje podataka prikupljenih na ovakav način omogućava brzo i efikasno ispravljanje grešaka.

U stvarnosti se ovo mišljenje treba ispitati na slojevit i kritičan način. Najozbiljniji je primjer takozvana zero-day sigurnosna ranjivost Log4Shell u popularnoj biblioteci za Java aplikacije Log4J, koja je otkrivena u studenom 2021. Možda ste čuli za upozorenje o visokom riziku od Log4Shell-a koje je izdao Njemački savezni ured za informacijsku sigurnost (BSI). Biblioteka Log4J, koju je proširio Apache Foundation (organizacija za potporu projekata softvera otvorenog koda) kao funkcionalni kvazi-standard, pronašla je svoje mjesto u mnogim sustavima od 2013. - uključujući i poznate web poslužitelje kao što je Amazon AWS.

Složenost ovih visoko razvijenih i održavanih biblioteka implicitno dopušta i korištenje snažnih funkcija kojih vanjski programeri često nisu svjesni u svom radu, a koje mogu iskoristiti napadači.

Još jedan čimbenik nesigurnosti kod komponenti otvorenog koda takozvani su napadi na lanac opskrbe, tj. ciljano ugrađene ranjivosti koje zlonamjerni programeri ugrađuju pretvarajući se da su dio sredine otvorenog koda i da pomažu u razvoju koda. Takva ranjivost izrazito je korisna hakerima koji putem nje napadaju brojne organizacije koje koriste tzv. downstream. Zato nije neobično što se ubrzano povećava broj napada: istraživanje softverskog poduzeća Sonatype utvrdilo je povećanje od 650% između 2020. i 2021. godine.

Kontrola informacijske sigurnosti 8.28 za sigurno kodiranje

Kako bi se pravovremeno očuvala sigurnost procesa razvoja softvera, Međunarodna organizacija za normizaciju (ISO - vijeće ISO/IEC JTC 1/SC 27) uvela je "Sigurno kodiranje" kao novu kontrolu 8.28 nove verzije norme ISO/IEC 27002 i ISO/IEC 27001:2022, standardi Priloga A. Svrha ove tehničke mjere za sigurno kodiranje preventivna je zaštita softvera.

Minimalna razina sigurnosti stvorena je na bazi proceduralnih zahtjeva, smanjujući tako broj mogućih sigurnosnih ranjivosti u softverima. Zahtjevi za stvaranje sigurnog koda primjenjivat će se sveobuhvatno i na programski kôd određenog poduzeća i na softvere trećih strana i izvora otvorenog koda. Neka od značajnijih načela implementacije su takozvani Security by Design i Least Privilege, koji su važni i u kodiranju.

Načela sigurnog kodiranja

Mjera 8.28 nekoliko puta spominje takozvana načela sigurnog kodiranja. Brojne organizacije i instituti koji redovito objavljuju vodiče i savjete za sigurno kodiranje daju detaljnije informacije o načelima. To su, na primjer, Načela sigurnog kodiranja zaklade OWASP, Standardi sigurnog kodiranja CERT-a (Computer Emergency Response Team) Instituta za softversko inženjerstvo (Software Engineering Institute - SEI), te katalog mjera za sigurnost web aplikacija njemačkog BSI-ja. Unatoč različitim izvorima, objašnjenja su u mnogočemu slična, kao na primjer u sljedećem:

• Vrednovanje ulaznih podataka
• Zaštita upravljanja autentifikacijom i lozinkama
• Kontrola sigurnosnog pristupa
• Jednostavan, transparentni kôd
• Provjerene kriptografske mjere i komponente
• Upravljanje i bilježenje pogrešaka
• Zaštita podataka
• Model prijetnji

U standardu ISO/ISO 27002:2022, preporučeni koraci za Kontrolu 8.28 podijeljeni su u tri dijela, "Planiranje i predkodiranje" "Kodiranje" i "Verifikacija i održavanje", čiji je temeljni sadržaj opisan u nastavku. 

Planiranje i predkodiranje

I razvoj novog i ponovno korištenje istog koda zahtijevaju primjenu načela sigurnog kodiranja - bez obzira na to je li kôd napisan za interni softver ili za vanjske proizvode i usluge. Zbog toga je potrebno unaprijed razumjeti očekivanja određene organizacije i značenje poznatih načela. Također, preporučene aktivnosti planiranja i predkodiranja uzimaju u obzir već poznate prakse kodiranja, kao i pogreške koje vode k ranjivostima.

Konfiguracija razvojnih alata, kao što je slučaj u integriranom razvojnom okruženju (IDE), trebala bi uključivati stvaranje sigurnog koda. Ono što je nesigurno jesu kvalifikacije programera i njihova upoznatost sa sigurnim arhitekturama i standardima programiranja. Podrazumijeva se stručnost za informacijsku sigurnost u razvojnim timovima.

Tijekom procesa kodiranja

Tijekom procesa kodiranja, načela kodiranja i tehnike strukturiranog programiranja dolaze u prvi plan, uzimajući u obzir posebne slučajeve i njihove sigurnosne potrebe. Nesigurne tehnike dizajna - na primjer, kodirane šifre - trebale bi biti trajno zabranjene. Kôd bi trebao biti adekvatno dokumentiran i pregledan kako bi se smanjila mogućnost sigurnosnih grešaka. Kôd bi se trebao pregledavati i tijekom i nakon razvoja putem ispitivanja sigurnosti statičkih aplikacija (SAST) ili sličnog postupka. Postupci statičkog ispitivanja vode se pristupom tzv. pomicanja ulijevo ("testiraj rano i često") pomicanjem ulijevo unutar životnog ciklusa aplikacija tako da se rano testira vidljivi kôd koji se treba prilagoditi pravilima.

Ovime se veoma rano mogu utvrditi zaraženi kôd, njegove veze s datotekama ili određenim kategorijama, ili propusti na razini aplikacija koji se mogu iskorištavati za nezapažene interakcije s programima trećih strana, a koji predstavljaju ranjivosti. Prije nego što se softver pokrene, Kontrola 8.28 zahtijeva evaluaciju područja napada i implementaciju takozvanog principa najmanje privilegije (least privilege). Trebala bi se ocijeniti i analiza najučestalijih grešaka pri programiranju te dokumentacija njihovih ispravaka. 

Verifikacija i održavanje

Čak i kada je softver pokrenut, potrebno je misliti na sigurnost kodiranja. To uključuje sigurnosna ažuriranja, ali i provjere poznatih ranjivosti u nekom kodu. Također, potrebno je dokumentirati greške i sumnje na napade kako bi se ispravno provele sve potrebne prilagodbe. U svakom slučaju, neovlaštene pristupe izvornom kodu potrebno je pouzdano spriječiti odgovarajućim alatima.

Otvoreni kôd

U području verifikacije i održavanja, Mjera 8.28 sadrži i jasne upute za korištenje vanjskih alata i biblioteka, kao što su softveri otvorenog koda. Ovakve komponente koda potrebno je voditi, ažurirati i održavati u inventarima. To je moguće, na primjer, pomoću SBOM-a (Software Bill of Material), službenog, strukturiranog popisa softverskih paketa i biblioteka, te njihovih povezanosti kako međusobno, tako i s lancem opskrbe, prvenstveno radi praćenja ponovng korištenja koda i komponenti otvorenog koda. SBOM pomaže u održavanju softvera i u potrebnim sigurnosnim ažuriranjima.

Zaključak

Sigurno kodiranje predstavlja temelj za zaustavljanje mogućih napada. Nova kontrola 8.28, imajući u vidu ove izazove, nadograđuje ključnu ulogu sigurnog kodiranja u njegovoj važnosti za informacijsku sigurnost. Ipak, s obzirom na to da mjera sadrži velik broj detaljnih preporuka i da je tehnički zahtjevna, bit će potrebno uložiti mnogo truda kako bi se implementirala - ovo bi trebalo uzeti u obzir od početka samog planiranja. 

U postizanju sukladne implementacije ove mjere podupiremo vas kroz profesionalnost naših iskusnih auditora. Uz više od 35 godina iskustva u auditima i certifikacijama vaš smo idealan partner i rado ćemo vam dati odgovore na pitanja vezana za područje informacijske sigurnosti i certifikacije prema normi ISO/IEC 27001:2022.

Revizija ISO 27001: Što ažuriranje znači za vašu certifikaciju?

ISO/IEC 27001:2022 objavljen je 25. listopada, 2022. To rezultira sljedećim prijelaznim vremenskim okvirima i rokovima za korisnike norme:

Posljednji datum za audite za inicijalnu certifikaciju ili recertifikaciju prema "staroj" normi ISO 27001:2013 

• Nakon 30. travnja 2024. DQS će provoditi certifikacijske i recertifikacijske audite isključivo prema novom standardu ISO/IEC 27001:2022

Prijelaz svih postojećih certifikata sa "stare" ISO/IEC 27001:2013 na novu normu ISO/IEC 27001:2022 

• Prijelazni period od 3 godine započinje 1. listopada 2022.
• Certifikati izdani prema normi ISO/IEC 27001:2013 ili DIN EN ISO/IEC 27001:2017 valjani su najkasnije do 31. listopada 2025., ili na ovaj datum trebaju biti povučeni. 

DQS: Simply leveraging Security.

Zbog prijelaznih perioda poduzeća imaju dovoljno vremena kako bi prilagodila svoje sustave upravljanja informacijskom sigurnošću (ISMS) novim zahtjevima i certificirala ih. Ipak, duljina i trud uložen u čitavi proces ne smije se podcijeniti - osobito ako nemate dovoljno specijaliziranih ljudskih resursa. Ako želite igrati na sigurno, trebali biste se pozabaviti ovom temom što je ranije moguće te ako je potrebno, pozvati iskusne stručnjake u pomoć.

Kao stručnjaci u auditima i certifikacijama već više od 35 godina, rado ćemo vas poduprijeti u ocjeni vašeg trenutnog statusa, na primjer, kao dio delta audita. Od naših brojnih iskusnih auditora saznajte više o najvažnijim promjenama i tome kako se one odražavaju na vašu organizaciju. Zajedno ćemo utvrditi vaš potencijal za napredak i poduprijeti vas da dobijete novi certifikat. Iskoristite priliku koju vam pruža naša stručnost iz područja informacijske sigurnosti! Radujemo se našem razgovoru.