No projekta līdz gatavībai auditam: lietojumprogrammu drošības prasību pārvaldība ISO 27001, DORA un NIS2 atbilstībai

Pirmsaudita spriedze bija skaidri jūtama. Marijai, vidēja lieluma fintech uzņēmuma informācijas drošības vadītājai (CISO), gaidāmā DORA atbilstības pārbaude šķita nevis kā kārtējā pārbaude, bet kā izšķirošs atskaites punkts. Viņas komanda bija kompetenta, IT infrastruktūra — droši konfigurēta, taču viens pastāvīgs ievainojamību avots neļāva mierīgi gulēt: plašā un haotiskā lietojumprogrammu vide.

Jaunākais satraukuma iemesls bija jauns klientiem pieejams maksājumu portāls, kas tika steidzīgi palaists tirgū, lai sasniegtu ceturkšņa mērķus. Izstrādes komanda, strādājot agresīvā Agile modelī, bija izpildījusi visas funkcionālās prasības. Taču, kad Marijas komanda veica sākotnējo skenēšanu, rezultāti apstiprināja viņas bažas.

Portālā trūka stingru sesijas noildzes noteikumu, ievades lauki bija pakļauti pamata injekciju uzbrukumiem, un kļūdu paziņojumi atklāja sensitīvu sistēmas informāciju. Tie nebija sarežģīti nulles dienas ievainojamību ekspluatācijas paņēmieni; tie bija fundamentāli projektēšanas trūkumi. Pamatcēlonis bija sāpīgi skaidrs. Drošības prasības nekad nebija formāli definētas, dokumentētas vai integrētas izstrādes sprintos. Komandai bija neskaidrs uzdevums “padarīt to drošu”, taču bez konkrētas projektēšanas ieceres drošība palika nenoteikta un bieži ignorēta pēcpārbaude.

Šis scenārijs nav unikāls. Tas izgaismo kritisko plaisu, ar kuru saskaras daudzi CISO un atbilstības vadītāji: kā nodomu “mēs nodrošinām drošību” pārvērst skaidrās, testējamās lietojumprogrammu drošības prasībās, kas atbilst pamata standartiem, piemēram, ISO/IEC 27001:2022, un galvenajiem regulējumiem, piemēram, NIS2, DORA un GDPR.

Neskaidrības augstā cena: ko patiesībā sagaida atbilstības prasības

Marijas problēmas būtība ir bieži sastopama organizatoriska kļūme: drošība tiek uztverta kā kvalitātes īpašība, nevis kā neapspriežamu prasību kopums. Efektīva drošības prasība ir konkrēta, izmērāma un testējama. “Lietojumprogrammai jābūt drošai” ir vēlme. “Lietojumprogrammai jāpiemēro 15 minūšu dīkstāves sesijas noildze, jāvalidē visa lietotāju sniegtā ievade pret iepriekš definētu rakstzīmju kopu un jāšifrē visi dati pārsūtē, izmantojot TLS 1.3” ir prasība. Tieši šādu skaidrību meklē auditori, un tieši tā izstrādātājiem ir vajadzīga drošas programmatūras izveidei.

Bez tās rodas kļūmju ķēde:

• Nekonsekventa ieviešana: dažādi izstrādātāji “drošu” interpretē atšķirīgi, radot fragmentāru kontroles pasākumu kopumu ar neprognozējamām nepilnībām.
• Paaugstinātas trūkumu novēršanas izmaksas: projektēšanas trūkuma atklāšana un labošana ražošanas vidē ir nesalīdzināmi dārgāka nekā tā novēršana projektēšanas posmā.
• Audita neatbilstības: auditori ātri identificēs strukturēta drošības prasību definēšanas procesa neesamību, radot būtiskus audita konstatējumus.
• Organizācijas risks: katra nedefinētā prasība ir potenciāls apdraudējuma vektors, kas pakļauj organizāciju personas datu aizsardzības pārkāpumiem, finansiāliem zaudējumiem un reputācijas kaitējumam.

