Od načrta do pripravljenosti na presojo: obvladovanje zahtev za varnost aplikacij za ISO 27001, DORA in NIS2

Predpresojna napetost je bila očitna. Za Mario, vodjo informacijske varnosti (CISO) v srednje velikem fintech podjetju, se prihajajoča presoja skladnosti z DORA ni zdela kot običajen pregled, temveč kot trenutek resnice. Njena ekipa je bila strokovna, infrastruktura IT utrjena, vendar jo je ponoči držala pokonci vztrajna ranljivost: razvejan in kaotičen svet njihovih aplikacij.

Najnovejša skrb je bil nov plačilni portal za stranke, ki je bil zaradi četrtletnih ciljev prehitro uveden na trg. Razvojna ekipa, ki je delovala po zelo zahtevnem agilnem modelu, je izpolnila vse funkcionalne zahteve. Ko pa je Marijina ekipa izvedla začetno skeniranje, so rezultati potrdili njene skrbi.

Portal ni imel robustnih pravil za časovno omejitev sej, njegova vnosna polja so bila dovzetna za osnovne napade z vrivanjem, sporočila o napakah pa so razkrivala občutljive sistemske informacije. To niso bile sofisticirane ranljivosti ničtega dne, temveč temeljne napake v zasnovi. Temeljni vzrok je bil boleče jasen. Varnostne zahteve niso bile nikoli formalno opredeljene, dokumentirane ali vključene v razvojne sprinte. Ekipa je imela nejasno navodilo, naj »poskrbi, da bo varno«, vendar je brez konkretnega načrta varnost ostala dvoumna in pogosto prezrta naknadna misel.

Ta scenarij ni osamljen. Poudarja ključno vrzel, s katero se soočajo številni vodje informacijske varnosti (CISO) in vodje skladnosti: kako namero »izvajamo varnost« pretvoriti v izrecne, preverljive zahteve za varnost aplikacij, usklajene s temeljnimi standardi, kot je ISO/IEC 27001:2022, in pomembnimi predpisi, kot so NIS2, DORA in GDPR.

Visoka cena dvoumnosti: kaj skladnost dejansko zahteva

Jedro Marijine težave je v pogosti organizacijski pomanjkljivosti: varnost se obravnava kot kakovostna lastnost, ne kot nabor neizpogajljivih zahtev. Učinkovita varnostna zahteva je specifična, merljiva in preverljiva. »Aplikacija mora biti varna« je želja. »Aplikacija mora uveljavljati 15-minutno časovno omejitev nedejavnih sej, preveriti vse uporabniške vnose glede na vnaprej določen nabor znakov in šifrirati vse podatke med prenosom z uporabo TLS 1.3« je zahteva. Takšna jasnost je tisto, kar iščejo presojevalci, in tisto, kar razvijalci potrebujejo za gradnjo varne programske opreme.

Brez tega sprožite verigo neuspehov:

• Nedosledna izvedba: različni razvijalci izraz »varno« razumejo različno, kar vodi v mozaik kontrol z nepredvidljivimi vrzelmi.
• Višji stroški odprave pomanjkljivosti: odkrivanje in odpravljanje napake v zasnovi v produkciji je eksponentno dražje kot obravnava v fazi zasnove.
• Neskladnosti pri presoji: presojevalci hitro prepoznajo odsotnost strukturiranega procesa za opredeljevanje varnostnih zahtev, kar vodi v pomembne ugotovitve presoje.
• Poslovno tveganje: vsaka neopredeljena zahteva je potencialni vektor napada, ki organizacijo izpostavlja kršitvam varnosti osebnih podatkov, finančni izgubi in škodi za ugled.

V sodobnih standardih je pričakovanje dosledno: varnost mora biti zgodaj opredeljena kot zahteve ter povezana s tveganji in zakonodajo. Smernice ISO/IEC 27002:2022 za kontrolo 8.26, zahteve za varnost aplikacij, od organizacij zahtevajo, da varnostne zahteve sistematično določijo, dokumentirajo in odobrijo na podlagi formalne ocene tveganja in regulativnih zahtev.

To eno načelo je vezni člen za širok nabor obveznosti skladnosti. Clarysecovo medokvirno mapiranje skladnosti v Zenith Controls: The Cross-Compliance Guide Zenith Controls prikazuje, kako se ta koncept pojavlja povsod:

• GDPR Articles 25 in 32 zahtevata »vgrajeno varstvo podatkov« in »varnost obdelave«.
• NIS2 Article 21(2)(d)-(e) poudarja varen razvoj in varnost dobavne verige.
• DORA Articles 6(4), 8, 10 in 11 zahtevajo upravljanje tveganj IKT in vgrajeno varnost za finančne subjekte.
• NIST SP 800-53 Rev.5 v kontrolah SA-4 in SA-15 zahteva opredeljene zahteve za informacijsko varnost sistemov in prakse varnega razvoja.
• COBIT 2019 v procesih BAI03 in DSS05 zahteva, da so varnostne zahteve pred gradnjo rešitve usklajene s poslovnimi potrebami in skladnostjo.

Cilj je, kot pravi Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, opredeliti »kaj varnost pomeni za vaše aplikacije, preden je napisana prva vrstica kode.«

Zakaj tradicionalni pristopi odpovejo: kontrolni seznami, pozno testiranje in navidezna varnost

Večina organizacij že izvaja neko obliko varnosti aplikacij. Težava je, da je ta redko strukturirana tako, da vzdrži certificiranje po ISO/IEC 27001:2022 ali regulativni nadzor.

Pogosti vzorci neuspeha vključujejo:

1. Generični kontrolni seznami: ekipe za vsak projekt ponovno uporabijo enostranski »kontrolni seznam varnega kodiranja«. Ta ni povezan s specifičnimi tveganji aplikacije, občutljivostjo podatkov ali regulativnim kontekstom. Ko presojevalec vpraša, kako je kontrolni seznam povezan z GDPR Article 25, ni jasnega odgovora.
2. Varnost kot pozna kontrolna točka: varnostne zahteve niso vključene v zasnovo ali uporabniške zgodbe. Pojavijo se na koncu kot zahteva za penetracijski test. Zenith Blueprint opozarja, da »zanašanje na varnostni kontrolni seznam ob koncu projekta ne deluje; te zahteve morajo od prvega dne oblikovati arhitekturo, vplivati na izbiro knjižnic in usmerjati določanje prioritet funkcionalnosti.«
3. Brez sledljivosti od zahteve do testa: zahteva za »šifriranje podatkov med prenosom« lahko obstaja, vendar ni povezanega testnega primera, ki bi preverjal uveljavljanje različice TLS, veljavnost digitalnih potrdil in moč šifer. Zenith Blueprint vztraja, da morajo biti pričakovanja merljiva in preverljiva, varnostni testi pa neposredno povezani z ustreznimi zahtevami.
4. Ad hoc obravnava kode tretjih oseb: sodobne aplikacije so pogosto »sestavljene iz notranje kode, knjižnic tretjih oseb, vmesnikov za aplikacijsko programiranje in izvorno oblačnih storitev«, kot navaja Zenith Blueprint. Brez izrecnih zahtev za dobavitelje in odprtokodne komponente tveganje dobavne verige ostane velika, nenadzorovana slepa pega.

Rezultat je navidezna varnost: dokumenti obstajajo in testi se izvajajo, vendar ko resen presojevalec ali regulator išče koherentno zgodbo o zahtevah, se celoten proces sesuje.

Gradnja temeljev: od politike do prakse

Discipliniran pristop k varnosti aplikacij se začne z jasnim upravljanjem. Politika ni zgolj birokracija; je uradni vir resnice, ki ekipam daje pooblastila in presojevalcem zagotavlja jasno izjavo o nameri. V Clarysec oblikujemo politike, ki so hkrati avtoritativne in praktične.

Naša Politika zahtev za varnost aplikacij Politika zahtev za varnost aplikacij določa neizpogajljiva osnovna pravila. Na primer, klavzula 5.2 v okviru »Zahtev upravljanja« določa:

Vse aplikacije morajo med načrtovanjem ali nabavo opraviti pregled varnostnih zahtev, z dokumentirano odobritvijo ekipe za varnost aplikacij.

Ta preprosta usmeritev preprečuje miselnost »najprej zgradi, pozneje zavaruj«. Politika prav tako jasno določa odgovornost. Klavzula 4.3.1 v okviru »Vlog in odgovornosti« določa, da se od razvijalcev pričakuje:

Implementacija aplikacij v skladu z opredeljenimi varnostnimi zahtevami in standardi.

S tem se odgovornost za varnost prenese z ločene, pogosto nasprotne varnostne ekipe na same ustvarjalce programske opreme. Poleg tega politika povezuje različna varnostna področja. Klavzula 10.2 se sklicuje na integracijo z drugimi ključnimi kontrolami:

P4 – Politika nadzora dostopa. Določa standarde za upravljanje identitet in sej, ki jih morajo uveljavljati vse aplikacije, vključno z močno avtentikacijo, načelom najmanjših privilegijev in zahtevami za pregled pravic dostopa.

Za manjše organizacije prilagojena politika, kot je naša Politika zahtev za varnost aplikacij za MSP Politika zahtev za varnost aplikacij za MSP, zagotavlja, da so ta načela razširljiva. Priznava, da so tveganja podobna, izvedba pa mora biti pragmatična. Obe različici sta na koncu usmerjeni v isti rezultat: zagotoviti, da je varnost aplikacij v celoti vključena v ISMS in pripravljena na presojo.

Praktični načrt: gradnja zahtev za varnost aplikacij, pripravljenih za presojo

Politika določa »kaj« in »zakaj«, razvijalci in vodje projektov pa potrebujejo »kako«. Strukturiran priročnik za izvedbo je nepogrešljiv za prevod visokoravenskih kontrol v izvedljive korake. Korak 21 v Zenith Blueprint, ki se osredotoča na kontrolo 8.26 standarda ISO/IEC 27002:2022, podaja jasno šeststopenjsko metodologijo.

Poglejmo ta proces na primeru Marijinega plačilnega portala.

Korak 1: začnite s tveganjem in regulativnim kontekstom

Z uporabo izhodov ocene tveganja, usklajene z ISO/IEC 27005:2024 (obravnava tveganj), najprej opredelite kontekst:

• Aplikacija: samopostrežni plačilni portal za stranke.
• Podatki: osebno določljivi podatki (PII), poverilnice, plačilni žetoni.
• Jurisdikcije: EU, finančne storitve, oblak.
• Predpisi: GDPR, DORA, PCI DSS.

Na podlagi smernic za kontrolo 8.26 v Zenith Controls in povezanih ISO standardov (27034-1, 27017, 27701) morajo začetne kategorije zahtev vključevati identifikacijo in avtentikacijo, avtorizacijo, razvrščanje podatkov, preverjanje vnosa, beleženje ter varstvo podatkov med prenosom in v mirovanju.

Korak 2: pripravite ali prevzemite predlogo varnostnih zahtev

Zenith Blueprint priporoča pripravo standardizirane predloge, da vsak projekt odgovori na ista temeljna varnostna vprašanja. Ta dokument naj postane del nabora orodij za začetek projekta.

Minimalni razdelki naj vključujejo:

• ime aplikacije, lastnika in kritičnost;
• kategorije podatkov in ravni občutljivosti;
• veljavne regulativne in pogodbene obveznosti (GDPR, DORA itd.);
• vhodne informacije o okolju groženj (izpeljane iz kontrole 5.7, obveščevalni podatki o grožnjah);
• specifične varnostne zahteve po kategorijah (avtentikacija, beleženje itd.);
• povezave z uporabniškimi zgodbami in merili sprejemljivosti;
• povezave s testnimi primeri (funkcionalnimi, varnostnimi, penetracijskimi);
• zahteve za dobavitelje in komponente tretjih oseb.

Korak 3: vključite zahteve v agilne artefakte

Varnostne zahteve morajo biti neposredno vključene v uporabniške zgodbe in merila sprejemljivosti. Za ep »registracija stranke« v projektu Marijinega portala to pomeni preoblikovanje preproste funkcionalne zgodbe v varnostno ozaveščeno.

• Izvirna uporabniška zgodba: »Kot nov uporabnik lahko ustvarim račun.«
• Varna uporabniška zgodba: »Kot nova stranka želim ustvariti varen račun, da so moji podatki o plačilih zaščiteni.«
• Merila sprejemljivosti (z vključeno varnostjo):
  • Sistem mora uveljavljati Politiko gesel v skladu s P4 – Politika nadzora dostopa.
  • Sistem mora pred aktivacijo računa zahtevati preverjanje e-pošte prek enkratne povezave.
  • Obrazec za ustvarjanje računa mora biti zaščiten s CAPTCHA, da se preprečijo napadi botov.
  • Vsi poskusi registracije morajo biti zabeleženi z izvornim naslovom IP in prstnim odtisom naprave.
  • Vsi podatki, poslani prek obrazca, morajo biti sanitizirani za preprečevanje cross-site scripting (XSS).

