Od nacrta do spremnosti za reviziju: ovladavanje zahtjevima za sigurnost aplikacija za ISO 27001, DORA i NIS2

Napetost uoči revizije bila je opipljiva. Za Mariju, CISO srednje velike fintech tvrtke, nadolazeća procjena usklađenosti s DORA-om djelovala je manje kao pregled, a više kao trenutak istine. Njezin je tim bio stručan, IT infrastruktura sigurnosno očvrsnuta, ali ju je noću budnom držala jedna uporna ranjivost: širok i neuređen ekosustav njihovih aplikacija.

Najnovija briga bio je novi portal za plaćanja dostupan klijentima, žurno pušten na tržište radi ispunjenja tromjesečnih ciljeva. Razvojni tim, radeći u vrlo zahtjevnom agilnom modelu, ispunio je sve funkcionalne zahtjeve. No kada je Marijin tim proveo preliminarno skeniranje, rezultati su potvrdili njezine strahove.

Portal nije imao robusna pravila isteka sesije, polja za unos bila su izložena osnovnim injection napadima, a poruke o pogreškama otkrivale su osjetljive informacije o sustavu. To nisu bili sofisticirani zero-day napadi; bili su to temeljni nedostaci dizajna. Temeljni uzrok bio je bolno jasan. Sigurnosni zahtjevi nikada nisu bili formalno definirani, dokumentirani ni integrirani u razvojne sprintove. Tim je imao neodređen mandat da aplikaciju „učini sigurnom”, ali bez konkretnog nacrta sigurnost je ostala nejasna i često zanemarena naknadna misao.

Ovaj scenarij nije iznimka. On pokazuje kritičan jaz s kojim se suočavaju mnogi CISO-i i voditelji usklađenosti: kako namjeru „provodimo sigurnost” pretvoriti u izričite, provjerljive zahtjeve za sigurnost aplikacija koji su usklađeni s temeljnim standardima kao što je ISO/IEC 27001:2022 i važnim propisima kao što su NIS2, DORA i GDPR.

Visoka cijena neodređenosti: što usklađenost doista očekuje

Srž Marijina problema leži u čestom organizacijskom propustu: sigurnost se tretira kao svojstvo kvalitete, a ne kao skup obveznih zahtjeva. Učinkovit sigurnosni zahtjev mora biti konkretan, mjerljiv i provjerljiv. „Aplikacija mora biti sigurna” želja je. „Aplikacija mora provoditi vremensko ograničenje neaktivne sesije od 15 minuta, provjeravati sve korisničke ulazne podatke prema unaprijed definiranom skupu znakova i šifrirati sve podatke u prijenosu koristeći TLS 1.3” zahtjev je. Upravo je ta jasnoća ono što revizori traže i što razvojnim inženjerima treba za izgradnju sigurnog softvera.

Bez toga stvarate preduvjete za niz neuspjeha:

• Nedosljedna provedba: Različiti razvojni inženjeri različito tumače pojam „sigurno”, što dovodi do neujednačenih kontrola s nepredvidivim prazninama.
• Veći troškovi korektivnih radnji: Pronalaženje i ispravljanje nedostatka dizajna u produkciji višestruko je skuplje nego njegovo rješavanje u fazi dizajna.
• Nesukladnosti u reviziji: Revizori će brzo utvrditi nepostojanje strukturiranog procesa za definiranje sigurnosnih zahtjeva, što dovodi do značajnih nalaza.
• Poslovni rizik: Svaki nedefinirani zahtjev potencijalni je vektor napada koji organizaciju izlaže povredama podataka, financijskim gubicima i reputacijskoj šteti.

U suvremenim standardima očekivanje je dosljedno: sigurnost mora biti definirana kao zahtjevi, u ranoj fazi te povezana s rizikom i zakonskim zahtjevima. Smjernice ISO/IEC 27002:2022 za kontrolu 8.26, Application security requirements, očekuju da organizacije sustavno utvrde, dokumentiraju i odobre sigurnosne zahtjeve na temelju formalne procjene rizika i regulatornih zahtjeva.

To je jedinstveno načelo središnja poveznica za širok raspon zahtjeva usklađenosti. Clarysecovo mapiranje međusobne usklađenosti u okviru Zenith Controls: The Cross-Compliance Guide Zenith Controls pokazuje kako se taj koncept pojavljuje posvuda:

• GDPR članci 25 i 32 očekuju „ugrađenu zaštitu podataka” i „sigurnost obrade”.
• NIS2 članak 21(2)(d)-(e) naglašava siguran razvoj i sigurnost opskrbnog lanca.
• DORA članci 6(4), 8, 10 i 11 zahtijevaju upravljanje IKT rizicima i ugrađenu sigurnost za financijske subjekte.
• NIST SP 800-53 Rev.5 u kontrolama SA-4 i SA-15 zahtijeva definirane sigurnosne zahtjeve sustava i prakse sigurnog razvoja.
• COBIT 2019 u procesima BAI03 i DSS05 zahtijeva da se sigurnosni zahtjevi usklade s poslovnim zahtjevima i zahtjevima usklađenosti prije izgradnje rješenja.

Cilj je, riječima Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, definirati „što sigurnost znači za vaše aplikacije prije nego što se napiše ijedan redak koda.”

Zašto tradicionalni pristupi ne uspijevaju: kontrolni popisi, kasno testiranje i privid sigurnosti

Većina organizacija već provodi neki oblik sigurnosti aplikacija. Problem je u tome što je rijetko strukturirana na način koji izdržava certifikaciju prema ISO/IEC 27001:2022 ili regulatornu provjeru.

Uobičajeni obrasci neuspjeha uključuju:

1. Generički kontrolni popisi: Timovi ponovno koriste jednostrani „kontrolni popis sigurnog kodiranja” za svaki projekt. On nije povezan sa specifičnim rizicima aplikacije, osjetljivošću podataka ili regulatornim kontekstom. Kada revizor pita kako se kontrolni popis mapira na GDPR članak 25, nema jasnog odgovora.
2. Sigurnost kao kasna kontrolna točka: Sigurnosni zahtjevi nisu ugrađeni u dizajn ili korisničke priče. Pojavljuju se na kraju kao zahtjev za penetracijsko testiranje. Zenith Blueprint upozorava da „oslanjanje na sigurnosni kontrolni popis na kraju projekta ne funkcionira; ti zahtjevi moraju oblikovati arhitekturu, utjecati na izbor biblioteka i usmjeravati prioritizaciju funkcionalnosti od prvog dana.”
3. Nema sljedivosti od zahtjeva do testa: Može postojati zahtjev za „šifriranje podataka u prijenosu”, ali ne postoji povezani testni slučaj koji provjerava provedbu TLS verzije, valjanost certifikata i snagu kriptografskih paketa. Zenith Blueprint inzistira da očekivanja moraju biti mjerljiva i provjerljiva, pri čemu se sigurnosni testovi izravno mapiraju na odgovarajuće zahtjeve.
4. Ad hoc postupanje s kodom trećih strana: Suvremene aplikacije često su „sastavljene od internog koda, biblioteka trećih strana, sučelja za programiranje aplikacija i cloud-native usluga”, kako navodi Zenith Blueprint. Bez izričitih zahtjeva za dobavljače i komponente otvorenog koda, rizik opskrbnog lanca ostaje golema, nekontrolirana slijepa točka.

Rezultat je privid sigurnosti: dokumenti postoje i testovi se provode, ali kada ozbiljan revizor ili regulator zatraži koherentnu priču o zahtjevima, cijeli se proces raspada.

Izgradnja temelja: od politike do prakse

Discipliniran pristup sigurnosti aplikacija počinje jasnim upravljanjem. Politika nije samo birokracija; ona je službeni izvor istine koji osnažuje timove i revizorima pruža jasnu izjavu o namjeri. U Clarysecu oblikujemo politike koje su istodobno obvezujuće i praktične.

Naša Application Security Requirements Policy Application Security Requirements Policy uspostavlja obvezna osnovna pravila. Primjerice, točka 5.2 u odjeljku „Zahtjevi upravljanja” propisuje:

Sve aplikacije moraju proći provjeru sigurnosnih zahtjeva tijekom planiranja ili nabave, uz dokumentirano odobrenje tima za sigurnost aplikacija.

Ova jednostavna odredba sprječava mentalitet „prvo izgradi, kasnije osiguraj”. Politika također dodjeljuje jasnu odgovornost. Točka 4.3.1 u odjeljku „Uloge i odgovornosti” navodi da razvojni inženjeri moraju:

Implementirati aplikacije u skladu s definiranim sigurnosnim zahtjevima i standardima.