Mūsdienu standartos sagaidāmais ir konsekvents: drošība jādefinē kā prasības, tas jādara agrīni, un tai jābūt sasaistītai ar risku un tiesību aktu prasībām. ISO/IEC 27002:2022 vadlīnijas par kontroli 8.26, Lietojumprogrammu drošības prasības, paredz, ka organizācijas sistemātiski nosaka, dokumentē un apstiprina drošības prasības, pamatojoties uz formālu riska novērtējumu un regulatīvajām prasībām.

Šis viens princips ir centrālais savienojuma punkts plašam atbilstības prasību lokam. Clarysec savstarpējās atbilstības kartējums Zenith Controls: The Cross-Compliance Guide Zenith Controls parāda, ka šis koncepts parādās visur:

• GDPR Articles 25 and 32 paredz “integrētu datu aizsardzību un datu aizsardzību pēc noklusējuma” un “apstrādes drošību”.
• NIS2 Article 21(2)(d)-(e) uzsver drošu izstrādi un piegādes ķēdes drošību.
• DORA Articles 6(4), 8, 10, and 11 pieprasa IKT riska pārvaldību un drošības iestrādi jau projektēšanas posmā finanšu subjektiem.
• NIST SP 800-53 Rev.5 kontroles pasākumos SA-4 un SA-15 prasa definētas sistēmu drošības prasības un drošas izstrādes prakses.
• COBIT 2019 procesos BAI03 un DSS05 prasa ar drošību saistītās prasības saskaņot ar organizācijas mērķiem un atbilstības prasībām pirms risinājuma izveides.

Mērķis, izmantojot Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint formulējumu, ir definēt “ko drošība nozīmē jūsu lietojumprogrammām, pirms ir uzrakstīta kaut viena koda rinda.”

Kāpēc tradicionālās pieejas neizdodas: kontrolsaraksti, vēla testēšana un drošības teātris

Lielākā daļa organizāciju jau īsteno kādu lietojumprogrammu drošības formu. Problēma ir tā, ka tā reti ir strukturēta tā, lai izturētu ISO/IEC 27001:2022 sertifikāciju vai regulatora pārbaudi.

Biežākie neveiksmju modeļi ir šādi:

1. Vispārīgi kontrolsaraksti: komandas atkārtoti izmanto vienas lapas “drošas kodēšanas kontrolsarakstu” katram projektam. Tas nav sasaistīts ar konkrētās lietojumprogrammas riskiem, datu sensitivitāti vai regulatīvo kontekstu. Kad auditors jautā, kā kontrolsaraksts sasaistās ar GDPR Article 25, skaidras atbildes nav.
2. Drošība kā vēls kontroles punkts: drošības prasības nav iestrādātas projektēšanā vai lietotājstāstos. Tās parādās beigās kā pieprasījums veikt ielaušanās testēšanu. Zenith Blueprint brīdina, ka “paļaušanās uz drošības kontrolsarakstu projekta beigās nestrādā; šīm prasībām jāveido arhitektūra, jāietekmē bibliotēku izvēle un jāvada funkcionalitātes prioritizācija jau no pirmās dienas.”
3. Nav izsekojamības no prasības līdz testam: var pastāvēt prasība “šifrēt datus pārsūtē”, taču tai nav piesaistīts testēšanas gadījums, kas verificētu TLS versijas piemērošanu, sertifikāta derīgumu un šifru stiprumu. Zenith Blueprint uzsver, ka gaidāmajiem rezultātiem jābūt izmērāmiem un testējamiem, un drošības testi tieši jāsasaista ar attiecīgajām prasībām.
4. Ad hoc rīcība ar trešo pušu kodu: mūsdienu lietojumprogrammas bieži ir “sašūtas kopā no iekšējā koda, trešo pušu bibliotēkām, lietojumprogrammu saskarnēm un mākoņvides pakalpojumiem”, kā norādīts Zenith Blueprint. Bez skaidrām prasībām piegādātājiem un atvērtā pirmkoda komponentēm piegādes ķēdes risks paliek būtiska, nekontrolēta aklā zona.

