Nuo projektavimo iki pasirengimo auditui: kaip valdyti taikomųjų programų saugumo reikalavimus pagal ISO 27001, DORA ir NIS2

Priešauditinis nerimas buvo juntamas. Marijai, vidutinio dydžio finansinių technologijų įmonės CISO, artėjantis DORA atitikties vertinimas atrodė ne kaip įprasta peržiūra, o kaip neišvengiama atskaitomybės akimirka. Jos komanda buvo stipri, infrastruktūra sustiprinta, tačiau viena įkyri pažeidžiamumo sritis neleido jai ramiai miegoti: platus ir chaotiškas jų taikomųjų programų portfelis.

Naujausias rūpestis buvo naujas klientams skirtas mokėjimų portalas, skubiai išleistas į rinką siekiant ketvirčio tikslų. Kūrimo komanda, dirbusi pagal agresyvų Agile modelį, buvo pažymėjusi visus funkcinius punktus. Tačiau kai Marijos komanda atliko preliminarų skenavimą, rezultatai patvirtino jos nuogąstavimus.

Portale trūko patikimų sesijų laiko limitų taisyklių, jo įvesties laukai buvo pažeidžiami elementarioms injekcijos atakoms, o klaidų pranešimai atskleidė jautrią sistemos informaciją. Tai nebuvo sudėtingi nulinės dienos pažeidžiamumų išnaudojimo atvejai; tai buvo esminiai projektavimo trūkumai. Pagrindinė priežastis buvo skausmingai aiški. Saugumo reikalavimai niekada nebuvo formaliai apibrėžti, dokumentuoti ar integruoti į kūrimo sprintus. Komanda turėjo miglotą nurodymą „padaryti saugiai“, tačiau be konkretaus projekto saugumas liko neapibrėžtas ir dažnai ignoruojamas priedas po fakto.

Šis scenarijus nėra išskirtinis. Jis išryškina kritinę spragą, su kuria susiduria daugelis CISO ir atitikties vadovų: kaip ketinimą „mes rūpinamės saugumu“ paversti aiškiais, testuojamais taikomųjų programų saugumo reikalavimais, suderintais su pamatiniais standartais, tokiais kaip ISO/IEC 27001:2022, ir pagrindiniais reglamentais, tokiais kaip NIS2, DORA ir GDPR.

Didelė neapibrėžtumo kaina: ko iš tikrųjų tikisi atitiktis

Marijos problemos esmė slypi dažname organizaciniame trūkume: saugumas traktuojamas kaip kokybės požymis, o ne kaip privalomų reikalavimų rinkinys. Veiksmingas saugumo reikalavimas yra konkretus, išmatuojamas ir testuojamas. „Taikomoji programa turi būti saugi“ yra pageidavimas. „Taikomoji programa turi taikyti 15 minučių neaktyvios sesijos laiko limitą, tikrinti visą naudotojo pateiktą įvestį pagal iš anksto nustatytą simbolių rinkinį ir šifruoti visus perduodamus duomenis naudojant TLS 1.3“ yra reikalavimas. Būtent tokio aiškumo ieško auditoriai ir būtent jo reikia kūrėjams, kad jie galėtų kurti saugią programinę įrangą.

Be to atsiranda visa nesėkmių grandinė:

• Nenuoseklus įgyvendinimas: skirtingi kūrėjai „saugumą“ supranta skirtingai, todėl susidaro kontrolės priemonių kratinys su sunkiai prognozuojamomis spragomis.
• Didesnės trūkumų šalinimo sąnaudos: projektavimo trūkumo radimas ir taisymas produkcinėje aplinkoje kainuoja nepalyginamai daugiau nei jo sprendimas projektavimo etape.
• Audito neatitiktys: auditoriai greitai nustatys, kad nėra struktūruoto proceso saugumo reikalavimams apibrėžti, o tai lemia reikšmingas išvadas.
• Verslo rizika: kiekvienas neapibrėžtas reikalavimas yra galimas atakos vektorius, keliantis organizacijai duomenų saugumo pažeidimų, finansinių nuostolių ir reputacijos žalos riziką.