Time se teret sigurnosti premješta s odvojenog, često suprotstavljenog sigurnosnog tima na same autore softvera. Nadalje, politika povezuje različite sigurnosne domene. Točka 10.2 upućuje na integraciju s drugim ključnim kontrolama:

P4 – Politika kontrole pristupa. Definira standarde upravljanja identitetom i sesijama koje moraju provoditi sve aplikacije, uključujući snažnu autentifikaciju, načelo najmanjih ovlasti i zahtjeve za preglede pristupa.

Za manje organizacije prilagođena politika poput naše Application Security Requirements Policy - sme Application Security Requirements Policy-sme osigurava da se ta načela mogu skalirati. Ona prepoznaje da su rizici slični, ali provedba mora biti pragmatična. Obje verzije u konačnici ciljaju isti ishod: osigurati da je sigurnost aplikacija potpuno integrirana u ISMS i spremna za reviziju.

Praktičan plan: izgradnja zahtjeva za sigurnost aplikacija spremnih za reviziju

Politika određuje „što” i „zašto”, ali razvojni inženjeri i voditelji projekata trebaju „kako”. Strukturirani vodič za provedbu nužan je za pretvaranje kontrola visoke razine u provedive korake. Korak 21 Zenith Blueprinta, usmjeren na kontrolu 8.26 iz ISO/IEC 27002:2022, pruža jasnu metodologiju u šest koraka.

Prođimo kroz taj proces na primjeru Marijina portala za plaćanja.

Korak 1: krenite od rizika i regulatornog konteksta

Koristeći izlaz procjene rizika usklađen s ISO/IEC 27005:2024 (obrada rizika), najprije utvrđujete kontekst:

• Aplikacija: portal za samostalno plaćanje klijenata.
• Podaci: osobni podaci (PII), vjerodajnice, platni tokeni.
• Jurisdikcije: EU, financijske usluge, hostirano u oblaku.
• Propisi: GDPR, DORA, PCI DSS.

Na temelju smjernica za kontrolu 8.26 u Zenith Controls i povezanih ISO standarda (27034-1, 27017, 27701), početne kategorije zahtjeva moraju uključivati identifikaciju i autentifikaciju, autorizaciju, klasifikaciju podataka, provjeru unosa, zapisivanje događaja te zaštitu podataka u prijenosu i u mirovanju.

Korak 2: izradite ili usvojite predložak sigurnosnih zahtjeva

Zenith Blueprint preporučuje izradu standardiziranog predloška kako bi svaki projekt odgovorio na ista temeljna sigurnosna pitanja. Taj dokument treba postati dio skupa alata za pokretanje projekta.

Minimalni odjeljci trebaju uključivati:

• naziv aplikacije, vlasnika i kritičnost.
• kategorije podataka i razine osjetljivosti.
• primjenjive regulatorne i ugovorne obveze (GDPR, DORA itd.).
• ulazne informacije o okruženju prijetnji (izvedene iz kontrole 5.7 Obavještajni podaci o prijetnjama).
• konkretne sigurnosne zahtjeve po kategorijama (autentifikacija, zapisivanje događaja itd.).
• poveznice s korisničkim pričama i kriterijima prihvata.
• poveznice s testnim slučajevima (funkcionalni, sigurnosni, penetracijski).
• zahtjeve za dobavljače i komponente trećih strana.

Korak 3: ugradite zahtjeve u agilne artefakte

Sigurnosni zahtjevi moraju se ugraditi izravno u korisničke priče i kriterije prihvata. Za ep „registracija korisnika” u Marijinu projektu portala to znači pretvaranje jednostavne funkcionalne priče u sigurnosno osviještenu priču.

• Izvorna korisnička priča: „Kao novi korisnik mogu kreirati račun.”
• Sigurna korisnička priča: „Kao novi klijent želim kreirati siguran račun kako bi moji podaci o plaćanju bili zaštićeni.”
• Kriteriji prihvata (s ugrađenom sigurnošću):
  • Sustav mora provoditi politiku snažne lozinke u skladu s P4 – Politikom kontrole pristupa.
  • Sustav mora zahtijevati potvrdu e-pošte putem jednokratne poveznice prije aktivacije računa.
  • Obrazac za kreiranje računa mora biti zaštićen CAPTCHA mehanizmom radi sprječavanja bot napada.
  • Svi pokušaji registracije moraju se bilježiti uz izvornu IP adresu i otisak uređaja.
  • Svi podaci poslani putem obrasca moraju se sanitizirati radi sprječavanja cross-site scripting (XSS) napada.

