Bezpečné kódovanie - výzvy v informačnej bezpečnosti

• Bezpečnostné zraniteľnosti v kóde
• Útoky na otvorený kód a dodávateľský reťazec
• Kontrola informačnej bezpečnosti 8.28 Bezpečné kódovanie
• Zásady bezpečného kódovania
• Záver
• Revízia normy ISO 27001: Čo znamená aktualizácia pre vašu certifikáciu?
• DQS - Jednoduché využitie bezpečnosti.

Bezpečnostné zraniteľnosti v kóde

Softvér operačného systému, aplikačný softvér alebo firmvér vstavaného systému sú elementárnymi súčasťami každej digitálnej infraštruktúry. Zvyšujúce sa zrýchlenie a tlak na termíny v digitalizačných projektoch však často vedú k zanedbávaniu nevyhnutných aspektov informačnej bezpečnosti. Požiadavky na vývoj softvéru sú zvyčajne zamerané na funkcie a zdôrazňujú konštruktívne aspekty, takže deštruktívny pohľad na potenciálne bezpečnostné zraniteľnosti je väčšinou diametrálne odlišný od skutočných cieľov vývoja: mnohým programátorom jednoducho chýba aj štruktúrovaný a vyostrený pohľad na kybernetickú bezpečnosť.

Za týchto podmienok majú vývojové tímy problém priebežne kontrolovať a dôsledne zabezpečovať kódovanie svojho softvéru, čoho dôkazom je množstvo zraniteľností, ktoré nezisková organizácia MITRE Corporation každoročne zverejňuje vo svojom zozname CVE (Common Vulnerabilities and Exposures). Pravidelné bezpečnostné záplaty dokonca aj známych výrobcov softvéru sú ukazovateľom sizyfovskej úlohy odstrániť chyby dôležité z hľadiska bezpečnosti, nehovoriac o ich identifikácii ešte pred uvedením na trh.

Otvorený zdrojový kód - osobitný prípad

Pri kódovaní softvéru vyvinutého vlastnými silami sa programátori radi uchyľujú ku knižniciam a modulom s otvoreným zdrojovým kódom. Praktické výhody sú zrejmé: Ak nemusíte znovu a znovu vynaliezať koleso, profitujete z tohto technologického impulzu, rýchleho vývoja, nižších nákladov na vývoj, väčšej transparentnosti vďaka otvorenému kódu a vyššej interoperability vďaka otvoreným štandardom a rozhraniam.

Často sa tiež hovorí, že kód s otvoreným zdrojovým kódom ponúka vysoký stupeň bezpečnosti, pretože kód bol overený mnohými používateľmi a rojčivá inteligencia komunity s otvoreným zdrojovým kódom umožňuje rýchle a efektívne odstraňovanie chýb.

V praxi sa táto dôvera musí teraz posudzovať diferencovane a kriticky. Najzávažnejším príkladom je bezpečnostná zraniteľnosť nultého dňa Log4Shell v široko používanej knižnici Log4J pre aplikácie Java, ktorá bola objavená v novembri 2021. Možno ste už počuli o červenom stupni výstrahy, ktorý pre Log4Shell vydal nemecký Spolkový úrad pre informačnú bezpečnosť (BSI). Knižnica Log4J, distribuovaná ako spoľahlivo fungujúci kvázi štandard prostredníctvom nadácie Apache Foundation, sa od roku 2013 etablovala v mnohých systémoch - vrátane známych webových služieb, ako je Amazon AWS.

Komplexnosť týchto dobre vyvinutých a tiež udržiavaných knižníc implicitne poskytuje výkonné funkcie, o ktorých importujúci vývojár často nevie pri vlastnom kombinovanom novom vývoji, ale ktoré môžu byť zneužité útočníkmi.

Ďalším faktorom nezabezpečenia komponentov s otvoreným zdrojovým kódom sú tzv. útoky dodávateľského reťazca, t. j. zámerné zabudované zraniteľnosti zo strany škodlivých subjektov, ktoré sa vydávajú za súčasť komunity open source a pomáhajú pri vývoji kódu. Takáto zraniteľnosť je pre hackerov mimoriadne účinným spôsobom, ako zaútočiť na veľký počet nadväzujúcich používateľských organizácií. Niet preto divu, že tento vektor útoku rýchlo rastie: štúdia spoločnosti Sonatype diagnostikovala 650 % nárast pri porovnaní rokov 2020 a 2021.

Kontrola informačnej bezpečnosti 8.28 bezpečné kódovanie