Šiuolaikiniuose standartuose lūkestis yra nuoseklus: saugumas turi būti anksti apibrėžtas kaip reikalavimai ir susietas su rizika bei teisės aktų reikalavimais. ISO/IEC 27002:2022 gairės dėl kontrolės priemonės 8.26, Taikomųjų programų saugumo reikalavimai, numato, kad organizacijos sistemingai nustato, dokumentuoja ir tvirtina saugumo reikalavimus remdamosi formaliu rizikos vertinimu ir reglamentavimo reikalavimais.

Šis vienas principas yra kertinis daugeliui atitikties įsipareigojimų. Clarysec kryžminės atitikties susiejimas Zenith Controls: The Cross-Compliance Guide Zenith Controls rodo, kad ši koncepcija kartojasi visur:

• GDPR Articles 25 ir 32 numato „duomenų apsaugą projektuojant“ ir „duomenų tvarkymo saugumą“.
• NIS2 Article 21(2)(d)-(e) akcentuoja saugų kūrimą ir tiekimo grandinės saugumą.
• DORA Articles 6(4), 8, 10 ir 11 reikalauja IRT rizikos valdymo ir projektuojant numatyto saugumo finansų subjektams.
• NIST SP 800-53 Rev.5 kontrolės priemonėse SA-4 ir SA-15 reikalaujama apibrėžtų sistemos saugumo reikalavimų ir saugaus kūrimo praktikų.
• COBIT 2019 procesuose BAI03 ir DSS05 reikalaujama, kad su saugumu susiję reikalavimai būtų suderinti su verslu ir atitiktimi dar prieš kuriant sprendimą.

Tikslas, kaip formuluojama Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, yra apibrėžti „ką saugumas reiškia jūsų taikomosioms programoms dar prieš parašant pirmą kodo eilutę.“

Kodėl tradiciniai metodai neveikia: kontroliniai sąrašai, vėlyvas testavimas ir saugumo teatras

Dauguma organizacijų jau taiko vienokią ar kitokią taikomųjų programų saugumo praktiką. Problema ta, kad ji retai būna struktūruota taip, kad atlaikytų ISO/IEC 27001:2022 sertifikavimą ar reguliacinę priežiūrą.

Dažniausi nesėkmių modeliai:

1. Bendriniai kontroliniai sąrašai: komandos kiekvienam projektui pakartotinai naudoja vieno puslapio „saugaus programavimo kontrolinį sąrašą“. Jis nėra susietas su konkrečiomis taikomosios programos rizikomis, duomenų jautrumu ar reglamentavimo kontekstu. Kai auditorius paklausia, kaip kontrolinis sąrašas susietas su GDPR Article 25, aiškaus atsakymo nėra.
2. Saugumas kaip vėlyvas vartų patikrinimas: saugumo reikalavimai neįtraukiami į projektavimą ar naudotojų istorijas. Jie atsiranda pabaigoje kaip prašymas atlikti įsiskverbimo testavimą. Zenith Blueprint įspėja, kad „pasikliauti saugumo kontroliniu sąrašu projekto pabaigoje neveikia; šie reikalavimai turi formuoti architektūrą, daryti įtaką bibliotekų pasirinkimui ir nukreipti funkcijų prioritetizavimą nuo pirmos dienos.“
3. Nėra atsekamumo nuo reikalavimo iki testo: reikalavimas „šifruoti perduodamus duomenis“ gali egzistuoti, tačiau nėra susieto testavimo atvejo, patvirtinančio TLS versijos taikymą, sertifikato galiojimą ir šifrų stiprumą. Zenith Blueprint pabrėžia, kad lūkesčiai turi būti išmatuojami ir testuojami, o saugumo testai tiesiogiai susieti su atitinkamais reikalavimais.
4. Ad hoc trečiųjų šalių kodo valdymas: šiuolaikinės taikomosios programos dažnai yra „susiūtos iš vidinio kodo, trečiųjų šalių bibliotekų, taikomųjų programų sąsajų ir debesijos natyviųjų paslaugų“, kaip pažymima Zenith Blueprint. Be aiškių reikalavimų tiekėjams ir atvirojo kodo komponentams, tiekimo grandinės rizika lieka didelė, nekontroliuojama akloji zona.

