Od návrhu k připravenosti na audit: zvládnutí požadavků na zabezpečení aplikací pro ISO 27001, DORA a NIS2

Předauditní nervozita byla hmatatelná. Pro Marii, ředitelku informační bezpečnosti (CISO) středně velké fintech společnosti, působilo nadcházející posouzení souladu s DORA méně jako přezkum a spíše jako zúčtování. Její tým byl schopný, infrastruktura posílená, ale jedna naléhavá zranitelnost jí nedala spát: rozsáhlý a chaotický svět jejich aplikací.

Nejnovější obavou byl nový zákaznický platební portál, uvedený na trh ve spěchu kvůli splnění čtvrtletních cílů. Vývojový tým pracoval v agresivním agilním režimu a splnil všechny funkční požadavky. Když však Mariin tým provedl předběžný sken, výsledky potvrdily její obavy.

Portál postrádal robustní pravidla pro ukončování relací, jeho vstupní pole byla náchylná k základním injekčním útokům a chybová hlášení zpřístupňovala citlivé systémové informace. Nešlo o sofistikované zero-day exploity; šlo o základní chyby návrhu. Kořenová příčina byla bolestně zřejmá. Bezpečnostní požadavky nebyly nikdy formálně definovány, dokumentovány ani integrovány do vývojových sprintů. Tým měl neurčité zadání „udělat to bezpečné“, ale bez konkrétního návrhu zůstala bezpečnost nejasnou a často přehlíženou dodatečnou aktivitou.

Tento scénář není výjimečný. Ukazuje zásadní mezeru, se kterou se potýká mnoho CISO a vedoucích pracovníků odpovědných za soulad: převést záměr „bezpečnost řešíme“ do explicitních, testovatelných požadavků na zabezpečení aplikací, které jsou sladěny se základními normami, jako je ISO/IEC 27001:2022, a významnými právními předpisy, jako jsou NIS2, DORA a GDPR.

Vysoká cena nejednoznačnosti: co soulad skutečně vyžaduje

Jádro Mariina problému spočívá v běžném organizačním selhání: bezpečnost je vnímána jako atribut kvality, nikoli jako soubor nevyjednatelných požadavků. Účinný bezpečnostní požadavek je konkrétní, měřitelný a testovatelný. „Aplikace musí být bezpečná“ je přání. „Aplikace musí po 15 minutách neaktivity vynutit ukončení relace, validovat veškeré vstupy zadané uživatelem vůči předem definované sadě znaků a šifrovat veškerá data při přenosu pomocí TLS 1.3“ je požadavek. Právě tuto jednoznačnost auditoři očekávají a vývojáři potřebují k vytvoření bezpečného softwaru.

Bez ní vzniká řetězec selhání:

• Nekonzistentní implementace: Různí vývojáři si pojem „bezpečné“ vykládají odlišně, což vede k roztříštěnému souboru opatření s nepředvídatelnými mezerami.
• Vyšší náklady na nápravu: Nalezení a oprava chyby návrhu v produkčním prostředí je násobně dražší než její řešení ve fázi návrhu.
• Auditní neshody: Auditoři rychle identifikují absenci strukturovaného procesu pro definování bezpečnostních požadavků, což vede k závažným zjištěním.
• Podnikové riziko: Každý nedefinovaný požadavek představuje potenciální vektor útoku a vystavuje organizaci porušení zabezpečení dat, finanční ztrátě a poškození reputace.

Napříč moderními normami je očekávání konzistentní: bezpečnost musí být definována jako požadavky, včas a s vazbou na rizika a právní povinnosti. Pokyny ISO/IEC 27002:2022 k opatření 8.26, požadavky na zabezpečení aplikací, očekávají, že organizace budou systematicky určovat, dokumentovat a schvalovat bezpečnostní požadavky na základě formálního posouzení rizik a regulatorních požadavků.

Tento jediný princip je klíčovým spojovacím prvkem široké škály požadavků na soulad. Mapování napříč rámci v rámci Zenith Controls: The Cross-Compliance Guide společnosti Clarysec Zenith Controls ukazuje, jak se tento koncept objevuje všude:

• GDPR v článcích 25 a 32 očekává „ochranu osobních údajů již od návrhu“ a „zabezpečení zpracování“.
• NIS2 v článku 21(2)(d)-(e) zdůrazňuje bezpečný vývoj a zabezpečení dodavatelského řetězce.
• DORA v článcích 6(4), 8, 10 a 11 vyžaduje řízení rizik v oblasti ICT a bezpečnost již ve fázi návrhu pro finanční subjekty.
• NIST SP 800-53 Rev.5 v opatřeních SA-4 a SA-15 vyžaduje definované bezpečnostní požadavky na systémy a postupy bezpečného vývoje.
• COBIT 2019 v procesech BAI03 a DSS05 vyžaduje, aby byly požadavky související s bezpečností sladěny s obchodními cíli a požadavky na soulad ještě před vytvořením řešení.

Cílem je definovat, slovy Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, „co bezpečnost znamená pro vaše aplikace, ještě před napsáním jediného řádku kódu.“

Proč tradiční přístupy selhávají: kontrolní seznamy, pozdní testování a bezpečnostní divadlo

Většina organizací již nějakou formu zabezpečení aplikací provádí. Problém je, že jen zřídka je strukturována způsobem, který obstojí při certifikaci podle ISO/IEC 27001:2022 nebo při regulatorním dohledu.

Mezi běžné vzorce selhání patří:

1. Obecné kontrolní seznamy: Týmy opakovaně používají jednostránkový „kontrolní seznam bezpečného kódování“ pro každý projekt. Není navázán na specifická rizika aplikace, citlivost dat ani regulatorní kontext. Když se auditor zeptá, jak se kontrolní seznam mapuje na článek 25 GDPR, neexistuje jasná odpověď.
2. Bezpečnost jako pozdní schvalovací brána: Bezpečnostní požadavky nejsou začleněny do návrhu ani uživatelských scénářů. Objeví se až na konci jako požadavek na penetrační test. Zenith Blueprint upozorňuje, že „spoléhat se na bezpečnostní kontrolní seznam na konci projektu nefunguje; tyto požadavky musí formovat architekturu, ovlivňovat volbu knihoven a řídit prioritizaci funkcí od prvního dne.“
3. Žádná dohledatelnost od požadavku k testu: Požadavek může znít „šifrovat data při přenosu“, ale neexistuje navázaný testovací případ ověřující vynucení verze TLS, platnost certifikátu a sílu šifer. Zenith Blueprint trvá na tom, že očekávání musí být měřitelná a testovatelná, přičemž bezpečnostní testy musí být přímo mapovány na odpovídající požadavky.
4. Ad hoc nakládání s kódem třetích stran: Moderní aplikace jsou často „poskládány z interního kódu, knihoven třetích stran, rozhraní API a cloudově nativních služeb“, jak uvádí Zenith Blueprint. Bez explicitních požadavků na dodavatele a open-source komponenty zůstává riziko dodavatelského řetězce rozsáhlým a neřízeným slepým místem.

Výsledkem je bezpečnostní divadlo: dokumenty existují a testy se provádějí, ale když seriózní auditor nebo regulatorní orgán hledá koherentní příběh požadavků, celý proces se rozpadá.

Budování základů: od politiky k praxi

Disciplinovaný přístup k zabezpečení aplikací začíná jasnou správou a řízením. Politika není jen byrokracie; je to oficiální zdroj pravdy, který zmocňuje týmy a poskytuje auditorům jasné vyjádření záměru. Ve společnosti Clarysec navrhujeme politiky, které jsou autoritativní i praktické.

Naše Politika požadavků na zabezpečení aplikací Politika požadavků na zabezpečení aplikací stanoví nevyjednatelná základní pravidla. Například kapitola 5.2 v části „Požadavky na správu a řízení“ ukládá:

Všechny aplikace musí během plánování nebo pořizování projít validací bezpečnostních požadavků s dokumentovaným schválením týmem zabezpečení aplikací.

Tento jednoduchý požadavek brání mentalitě „nejdřív postavit, zabezpečit později“. Politika také přiřazuje jasnou odpovědnost. Kapitola 4.3.1 v části „Role a odpovědnosti“ stanoví, že od vývojářů se očekává:

Implementovat aplikace v souladu s definovanými bezpečnostními požadavky a normami.

