Od návrhu po auditnú pripravenosť: zvládnutie požiadaviek na bezpečnosť aplikácií pre ISO 27001, DORA a NIS2

Predauditové napätie bolo citeľné. Pre Máriu, riaditeľku informačnej bezpečnosti (CISO) v stredne veľkej fintechovej spoločnosti, nadchádzajúce posúdenie súladu s DORA nepôsobilo ako bežná kontrola, ale skôr ako zúčtovanie. Jej tím bol odborný, infraštruktúra riadne spevnená, no jedna pretrvávajúca zraniteľnosť jej nedala spať: rozsiahly a chaotický svet ich aplikácií.

Najnovšou obavou bol nový zákaznícky platobný portál, uvedený do prevádzky narýchlo, aby sa splnili kvartálne ciele. Vývojový tím pracujúci vo vysokom agilnom tempe splnil všetky funkčné požiadavky. Keď však Máriin tím vykonal predbežný sken, výsledky potvrdili jej obavy.

Portálu chýbali robustné pravidlá časového limitu relácie, jeho vstupné polia boli náchylné na základné injekčné útoky a chybové hlásenia odhaľovali citlivé systémové informácie. Nešlo o sofistikované zero-day exploity; boli to základné chyby návrhu. Koreňová príčina bola bolestne zrejmá. Bezpečnostné požiadavky neboli nikdy formálne definované, zdokumentované ani integrované do vývojových sprintov. Tím mal nejasný mandát „urobiť to bezpečné“, ale bez konkrétneho návrhu zostala bezpečnosť nejednoznačnou a často ignorovanou témou riešenou až dodatočne.

Tento scenár nie je výnimočný. Poukazuje na kritickú medzeru, ktorej čelia mnohí CISO a lídri zodpovední za súlad s požiadavkami: premeniť zámer „robíme bezpečnosť“ na explicitné, testovateľné požiadavky na bezpečnosť aplikácií zosúladené so základnými normami, ako je ISO/IEC 27001:2022, a s hlavnými predpismi, ako sú NIS2, DORA a GDPR.

Vysoká cena nejednoznačnosti: čo súlad v skutočnosti vyžaduje

Jadro Máriinho problému spočíva v bežnom organizačnom zlyhaní: bezpečnosť sa považuje za kvalitatívnu vlastnosť, nie za súbor nevyjednateľných požiadaviek. Účinná bezpečnostná požiadavka je konkrétna, merateľná a testovateľná. „Aplikácia musí byť bezpečná“ je želanie. „Aplikácia musí vynucovať časový limit nečinnosti relácie 15 minút, validovať všetky vstupy zadané používateľom voči vopred definovanej množine znakov a šifrovať všetky údaje pri prenose pomocou TLS 1.3“ je požiadavka. Práve takúto jasnosť hľadajú audítori a potrebujú vývojári na tvorbu bezpečného softvéru.

Bez nej vzniká reťazec zlyhaní:

• Nekonzistentná implementácia: Rôzni vývojári chápu pojem „bezpečné“ rôzne, čo vedie k nesúrodému súboru kontrolných opatrení s nepredvídateľnými medzerami.
• Vyššie náklady na nápravu: Nájsť a opraviť chybu návrhu v produkčnom prostredí je násobne drahšie než riešiť ju vo fáze návrhu.
• Nezhody z auditu: Audítori rýchlo identifikujú absenciu štruktúrovaného procesu na definovanie bezpečnostných požiadaviek, čo vedie k významným zisteniam.
• Riziko pre organizáciu: Každá nedefinovaná požiadavka je potenciálnym vektorom útoku, ktorý organizáciu vystavuje porušeniam ochrany údajov, finančným stratám a reputačnej ujme.

V moderných normách je očakávanie konzistentné: bezpečnosť musí byť definovaná ako požiadavky, včas a s väzbou na riziká a právne požiadavky. Usmernenie ISO/IEC 27002:2022 k opatreniu 8.26, požiadavky na bezpečnosť aplikácií, očakáva, že organizácie budú systematicky určovať, dokumentovať a schvaľovať bezpečnostné požiadavky na základe formálneho posúdenia rizík a regulačných požiadaviek.

Tento jediný princíp je kľúčovým spojovacím prvkom širokého spektra požiadaviek na súlad. Mapovanie naprieč rámcami súladu v Clarysec v rámci Zenith Controls: The Cross-Compliance Guide Zenith Controls ukazuje, ako sa tento koncept objavuje všade:

• GDPR články 25 a 32 očakávajú „ochranu údajov už od návrhu“ a „bezpečnosť spracúvania“.
• NIS2 článok 21(2)(d)-(e) zdôrazňuje bezpečný vývoj a bezpečnosť dodávateľského reťazca.
• DORA články 6(4), 8, 10 a 11 vyžadujú riadenie rizík IKT a bezpečnosť už od návrhu pre finančné subjekty.
• NIST SP 800-53 Rev.5 v kontrolách SA-4 a SA-15 vyžaduje definované bezpečnostné požiadavky na systémy a praktiky bezpečného vývoja.
• COBIT 2019 v procesoch BAI03 a DSS05 vyžaduje, aby boli bezpečnostné požiadavky zosúladené s potrebami organizácie a požiadavkami na súlad ešte pred vytvorením riešenia.

Cieľom je definovať, slovami Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, „čo bezpečnosť znamená pre vaše aplikácie ešte pred napísaním jediného riadku kódu.“

Prečo tradičné prístupy zlyhávajú: kontrolné zoznamy, neskoré testovanie a bezpečnostné divadlo

Väčšina organizácií už nejakú formu bezpečnosti aplikácií vykonáva. Problém je v tom, že len zriedka je štruktúrovaná tak, aby obstála pri certifikácii podľa ISO/IEC 27001:2022 alebo pri regulačnej kontrole.

Bežné vzorce zlyhania zahŕňajú:

1. Generické kontrolné zoznamy: Tímy opakovane používajú jednostránkový „kontrolný zoznam bezpečného programovania“ pre každý projekt. Nie je naviazaný na špecifické riziká aplikácie, citlivosť údajov ani regulačný kontext. Keď sa audítor opýta, ako kontrolný zoznam mapuje na GDPR Article 25, neexistuje jasná odpoveď.
2. Bezpečnosť ako neskorá brána: Bezpečnostné požiadavky nie sú začlenené do návrhu ani používateľských príbehov. Objavia sa až na konci ako požiadavka na penetračný test. Zenith Blueprint upozorňuje, že „spoliehať sa na bezpečnostný kontrolný zoznam na konci projektu nefunguje; tieto požiadavky musia formovať architektúru, ovplyvňovať výber knižníc a usmerňovať prioritizáciu funkcií od prvého dňa.“
3. Žiadna sledovateľnosť od požiadavky k testu: Môže existovať požiadavka „šifrovať údaje pri prenose“, ale neexistuje prepojený testovací prípad overujúci vynútenie verzie TLS, platnosť certifikátu a silu šifry. Zenith Blueprint trvá na tom, že očakávania musia byť merateľné a testovateľné, pričom bezpečnostné testy sú priamo mapované na príslušné požiadavky.
4. Ad hoc nakladanie s kódom tretích strán: Moderné aplikácie sú často „poskladané z interného kódu, knižníc tretích strán, rozhraní API a cloudovo natívnych služieb“, ako uvádza Zenith Blueprint. Bez explicitných požiadaviek na dodávateľov a open-source komponenty zostáva riziko dodávateľského reťazca rozsiahlym, nekontrolovaným slepým miestom.

Výsledkom je bezpečnostné divadlo: dokumenty existujú a testy sa vykonávajú, no keď skúsený audítor alebo regulátor hľadá koherentný príbeh požiadaviek, celý proces sa rozpadne.

Budovanie základov: od politiky k praxi

Disciplinovaný prístup k bezpečnosti aplikácií začína jasnou správou a riadením. Politika nie je iba byrokracia; je oficiálnym zdrojom pravdy, ktorý posilňuje tímy a poskytuje audítorom jasné vyhlásenie zámeru. V Clarysec navrhujeme politiky, ktoré sú autoritatívne aj praktické.

Naša politika Application Security Requirements Policy Application Security Requirements Policy stanovuje nevyjednateľné základné pravidlá. Napríklad bod 5.2 v časti „Požiadavky na správu a riadenie“ vyžaduje:

Všetky aplikácie musia počas plánovania alebo obstarávania prejsť validáciou bezpečnostných požiadaviek so zdokumentovaným schválením tímom bezpečnosti aplikácií.

Táto jednoduchá požiadavka bráni mentalite „najprv postaviť, zabezpečiť neskôr“. Politika zároveň prideľuje jasnú zodpovednosť. Bod 4.3.1 v časti „Roly a zodpovednosti“ uvádza, že vývojári musia:

Implementovať aplikácie v súlade s definovanými bezpečnostnými požiadavkami a normami.