Rezultatas – saugumo teatras: dokumentai egzistuoja ir testai atliekami, tačiau kai rimtas auditorius ar reguliavimo institucija ieško nuoseklios reikalavimų istorijos, visas procesas subyra.

Pagrindo kūrimas: nuo politikos iki praktikos

Drausmingas požiūris į taikomųjų programų saugumą prasideda nuo aiškios valdysenos. Politika nėra vien biurokratija; tai oficialus tiesos šaltinis, suteikiantis komandoms įgaliojimus ir auditoriams pateikiantis aiškų ketinimų pareiškimą. Clarysec kuriame politikas, kurios yra ir autoritetingos, ir praktiškos.

Mūsų Taikomųjų programų saugumo reikalavimų politika Taikomųjų programų saugumo reikalavimų politika nustato privalomas pagrindines taisykles. Pavyzdžiui, 5.2 punktas skiltyje „Valdysenos reikalavimai“ nustato:

Visoms taikomosioms programoms planavimo arba įsigijimo metu turi būti atliktas saugumo reikalavimų patvirtinimas, gavus dokumentuotą Taikomųjų programų saugumo komandos patvirtinimą.

Šis paprastas reikalavimas užkerta kelią mąstysenai „pirma sukurti, vėliau apsaugoti“. Politika taip pat aiškiai priskiria atskaitomybę. 4.3.1 punktas skiltyje „Vaidmenys ir atsakomybės“ nurodo, kad kūrėjai turi:

Įgyvendinti taikomąsias programas laikantis apibrėžtų saugumo reikalavimų ir standartų.

Taip saugumo našta perkeliama nuo atskiros, dažnai priešpriešoje esančios saugumo komandos patiems programinės įrangos kūrėjams. Be to, politika sujungia skirtingas saugumo sritis. 10.2 punktas nurodo integraciją su kitomis pagrindinėmis kontrolės priemonėmis:

P4 – Prieigos kontrolės politika. Apibrėžia tapatybės ir sesijų valdymo standartus, kuriuos turi taikyti visos taikomosios programos, įskaitant stiprų autentifikavimą, mažiausių privilegijų principą ir prieigos peržiūros reikalavimus.

Mažesnėms organizacijoms pritaikyta politika, tokia kaip mūsų Taikomųjų programų saugumo reikalavimų politika - SME Taikomųjų programų saugumo reikalavimų politika - SME, užtikrina, kad šiuos principus būtų galima taikyti proporcingai. Ji pripažįsta, kad nors rizikos yra panašios, įgyvendinimas turi būti pragmatiškas. Abi versijos galiausiai siekia to paties rezultato – užtikrinti, kad taikomųjų programų saugumas būtų visiškai integruotas į ISVS ir parengtas auditui.

Praktinis veiksmų planas: auditui parengtų taikomųjų programų saugumo reikalavimų kūrimas

Politika nustato „ką“ ir „kodėl“, tačiau kūrėjams ir projektų vadovams reikia „kaip“. Struktūruotas įgyvendinimo vadovas būtinas tam, kad aukšto lygio kontrolės priemonės būtų paverstos įgyvendinamais veiksmais. Zenith Blueprint 21 žingsnis, skirtas ISO/IEC 27002:2022 kontrolės priemonei 8.26, pateikia aiškią šešių žingsnių metodiką.

Peržvelkime šį procesą naudodami Marijos mokėjimų portalą kaip pavyzdį.

1 žingsnis: pradėkite nuo rizikos ir reglamentavimo konteksto

Naudodami rizikos vertinimo rezultatus, suderintus su ISO/IEC 27005:2024 (rizikos tvarkymas), pirmiausia nustatote kontekstą:

• Taikomoji programa: klientų savitarnos mokėjimų portalas.
• Duomenys: asmens identifikavimo informacija (AII), prisijungimo duomenys, mokėjimo žetonai.
• Jurisdikcijos: ES, finansinės paslaugos, debesijos sprendimas.
• Reglamentai: GDPR, DORA, PCI DSS.