Rezultāts ir drošības teātris: dokumenti pastāv un testi tiek veikti, taču, kad nopietns auditors vai regulators meklē saskaņotu prasību stāstu, viss process sabrūk.

Pamata izveide: no politikas līdz praksei

Disciplinēta pieeja lietojumprogrammu drošībai sākas ar skaidru pārvaldību. Politika nav tikai birokrātija; tā ir oficiālais patiesības avots, kas pilnvaro komandas un auditoriem sniedz skaidru nodoma formulējumu. Clarysec mēs izstrādājam politikas, kas ir gan autoritatīvas, gan praktiski ieviešamas.

Mūsu Lietojumprogrammu drošības prasību politika Lietojumprogrammu drošības prasību politika nosaka neapspriežamus pamatnoteikumus. Piemēram, 5.2. punkts sadaļā “Pārvaldības prasības” nosaka:

Visām lietojumprogrammām plānošanas vai iepirkuma posmā jāveic drošības prasību validācija, saņemot dokumentētu apstiprinājumu no lietojumprogrammu drošības komandas.

Šī vienkāršā prasība novērš domāšanu “vispirms uzbūvēt, pēc tam nodrošināt drošību”. Politika arī piešķir skaidru pārskatatbildību. 4.3.1. punkts sadaļā “Lomas un pienākumi” nosaka, ka izstrādātājiem ir pienākums:

Ieviest lietojumprogrammas saskaņā ar definētajām drošības prasībām un standartiem.

Tas pārvieto drošības atbildību no atsevišķas, bieži pretstatītas drošības komandas uz pašiem programmatūras radītājiem. Turklāt politika sasaista dažādas drošības jomas. 10.2. punkts atsaucas uz integrāciju ar citiem būtiskiem kontroles pasākumiem:

P4 – Piekļuves kontroles politika. Definē identitātes un sesiju pārvaldības standartus, kas jāpiemēro visām lietojumprogrammām, tostarp stipru autentifikāciju, minimāli nepieciešamās piekļuves tiesības un piekļuves tiesību pārskatīšanas prasības.

Mazākām organizācijām pielāgota politika, piemēram, mūsu Lietojumprogrammu drošības prasību politika MVU Lietojumprogrammu drošības prasību politika MVU, nodrošina šo principu mērogojamību. Tā atzīst, ka riski ir līdzīgi, taču ieviešanai jābūt pragmatiskai. Abas versijas galu galā tiecas uz vienu rezultātu — nodrošināt, ka lietojumprogrammu drošība ir pilnībā integrēta IDPS un gatava auditam.

Praktiska ceļkarte: auditam gatavu lietojumprogrammu drošības prasību izveide

Politika nosaka “ko” un “kāpēc”, bet izstrādātājiem un projektu vadītājiem ir vajadzīgs “kā”. Strukturētas ieviešanas vadlīnijas ir neaizstājamas, lai augsta līmeņa kontroles pasākumus pārvērstu izpildāmās darbībās. Zenith Blueprint 21. solis, kas fokusējas uz ISO/IEC 27002:2022 kontroli 8.26, sniedz skaidru sešu soļu metodoloģiju.

Apskatīsim šo procesu, izmantojot Marijas maksājumu portālu kā piemēru.

1. solis: sāciet ar risku un regulatīvo kontekstu

Izmantojot riska novērtējuma rezultātus, kas saskaņoti ar ISO/IEC 27005:2024 (riska apstrāde), vispirms identificējiet kontekstu:

• Lietojumprogramma: klientu pašapkalpošanās maksājumu portāls.
• Dati: personu identificējoša informācija (PII), autentifikācijas dati, maksājumu marķieri.
• Jurisdikcijas: ES, finanšu pakalpojumi, izvietots mākoņvidē.
• Regulējumi: GDPR, DORA, PCI DSS.