Tým sa ťarcha bezpečnosti presúva z oddeleného, často protistranne vnímaného bezpečnostného tímu na samotných tvorcov softvéru. Politika navyše prepája jednotlivé bezpečnostné oblasti. Bod 10.2 odkazuje na integráciu s ďalšími kľúčovými kontrolnými opatreniami:

P4 – Politika riadenia prístupu. Definuje normy správy identít a riadenia relácií, ktoré musia vynucovať všetky aplikácie vrátane silnej autentifikácie, zásady minimálnych oprávnení a požiadaviek na revíziu prístupových práv.

Pre menšie organizácie zabezpečuje prispôsobená politika, ako je naša Application Security Requirements Policy - sme Application Security Requirements Policy-sme, škálovateľnosť týchto princípov. Uznáva, že hoci riziká sú podobné, implementácia musí byť pragmatická. Obe verzie napokon smerujú k rovnakému výsledku: zabezpečiť, aby bola bezpečnosť aplikácií plne integrovaná do ISMS a pripravená na audit.

Praktická cestovná mapa: budovanie požiadaviek na bezpečnosť aplikácií pripravených na audit

Politika určuje „čo“ a „prečo“, ale vývojári a projektoví manažéri potrebujú „ako“. Štruktúrovaný implementačný sprievodca je nevyhnutný na premenu vysokoúrovňových kontrolných opatrení na vykonateľné kroky. Krok 21 v Zenith Blueprint, zameraný na opatrenie ISO/IEC 27002:2022 8.26, poskytuje jasnú šesťkrokovú metodiku.

Prejdime si tento proces na príklade Máriinho platobného portálu.

Krok 1: Začnite od rizika a regulačného kontextu

Pomocou výstupu z posúdenia rizík zosúladeného s ISO/IEC 27005:2024 (ošetrenie rizík) najprv identifikujete kontext:

• Aplikácia: Zákaznícky samoobslužný platobný portál.
• Údaje: osobné identifikačné údaje (PII), prihlasovacie údaje, platobné tokeny.
• Jurisdikcie: EÚ, finančné služby, prevádzka v cloude.
• Predpisy: GDPR, DORA, PCI DSS.

Na základe usmernenia k opatreniu 8.26 v Zenith Controls a súvisiacich normách ISO (27034-1, 27017, 27701) musia počiatočné kategórie požiadaviek zahŕňať identifikáciu a autentifikáciu, autorizáciu, klasifikáciu údajov, validáciu vstupov, logovanie a ochranu údajov pri prenose aj v pokoji.

Krok 2: Vytvorte alebo prevezmite šablónu bezpečnostných požiadaviek

Zenith Blueprint odporúča vytvoriť štandardizovanú šablónu, aby každý projekt odpovedal na rovnaké základné bezpečnostné otázky. Tento dokument by sa mal stať súčasťou nástrojovej súpravy pri štarte projektu.

Minimálne sekcie by mali zahŕňať:

• Názov aplikácie, vlastníka a kritickosť.
• Kategórie údajov a úrovne citlivosti.
• Uplatniteľné regulačné a zmluvné povinnosti (GDPR, DORA atď.).
• Vstupy z prostredia hrozieb (odvodené z opatrenia 5.7 Spravodajstvo o hrozbách).
• Konkrétne bezpečnostné požiadavky podľa kategórií (autentifikácia, logovanie atď.).
• Väzby na používateľské príbehy a akceptačné kritériá.
• Väzby na testovacie prípady (funkčné, bezpečnostné, penetračné).
• Požiadavky na dodávateľov a komponenty tretích strán.

Krok 3: Začleňte požiadavky do agilných artefaktov

Bezpečnostné požiadavky musia byť začlenené priamo do používateľských príbehov a akceptačných kritérií. Pri epiku „registrácia zákazníka“ v projekte Máriinho portálu to znamená premeniť jednoduchý funkčný príbeh na príbeh zohľadňujúci bezpečnosť.

• Pôvodný používateľský príbeh: „Ako nový používateľ si môžem vytvoriť účet.“
• Bezpečný používateľský príbeh: „Ako nový zákazník si chcem vytvoriť bezpečný účet, aby boli moje platobné informácie chránené.“
• Akceptačné kritériá (so začlenenou bezpečnosťou):
  • Systém musí vynucovať silnú politiku hesiel v súlade s P4 – Politikou riadenia prístupu.
  • Systém musí pred aktiváciou účtu vyžadovať overenie e-mailu prostredníctvom jednorazového odkazu.
  • Formulár na vytvorenie účtu musí byť chránený mechanizmom CAPTCHA na prevenciu bot útokov.
  • Všetky pokusy o registráciu musia byť logované so zdrojovou IP adresou a odtlačkom zariadenia.
  • Všetky údaje odoslané prostredníctvom formulára musia byť sanitizované na prevenciu cross-site scripting (XSS).