To nisu odvojeni sigurnosni zadaci; oni su sastavni dio definicije „dovršeno” za funkcionalnost.

Korak 4: povežite zahtjeve sa sigurnosnim testiranjem

Koristeći kontrolu 8.29 Sigurnosno testiranje iz Zenith Controls, osiguravate da svaki zahtjev ima povezani testni slučaj. Time se zatvara krug i osiguravaju revizijski dokazi o djelotvornosti kontrola.

• Zahtjev: šifriranje u prijenosu uz TLS 1.3. → Test: automatizirano skeniranje za provjeru provedbe TLS-a, valjanosti certifikata i odobrenih kriptografskih paketa.
• Zahtjev: provjera unosa radi sprječavanja SQL injection napada. → Test: automatizirano SAST/DAST skeniranje i ručni fuzzing tijekom QA.
• Zahtjev: vremensko ograničenje neaktivne sesije od 15 minuta. → Test: automatizirani i ručni testovi kojima se potvrđuje poništenje sesije na strani poslužitelja nakon 15 minuta neaktivnosti.

Korak 5: proširite zahtjeve na opskrbni lanac

Budući da je ISO kontrola 8.26 povezana sa sigurnošću dobavljača (5.19, 5.20) i razvojem izdvojenim vanjskim izvođačima (8.30) u Zenith Controls, vaš proces mora obuhvatiti kod trećih strana. Za SME organizacije koje se snažno oslanjaju na vanjske biblioteke ključna je odredba politike iz Application Security Requirements Policy - sme:

Svaki alat treće strane, dodatak ili vanjska biblioteka koda korištena u aplikaciji mora se evidentirati i najmanje jednom godišnje pregledati u pogledu sigurnosnog utjecaja i statusa zakrpanosti.

Ovaj jednostavan, pragmatičan zahtjev nameće način razmišljanja o popisu softverskih komponenti (SBOM), što je ključno očekivanje prema propisima kao što je NIS2. Za glavne dobavljače isti zahtjevi za sigurnost aplikacija moraju biti uključeni u ugovore, uz upućivanje na ISO/IEC 27036-1 (sigurnost IKT opskrbnog lanca).

Korak 6: uvedite periodično preispitivanje

Kako se aplikacije razvijaju, razvijaju se i njihovi rizici. Smjernice Zenith Blueprinta o periodičnom preispitivanju ključne su. Kada integrirate novo sučelje za programiranje aplikacija ili prijeđete na drugu uslugu u oblaku, mijenja se kontekst rizika. To mora pokrenuti pregled postojećih sigurnosnih zahtjeva kako bi se osiguralo da su i dalje primjereni. To je usklađeno s ISO/IEC 27005:2024 (kontinuirana obrada rizika) i pretvara sigurnost aplikacija u kontinuiranu praksu, a ne jednokratan projekt.

Razlaganje ekosustava kontrola

ISO kontrola nikada ne postoji u vakuumu. Učinkovita sigurnost oslanja se na međusobno povezanu mrežu mjera. Prava vrijednost kontrole 8.26 ostvaruje se kada razumijete njezin odnos s drugim kontrolama, što je perspektiva detaljno prikazana u Zenith Controls.

Kontrola 8.26 klasificirana je kao preventivna kontrola, ali djeluje kao središnje čvorište za cijeli proces sigurnog razvoja, povezujući se s:

• 8.25 - Sigurni životni ciklus razvoja softvera: Ovo je krovni okvir. Kontrola 8.26 pruža konkretno što (zahtjeve) koje se mora integrirati u kako (SDLC proces).
• 8.27 - Sigurna arhitektura sustava i načela inženjeringa: Zahtjevi usmjeravaju arhitekturne odluke i osiguravaju da je sigurnost temeljna.
• 8.28 - Sigurno kodiranje: Nakon što su zahtjevi definirani (npr. „spriječiti SQL injection”), standardi sigurnog kodiranja razvojnim inženjerima daju tehnike za ispunjavanje tog zahtjeva.
• 8.29 - Sigurnosno testiranje u razvoju i prihvatu: Ova kontrola potvrđuje da su zahtjevi definirani u 8.26 pravilno implementirani.
• 5.34 - Privatnost i zaštita osobnih podataka (PII): Kada aplikacija obrađuje osobne podatke, zahtjevi iz 8.26 moraju uključivati načela ugrađene zaštite privatnosti.
• 5.19 i 5.20 - Informacijska sigurnost u odnosima s dobavljačima: Za kupljene ili vanjsko ugovorene aplikacije kontrola 8.26 nalaže da se vaši sigurnosni zahtjevi prošire na opskrbni lanac.