Tím se těžiště odpovědnosti za bezpečnost přesouvá z odděleného, často protistranného bezpečnostního týmu na samotné tvůrce softwaru. Politika dále propojuje jednotlivé bezpečnostní domény. Kapitola 10.2 odkazuje na integraci s dalšími klíčovými opatřeními:

P4 – Politika řízení přístupu. Definuje standardy správy identit a relací, které musí vynucovat všechny aplikace, včetně silné autentizace, zásady minimálních oprávnění a požadavků na přezkum přístupových práv.

Pro menší organizace zajišťuje přizpůsobená politika, jako je naše Politika požadavků na zabezpečení aplikací – SME Politika požadavků na zabezpečení aplikací – SME, že tyto principy lze škálovat. Uznává, že rizika jsou podobná, ale implementace musí být pragmatická. Obě verze nakonec míří ke stejnému výsledku: zajistit, aby bylo zabezpečení aplikací plně integrováno do ISMS a připraveno na audit.

Praktický plán: tvorba požadavků na zabezpečení aplikací připravených na audit

Politika stanovuje „co“ a „proč“, ale vývojáři a projektoví manažeři potřebují „jak“. Strukturovaný implementační průvodce je nezbytný pro převod opatření na vysoké úrovni do proveditelných kroků. Krok 21 Zenith Blueprint, zaměřený na opatření ISO/IEC 27002:2022 8.26, poskytuje jasnou šestikrokovou metodiku.

Projděme si tento proces na příkladu Mariina platebního portálu.

Krok 1: Začněte rizikem a regulatorním kontextem

S využitím výstupu posouzení rizik sladěného s ISO/IEC 27005:2024 (ošetření rizik) nejprve určíte kontext:

• Aplikace: Samoobslužný platební portál pro zákazníky.
• Data: osobně identifikovatelné informace, přihlašovací údaje, platební tokeny.
• Jurisdikce: EU, finanční služby, provozováno v cloudu.
• Právní předpisy: GDPR, DORA, PCI DSS.

Na základě pokynů k opatření 8.26 v Zenith Controls a souvisejících normách ISO (27034-1, 27017, 27701) musí výchozí kategorie požadavků zahrnovat identifikaci a autentizaci, autorizaci, klasifikaci dat, validaci vstupů, protokolování a ochranu dat při přenosu i v klidu.

Krok 2: Vytvořte nebo přijměte šablonu bezpečnostních požadavků

Zenith Blueprint doporučuje vytvořit standardizovanou šablonu, která zajistí, že každý projekt odpoví na stejné základní bezpečnostní otázky. Tento dokument by se měl stát součástí sady nástrojů pro zahájení projektu.

Minimální části by měly zahrnovat:

• Název aplikace, vlastníka a kritičnost.
• Kategorie dat a úrovně citlivosti.
• Použitelné regulatorní a smluvní povinnosti (GDPR, DORA atd.).
• Vstupy o prostředí hrozeb (odvozené z opatření 5.7 informace o hrozbách).
• Konkrétní bezpečnostní požadavky podle kategorií (autentizace, protokolování atd.).
• Vazby na uživatelské scénáře a akceptační kritéria.
• Vazby na testovací případy (funkční, bezpečnostní, penetrační).
• Požadavky na dodavatele a komponenty třetích stran.

Krok 3: Začleňte požadavky do agilních artefaktů

Bezpečnostní požadavky musí být přímo začleněny do uživatelských scénářů a akceptačních kritérií. U epiku „registrace zákazníka“ v Mariině projektu portálu to znamená převést jednoduchý funkční scénář na scénář zohledňující bezpečnost.

• Původní uživatelský scénář: „Jako nový uživatel si mohu vytvořit účet.“
• Bezpečný uživatelský scénář: „Jako nový zákazník si chci vytvořit zabezpečený účet, aby byly mé platební údaje chráněny.“
• Akceptační kritéria (se začleněnou bezpečností):
  • Systém musí vynucovat politiku silných hesel v souladu s P4 – Politikou řízení přístupu.
  • Systém musí před aktivací účtu vyžadovat ověření e-mailu prostřednictvím jednorázového odkazu.
  • Formulář pro vytvoření účtu musí být chráněn pomocí CAPTCHA, aby se zabránilo útokům botů.
  • Všechny pokusy o registraci musí být protokolovány se zdrojovou IP adresou a otiskem zařízení.
  • Veškerá data odeslaná prostřednictvím formuláře musí být ošetřena, aby se zabránilo cross-site scripting (XSS).