Toto nie sú samostatné bezpečnostné úlohy; sú neoddeliteľnou súčasťou definície „hotovo“ pre danú funkcionalitu.

Krok 4: Prepojte požiadavky s bezpečnostným testovaním

Pomocou opatrenia 8.29 Bezpečnostné testovanie z Zenith Controls zabezpečíte, aby každá požiadavka mala priradený testovací prípad. Tým sa uzavrie spätná väzba a vzniknú auditovateľné dôkazy o účinnosti kontrolných opatrení.

• Požiadavka: Šifrovanie pri prenose pomocou TLS 1.3. → Test: Automatizovaný sken na overenie vynucovania TLS, platnosti certifikátu a schválených sád šifier.
• Požiadavka: Validácia vstupov na prevenciu SQL injection. → Test: Automatizované skenovanie SAST/DAST a manuálny fuzzing počas QA.
• Požiadavka: Časový limit nečinnosti relácie 15 minút. → Test: Automatizované a manuálne testy potvrdzujúce zneplatnenie relácie na strane servera po 15 minútach nečinnosti.

Krok 5: Rozšírte požiadavky na dodávateľský reťazec

Keďže opatrenie ISO 8.26 je v Zenith Controls prepojené s bezpečnosťou dodávateľov (5.19, 5.20) a outsourcovaným vývojom (8.30), váš proces musí zohľadňovať kód tretích strán. Pre MSP vo veľkej miere závislé od externých knižníc je kritické ustanovenie z Application Security Requirements Policy - sme:

Každý nástroj tretej strany, doplnok alebo externá knižnica kódu použitá v aplikácii musí byť zaznamenaná a každoročne preskúmaná z hľadiska bezpečnostného dopadu a stavu záplatovania.

Táto jednoduchá a pragmatická požiadavka vynucuje prístup založený na softvérovom kusovníku (SBOM), ktorý je kľúčovým očakávaním podľa predpisov, ako je NIS2. Pri významných dodávateľoch musia byť rovnaké požiadavky na bezpečnosť aplikácií zahrnuté v zmluvách s odkazom na ISO/IEC 27036-1 (bezpečnosť dodávateľského reťazca IKT).

Krok 6: Nastavte pravidelné prehodnocovanie

Ako sa aplikácie vyvíjajú, menia sa aj ich riziká. Usmernenie Zenith Blueprint k pravidelnému prehodnocovaniu je zásadné. Keď integrujete nové API alebo prejdete na inú cloudovú službu, mení sa rizikový kontext. To musí spustiť preskúmanie existujúcich bezpečnostných požiadaviek, aby sa zabezpečilo, že sú stále primerané. Tento prístup je v súlade s ISO/IEC 27005:2024 (priebežné ošetrenie rizík) a mení bezpečnosť aplikácií na kontinuálnu prax, nie jednorazový projekt.

Rozbor ekosystému kontrolných opatrení

Opatrenie ISO nikdy neexistuje izolovane. Účinná bezpečnosť závisí od prepojenej siete opatrení. Skutočná hodnota opatrenia 8.26 sa prejaví vtedy, keď rozumiete jeho vzťahu k ďalším kontrolným opatreniam, ako podrobne vysvetľuje Zenith Controls.

Opatrenie 8.26 je klasifikované ako preventívne kontrolné opatrenie, ale funguje ako centrálny uzol celého procesu bezpečného vývoja a prepája sa s:

• 8.25 - Životný cyklus bezpečného vývoja: Ide o zastrešujúci rámec. Opatrenie 8.26 poskytuje konkrétne čo (požiadavky), ktoré musí byť integrované do ako (proces SDLC).
• 8.27 - Bezpečná systémová architektúra a inžinierske princípy: Požiadavky riadia architektonické rozhodnutia a zabezpečujú, že bezpečnosť je základom návrhu.
• 8.28 - Bezpečné programovanie: Po definovaní požiadaviek (napr. „zabrániť SQL injection“) poskytujú štandardy bezpečného programovania vývojárom techniky na splnenie tejto požiadavky.
• 8.29 - Bezpečnostné testovanie vo vývoji a akceptácii: Toto opatrenie overuje, že požiadavky definované v 8.26 boli správne implementované.
• 5.34 - Ochrana súkromia a ochrana PII: Ak aplikácia spracúva osobné údaje, požiadavky z 8.26 musia zahŕňať princípy ochrany súkromia už od návrhu.
• 5.19 & 5.20 - Informačná bezpečnosť vo vzťahoch s dodávateľmi: Pri zakúpených alebo outsourcovaných aplikáciách opatrenie 8.26 určuje, že vaše bezpečnostné požiadavky musia siahať aj do dodávateľského reťazca.