Remiantis Zenith Controls gairėmis dėl kontrolės priemonės 8.26 ir susijusiais ISO standartais (27034-1, 27017, 27701), pradinės reikalavimų kategorijos turi apimti identifikavimą ir autentifikavimą, autorizavimą, duomenų klasifikavimą, įvesties tikrinimą, žurnalavimą ir duomenų apsaugą perduodant bei saugant.

2 žingsnis: sukurkite arba pritaikykite saugumo reikalavimų šabloną

Zenith Blueprint rekomenduoja sukurti standartizuotą šabloną, kad kiekvienas projektas atsakytų į tuos pačius pamatinius saugumo klausimus. Šis dokumentas turi tapti jūsų projekto inicijavimo priemonių rinkinio dalimi.

Minimalios skiltys turi apimti:

• Taikomosios programos pavadinimą, savininką ir kritiškumą.
• Duomenų kategorijas ir jautrumo lygius.
• Taikomus reglamentavimo ir sutartinius įsipareigojimus (GDPR, DORA ir kt.).
• Grėsmių aplinkos įvestis (pagal kontrolės priemonę 5.7 Grėsmių žvalgyba).
• Konkrečius saugumo reikalavimus pagal kategorijas (autentifikavimas, žurnalavimas ir kt.).
• Sąsajas su naudotojų istorijomis ir priėmimo kriterijais.
• Sąsajas su testavimo atvejais (funkciniais, saugumo, įsiskverbimo).
• Reikalavimus tiekėjams ir trečiųjų šalių komponentams.

3 žingsnis: įtraukite reikalavimus į Agile artefaktus

Saugumo reikalavimai turi būti tiesiogiai įtraukti į naudotojų istorijas ir priėmimo kriterijus. Marijos portalo projekto „kliento registracijos“ epikui tai reiškia paprastos funkcinės istorijos pavertimą saugumą įtraukiančia istorija.

• Pradinė naudotojo istorija: „Kaip naujas naudotojas galiu susikurti paskyrą.“
• Saugi naudotojo istorija: „Kaip naujas klientas noriu susikurti saugią paskyrą, kad mano mokėjimo informacija būtų apsaugota.“
• Priėmimo kriterijai (su integruotu saugumu):
  • Sistema turi taikyti stiprią slaptažodžių politiką pagal P4 – Prieigos kontrolės politiką.
  • Prieš aktyvuojant paskyrą sistema turi reikalauti el. pašto patvirtinimo vienkartine nuoroda.
  • Paskyros kūrimo forma turi būti apsaugota CAPTCHA, kad būtų išvengta botnetų atakų.
  • Visi registracijos bandymai turi būti registruojami žurnaluose kartu su šaltinio IP adresu ir įrenginio atpažinties profiliu.
  • Visi per formą pateikti duomenys turi būti išvalomi, kad būtų išvengta cross-site scripting (XSS).

Tai nėra atskiros saugumo užduotys; jos yra neatsiejama funkcijos „atlikta“ apibrėžties dalis.

4 žingsnis: susiekite reikalavimus su saugumo testavimu

Naudodami Zenith Controls kontrolės priemonę 8.29 Saugumo testavimas, užtikrinate, kad kiekvienas reikalavimas turėtų susietą testavimo atvejį. Taip uždaromas ciklas ir pateikiami audituojami kontrolės veiksmingumo įrodymai.

• Reikalavimas: perduodamų duomenų šifravimas naudojant TLS 1.3. → Testas: automatizuotas skenavimas, patvirtinantis TLS taikymą, sertifikato galiojimą ir patvirtintus šifrų rinkinius.
• Reikalavimas: įvesties tikrinimas siekiant išvengti SQL injekcijos. → Testas: automatizuotas SAST/DAST skenavimas ir rankinis fuzzing testavimas QA metu.
• Reikalavimas: 15 minučių neaktyvios sesijos laiko limitas. → Testas: automatizuoti ir rankiniai testai, patvirtinantys sesijos anuliavimą serverio pusėje po 15 minučių neaktyvumo.

5 žingsnis: išplėskite reikalavimus tiekimo grandinei