Pamatojoties uz Zenith Controls vadlīnijām par kontroli 8.26 un saistītajiem ISO standartiem (27034-1, 27017, 27701), sākotnējām prasību kategorijām jāietver identifikācija un autentifikācija, autorizācija, datu klasifikācija, ievades validācija, žurnalēšana, kā arī datu aizsardzība pārsūtē un glabāšanā.

2. solis: izveidojiet vai pieņemiet drošības prasību veidni

Zenith Blueprint iesaka izveidot standartizētu veidni, lai katrs projekts atbildētu uz vieniem un tiem pašiem pamata drošības jautājumiem. Šim dokumentam jākļūst par daļu no projekta uzsākšanas rīkkopas.

Minimālajām sadaļām jāietver:

• Lietojumprogrammas nosaukums, īpašnieks un kritiskums.
• Datu kategorijas un sensitivitātes līmeņi.
• Piemērojamie regulatīvie un līgumiskie pienākumi (GDPR, DORA u. c.).
• Apdraudējumu vides ievaddati (atvasināti no kontroles 5.7 Draudu izlūkošana).
• Konkrētas drošības prasības pa kategorijām (autentifikācija, žurnalēšana u. c.).
• Sasaistes ar lietotājstāstiem un pieņemšanas kritērijiem.
• Sasaistes ar testēšanas gadījumiem (funkcionālajiem, drošības, ielaušanās testiem).
• Prasības piegādātājiem un trešo pušu komponentēm.

3. solis: iestrādājiet prasības Agile artefaktos

Drošības prasības jāiestrādā tieši lietotājstāstos un pieņemšanas kritērijos. Marijas portāla projekta “klienta reģistrācijas” epikam tas nozīmē vienkārša funkcionāla stāsta pārveidošanu par drošību iekļaujošu stāstu.

• Sākotnējais lietotājstāsts: “Kā jauns lietotājs es varu izveidot kontu.”
• Drošs lietotājstāsts: “Kā jauns klients es vēlos izveidot drošu kontu, lai mana maksājumu informācija būtu aizsargāta.”
• Pieņemšanas kritēriji (ar iestrādātu drošību):
  • Sistēmai jāpiemēro stingra paroļu politika saskaņā ar P4 – Piekļuves kontroles politiku.
  • Sistēmai pirms konta aktivizēšanas jāpieprasa e-pasta verifikācija, izmantojot vienreizēju saiti.
  • Konta izveides forma jāaizsargā ar CAPTCHA, lai novērstu botu uzbrukumus.
  • Visi reģistrācijas mēģinājumi jāreģistrē žurnālos ar avota IP adresi un ierīces pirkstnospiedumu.
  • Visi dati, kas iesniegti, izmantojot formu, jāsanitizē, lai novērstu starpvietņu skriptošanu (XSS).

Tie nav atsevišķi drošības uzdevumi; tie ir neatņemama funkcionalitātes “pabeigts” definīcijas daļa.

4. solis: sasaistiet prasības ar drošības testēšanu

Izmantojot Zenith Controls kontroli 8.29 Drošības testēšana, jānodrošina, ka katrai prasībai ir piesaistīts testēšanas gadījums. Tas noslēdz ciklu un sniedz auditējamus pierādījumus par kontroles efektivitāti.

• Prasība: šifrēšana pārsūtē ar TLS 1.3. → Tests: automatizēta skenēšana, lai pārbaudītu TLS piemērošanu, sertifikāta derīgumu un apstiprinātas šifru kopas.
• Prasība: ievades validācija, lai novērstu SQL injekciju. → Tests: automatizēta SAST/DAST skenēšana un manuāla fuzzing testēšana QA laikā.
• Prasība: 15 minūšu dīkstāves sesijas noildze. → Tests: automatizēti un manuāli testi, kas apstiprina sesijas nederīguma iestāšanos servera pusē pēc 15 minūšu neaktivitātes.