Ak sa na tieto opatrenia pozeráte ako na ekosystém, a nie ako na kontrolný zoznam, dokážete vybudovať viacvrstvový, obhájiteľný bezpečnostný stav.

Pohľad audítora: príprava na kontrolu

Audítori uvažujú v pojmoch dôkazov. Aby ste sa pripravili, musíte rozumieť rôznym perspektívam, z ktorých môže audítor vychádzať. Časť metodiky auditu v Zenith Controls predvída tieto rôzne prístupy.

Pochopenie týchto pohľadov vám umožní pripraviť komplexné portfólio dôkazov, ktoré preukazuje živý a funkčný proces zakotvený vo vašej organizácii.

Kompas naprieč rámcami súladu: jeden proces, viacero rámcov

Pre spoločnosť, ako je Máriina, je splnenie požiadaviek DORA, GDPR a NIS2 povinné. Manuálne mapovanie kontrolných opatrení je receptom na duplicitnú prácu a medzery v súlade. Centralizovaný prístup naprieč rámcami súladu prináša významnú hodnotu. Definovanie požiadaviek na bezpečnosť aplikácií je praktickou implementáciou princípu bezpečnosti už od návrhu, ktorý tvorí základ všetkých týchto moderných predpisov.

Implementáciou robustného procesu požiadaviek na bezpečnosť aplikácií založeného na ISO/IEC 27002:2022 zároveň vytvárate dôkazy na splnenie významnej časti týchto ďalších predpisov. Nerobíte iba „ISO“; budujete univerzálne súladný bezpečnostný program.

Od chaosu ku kontrole: vaša ďalšia cesta

Máriin príbeh má pozitívny výsledok. Incident s platobným portálom využila ako katalyzátor zmeny. Vyzbrojená jasným rámcom politík od Clarysec a praktickým implementačným sprievodcom spojila svoje vývojové, bezpečnostné a produktové tímy. Pomocou metodiky Zenith Blueprint spätne definovali požiadavky pre portál a prioritizovali nápravné opatrenia podľa rizika.

Ešte dôležitejšie je, že zaviedli nový spôsob práce. „Bezpečnostný kontrolný zoznam“ nahradili spoločnými návrhovými stretnutiami. Keď prišli audítori DORA, Mária im dokázala ukázať nielen bezpečnú aplikáciu, ale aj preukázať zrelý, opakovateľný proces zabezpečujúci, že všetky budúce aplikácie budú postavené na bezpečnostnom základe.

Transformácia vášho bezpečnostného stavu aplikácií sa začína jedným štruktúrovaným krokom. Vaša cesta je jasná:

1. Zaveďte správu a riadenie: Implementujte formálnu politiku na definovanie požiadaviek na bezpečnosť aplikácií. Naše šablóny, ako je Application Security Requirements Policy, poskytujú východisko pripravené na audit.
2. Prijmite praktický rámec: Použite Zenith Blueprint na integráciu bezpečnostných požiadaviek priamo do životného cyklu vývoja, aby boli vykonateľné, testovateľné a sledovateľné.
3. Pochopte celý kontext: Využite Zenith Controls, aby ste videli, ako toto kritické kontrolné opatrenie súvisí so širším bezpečnostným ekosystémom a ako sa mapuje naprieč DORA, NIS2, GDPR a ďalšími rámcami.
4. Škálujte na celé portfólio: Keď prístup funguje pre jednu aplikáciu, rozšírte ho na celé portfólio integráciou šablóny bezpečnostných požiadaviek do štandardných kontrolných zoznamov pri štarte projektu, agilných šablón a procesov obstarávania.

Ak chcete túto transformáciu urýchliť, Clarysec poskytuje vopred pripravené politiky, implementačné cestovné mapy a mapovania naprieč rámcami súladu, ktoré vás posunú od fragmentovaných aktivít k preukázateľne zrelému programu pripravenému na audit. Prestaňte zaobchádzať s bezpečnosťou aplikácií ako s finálnou kontrolou pri bráne. Začnite ju zabudovávať do návrhu všetkého, čo vytvárate.