Kadangi ISO kontrolės priemonė 8.26 Zenith Controls susieta su tiekėjų saugumu (5.19, 5.20) ir išoriniu kūrimu (8.30), jūsų procesas turi apimti trečiųjų šalių kodą. MVĮ, kurios labai priklauso nuo išorinių bibliotekų, kritiškai svarbus šis Taikomųjų programų saugumo reikalavimų politika - SME politikos punktas:

Bet kuri trečiosios šalies priemonė, papildinys ar išorinė kodo biblioteka, naudojama taikomojoje programoje, turi būti užregistruota ir kasmet peržiūrima dėl saugumo poveikio ir pataisų būsenos.

Šis paprastas, pragmatiškas reikalavimas įtvirtina programinės įrangos sudedamųjų dalių sąrašo (SBOM) mąstyseną, kuri yra svarbus lūkestis pagal tokius reglamentus kaip NIS2. Didiesiems tiekėjams tie patys taikomųjų programų saugumo reikalavimai turi būti įtraukti į sutartis, nurodant ISO/IEC 27036-1 (IRT tiekimo grandinės saugumas).

6 žingsnis: įtvirtinkite periodinį pakartotinį vertinimą

Taikomosioms programoms vystantis, kinta ir jų rizikos. Zenith Blueprint gairės dėl periodinio pakartotinio vertinimo yra itin svarbios. Integravus naują taikomųjų programų sąsają arba perėjus prie kitos debesijos paslaugos, rizikos kontekstas pasikeičia. Tai turi inicijuoti esamų saugumo reikalavimų peržiūrą, siekiant užtikrinti, kad jie vis dar pakankami. Tai dera su ISO/IEC 27005:2024 (nuolatinis rizikos tvarkymas) ir paverčia taikomųjų programų saugumą tęstine praktika, o ne vienkartiniu projektu.

Kontrolės priemonių ekosistemos išskaidymas

ISO kontrolės priemonė niekada neegzistuoja vakuume. Veiksmingas saugumas remiasi tarpusavyje susijusių priemonių tinklu. Tikroji kontrolės priemonės 8.26 vertė atsiskleidžia supratus jos ryšį su kitomis kontrolės priemonėmis; ši perspektyva išsamiai aprašyta Zenith Controls.

Kontrolės priemonė 8.26 klasifikuojama kaip prevencinė kontrolės priemonė, tačiau ji veikia kaip viso saugaus kūrimo proceso centrinis mazgas, jungiantis su:

• 8.25 - Saugus programinės įrangos kūrimo gyvavimo ciklas: tai bendroji sistema. Kontrolės priemonė 8.26 pateikia konkretų ką (reikalavimus), kuris turi būti integruotas į kaip (SDLC procesą).
• 8.27 - Saugi sistemos architektūra ir inžinerijos principai: reikalavimai lemia architektūrinius sprendimus, užtikrindami, kad saugumas būtų pamatinis.
• 8.28 - Saugus programavimas: kai reikalavimai apibrėžti (pvz., „išvengti SQL injekcijos“), saugaus programavimo standartai suteikia kūrėjams metodus, kaip tą reikalavimą įvykdyti.
• 8.29 - Saugumo testavimas kūrimo ir priėmimo metu: ši kontrolės priemonė patvirtina, kad 8.26 apibrėžti reikalavimai buvo tinkamai įgyvendinti.
• 5.34 - Privatumas ir AII apsauga: kai taikomoji programa tvarko asmens duomenis, 8.26 reikalavimai turi įtraukti privatumo pagal projektavimą principus.
• 5.19 ir 5.20 - Informacijos saugumas tiekėjų santykiuose: įsigyjamoms arba išorėje kuriamoms taikomosioms programoms kontrolės priemonė 8.26 nustato, kad jūsų saugumo reikalavimai turi būti išplėsti į tiekimo grandinę.

Vertindami šias kontrolės priemones kaip ekosistemą, o ne kaip kontrolinį sąrašą, galite sukurti daugiasluoksnę, dokumentuotais įrodymais pagrįstą saugumo būklę.

