Bezpečné kódování - výzvy v oblasti informační bezpečnosti

• Bezpečnostní chyby v kódu
• Otevřený zdrojový kód a útoky na dodavatelský řetězec
• Kontrola bezpečnosti informací 8.28 bezpečné kódování
• Zásady bezpečného kódování
• Závěr
• Revize normy ISO 27001: Co znamená aktualizace pro vaši certifikaci?
• DQS - Jednoduché využití bezpečnosti.

Bezpečnostní chyby v kódu

Software operačního systému, aplikační software nebo firmware vestavěného systému jsou elementárními součástmi každé digitální infrastruktury. Rostoucí zrychlení a tlak na termíny digitalizačních projektů však často vedou k zanedbávání nezbytných aspektů informační bezpečnosti. Požadavky na vývoj softwaru jsou obvykle zaměřeny na funkce a zdůrazňují konstruktivní aspekty, takže destruktivní pohled na potenciální bezpečnostní zranitelnosti je většinou diametrálně odlišný od skutečných cílů vývoje: mnoha programátorům jednoduše chybí také strukturovaný a vyostřený pohled na kybernetickou bezpečnost.

Za těchto podmínek mají vývojové týmy problém průběžně kontrolovat a důsledně zabezpečovat kódování svého softwaru, což dokládá množství zranitelností, které nezisková organizace MITRE Corporation každoročně zveřejňuje ve svém seznamu CVE (Common Vulnerabilities and Exposures). Pravidelné bezpečnostní záplaty dokonce i známých výrobců softwaru jsou ukazatelem sisyfovského úkolu odstranit bezpečnostně relevantní chyby, natož je identifikovat ještě před uvedením na trh.

Otevřený zdrojový kód - zvláštní případ

Při kódování vlastního softwaru se programátoři rádi uchylují ke knihovnám a modulům s otevřeným zdrojovým kódem. Praktické výhody jsou zřejmé: Pokud nemusíte znovu a znovu vynalézat kolo, těžíte z tohoto technologického nárůstu, rychlejšího vývoje, nižších nákladů na vývoj, větší transparentnosti díky otevřenému zdrojovému kódu a vyšší interoperability díky otevřeným standardům a rozhraním.

Často se také říká, že kód s otevřeným zdrojovým kódem nabízí vysoký stupeň bezpečnosti, protože kód byl ověřen mnoha uživateli a rojová inteligence komunity open source umožňuje rychlé a efektivní opravy chyb.

V praxi je nyní třeba tuto důvěru posuzovat diferencovaně a kriticky. Nejzávažnějším příkladem je bezpečnostní chyba nultého dne Log4Shell v široce používané knihovně Log4J pro logování aplikací v jazyce Java, která byla objevena v listopadu 2021. Možná jste slyšeli o červeném stupni výstrahy, který pro Log4Shell vydal německý Spolkový úřad pro bezpečnost informací (BSI). Knihovna Log4J, distribuovaná jako spolehlivě fungující kvazistandard prostřednictvím nadace Apache Foundation, se od roku 2013 prosadila v mnoha systémech - včetně známých webových služeb, jako je Amazon AWS.

Komplexnost těchto dobře vyvinutých a také udržovaných knihoven implicitně poskytuje výkonné funkcionality, o kterých importující vývojář při svém vlastním kombinovaném novém vývoji často neví, ale které mohou být zneužity útočníky.

Dalším faktorem nezabezpečenosti open source komponent jsou tzv. supply chain útoky, tj. záměrně zabudované zranitelnosti záškodníky, kteří se vydávají za součást open source komunity a pomáhají při vývoji kódu. Taková zranitelnost představuje pro hackery mimořádně účinný způsob, jak napadnout velké množství navazujících uživatelských organizací. Není tedy divu, že tento vektor útoku rychle roste: studie společnosti Sonatype diagnostikovala 650% nárůst při srovnání let 2020 a 2021.

Kontrola bezpečnosti informací 8.28 bezpečné kódování