Nejde o samostatné bezpečnostní úkoly; jsou nedílnou součástí definice „hotovo“ pro danou funkci.

Krok 4: Propojte požadavky s bezpečnostním testováním

S využitím opatření 8.29 Bezpečnostní testování z Zenith Controls zajistíte, aby měl každý požadavek přiřazený testovací případ. Tím se uzavírá smyčka a vznikají auditovatelné důkazy o účinnosti opatření.

• Požadavek: Šifrování při přenosu pomocí TLS 1.3. → Test: Automatizovaný sken ověřující vynucení TLS, platnost certifikátu a schválené sady šifer.
• Požadavek: Validace vstupů k prevenci SQL injection. → Test: Automatizované skenování SAST/DAST a manuální fuzzing během zajištění kvality (QA).
• Požadavek: Časový limit neaktivní relace 15 minut. → Test: Automatizované a manuální testy potvrzující zneplatnění relace na straně serveru po 15 minutách neaktivity.

Krok 5: Rozšiřte požadavky na dodavatelský řetězec

Protože opatření ISO 8.26 je v Zenith Controls navázáno na bezpečnost dodavatelů (5.19, 5.20) a outsourcovaný vývoj (8.30), váš proces musí zohledňovat kód třetích stran. Pro SME výrazně závislé na externích knihovnách je klíčové ustanovení politiky z Politiky požadavků na zabezpečení aplikací – SME:

Jakýkoli nástroj třetí strany, plugin nebo externí knihovna kódu použitá v aplikaci musí být zaznamenána a každoročně přezkoumána z hlediska bezpečnostního dopadu a stavu záplat.

Tento jednoduchý, pragmatický požadavek vynucuje přístup založený na softwarovém kusovníku (SBOM), který je jedním z klíčových očekávání podle předpisů, jako je NIS2. U významných dodavatelů musí být stejné požadavky na zabezpečení aplikací zahrnuty do smluv s odkazem na ISO/IEC 27036-1 (zabezpečení dodavatelského řetězce ICT).

Krok 6: Zaveďte pravidelné opětovné posuzování

Jak se aplikace vyvíjejí, mění se i jejich rizika. Pokyny Zenith Blueprint k pravidelnému opětovnému posuzování jsou zásadní. Když integrujete nové rozhraní API nebo přecházíte na jinou cloudovou službu, mění se rizikový kontext. To musí vyvolat přezkum stávajících bezpečnostních požadavků, aby bylo zajištěno, že jsou stále přiměřené. Tento postup je v souladu s ISO/IEC 27005:2024 (průběžné ošetření rizik) a mění zabezpečení aplikací v nepřetržitou praxi, nikoli v jednorázový projekt.

Rozbor ekosystému opatření

Opatření ISO nikdy neexistuje ve vakuu. Účinná bezpečnost závisí na propojené síti opatření. Skutečný přínos opatření 8.26 se projeví, když porozumíte jeho vztahu k dalším opatřením, což podrobně popisuje Zenith Controls.

Opatření 8.26 je klasifikováno jako preventivní opatření, ale funguje jako centrální uzel celého procesu bezpečného vývoje a propojuje se s:

• 8.25 - životní cyklus bezpečného vývoje: Jde o zastřešující rámec. Opatření 8.26 poskytuje konkrétní co (požadavky), které musí být integrováno do jak (proces SDLC).
• 8.27 - bezpečná architektura systémů a inženýrské principy: Požadavky určují architektonická rozhodnutí a zajišťují, že bezpečnost je základní součástí návrhu.
• 8.28 - bezpečné kódování: Jakmile jsou požadavky definovány (např. „zabránit SQL injection“), standardy bezpečného kódování poskytují vývojářům techniky, jak daný požadavek splnit.
• 8.29 - bezpečnostní testování ve vývoji a akceptaci: Toto opatření ověřuje, že požadavky definované v 8.26 byly správně implementovány.
• 5.34 - ochrana soukromí a ochrana osobně identifikovatelných informací: Pokud aplikace zpracovává osobní údaje, požadavky z 8.26 musí zahrnovat principy ochrany soukromí již ve fázi návrhu.
• 5.19 & 5.20 - bezpečnost informací ve vztazích s dodavateli: U pořizovaných nebo outsourcovaných aplikací opatření 8.26 stanoví, že vaše bezpečnostní požadavky musí zasahovat do dodavatelského řetězce.