Promatranje tih kontrola kao ekosustava, a ne kao kontrolnog popisa, omogućuje izgradnju višeslojnog i dokazivog sigurnosnog profila.

Revizorska perspektiva: priprema za provjeru

Revizori razmišljaju u kategorijama dokaza. Da biste se pripremili, morate razumjeti različite perspektive iz kojih revizor može pristupiti provjeri. Odjeljak o metodologiji revizije u Zenith Controls predviđa te različite pristupe.

Razumijevanje tih perspektiva omogućuje pripremu sveobuhvatnog portfelja dokaza koji pokazuje živ proces ugrađen u vašu organizaciju.

Kompas međusobne usklađenosti: jedan proces, više okvira

Za tvrtku poput Marijine usklađenost s DORA-om, GDPR-om i NIS2 obvezna je. Ručno mapiranje kontrola recept je za udvostručeni rad i praznine u usklađenosti. Centralizirani pristup međusobnoj usklađenosti donosi veliku vrijednost. Definiranje zahtjeva za sigurnost aplikacija praktična je provedba načela „ugrađene sigurnosti” na kojem se temelje svi ti suvremeni propisi.

Implementacijom robusnog procesa zahtjeva za sigurnost aplikacija temeljenog na ISO/IEC 27002:2022 istodobno gradite dokaze za ispunjavanje znatnog dijela tih drugih propisa. Ne provodite samo „ISO”; gradite univerzalno usklađen sigurnosni program.

Od kaosa do kontrole: vaš put naprijed

Marijina priča ima pozitivan ishod. Incident s portalom za plaćanja iskoristila je kao pokretač promjene. Naoružana jasnim okvirom politike iz Claryseca i praktičnim vodičem za provedbu, okupila je razvojne, sigurnosne i proizvodne timove. Koristili su metodologiju Zenith Blueprinta kako bi naknadno definirali zahtjeve za portal, prioritizirajući korektivne radnje prema riziku.

Još važnije, uspostavili su novi način rada. „Sigurnosni kontrolni popis” zamijenjen je suradničkim dizajnerskim radionicama. Kada su DORA revizori stigli, Maria im nije mogla samo pokazati sigurnu aplikaciju, nego i dokazati zreo, ponovljiv proces kojim se osigurava da se sve buduće aplikacije grade na sigurnosnim temeljima.

Transformacija vašeg sigurnosnog profila aplikacija počinje jednim strukturiranim korakom. Put naprijed je jasan:

1. Uspostavite upravljanje: Uvedite formalnu politiku za definiranje zahtjeva za sigurnost aplikacija. Naši predlošci, poput Application Security Requirements Policy, pružaju početnu točku spremnu za reviziju.
2. Usvojite praktičan okvir: Upotrijebite Zenith Blueprint za izravnu integraciju sigurnosnih zahtjeva u životni ciklus razvoja, čineći ih provedivima, provjerljivima i sljedivima.
3. Razumijte puni kontekst: Iskoristite Zenith Controls kako biste vidjeli kako se ova kritična kontrola povezuje sa širim sigurnosnim ekosustavom i mapira kroz DORA, NIS2, GDPR i druge okvire.
4. Proširite na portfelj: Kada pristup funkcionira za jednu aplikaciju, proširite ga na cijeli portfelj integracijom predloška sigurnosnih zahtjeva u standardne kontrolne popise za pokretanje projekata, agilne predloške i postupke nabave.

Ako želite ubrzati ovu transformaciju, Clarysec pruža unaprijed pripremljene politike, planove provedbe i mapiranja međusobne usklađenosti kako biste prešli s fragmentiranih napora na dokazivo zreo program spreman za reviziju. Prestanite tretirati sigurnost aplikacija kao završnu kontrolnu točku. Počnite je ugrađivati u nacrt svega što stvarate.