Sigurno kodiranje - Izazovi u informacionoj sigurnosti

• Sigurnosne ranjivosti u kodu
• Otvoreni sigurnosni kod i napadi na lanac snabdijevanja
• Kontrola sigurnosti informacija 8.28 sigurno kodiranje
• Principi sigurnog kodiranja
• Zaključak
• Revizija ISO 27001: Šta ažuriranje znači za vašu certifikaciju?
• DQS - Simply leveraging Security.

Kontrola sigurnosti informacija 8.28 sigurno kodiranje

Kako bi se pravovremeno zaštitio proces razvoja softvera, Međunarodna organizacija za standardizaciju (ISO - komitet ISO/IEC JTC 1/SC 27) je uključila "Sigurno kodiranje" kao novu kontrolu 8.28 u novi ISO/IEC 27002 i ISO/IEC 27001:2022, Anex A standarda. Svrha tehničke mjere za sigurno kodiranje je preventivna zaštita softvera.

Minimalni nivo sigurnosti se stvara već u fazi pisanja na osnovu proceduralnih propisa, čime se minimizira broj potencijalnih sigurnosnih propusta u softveru. Regulatorni okvir za sigurno generisanje koda treba da se primjenjuje holistički i na sopstveni programski kod kompanije i na softver trećih strana i otvorenog koda. Značajni principi za implementaciju su Sigurnost po dizajnu i Najmanja privilegija, koja se također mora uzeti u obzir pri kodiranju.

Principi sigurnog kodiranja

Mjera 8.28 se nekoliko puta bavi takozvanim principima sigurnog kodiranja. Smjernice o tome šta bi to moglo biti daju brojne organizacije i instituti koji redovno izdaju vodiče i najbolje prakse za sigurno kodiranje. To uključuje, na primjer, Prakse sigurnog kodiranja OWASP Fondacije, Standarde sigurnog kodiranja Računarski tim za hitne slučajeve (CERT) Instituta za softversko inženjerstvo (SEI) i katalog mjera za sigurnost web aplikacija njemačkog BSI-a. Uprkos različitim izvorima, elaborati pokazuju mnoge paralele, na primjer u pogledu sljedećih tačaka:

• Validacija unosa podataka
• Osiguravanje autentifikacije i upravljanje lozinkama
• Sigurna kontrola pristupa
• Jednostavan, transparentan kod
• Održivo testirane kriptografske mjere i komponente
• Rukovanje greškama i evidentiranje
• Zaštita podataka
• Modeliranje prijetnji

U standardu ISO/ISO 27002:2022, preporučene radnje za Kontrolu 8.28 podijeljene su u tri odjeljka, "Planiranje i prethodno kodiranje", "Tokom kodiranja" i "Provjera i održavanje", čiji je osnovni sadržaj naveden u nastavku.

Sigurnosne ranjivosti u kodu

Softver operativnog sistema, aplikativni softver ili firmver u ugrađenom sistemu su osnovne komponente bilo koje digitalne infrastrukture. Međutim, sve veće ubrzanje i pritisak na rokove u projektima digitalizacije često dovode do zanemarivanja imperativnih aspekata sigurnosti informacija. Razvojni zahtjevi za softver obično su usmjereni na funkciju i naglašavaju konstruktivne aspekte, tako da je destruktivni pogled na potencijalne sigurnosne ranjivosti uglavnom dijametralno suprotan stvarnim razvojnim ciljevima: mnogim programerima jednostavno nedostaje strukturiran i izoštren pogled na kibernetičku sigurnost.

U ovim uslovima, razvojni timovi imaju teškoća da kontinuirano pregledavaju i dosljedno obezbjeđuju kodiranje svog softvera, o čemu svjedoče brojne ranjivosti koje neprofitna korporacija MITER svake godine objavljuje u svojoj CVE (Common Vulnerabilities and Exposures - Uobičajene ranjivosti i izloženosti) listi. Redovne sigurnosne zakrpe čak i poznatih proizvođača softvera pokazatelj su sizifovog zadatka zatvaranja sigurnosnih grešaka, a kamoli da ih identifikuju prije nego što se uopšte lansiraju na tržište.