Vnímání těchto opatření jako ekosystému, nikoli jako kontrolního seznamu, umožňuje vybudovat vícevrstvý a obhajitelný bezpečnostní stav.

Pohled auditora: příprava na prověrku

Auditoři uvažují v pojmech důkazů. Chcete-li se připravit, musíte rozumět různým perspektivám, které auditor může uplatnit. Část metodiky auditu v Zenith Controls tyto různé přístupy předvídá.

Pochopení těchto pohledů vám umožní připravit komplexní portfolio důkazů, které prokazuje živý, fungující proces zakotvený ve vaší organizaci.

Kompas napříč rámci souladu: jeden proces, mnoho rámců

Pro firmu, jako je ta Mariina, je splnění DORA, GDPR a NIS2 povinné. Ruční mapování opatření je receptem na duplicitní úsilí a mezery v souladu. Centralizovaný přístup napříč rámci pro soulad přináší zásadní hodnotu. Definování požadavků na zabezpečení aplikací je praktickou implementací principu „bezpečnost již ve fázi návrhu“, na němž stojí všechny tyto moderní právní předpisy.

Implementací robustního procesu pro požadavky na zabezpečení aplikací založeného na ISO/IEC 27002:2022 současně vytváříte důkazy pro splnění významné části těchto dalších předpisů. Neděláte pouze „ISO“; budujete bezpečnostní program obecně využitelný pro plnění požadavků na soulad.

Od chaosu k řízení: vaše další kroky

Mariin příběh má pozitivní výsledek. Incident s platebním portálem využila jako katalyzátor změny. Vyzbrojena jasným rámcem politik od Clarysec a praktickým implementačním průvodcem spojila vývojové, bezpečnostní a produktové týmy. Pomocí metodiky Zenith Blueprint zpětně definovali požadavky pro portál a prioritizovali nápravná opatření podle rizika.

Ještě důležitější je, že zavedli nový způsob práce. „Bezpečnostní kontrolní seznam“ nahradila společná návrhová sezení. Když dorazili auditoři DORA, Maria jim mohla nejen ukázat bezpečnou aplikaci, ale také prokázat vyspělý a opakovatelný proces, který zajišťuje, že všechny budoucí aplikace budou postaveny na bezpečných základech.

Transformace bezpečnostního stavu vašich aplikací začíná jedním strukturovaným krokem. Vaše cesta je jasná:

1. Zaveďte správu a řízení: Implementujte formální politiku pro definování požadavků na zabezpečení aplikací. Naše šablony, například Politika požadavků na zabezpečení aplikací, poskytují výchozí bod připravený na audit.
2. Přijměte praktický rámec: Použijte Zenith Blueprint k integraci bezpečnostních požadavků přímo do životního cyklu vývoje, aby byly proveditelné, testovatelné a dohledatelné.
3. Pochopte celý kontext: Využijte Zenith Controls, abyste viděli, jak se toto kritické opatření propojuje s širším bezpečnostním ekosystémem a mapuje napříč DORA, NIS2, GDPR a dalšími rámci.
4. Škálujte na celé portfolio: Jakmile přístup funguje pro jednu aplikaci, rozšiřte jej napříč portfoliem začleněním šablony bezpečnostních požadavků do standardních kontrolních seznamů pro zahájení projektů, agilních šablon a procesů pořizování.

Pokud chcete tuto transformaci urychlit, Clarysec poskytuje předpřipravené politiky, implementační plány a mapování napříč rámci pro soulad, které vás posunou od roztříštěných aktivit k prokazatelně vyspělému programu připravenému na audit. Přestaňte zacházet se zabezpečením aplikací jako se závěrečnou schvalovací bránou. Začněte jej zabudovávat do návrhu všeho, co vytváříte.