To niso ločene varnostne naloge; so sestavni del opredelitve funkcionalnosti kot »dokončane«.

Korak 4: povežite zahteve z varnostnim testiranjem

Z uporabo kontrole 8.29 Varnostno testiranje iz Zenith Controls zagotovite, da ima vsaka zahteva povezan testni primer. S tem zaprete zanko in zagotovite dokazila o učinkovitosti kontrol, ki jih je mogoče preveriti pri presoji.

• Zahteva: šifriranje med prenosom s TLS 1.3. → Test: samodejno skeniranje za preverjanje uveljavljanja TLS, veljavnosti digitalnih potrdil in odobrenih naborov šifer.
• Zahteva: preverjanje vnosa za preprečevanje SQL injection. → Test: samodejno skeniranje SAST/DAST in ročno fuzz testiranje med QA.
• Zahteva: 15-minutna časovna omejitev nedejavne seje. → Test: samodejni in ročni testi za potrditev razveljavitve seje na strani strežnika po 15 minutah nedejavnosti.

Korak 5: razširite zahteve na dobavno verigo

Ker je ISO kontrola 8.26 v Zenith Controls povezana z varnostjo dobaviteljev (5.19, 5.20) in zunanjim razvojem (8.30), mora vaš proces upoštevati kodo tretjih oseb. Za MSP, ki so močno odvisna od zunanjih knjižnic, je klavzula iz Politike zahtev za varnost aplikacij za MSP ključna:

Vsako orodje tretje osebe, vtičnik ali zunanja knjižnica kode, uporabljena v aplikaciji, mora biti evidentirana in letno pregledana glede varnostnega vpliva in stanja nameščenih popravkov.

Ta preprosta, pragmatična zahteva uvaja miselnost kosovnice programske opreme (SBOM), kar je ključno pričakovanje v okviru predpisov, kot je NIS2. Za pomembne dobavitelje morajo biti iste zahteve za varnost aplikacij vključene v pogodbe, s sklicem na ISO/IEC 27036-1 (varnost dobavne verige IKT).

Korak 6: uvedite periodično ponovno oceno

Z razvojem aplikacij se spreminjajo tudi njihova tveganja. Smernice Zenith Blueprint glede periodične ponovne ocene so ključne. Ko integrirate nov API ali preidete na drugo storitev v oblaku, se spremeni kontekst tveganja. To mora sprožiti pregled obstoječih varnostnih zahtev, da se zagotovi njihova nadaljnja ustreznost. To je usklajeno z ISO/IEC 27005:2024 (stalna obravnava tveganj) in varnost aplikacij spremeni v neprekinjeno prakso, ne v enkraten projekt.

Razgradnja ekosistema kontrol

ISO kontrola nikoli ne obstaja v vakuumu. Učinkovita varnost temelji na medsebojno povezanem naboru ukrepov. Prava vrednost kontrole 8.26 se pokaže, ko razumete njen odnos z drugimi kontrolami, kar je podrobno predstavljeno v Zenith Controls.

Kontrola 8.26 je razvrščena kot preventivna kontrola, vendar deluje kot osrednje vozlišče celotnega procesa varnega razvoja in se povezuje z:

• 8.25 - Življenjski cikel varnega razvoja: to je krovni okvir. Kontrola 8.26 zagotavlja specifični kaj (zahteve), ki mora biti vključen v kako (proces SDLC).
• 8.27 - Varna sistemska arhitektura in inženirska načela: zahteve usmerjajo arhitekturne odločitve in zagotavljajo, da je varnost temeljna.
• 8.28 - Varno kodiranje: ko so zahteve opredeljene (npr. »preprečiti SQL injection«), standardi varnega razvoja kode razvijalcem zagotovijo tehnike za izpolnitev zahteve.
• 8.29 - Varnostno testiranje v razvoju in sprejemu: ta kontrola potrjuje, da so bile zahteve, opredeljene v 8.26, pravilno implementirane.
• 5.34 - Zasebnost in varstvo osebno določljivih podatkov: kadar aplikacija obdeluje osebne podatke, morajo zahteve iz 8.26 vključevati načela vgrajenega varstva zasebnosti.
• 5.19 & 5.20 - Informacijska varnost v odnosih z dobavitelji: pri nabavljenih ali zunanje razvitih aplikacijah kontrola 8.26 določa, da se morajo vaše varnostne zahteve razširiti v dobavno verigo.