Za účelem včasného zabezpečení procesu vývoje softwaru zařadila Mezinárodní organizace pro normalizaci (ISO - výbor ISO/IEC JTC 1/SC 27) do nových norem ISO/IEC 27002 a ISO/IEC 27001:2022, příloha A, jako novou kontrolu 8.28 "Bezpečné kódování". Účelem technického opatření pro bezpečné kódování je preventivní ochrana softwaru.

Minimální úroveň bezpečnosti se vytváří již ve fázi psaní na základě procesních předpisů, čímž se minimalizuje počet potenciálních bezpečnostních zranitelností softwaru. Regulační rámec pro tvorbu bezpečného kódu má být aplikován komplexně jak na vlastní programový kód společnosti, tak na software od třetích stran a z otevřených zdrojů. Významnými zásadami pro implementaci jsou Security by Design a Least Privilege, které je třeba zohlednit i při kódování.

Zásady bezpečného kódování

Opatření 8.28 se několikrát zabývá tzv. zásadami bezpečného kódování. Návod, jaké by to mohly být, poskytuje řada organizací a institutů, které pravidelně vydávají příručky a osvědčené postupy pro bezpečné kódování. Patří mezi ně například Zásady bezpečného kódování nadace OWASP, Standardy bezpečného kódování týmu CERT (Computer Emergency Response Team) Institutu softwarového inženýrství (SEI) a katalog opatření pro bezpečnost webových aplikací německého BSI. Navzdory rozdílným zdrojům vykazují vypracování řadu paralel, například pokud jde o následující body:

• Ověřování vstupních dat
• Zabezpečení ověřování a správa hesel
• Bezpečné řízení přístupu
• Jednoduchý a transparentní kód
• Trvale testovaná kryptografická opatření a komponenty
• Zpracování chyb a protokolování
• Ochrana dat
• Modelování hrozeb

V normě ISO/ISO 27002:2022 jsou doporučené činnosti pro kontrolu 8.28 rozděleny do tří částí: "Plánování a předběžné kódování", "Během kódování" a "Ověřování a údržba", jejichž základní obsah je uveden níže.

Plánování a předkódování

Vývoj nového kódu i jeho opětovné použití vyžadují uplatnění zásad bezpečného kódování - bez ohledu na to, zda je kód psán pro interní software nebo pro externí produkty a služby. To vyžaduje vyhodnocení specifických očekávání organizace a definování uznávaných zásad předem. Doporučené kroky pro plánování a předběžné kódování navíc zohledňují známé běžné a historické postupy kódování a chyby, které by mohly vést ke zranitelnostem.

Konfigurace vývojových nástrojů, například na základě pravidel v integrovaných vývojových prostředích (IDE), by měla vynucovat vytváření bezpečného kódu. Zcela zásadní je kvalifikace vývojářů a jejich znalost bezpečných architektur a programovacích standardů. Samozřejmostí je začlenění odborníků na bezpečnost informací do vývojového týmu.

Během procesu kódování

Během procesu kódování hrají primární roli postupy kódování a techniky strukturovaného programování, které zohledňují konkrétní případ použití a jeho bezpečnostní potřeby. Nezabezpečené návrhové techniky - například hesla kódovaná natvrdo - by měly být důsledně zakázány. Kód by měl být náležitě dokumentován a kontrolován, aby se co nejlépe odstranily chyby související se zabezpečením. Revize kódu by měla probíhat jak v průběhu vývoje, tak po něm, a to prostřednictvím statického testování bezpečnosti aplikací (SAST) nebo podobným způsobem. Metody statického testování podporují přístup posunu doleva ("testovat včas a často") tím, že se v životním cyklu posunou doleva včasným testováním viditelného kódu na shodu s pravidly.

To umožňuje včasnou identifikaci poskvrněného kódu, spojení se soubory nebo specifickými třídami objektů nebo mezer na úrovni aplikace, které mohou být zneužity k nepozorované interakci s programy třetích stran jako zneužitelné zranitelnosti. Před uvedením softwaru do provozu vyžaduje kontrola 8.28 vyhodnocení ploch útoku a implementaci principu nejmenších oprávnění. Měla by být vyhodnocena provedená analýza nejčastějších programátorských chyb a dokumentace jejich opravy.

Ověřování a údržba