Otvoreni sigurnosni kod - specijalni slučaj

Kada kodiraju softver koji su sami razvili, programeri vole da posežu za bibliotekama i modulima otvorenog koda. Praktične prednosti su očigledne: ako ne morate iznova i iznova izmišljati točak, imate koristi od ovog poboljšanja tehnologije, brzog razvoja, nižih troškova razvoja, veće transparentnosti kroz otvoreni izvorni kod i veće interoperabilnosti kroz otvorene standarde i sučelja.

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

U praksi, ovo povjerenje se sada mora vrednovati na diferenciran i kritički način. Najozbiljniji primjer je sigurnosna ranjivost nultog dana Log4Shell u široko korištenoj biblioteci evidencije Log4J za Java aplikacije, koja je otkrivena u novembru 2021. Možda ste čuli za nivo crvenog upozorenja koji je izdao njemački savezni ured za sigurnost informacija (BSI ) za Log4Shell. Log4J biblioteka, distribuirana kao pouzdano funkcionalni kvazi-standard preko Apache fondacije, etablirala se u mnogim sistemima od 2013. godine - uključujući dobro poznate web servise kao što je Amazon AWS.

Složenost ovih dobro razvijenih i također održavanih biblioteka implicitno pruža moćne funkcionalnosti kojih programer koji uvozi često nije svjestan u svom vlastitom kombinovanom novom razvoju, ali koje napadači mogu iskoristiti.

Drugi faktor nesigurnosti komponenti otvorenog koda su takozvani napadi na lanac snabdjevanja, odnosno namjerene ugrađene ranjivosti od strane zlonamjernih aktera koji se predstavljaju kao dio zajednice otvorenog koda i pomažu u razvoju koda. Takva ranjivost je izuzetno efikasan način za hakere da napadnu veliki broj organizacija ostalih korisnika. Stoga nije ni čudo što ovaj vektor napada brzo raste: Sonatype studija dijagnosticira povećanje od 650% u poređenju sa 2020. i 2021.

Planiranje i prethodno kodiranje

I razvoj novog koda i ponovna upotreba koda zahtijevaju primjenu principa sigurnog kodiranja - bez obzira da li je kod napisan za interni softver ili za eksterne proizvode i usluge. Ovo zahtijeva procjenu specifičnih očekivanja organizacije i unaprijed 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 bi mogle dovesti do ranjivosti.

Konfiguracija razvojnih alata, kao što je bazirana na pravilima u integrisanim razvojnim okruženjima (IDE), trebala bi nametnuti stvaranje sigurnog koda. Prilično je kritična kvalifikacija programera i njihovo poznavanje sigurnih arhitektura i programskih standarda. Uključivanje stručnosti o informacijskoj sigurnosti u razvojni tim se podrazumijeva.

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 sigurnosne potrebe. Nesigurne tehnike dizajna - na primjer, tvrdo kodirane lozinke - treba dosljedno zabranjivati. Kôd bi trebao biti adekvatno dokumentiran i pregledan kako bi se najbolje eliminisale greške vezane za sigurnost. Pregled koda bi se trebao odvijati tokom i nakon razvoja, putem statičkog testiranja sigurnosti aplikacije (SAST) ili slično. Metode statičkog testiranja podržavaju pristup pomaka ulijevo („testirajte rano i često“) pomjeranjem ulijevo u životnom ciklusu testiranjem vidljivog koda za usaglašenost pravila rano.

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 neprimjećenu interakciju sa programima trećih strana kao ranjivosti koje se mogu iskoristiti. Prije nego što se softver pusti u rad, Kontrola 8.28 zahtijeva procjenu površina napada i implementaciju principa najmanje privilegija. Treba evaluirati obavljenu analizu najčešćih programskih grešaka i dokumentaciju o njihovoj korekciji.