5. solis: paplašiniet prasības uz piegādes ķēdi

Tā kā ISO kontrole 8.26 Zenith Controls ietvarā ir sasaistīta ar piegādātāju drošību (5.19, 5.20) un ārpakalpojuma izstrādi (8.30), procesā jāņem vērā trešo pušu kods. MVU, kas lielā mērā paļaujas uz ārējām bibliotēkām, kritisks ir politikas punkts no Lietojumprogrammu drošības prasību politikas MVU:

Jebkurš trešās puses rīks, spraudnis vai ārēja koda bibliotēka, kas tiek izmantota lietojumprogrammā, jāreģistrē un reizi gadā jāpārskata attiecībā uz drošības ietekmi un ielāpu statusu.

Šī vienkāršā, pragmatiskā prasība ievieš programmatūras materiālu saraksta (SBOM) domāšanu, kas ir būtiska sagaidāmā prasība tādos regulējumos kā NIS2. Lielākajiem piegādātājiem tās pašas lietojumprogrammu drošības prasības jāiekļauj līgumos, atsaucoties uz ISO/IEC 27036-1 (IKT piegādes ķēdes drošība).

6. solis: ieviesiet periodisku atkārtotu novērtēšanu

Lietojumprogrammām attīstoties, attīstās arī to riski. Zenith Blueprint vadlīnijas par periodisku atkārtotu novērtēšanu ir būtiskas. Integrējot jaunu lietojumprogrammu saskarni vai pārejot uz citu mākoņpakalpojumu, riska konteksts mainās. Tam jāierosina esošo drošības prasību pārskatīšana, lai nodrošinātu, ka tās joprojām ir pietiekamas. Tas atbilst ISO/IEC 27005:2024 (nepārtraukta riska apstrāde) un pārvērš lietojumprogrammu drošību par nepārtrauktu praksi, nevis vienreizēju projektu.

Kontroļu ekosistēmas izpratne

ISO kontrole nekad nepastāv vakuumā. Efektīva drošība balstās uz savstarpēji saistītu pasākumu tīklu. Kontroles 8.26 patiesā vērtība atklājas, izprotot tās attiecības ar citām kontrolēm — perspektīvu, kas detalizēti aprakstīta Zenith Controls.

Kontrole 8.26 ir klasificēta kā preventīvs kontroles pasākums, taču tā darbojas kā centrālais mezgls visam drošas izstrādes procesam, sasaistoties ar:

• 8.25 - Drošas izstrādes dzīves cikls: tas ir virsējais ietvars. Kontrole 8.26 nodrošina konkrēto ko (prasības), kas jāintegrē kā (SDLC procesā).
• 8.27 - Droša sistēmu arhitektūra un inženierijas principi: prasības virza arhitektūras lēmumus, nodrošinot drošību kā pamatu.
• 8.28 - Droša kodēšana: kad prasības ir definētas (piemēram, “novērst SQL injekciju”), drošas kodēšanas standarti izstrādātājiem sniedz paņēmienus šīs prasības izpildei.
• 8.29 - Drošības testēšana izstrādē un pieņemšanā: šī kontrole validē, ka 8.26 definētās prasības ir pareizi ieviestas.
• 5.34 - Privātums un PII aizsardzība: ja lietojumprogramma apstrādā personas datus, 8.26 prasībās jāiekļauj integrētas datu aizsardzības principi.
• 5.19 & 5.20 - Informācijas drošība piegādātāju attiecībās: iegādātām vai ārpakalpojumā izstrādātām lietojumprogrammām kontrole 8.26 nosaka, ka jūsu drošības prasībām jāattiecas arī uz piegādes ķēdi.

Skatot šos kontroles pasākumus kā ekosistēmu, nevis kontrolsarakstu, iespējams izveidot daudzslāņu un pamatotu drošības stāvokli.

Auditora skatījums: sagatavošanās pārbaudei

