Bezbedno kodiranje - Izazovi u bezbednosti informacija

• Bezbednosne ranjivosti u kodu
• Otvoreni izvorni kod i napadi na lanac snabdevanja
• Kontrola bezbednosti informacija 8.28 bezbedno kodiranje
• Principi bezbednog kodiranja
• Zaključak
• Revizija ISO 27001: Šta ažuriranje znači za vašu sertifikaciju?
• DQS - Jednostavno korišćenje bezbednosti.

Bezbednosne ranjivosti u kodu

Softver operativnog sistema, aplikativni softver ili firmver u ugrađenom sistemu su elementarne komponente bilo koje digitalne infrastrukture. Sve veće ubrzanje i pritisak na rokove u projektima digitalizacije često dovode do zanemarivanja imperativnih aspekata bezbednosti informacija. Razvojni zahtevi za softver su obično usmereni na funkciju i naglašavaju konstruktivne aspekte, tako da je destruktivni pogled na potencijalne bezbednosne propuste uglavnom dijametralno suprotan stvarnim razvojnim ciljevima: mnogim programerima jednostavno nedostaje strukturiran i izoštren pogled na sajber bezbednost.

U ovim uslovima, razvojnim timovima je teško da kontinuirano pregledaju i dosledno obezbeđuju kodiranje svog softvera, o čemu svedoče mnoge ranjivosti koje neprofitna korporacija MITER svake godine objavljuje na svojoj listi CVE (Common Vulnerabilities and Ekposures). Redovne bezbednosne zakrpe čak i poznatih proizvođača softvera su pokazatelj sizifovog zadatka zatvaranja sigurnosnih grešaka, a kamoli da ih identifikuju pre nego što se uopšte plasiraju na tržište.

Otvoreni izvorni kod (source code) - poseban slučaj

Kada kodiraju softver koji su sami razvili, programeri vole da pribegavaju bibliotekama i modulima otvorenog koda. Praktične prednosti su očigledne: ako ne morate ponovo i iznova da izmišljate točak, imate koristi od ovog unapređenja tehnologije, brzog razvoja, nižih troškova razvoja, veće transparentnosti preko otvorenog koda i međusobno delovanje kroz otvorene standarde i interfejse .

Takođe se često kaže da kod iz otvorenog koda nudi visok stepen sigurnosti jer je kod potvrđen od strane mnogih korisnika, a inteligencija roja zajednice otvorenog koda omogućava brzo i efikasno ispravljanje grešaka.

U praksi, ovo poverenje se sada mora vrednovati na diferenciran i kritički način. Najozbiljniji primer je bezbednosna ranjivost nultog dana Log4Shell u široko korišćenoj biblioteci evidencije Log4J za Java aplikacije, koja je otkrivena u novembru 2021. Možda ste čuli za nivo crvenog upozorenja koji je izdala kancelarija za bezbednost informacija (BSI ) za Log4Shell. Log4J biblioteka, distribuirana kao pouzdano funkcionalan kvazi-standard preko Apache fondacije, etablirala se u mnogim sistemima od 2013. godine – uključujući dobro poznate veb servise kao što je Amazon AVS.

Složenost ovih dobro razvijenih i takođe održavanih biblioteka implicitno pruža moćne funkcionalnosti kojih programer koji uvozi često nije svestan u sopstvenom kombinovanom novom razvoju, ali koje napadači mogu da iskoriste.

Drugi faktor nesigurnosti komponenti otvorenog koda su takozvani napadi na lanac snabdevanja, to jest, namerene ugrađene ranjivosti od strane zlonamernih aktera koji se predstavljaju kao deo zajednice otvorenog koda i pomažu u razvoju koda. Takva ranjivost je izuzetno efikasan način za hakere da napadnu veliki broj organizacija korisnika na nižem nivou. Nije ni čudo što ovaj vektor napada brzo raste: studija Sonatipe je dijagnostikovala povećanje od 650% kada se uporede 2020. i 2021.

Kontrola bezbednosti informacija 8.28 bezbedno kodiranje

Da bi se pravovremeno zaštitio proces razvoja softvera, Međunarodna organizacija za standardizaciju (ISO - komitet ISO/IEC JTC 1/SC 27) je uključila „Bezbedno kodiranje“ kao novu kontrolu 8.28 u novi ISO/IEC 27002 i ISO/IEC 27001:2022, Aneks A standardi. Svrha tehničke mere za bezbedno kodiranje je preventivna zaštita softvera.