Verifikacija i održavanje

Čak i nakon što je softver pokrenut, tema sigurnog kodiranja ostaje relevantna. Ovo uključuje sigurna ažuriranja, kao i provjere poznatih ranjivosti u nečijem kodu. Osim toga, greške i sumnjivi napadi moraju biti dokumentirani kako bi se potrebne prilagodbe mogle brzo izvršiti. U svakom slučaju, neovlašteni pristup izvornom kodu mora biti pouzdano spriječen odgovarajućim alatima.

Kod otvorenog izvora

U oblasti verifikacije i održavanja, Mjera 8.28 dodatno navodi eksplicitna uputstva za korištenje eksternih alata i biblioteka, kao što je softver otvorenog koda. Ovim komponentama koda treba upravljati, ažurirati ih i održavati u zalihama. To se može učiniti, na primjer, putem softverske liste materijala (SBOM). SBOM je formalni, strukturirani zapis softverskih paketa i biblioteka njihovih međusobnih odnosa i unutar lanca sabdijevanja, posebno za praćenje ponovno korištenog koda i komponenti otvorenog koda. SBOM podržava mogućnost održavanja softvera i ciljana sigurnosna ažuriranja.

Zaključak

Sigurnosni kod je fundamentalna osnova za zaustavljanje potencijalnih napada. Nova Kontrola 8.28 uzima u obzir ovaj dugotrajni uvid i unaprijeđuje ključnu ulogu sigurnog kodiranja u njegovoj važnosti za sigurnost informacija. Međutim, budući da mjera sadrži veliki broj detaljnih preporuka za djelovanje i da je tehnički zahtjevna, njena implementacija će zahtijevati relativno visok nivo napora – to treba uzeti u obzir već u fazi planiranja.

Uz profesionalni pogled naših iskusnih auditora, podržavamo vas u usklađenoj implementaciji mjere. Sa našom stručnošću u auditu i certifikaciji dugom više od 35 godina, mi smo vaš idealan kontakt partner i rado ćemo vam pomoći na temu sigurnosti informacija i certifikacije u skladu sa standardom ISO/IEC 27001:2022.

Šta ažuriranje znači za vašu organizaciju?

ISO/IEC 27001:2022 objavljen je 25. oktobra 2022. Ovo rezultira sljedećim rokovima i vremenskim okvirima za korisnike za tranziciju:

Posljednji datum za inicijalni/ recertifikacijski audit u skladu sa "starim" ISO 27001:2013 

• Nakon 30. aprila 2024., DQS će provoditi inicijalne i recertifikacijske audite samo prema novom standardu ISO/IEC 27001:2022

Tranzicija svih postojećih certifikata prema "starom" ISO/IEC 27001:2013 na novi ISO/IEC 27001:2022 

• Postoji trogodišnji prelazni period počevši od 31. oktobra 2022. 
• Certifikati izdati u skladu sa ISO/IEC 27001:2013 ili DIN EN ISO/IEC 27001:2017 vrijede najkasnije do 31. oktobra 2025. ili se moraju povući ovog datuma.

DQS: Simply leveraging Security.

Zbog prelaznih perioda, kompanije imaju dovoljno vremena da prilagode svoj ISMS u skladu sa novim zahtjevima i da ga certificiraju. Međutim, trajanje i napor čitavog procesa promjene ne treba potcijeniti – pogotovo ako nemate dovoljno specijalizovanog osoblja. Ako želite da budete sigurni, trebali biste se pozabaviti problemom prije nego kasnije i pozvati iskusne stručnjake ako je potrebno.

Kao stručnjaci za audit i certifikaciju s više od 35 godina iskustva, rado ćemo vas podržati u procjeni vašeg trenutnog statusa, možda u sklopu delta audita. Saznajte od naših brojnih iskusnih auditora o najvažnijim promjenama 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 certifikat. Iskoristite naše kompetencije u informacionoj sigurnosti! Radujemo se Vašem upitu.