Auditori domā pierādījumu kategorijās. Lai sagatavotos, jāsaprot dažādās perspektīvas, ar kurām auditors var ierasties. Zenith Controls audita metodoloģijas sadaļa paredz šīs atšķirīgās pieejas.

Šo skatījumu izpratne ļauj sagatavot visaptverošu pierādījumu portfeli, kas demonstrē dzīvu, organizācijā iestrādātu procesu.

Savstarpējās atbilstības kompass: viens process, daudzi ietvari

Tādam uzņēmumam kā Marijas organizācija DORA, GDPR un NIS2 prasību izpilde ir obligāta. Manuāla kontroles pasākumu kartēšana rada dublētu darbu un atbilstības trūkumus. Centralizēta savstarpējās atbilstības pieeja sniedz būtisku vērtību. Lietojumprogrammu drošības prasību definēšana ir praktiska projektēšanas posmā iestrādātas drošības principa ieviešana, uz kuru balstās visi šie mūsdienu regulējumi.

Ieviešot stingru lietojumprogrammu drošības prasību procesu, kas balstīts uz ISO/IEC 27002:2022, jūs vienlaikus veidojat pierādījumus, lai izpildītu būtisku daļu no šo citu regulējumu prasībām. Jūs ne tikai “ieviešat ISO”; jūs veidojat universāli atbilstošu drošības programmu.

No haosa uz kontroli: turpmākais ceļš

Marijas stāstam ir pozitīvs iznākums. Viņa izmantoja maksājumu portāla incidentu kā pārmaiņu katalizatoru. Ar skaidru Clarysec politikas ietvaru un praktiskām ieviešanas vadlīnijām viņa apvienoja izstrādes, drošības un produktu komandas. Tās izmantoja Zenith Blueprint metodoloģiju, lai retrospektīvi definētu portāla prasības, prioritizējot trūkumu novēršanu pēc riska.

Vēl svarīgāk — tika ieviests jauns darba veids. “Drošības kontrolsarakstu” aizstāja sadarbības projektēšanas sesijas. Kad ieradās DORA auditori, Marija varēja ne tikai parādīt drošu lietojumprogrammu, bet arī demonstrēt nobriedušu, atkārtojamu procesu, kas nodrošina, ka visas nākotnes lietojumprogrammas tiks veidotas uz drošības pamatiem.

Lietojumprogrammu drošības stāvokļa pārveide sākas ar vienu strukturētu soli. Turpmākais ceļš ir skaidrs:

1. Izveidojiet pārvaldību: ieviesiet formālu politiku lietojumprogrammu drošības prasību definēšanai. Mūsu veidnes, piemēram, Lietojumprogrammu drošības prasību politika, sniedz auditam gatavu sākumpunktu.
2. Pieņemiet praktisku ietvaru: izmantojiet Zenith Blueprint, lai drošības prasības tieši integrētu izstrādes dzīves ciklā, padarot tās izpildāmas, testējamas un izsekojamas.
3. Izprotiet pilnu kontekstu: izmantojiet Zenith Controls, lai redzētu, kā šī kritiskā kontrole ir saistīta ar plašāku drošības ekosistēmu un kā tā kartējas pret DORA, NIS2, GDPR un citiem regulējumiem.
4. Mērogojiet uz visu portfeli: kad pieeja darbojas vienai lietojumprogrammai, mērogojiet to visā portfelī, integrējot drošības prasību veidni standarta projektu uzsākšanas kontrolsarakstos, Agile veidnēs un iepirkuma procesos.

Ja vēlaties paātrināt šo pārveidi, Clarysec nodrošina iepriekš sagatavotas politikas, ieviešanas ceļkartes un savstarpējās atbilstības kartējumus, lai pārietu no fragmentētiem centieniem uz pierādāmi nobriedušu un auditam gatavu programmu. Pārtrauciet uztvert lietojumprogrammu drošību kā noslēguma kontroles punktu. Sāciet to iestrādāt visa, ko veidojat, projektā.