Minimalni nivo bezbednosti se stvara već u fazi pisanja na osnovu proceduralnih propisa, čime se minimizira broj potencijalnih bezbednosnih propusta u softveru. Regulatorni okvir za bezbedno generisanje koda treba da se primenjuje holistički i na sopstveni programski kod kompanije i na softver trećih strana i otvorenog koda. Značajni principi za implementaciju su Securiti by Design i Least Privilege, koji se takođe moraju uzeti u obzir u kodiranju.

Principi bezbednog kodiranja

Mera 8.28 se više puta bavi takozvanim principima bezbednog kodiranja. Smernice o tome šta bi to moglo biti daju brojne organizacije i instituti koji redovno izdaju vodiče i najbolje prakse za bezbedno kodiranje. To uključuje, na primer, prakse bezbednog kodiranja Fondacije OWASP, standarde bezbednog kodiranja tima za reagovanje na računarske hitne slučajeve (CERT) Instituta za softversko inženjerstvo (SEI) i katalog mera za bezbednost veb aplikacija nemačkog BSI. Uprkos različitim izvorima, elaborati pokazuju mnoge paralele, na primer u pogledu sledećih tačaka:

• Validacija unosa podataka
• Obezbeđivanje autentifikacije i upravljanje lozinkama
• Bezbedna kontrola pristupa
• Jednostavan, transparentan kod
• Održivo testirane kriptografske mere i komponente
• Rukovanje greškama i evidentiranje
• Zaštita podataka
• Modelovanje pretnji

U standardu ISO/ISO 27002:2022, preporučene radnje za Kontrolu 8.28 podeljene su u tri odeljka, „Planiranje i prethodno kodiranje“, „Tokom kodiranja“ i „Verifikacija i održavanje“, čiji je osnovni sadržaj naveden u nastavku.

Planiranje i prethodno kodiranje

Razvoj novog koda i ponovna upotreba koda zahtevaju primenu principa bezbednog kodiranja – bez obzira da li je kod napisan za interni softver ili za eksterne proizvode i usluge. Ovo zahteva unapred procenu očekivanja specifičnih za organizaciju i definisanje priznatih principa. Pored toga, preporučene akcije za planiranje i prethodno kodiranje uzimaju u obzir poznate uobičajene i istorijske prakse kodiranja i greške koje mogu dovesti do ranjivosti.

Konfiguracija razvojnih alata, kao što je bazirana na pravilima u integrisanim razvojnim okruženjima (IDE), treba da nametne pravljenje bezbednog koda. Prilično je kritična kvalifikacija programera i njihovo poznavanje bezbednih arhitektura i programskih standarda. Uključivanje ekspertize za bezbednost informacija u razvojni tim se podrazumeva.

Tokom procesa kodiranja

Tokom procesa kodiranja, prakse kodiranja i tehnike strukturiranog programiranja igraju primarnu ulogu, uzimajući u obzir specifičan slučaj upotrebe i njegove bezbednosne potrebe. Nesigurne tehnike dizajna – na primer, tvrdo kodirane lozinke – treba dosledno zabranjivati. Kod treba da bude adekvatno dokumentovan i pregledan kako bi se na najbolji način eliminisale greške vezane za bezbednost. Pregled koda treba da se odvija tokom i nakon razvoja, putem statičkog testiranja bezbednosti aplikacije (SAST) ili slično. Metode statičkog testiranja podržavaju pristup pomeranja ulevo („testirajte rano i često“) pomeranjem ulevo u životnom ciklusu tako što rano testiraju vidljivi kod za usaglašenost pravila.

Ovo omogućava ranu identifikaciju oštećenog koda, veze sa datotekama ili specifičnim klasama objekata ili praznine na nivou aplikacije koje se mogu zloupotrebiti za neprimećenu interakciju sa programima trećih strana kao ranjivosti koje se mogu iskoristiti. Pre nego što se softver pusti u rad, Control 8.28 zahteva procenu površina napada i primenu principa najmanjih privilegija. Treba proceniti izvršenu analizu najčešćih programskih grešaka i dokumentaciju o njihovom ispravljanju.