I po uvedení softwaru do provozu zůstává téma bezpečného kódování aktuální. To zahrnuje bezpečné aktualizace i kontroly známých zranitelností vlastního kódu. Kromě toho je třeba dokumentovat chyby a podezření na útoky, aby bylo možné neprodleně provést potřebné úpravy. V každém případě je třeba vhodnými nástroji spolehlivě zabránit neoprávněnému přístupu ke zdrojovému kódu.

Otevřený zdrojový kód

V oblasti ověřování a údržby jsou v opatření 8.28 navíc uvedeny výslovné pokyny pro používání externích nástrojů a knihoven, například softwaru s otevřeným zdrojovým kódem. Tyto součásti kódu by měly být spravovány, aktualizovány a udržovány v soupisech. To lze provést například prostřednictvím softwarového kusovníku (SBOM). SBOM je formální strukturovaný záznam softwarových balíčků a knihoven a jejich vzájemných vztahů a vztahů v rámci dodavatelského řetězce, zejména pro sledování opakovaně používaného kódu a komponent s otevřeným zdrojovým kódem. SBOM podporuje udržovatelnost softwaru a cílené bezpečnostní aktualizace.

Závěr

Bezpečný kód je elementárním základem pro zastavení potenciálních útoků. Nová verze Control 8.28 tento dlouholetý poznatek zohledňuje a povyšuje klíčovou roli bezpečného kódování na důležitou pro bezpečnost informací. Protože však opatření obsahuje velké množství podrobných doporučení k činnosti a je technicky náročné, bude jeho implementace vyžadovat poměrně velké úsilí - to je třeba vzít v úvahu již ve fázi plánování.

S odborným pohledem našich zkušených auditorů vás podpoříme v souladu s předpisy při zavádění tohoto opatření. Díky našim více než 35letým zkušenostem v oblasti auditu a certifikace jsme vaším ideálním kontaktním partnerem a rádi vám pomůžeme s tématem bezpečnosti informací a certifikace podle norem ISO/IEC 27001:2022.

Revize normy ISO 27001: Co znamená aktualizace pro vaši certifikaci?

Norma ISO/IEC 27001:2022 byla zveřejněna 25. října 2022. Z toho vyplývají následující termíny a lhůty pro přechod uživatelů:

Připravenost k certifikaci podle normy ISO/IEC 27001:2022

• Očekává se od června/července 2023 (v závislosti na německém akreditačním orgánu GmbH (DAkkS)).

Poslední termín pro počátečních/recertifikačních auditů podle "staré" normy ISO 27001:2013.

• Po 31. říjnu 2023 bude DQS provádět počáteční a recertifikační audity pouze podle nové normy ISO/IEC 27001:2022.

Přechod všech stávajících certifikátů ze "staré" normy ISO/IEC 27001:2013 na novou normu ISO/IEC 27001:2022.

• Od 31. října 2022 běží tříleté přechodné období.
• Certifikáty vydané podle normy ISO/IEC 27001:2013 nebo DIN EN ISO/IEC 27001:2017 budou nadále platné nejpozději do 31. října 2025, nebo musí být k tomuto datu zrušeny.

DQS: DQS: Jednoduše využívat zabezpečení.

Vzhledem k přechodným obdobím mají společnosti dostatek času na to, aby svůj systém ISMS upravily v souladu s novými požadavky a nechaly si jej certifikovat. Délku a náročnost celého procesu změny však nelze podceňovat - zejména pokud nemáte dostatek specializovaných pracovníků. Pokud chcete být na bezpečné straně, měli byste se touto problematikou zabývat raději dříve než později a v případě potřeby povolat zkušené odborníky.

Jako odborníci na audit a certifikaci s více než 35letou praxí vám rádi pomůžeme s vyhodnocením vašeho současného stavu, třeba v rámci delta auditu. Od našich četných zkušených auditorů se dozvíte o nejdůležitějších změnách a jejich významu pro vaši organizaci. Společně s vámi probereme možnosti zlepšení a podpoříme vás až do získání nového certifikátu. Využijte našich kompetencí v oblasti bezpečnosti informací! Těšíme se na vaše dotazy.