S cieľom včas zabezpečiť proces vývoja softvéru Medzinárodná organizácia pre normalizáciu (ISO - výbor ISO/IEC JTC 1/SC 27) zaradila "bezpečné kódovanie" ako novú kontrolu 8.28 do nových noriem ISO/IEC 27002 a ISO/IEC 27001:2022, príloha A. Účelom technického opatrenia pre bezpečné kódovanie je preventívna ochrana softvéru.

Minimálna úroveň bezpečnosti sa vytvára už vo fáze písania na základe procesných predpisov, čím sa minimalizuje počet potenciálnych bezpečnostných zraniteľností softvéru. Regulačný rámec pre tvorbu bezpečného kódu sa má uplatňovať komplexne tak na vlastný programový kód spoločnosti, ako aj na softvér od tretích strán a z otvorených zdrojov. Významné zásady implementácie sú Security by Design (Bezpečnosť už od návrhu ) a Least Privilege (Najmenšie privilégiá), ktoré sa musia zohľadniť aj pri kódovaní.

Zásady bezpečného kódovania

Opatrenie 8.28 sa niekoľkokrát zaoberá tzv. zásadami bezpečného kódovania. Usmernenia, aké by to mohli byť, poskytujú mnohé organizácie a inštitúty, ktoré pravidelne vydávajú príručky a osvedčené postupy pre bezpečné kódovanie. Patria medzi ne napríklad Pravidlá bezpečného kódovania nadácie OWASP, Štandardy bezpečného kódovania tímu CERT (Computer Emergency Response Team) Inštitútu softvérového inžinierstva (SEI) a katalóg opatrení pre bezpečnosť webových aplikácií nemeckého inštitútu BSI. Napriek rôznym zdrojom vykazujú vypracovania mnoho paralel, napríklad pokiaľ ide o nasledujúce body:

• Overovanie vstupných údajov
• Zabezpečenie autentifikácie a správy hesiel
• Bezpečné riadenie prístupu
• Jednoduchý a prehľadný kód
• Trvalo testované kryptografické opatrenia a komponenty
• Spracovanie chýb a protokolovanie
• Ochrana údajov
• Modelovanie hrozieb

V norme ISO/ISO 27002:2022 sú odporúčané činnosti pre kontrolu 8.28 rozdelené do troch častí: "Plánovanie a predbežné kódovanie", "Počas kódovania" a "Overovanie a údržba", ktorých hlavný obsah je uvedený ďalej.

Plánovanie a predkódovanie

Vývoj nového kódu aj opätovné použitie kódu si vyžaduje uplatňovanie zásad bezpečného kódovania - bez ohľadu na to, či sa kód píše pre interný softvér alebo pre externé produkty a služby. To si vyžaduje vyhodnotenie špecifických očakávaní organizácie a definovanie uznávaných zásad vopred. Okrem toho odporúčané opatrenia na plánovanie a predbežné kódovanie zohľadňujú známe bežné a historické postupy kódovania a chyby, ktoré by mohli viesť k zraniteľnostiam.

Konfigurácia vývojových nástrojov, ako sú napríklad nástroje založené na pravidlách v integrovaných vývojových prostrediach (IDE), by mala vynútiť tvorbu bezpečného kódu. Pomerne kritická je kvalifikácia vývojárov a ich znalosť bezpečných architektúr a programovacích štandardov. Samozrejmosťou je začlenenie odborníkov v oblasti informačnej bezpečnosti do vývojového tímu.

Počas procesu kódovania

Počas procesu kódovania zohrávajú primárnu úlohu postupy kódovania a techniky štruktúrovaného programovania, pričom sa zohľadňuje konkrétny prípad použitia a jeho bezpečnostné potreby. Nebezpečné techniky návrhu - napríklad heslá kódované napevno - by mali byť dôsledne zakázané. Kód by mal byť primerane zdokumentovaný a preskúmaný, aby sa čo najlepšie odstránili chyby súvisiace s bezpečnosťou. Preskúmanie kódu by sa malo uskutočniť počas vývoja aj po ňom prostredníctvom statického testovania bezpečnosti aplikácií (SAST) alebo podobným spôsobom. Metódy statického testovania podporujú prístup posunu doľava ("testovať včas a často") posunom doľava v životnom cykle včasným testovaním viditeľného kódu na zhodu s pravidlami.

To umožňuje včasnú identifikáciu kontaminovaného kódu, prepojení na súbory alebo špecifické triedy objektov alebo medzier na úrovni aplikácie, ktoré môžu byť zneužité na nepozorovanú interakciu s programami tretích strán ako zneužiteľné zraniteľnosti. Pred uvedením softvéru do prevádzky vyžaduje kontrola 8.28 vyhodnotenie plôch útoku a implementáciu princípu najmenších privilégií. Mala by sa vyhodnotiť vykonaná analýza najčastejších programátorských chýb a dokumentácia ich opravy.