Verifikacija i održavanje

Čak i nakon što je softver pokrenut, tema bezbednog kodiranja ostaje relevantna. Ovo uključuje bezbedna ažuriranja, kao i provere poznatih ranjivosti u nečijem kodu. Pored toga, greške i sumnjivi napadi moraju biti dokumentovani tako da se neophodna prilagođavanja mogu izvršiti što pre. U svakom slučaju, neovlašćeni pristup izvornom kodu mora biti pouzdano sprečen odgovarajućim alatima.

Otvoreni Source code

U oblasti verifikacije i održavanja, Mera 8.28 dodatno navodi eksplicitna uputstva za korišćenje eksternih alata i biblioteka, kao što je softver otvorenog koda. Ovim komponentama koda treba upravljati, ažurirati ih i održavati u zalihama. Ovo se može uraditi, na primer, preko softverske liste materijala (SBOM). SBOM je formalni, strukturirani zapis o softverskim paketima i bibliotekama i njihovim međusobnim odnosima i unutar lanca snabdevanja, posebno za praćenje ponovo korišćenog koda i komponenti otvorenog koda. SBOM podržava mogućnost održavanja softvera i ciljana bezbednosna ažuriranja.

Zaključak

Bezbedni kod je osnovna za zaustavljanje potencijalnih napada. Novi Control 8.28 uzima u obzir ovaj dugotrajni uvid i unapređuje ključnu ulogu bezbednog kodiranja u njegovom značaju za bezbednost informacija. Međutim, pošto mera sadrži veliki broj detaljnih preporuka za akciju i tehnički je zahtevna, njena implementacija će zahtevati relativno visok nivo napora – to treba uzeti u obzir već u fazi planiranja.

Sa profesionalnim stavom naših iskusnih proveravača, podržavamo vas u usklađenoj implementaciji mere. Sa našom stručnošću u proveri i sertifikaciji od više od 35 godina, mi smo vaš idealan kontakt partner i rado ćemo vam pomoći u vezi sa temom bezbednosti informacija i sertifikacije u skladu sa standardima ISO/IEC 27001:2022.

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

ISO/IEC 27001:2022 je objavljen 25. oktobra 2022. Ovo rezultira sledećim rokovima i vremenskim okvirima za korisnike da pređu:

Spremnost sertifikacije prema ISO/IEC 27001:2022

• Najkasnije od novembra 2023. (u zavisnosti od nemačkog akreditacionog tela DAkkS)

Poslednji datum za inicijalne/resertifikacione provere prema „starom“ ISO 27001:2013

• Nakon 30. aprila 2024., DQS će sprovoditi početne i resertifikacione provere samo u skladu sa novim standardom ISO/IEC 27001:2022

Prelazak svih postojećih sertifikata prema „starom“ ISO/IEC 27001:2013 na novi ISO/IEC 27001:2022

• Postoji trogodišnji prelazni rok koji počinje 31. oktobra 2022
• Sertifikati izdati u skladu sa ISO/IEC 27001:2013 ili DIN EN ISO/IEC 27001:2017 važe najkasnije do 31. oktobra 2025. godine ili moraju biti povučeni ovog datuma.

DQS: Jednostavno korišćenje bezbednosti.

Zbog prelaznih perioda, kompanije imaju dovoljno vremena da prilagode svoj ISMS u skladu sa novim zahtevima i da ga sertifikuju. Međutim, trajanje i napor čitavog procesa promene ne treba potcenjivati – posebno ako nemate dovoljno specijalizovanog osoblja. Ako želite da budete sigurni, trebalo bi da se pozabavite problemom pre nego kasnije i pozovite iskusne stručnjake ako je potrebno.

Kao stručnjaci za proveru i sertifikaciju sa više od 35 godina stručnosti, rado ćemo vam pružiti podršku u proceni vašeg trenutnog statusa, možda kao deo delta provere. Saznajte od naših brojnih iskusnih proveravača o najvažnijim promenama i njihovoj važnosti za vašu organizaciju. Zajedno ćemo razgovarati o vašem potencijalu za poboljšanje i podržavati vas dok ne dobijete svoj novi sertifikat. Iskoristite naše kompetencije u oblasti bezbednosti informacija! Mi očekujemo da čujemo od vas.