Auditoriaus požiūris: pasirengimas patikrai

Auditoriai mąsto įrodymais. Norėdami pasirengti, turite suprasti skirtingas perspektyvas, kurias auditorius gali taikyti. Zenith Controls audito metodikos skiltis numato šiuos skirtingus požiūrius.

Šių požiūrių supratimas leidžia parengti išsamų įrodymų portfelį, kuris parodo gyvą, veikiantį procesą, įdiegtą jūsų organizacijoje.

Kryžminės atitikties kompasas: vienas procesas, daug sistemų

Tokiai įmonei kaip Marijos DORA, GDPR ir NIS2 laikymasis yra privalomas. Rankinis kontrolės priemonių susiejimas yra pasikartojančio darbo ir atitikties spragų receptas. Centralizuotas kryžminės atitikties požiūris suteikia didelę vertę. Taikomųjų programų saugumo reikalavimų apibrėžimas yra praktinis projektuojant numatyto saugumo principo, kuriuo grindžiami visi šie modernūs reglamentai, įgyvendinimas.

Įgyvendindami tvirtą taikomųjų programų saugumo reikalavimų procesą, paremtą ISO/IEC 27002:2022, kartu kaupiate įrodymus, reikalingus reikšmingai daliai kitų reglamentų tenkinti. Jūs ne tik „darote ISO“; jūs kuriate universaliai atitinkančią saugumo programą.

Nuo chaoso prie kontrolės: jūsų kelias pirmyn

Marijos istorija baigėsi teigiamai. Incidentą su mokėjimų portalu ji panaudojo kaip pokyčių katalizatorių. Turėdama aiškią Clarysec politikų sistemą ir praktinį įgyvendinimo vadovą, ji subūrė kūrimo, saugumo ir produkto komandas. Jos pasitelkė Zenith Blueprint metodiką, kad retrospektyviai apibrėžtų portalo reikalavimus ir pagal riziką prioritetizuotų trūkumų šalinimą.

Dar svarbiau – jos įtvirtino naują darbo būdą. „Saugumo kontrolinį sąrašą“ pakeitė bendros projektavimo sesijos. Atvykus DORA auditoriams, Marija galėjo ne tik parodyti saugią taikomąją programą, bet ir pagrįsti brandų, pakartojamą procesą, užtikrinantį, kad visos būsimos taikomosios programos būtų kuriamos ant saugumo pagrindo.

Jūsų taikomųjų programų saugumo būklės transformacija prasideda nuo vieno struktūruoto žingsnio. Kelias pirmyn aiškus:

1. Įtvirtinkite valdyseną: įgyvendinkite formalią taikomųjų programų saugumo reikalavimų apibrėžimo politiką. Mūsų šablonai, tokie kaip Taikomųjų programų saugumo reikalavimų politika, suteikia auditui parengtą pradžios tašką.
2. Pritaikykite praktinę sistemą: naudokite Zenith Blueprint, kad saugumo reikalavimai būtų tiesiogiai integruoti į jūsų kūrimo gyvavimo ciklą ir taptų įgyvendinami, testuojami bei atsekami.
3. Supraskite visą kontekstą: pasitelkite Zenith Controls, kad matytumėte, kaip ši kritinė kontrolės priemonė jungiasi su platesne saugumo ekosistema ir kaip ji susiejama su DORA, NIS2, GDPR ir kitais reikalavimais.
4. Išplėskite į visą portfelį: kai metodas pasiteisina vienai taikomajai programai, išplėskite jį visam portfeliui, integruodami Saugumo reikalavimų šabloną į standartinius projektų inicijavimo kontrolinius sąrašus, Agile šablonus ir pirkimų procesus.

Jei norite paspartinti šią transformaciją, Clarysec teikia iš anksto parengtas politikas, įgyvendinimo veiksmų planus ir kryžminės atitikties susiejimus, padedančius pereiti nuo fragmentuotų pastangų prie įrodomai brandžios ir auditui parengtos programos. Nustokite taikomųjų programų saugumą vertinti kaip galutinį vartų patikrinimą. Pradėkite jį įtraukti į visko, ką kuriate, projektą.