Overovanie a údržba

Aj po uvedení softvéru do prevádzky je téma bezpečného kódovania stále aktuálna. Patria sem bezpečné aktualizácie, ako aj kontroly známych zraniteľností vlastného kódu. Okrem toho je potrebné zdokumentovať chyby a podozrenia na útoky, aby bolo možné okamžite vykonať potrebné úpravy. V každom prípade je potrebné vhodnými nástrojmi spoľahlivo zabrániť neoprávnenému prístupu k zdrojovému kódu.

Otvorený zdrojový kód

V oblasti overovania a údržby sa v opatrení 8.28 navyše uvádzajú výslovné pokyny na používanie externých nástrojov a knižníc, ako je napríklad softvér s otvoreným zdrojovým kódom. Tieto zložky kódu by sa mali spravovať, aktualizovať a udržiavať v súpisoch. Môže sa to uskutočniť napríklad prostredníctvom zoznamu softvéru (Software Bill of Material - SBOM). SBOM je formálny, štruktúrovaný záznam softvérových balíkov a knižníc a ich vzájomných vzťahov a vzťahov v rámci dodávateľského reťazca, najmä na sledovanie opakovane použitého kódu a komponentov s otvoreným zdrojovým kódom. SBOM podporuje udržiavateľnosť softvéru a cielené bezpečnostné aktualizácie.

Záver

Bezpečný kód je elementárnym základom na zastavenie potenciálnych útokov. Nová verzia Control 8.28 zohľadňuje tento dlhoročný poznatok a aktualizuje kľúčovú úlohu bezpečného kódovania v jeho význame pre informačnú bezpečnosť. Keďže však toto opatrenie obsahuje veľké množstvo podrobných odporúčaní pre činnosť a je technicky náročné, jeho implementácia si vyžiada pomerne veľké úsilie - to by sa malo vziať do úvahy už vo fáze plánovania.

S profesionálnym pohľadom našich skúsených audítorov vás podporíme pri kompatibilnej implementácii opatrenia. Vďaka našim viac ako 35-ročným skúsenostiam v oblasti auditu a certifikácie sme vaším ideálnym kontaktným partnerom a radi vám pomôžeme s témou informačnej bezpečnosti a certifikácie v súlade s normami ISO/IEC 27001:2022.

Revízia normy ISO 27001: Čo znamená aktualizácia pre vašu certifikáciu?

Norma ISO/IEC 27001:2022 bola zverejnená 25. októbra 2022. Z toho vyplývajú nasledujúce termíny a časové rámce pre prechod používateľov:

Pripravenosť na certifikáciu podľa normy ISO/IEC 27001:2022

• Očakáva sa od júna/júla 2023 (v závislosti od nemeckého akreditačného orgánu GmbH (DAkkS)).

Posledný termín pre počiatočné/re-certifikačné audity podľa "starej" normy ISO 27001:2013

• Po 31. októbri 2023 bude DQS vykonávať počiatočné a recertifikačné audity len podľa novej normy ISO/IEC 27001:2022.

Prechod všetkých existujúcich certifikátov zo "starej" normy ISO/IEC 27001:2013 na novú normu ISO/IEC 27001:2022

• Od 31. októbra 2022 je trojročné prechodné obdobie
• Certifikáty vydané podľa normy ISO/IEC 27001:2013 alebo DIN EN ISO/IEC 27001:2017 budú naďalej platné najneskôr do 31. októbra 2025 alebo musia byť k tomuto dátumu zrušené.

DQS: Jednoduché využitie bezpečnosti.

Vzhľadom na prechodné obdobia majú spoločnosti dostatok času na to, aby svoj ISMS prispôsobili novým požiadavkám a nechali si ho certifikovať. Trvanie a náročnosť celého procesu zmien však netreba podceňovať - najmä ak nemáte dostatok špecializovaného personálu. Ak chcete byť na bezpečnej strane, mali by ste sa touto problematikou zaoberať radšej skôr ako neskôr a v prípade potreby sa obrátiť na skúsených odborníkov.

Ako odborníci na audit a certifikáciu s viac ako 35-ročnou praxou vám radi pomôžeme pri hodnotení vášho súčasného stavu, možno v rámci delta auditu. Od našich početných skúsených audítorov sa dozviete o najdôležitejších zmenách a ich význame pre vašu organizáciu. Spoločne s vami prediskutujeme váš potenciál na zlepšenie a budeme vás podporovať až do získania nového certifikátu. Využite naše kompetencie v oblasti informačnej bezpečnosti! Tešíme sa na vás.