Če te kontrole obravnavate kot ekosistem in ne kot kontrolni seznam, lahko zgradite večplastni, zagovorljiv profil tveganja na področju varnosti.

Pogled presojevalca: priprava na preverjanje

Presojevalci razmišljajo v dokazilih. Za pripravo morate razumeti različne vidike, s katerih lahko presojevalec pristopi. Razdelek o metodologiji presoje v Zenith Controls predvideva te različne pristope.

Razumevanje teh pogledov vam omogoča pripravo celovitega portfelja dokazil, ki dokazuje živ, delujoč proces, vgrajen v vašo organizacijo.

Kompas medokvirne skladnosti: en proces, več okvirov

Za podjetje, kot je Marijino, je izpolnjevanje zahtev DORA, GDPR in NIS2 obvezno. Ročno mapiranje kontrol je recept za podvajanje dela in vrzeli v skladnosti. Centraliziran, medokvirni pristop k skladnosti prinaša veliko vrednost. Opredeljevanje zahtev za varnost aplikacij je praktična uvedba načela vgrajene varnosti, ki podpira vse te sodobne predpise.

Z uvedbo zanesljivega procesa za zahteve za varnost aplikacij na podlagi ISO/IEC 27002:2022 hkrati gradite dokazila za izpolnjevanje znatnega dela teh drugih predpisov. Ne izvajate zgolj »ISO«; gradite univerzalno skladen varnostni program.

Od kaosa do nadzora: vaša pot naprej

Marijina zgodba ima pozitiven razplet. Incident s plačilnim portalom je uporabila kot katalizator sprememb. Oborožena z jasnim okvirom politik Clarysec in praktičnim priročnikom za izvedbo je povezala razvojne, varnostne in produktne ekipe. Z metodologijo Zenith Blueprint so za portal naknadno opredelili zahteve in prednostno obravnavali odpravo pomanjkljivosti na podlagi tveganja.

Še pomembneje, vzpostavili so nov način dela. »Varnostni kontrolni seznam« so zamenjale sodelovalne seje zasnove. Ko so prišli presojevalci DORA, jim Maria ni mogla pokazati le varne aplikacije, temveč tudi dokazati zrel, ponovljiv proces, ki zagotavlja, da bodo vse prihodnje aplikacije zgrajene na varnostnih temeljih.

Preobrazba vašega profila tveganja na področju varnosti aplikacij se začne z enim strukturiranim korakom. Vaša pot naprej je jasna:

1. Vzpostavite upravljanje: uvedite formalno politiko za opredeljevanje zahtev za varnost aplikacij. Naše predloge, kot je Politika zahtev za varnost aplikacij, zagotavljajo izhodišče, pripravljeno za presojo.
2. Sprejmite praktičen okvir: uporabite Zenith Blueprint, da varnostne zahteve neposredno vključite v življenjski cikel razvoja ter jih naredite izvedljive, preverljive in sledljive.
3. Razumite celoten kontekst: uporabite Zenith Controls, da vidite, kako se ta ključna kontrola povezuje s širšim varnostnim ekosistemom in mapira na DORA, NIS2, GDPR ter druge okvire.
4. Razširite na portfelj: ko pristop deluje za eno aplikacijo, ga razširite po portfelju tako, da predlogo varnostnih zahtev vključite v standardne kontrolne sezname za začetek projektov, agilne predloge in nabavne procese.

Če želite to preobrazbo pospešiti, Clarysec zagotavlja vnaprej pripravljene politike, načrte uvedbe in medokvirna mapiranja skladnosti, s katerimi lahko preidete od razdrobljenih prizadevanj do dokazljivo zrelega programa, pripravljenega za presojo. Prenehajte obravnavati varnost aplikacij kot končni pregled pred izdajo. Začnite jo vgrajevati v načrt vsega, kar ustvarite.