A tervrajztól az auditkész állapotig: az alkalmazásbiztonsági követelmények szakszerű kezelése ISO 27001, DORA és NIS2 megfeleléshez

Az audit előtti feszültség szinte kézzelfogható volt. Maria, egy közepes méretű fintech vállalat információbiztonsági vezetője számára a közelgő DORA megfelelőségi értékelés kevésbé tűnt felülvizsgálatnak, sokkal inkább elszámoltatásnak. Csapata felkészült volt, infrastruktúrája megerősített, de egy makacs sérülékenységi terület éjszakánként nem hagyta nyugodni: az alkalmazások kiterjedt és kaotikus világa.

A legutóbbi aggodalom egy új, ügyféloldali fizetési portál volt, amelyet a negyedéves célok teljesítése érdekében sietve vezettek piacra. A fejlesztőcsapat agresszív agilis modellben dolgozva minden funkcionális elvárást teljesített. Amikor azonban Maria csapata előzetes vizsgálatot futtatott, az eredmények igazolták a félelmeit.

A portálból hiányoztak a robusztus munkamenet-időtúllépési szabályok, beviteli mezői alapvető injektálási támadásoknak voltak kitéve, a hibaüzenetek pedig érzékeny rendszerinformációkat szivárogtattak. Ezek nem kifinomult zero-day exploitok voltak, hanem alapvető tervezési hibák. A gyökérok fájdalmasan egyértelmű volt: a biztonsági követelményeket soha nem határozták meg formálisan, nem dokumentálták, és nem építették be a fejlesztési sprintekbe. A csapat homályos megbízást kapott arra, hogy „tegyék biztonságossá”, de konkrét tervrajz nélkül a biztonság bizonytalan és gyakran figyelmen kívül hagyott utólagos szempont maradt.

Ez a helyzet nem egyedi. Rámutat arra a kritikus hiányosságra, amellyel sok információbiztonsági vezető és megfelelési vezető szembesül: hogyan alakítható át a „nálunk van biztonság” szándéka olyan explicit, tesztelhető alkalmazásbiztonsági követelményekké, amelyek összhangban állnak az olyan alapvető szabványokkal, mint az ISO/IEC 27001:2022, valamint az olyan jelentős szabályozásokkal, mint a NIS2, DORA és GDPR.

A bizonytalanság magas ára: mit vár el valójában a megfelelés

Maria problémájának lényege egy gyakori szervezeti hibában rejlik: a biztonságot minőségi jellemzőként kezelik, nem pedig nem tárgyalható követelmények halmazaként. A hatékony biztonsági követelmény konkrét, mérhető és tesztelhető. „Az alkalmazás legyen biztonságos” kívánság. „Az alkalmazásnak 15 perces inaktivitás utáni munkamenet-időtúllépést kell érvényesítenie, minden felhasználói bemenetet előre meghatározott karakterkészlet alapján kell validálnia, és minden továbbított adatot TLS 1.3 használatával kell titkosítania” követelmény. Ez az egyértelműség az, amit az auditorok keresnek, és amire a fejlesztőknek szükségük van biztonságos szoftver építéséhez.

Enélkül hibák láncolata indul el:

• Inkonzisztens megvalósítás: A különböző fejlesztők eltérően értelmezik a „biztonságos” fogalmát, ami kiszámíthatatlan hiányosságokat tartalmazó kontrollmozaikhoz vezet.
• Megnövekedett helyesbítési költségek: Egy tervezési hiba éles környezetben történő megtalálása és javítása nagyságrendekkel drágább, mint a tervezési szakaszban történő kezelése.
• Auditmeg nem felelések: Az auditorok gyorsan azonosítják a biztonsági követelmények meghatározására szolgáló strukturált folyamat hiányát, ami jelentős megállapításokhoz vezet.
• Üzleti kockázat: Minden meghatározatlan követelmény potenciális támadási vektor, amely adatsértésnek, pénzügyi veszteségnek és reputációs kárnak teszi ki a szervezetet.

A korszerű szabványokban az elvárás következetes: a biztonságot követelményként, korai szakaszban, kockázathoz és jogszabályhoz kötve kell meghatározni. Az ISO/IEC 27002:2022 8.26 kontrollra, alkalmazásbiztonsági követelményekre vonatkozó iránymutatása elvárja, hogy a szervezetek formális kockázatértékelés és szabályozási követelmények alapján rendszerezetten határozzák meg, dokumentálják és hagyják jóvá a biztonsági követelményeket.

Ez az egyetlen elv a megfelelési előírások széles körének tartópillére. A Clarysec keresztmegfelelési megfeleltetése a Zenith Controls: The Cross-Compliance Guide Zenith Controls keretében megmutatja, hogy ez a koncepció mindenhol megjelenik:

• A GDPR Articles 25 és 32 „Beépített adatvédelem” és „Az adatkezelés biztonsága” elvárásokat fogalmaz meg.
• A NIS2 Article 21(2)(d)-(e) a biztonságos fejlesztést és az ellátási lánc biztonságát hangsúlyozza.
• A DORA Articles 6(4), 8, 10 és 11 IKT-kockázatkezelést és tervezésbe épített biztonságot ír elő pénzügyi szervezetek számára.
• A NIST SP 800-53 Rev.5 SA-4 és SA-15 kontrolljai meghatározott rendszerbiztonsági követelményeket és biztonságos fejlesztési gyakorlatokat követelnek meg.
• A COBIT 2019 BAI03 és DSS05 folyamatai megkövetelik, hogy a biztonsággal kapcsolatos követelmények a megoldás kialakítása előtt összhangban legyenek az üzleti és megfelelési elvárásokkal.

A cél a Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint megfogalmazásával: „még az első kódsor megírása előtt meghatározni, mit jelent a biztonság az alkalmazások számára.”

Miért vallanak kudarcot a hagyományos megközelítések: ellenőrzőlisták, késői tesztelés és biztonsági látszattevékenység

A legtöbb szervezet végez valamilyen alkalmazásbiztonsági tevékenységet. A probléma az, hogy ez ritkán olyan strukturált, hogy megfeleljen az ISO/IEC 27001:2022 tanúsítás vagy a szabályozói vizsgálat elvárásainak.

Gyakori hibaminták:

1. Generikus ellenőrzőlisták: A csapatok minden projekthez ugyanazt az egyoldalas „biztonságos kódolási ellenőrzőlistát” használják. Ez nem kapcsolódik az alkalmazás konkrét kockázataihoz, az adatok érzékenységéhez vagy a szabályozási környezethez. Amikor az auditor megkérdezi, hogyan feleltethető meg az ellenőrzőlista a GDPR Article 25 előírásainak, nincs egyértelmű válasz.
2. Biztonság mint késői kapu: A biztonsági követelmények nem épülnek be a tervezésbe vagy a felhasználói történetekbe. A folyamat végén jelennek meg penetrációs teszt iránti kérésként. A Zenith Blueprint figyelmeztet: „nem működik, ha a projekt végén biztonsági ellenőrzőlistára támaszkodunk; ezeknek a követelményeknek már az első naptól alakítaniuk kell az architektúrát, befolyásolniuk kell a könyvtárválasztást és irányítaniuk kell a funkciók priorizálását.”
3. Nincs visszakövethetőség a követelménytől a tesztig: Létezhet olyan követelmény, hogy „a továbbított adatokat titkosítani kell”, de nincs kapcsolódó teszteset, amely ellenőrizné a TLS-verzió kikényszerítését, a tanúsítvány érvényességét és a titkosítási algoritmus erősségét. A Zenith Blueprint ragaszkodik ahhoz, hogy az elvárások mérhetők és tesztelhetők legyenek, és a biztonsági teszteket közvetlenül hozzá kell rendelni a megfelelő követelményekhez.
4. Harmadik féltől származó kód eseti kezelése: A modern alkalmazások gyakran „belső kódból, harmadik féltől származó könyvtárakból, alkalmazásprogramozási interfészekből és felhőnatív szolgáltatásokból állnak össze”, ahogy a Zenith Blueprint megjegyzi. A beszállítókra és nyílt forráskódú komponensekre vonatkozó explicit követelmények nélkül az ellátási lánc kockázata hatalmas, kontrollálatlan vakfolt marad.

Az eredmény biztonsági látszattevékenység: dokumentumok léteznek és tesztek futnak, de amikor egy komoly auditor vagy szabályozó hatóság koherens követelménykezelési történetet keres, az egész folyamat szétesik.

Az alapok megteremtése: a szabályzattól a gyakorlatig

A fegyelmezett alkalmazásbiztonsági megközelítés világos irányítással kezdődik. A szabályzat nem puszta bürokrácia; hivatalos igazodási pont, amely felhatalmazza a csapatokat, és az auditorok számára egyértelmű szándéknyilatkozatot biztosít. A Clarysec olyan szabályzatokat tervez, amelyek egyszerre irányadók és gyakorlatiasak.

Az Alkalmazásbiztonsági követelmények szabályzata Alkalmazásbiztonsági követelmények szabályzata nem tárgyalható alapszabályokat rögzít. Például az „Irányítási követelmények” alatti 5.2 pont előírja:

Minden alkalmazásnak biztonsági követelmény-ellenőrzésen kell átesnie a tervezés vagy beszerzés során, az Alkalmazásbiztonsági csapat dokumentált jóváhagyásával.

Ez az egyszerű előírás megelőzi az „előbb építsük meg, majd később tegyük biztonságossá” szemléletet. A szabályzat világos elszámoltathatóságot is kijelöl. A „Szerepkörök és felelősségek” alatti 4.3.1 pont kimondja, hogy a fejlesztőktől elvárt:

Az alkalmazások megvalósítása a meghatározott biztonsági követelményeknek és szabványoknak megfelelően.

Ez a biztonság terhét a különálló, gyakran ellenérdekeltként érzékelt biztonsági csapattól magukra a szoftver készítőire helyezi át. A szabályzat emellett összekapcsolja a különböző biztonsági területeket. A 10.2 pont más kulcskontrollokkal való integrációjára hivatkozik:

P4 – Hozzáférés-szabályozási szabályzat. Meghatározza az identitás- és munkamenet-kezelési szabványokat, amelyeket minden alkalmazásban érvényesíteni kell, beleértve az erős hitelesítést, a legkisebb jogosultság elvét és a hozzáférési felülvizsgálati követelményeket.

Kisebb szervezetek számára egy testre szabott szabályzat, például az Alkalmazásbiztonsági követelmények szabályzata – KKV Alkalmazásbiztonsági követelmények szabályzata – KKV biztosítja, hogy ezek az elvek skálázhatók legyenek. Elismeri, hogy bár a kockázatok hasonlóak, a megvalósításnak pragmatikusnak kell lennie. Mindkét változat végső célja ugyanaz: az alkalmazásbiztonság teljes integrálása az IBIR-be és az auditkész állapot biztosítása.

Gyakorlati ütemterv: auditkész alkalmazásbiztonsági követelmények kialakítása

A szabályzat meghatározza a „mit” és a „miért” kérdéseket, de a fejlesztőknek és projektvezetőknek a „hogyanra” van szükségük. A strukturált bevezetési útmutató nélkülözhetetlen a magas szintű kontrollok végrehajtható lépésekké alakításához. A Zenith Blueprint 21. lépése, amely az ISO/IEC 27002:2022 8.26 kontrolljára fókuszál, világos, hatlépéses módszertant ad.

Nézzük végig ezt a folyamatot Maria fizetési portáljának példáján.

1. lépés: indulás a kockázati és szabályozási kontextusból

Az ISO/IEC 27005:2024 szabvánnyal összhangban álló kockázatértékelési kimeneteket használva először azonosítani kell a kontextust:

• Alkalmazás: ügyfél önkiszolgáló fizetési portál.
• Adatok: személyazonosításra alkalmas információk (PII), hitelesítő adatok, fizetési tokenek.
• Joghatóságok: EU, pénzügyi szolgáltatások, felhőben üzemeltetett.
• Szabályozások: GDPR, DORA, PCI DSS.

A Zenith Controls 8.26 kontrollra vonatkozó iránymutatása és a kapcsolódó ISO szabványok (27034-1, 27017, 27701) alapján a kiinduló követelménykategóriáknak tartalmazniuk kell az azonosítást és hitelesítést, a jogosultságkezelést, az adatosztályozást, a bemeneti adatok validálását, a naplózást, valamint a továbbított és tárolt adatok védelmét.

2. lépés: biztonsági követelménysablon létrehozása vagy átvétele

A Zenith Blueprint szabványosított sablon létrehozását javasolja annak érdekében, hogy minden projekt ugyanazokra az alapvető biztonsági kérdésekre válaszoljon. Ennek a dokumentumnak a projektindítási eszközkészlet részévé kell válnia.

A minimális szakaszok:

• Alkalmazás neve, tulajdonosa és kritikussága.
• Adatkategóriák és érzékenységi szintek.
• Alkalmazandó szabályozási és szerződéses kötelezettségek (GDPR, DORA stb.).
• Fenyegetettségi környezet bemenetei (az 5.7 Fenyegetettségi információk kontrollból levezetve).
• Konkrét biztonsági követelmények kategóriánként (hitelesítés, naplózás stb.).
• Kapcsolódások a felhasználói történetekhez és elfogadási kritériumokhoz.
• Kapcsolódások a tesztesetekhez (funkcionális, biztonsági, penetrációs).
• Beszállítói és harmadik féltől származó komponensekre vonatkozó követelmények.

3. lépés: követelmények beépítése az agilis artefaktumokba

A biztonsági követelményeket közvetlenül be kell építeni a felhasználói történetekbe és az elfogadási kritériumokba. Maria portálprojektjében az „ügyfél-regisztráció” epik esetében ez azt jelenti, hogy egy egyszerű funkcionális történetet biztonságtudatos történetté kell alakítani.

• Eredeti felhasználói történet: „Új felhasználóként létre tudok hozni egy fiókot.”
• Biztonságos felhasználói történet: „Új ügyfélként biztonságos fiókot szeretnék létrehozni, hogy a fizetési adataim védettek legyenek.”
• Elfogadási kritériumok (beépített biztonsággal):
  • A rendszernek erős jelszóházirendet kell érvényesítenie a P4 – Hozzáférés-szabályozási szabályzat szerint.
  • A rendszernek a fiók aktiválása előtt egyszer használatos hivatkozáson keresztüli e-mailes ellenőrzést kell megkövetelnie.
  • A fióklétrehozási űrlapot CAPTCHA-védelemmel kell ellátni a bot-támadások megelőzése érdekében.
  • Minden regisztrációs kísérletet naplózni kell forrás IP-címmel és eszköz-ujjlenyomattal.
  • Az űrlapon beküldött valamennyi adatot validálni és kezelni kell a cross-site scripting (XSS) megelőzése érdekében.

Ezek nem külön biztonsági feladatok; a funkció „kész” állapotának szerves részét képezik.

4. lépés: követelmények összekapcsolása a biztonsági teszteléssel

A Zenith Controls 8.29 Biztonsági tesztelés kontrollját használva biztosítani kell, hogy minden követelményhez kapcsolódjon teszteset. Ez zárja a kört, és audit során ellenőrizhető bizonyítékokat biztosít a kontrollhatékonyságról.

• Követelmény: továbbított adatok titkosítása TLS 1.3 használatával. → Teszt: automatizált vizsgálat a TLS kikényszerítésének, a tanúsítvány érvényességének és a jóváhagyott titkosítási algoritmuscsomagok ellenőrzésére.
• Követelmény: bemeneti adatok validálása az SQL-injektálás megelőzésére. → Teszt: automatizált SAST/DAST vizsgálat és manuális fuzzing a minőségbiztosítási szakaszban.
• Követelmény: 15 perces inaktivitás utáni munkamenet-időtúllépés. → Teszt: automatizált és manuális tesztek annak megerősítésére, hogy 15 perc inaktivitás után a munkamenet szerveroldalon érvénytelenítésre kerül.

5. lépés: a követelmények kiterjesztése az ellátási láncra

Mivel az ISO 8.26 kontroll a Zenith Controls szerint kapcsolódik a beszállítói biztonsághoz (5.19, 5.20) és a kiszervezett fejlesztéshez (8.30), a folyamatnak számolnia kell a harmadik féltől származó kóddal is. A külső könyvtárakra erősen támaszkodó KKV-k számára az Alkalmazásbiztonsági követelmények szabályzata – KKV alábbi szabályzati pontja kritikus:

Az alkalmazásban használt bármely harmadik féltől származó eszközt, bővítményt vagy külső kódkönyvtárat nyilvántartásba kell venni, és évente felül kell vizsgálni biztonsági hatása és javításkezelési állapota szempontjából.

Ez az egyszerű, pragmatikus követelmény szoftveranyagjegyzék (SBOM) szemléletet kényszerít ki, amely az olyan szabályozások, mint a NIS2, egyik kulcselvárása. Jelentős beszállítók esetében ugyanezeket az alkalmazásbiztonsági követelményeket a szerződésekbe is be kell építeni, az ISO/IEC 27036-1 szabványra (IKT ellátási lánc biztonsága) hivatkozva.

6. lépés: időszakos újraértékelés bevezetése

Ahogy az alkalmazások fejlődnek, a kockázataik is változnak. A Zenith Blueprint időszakos újraértékelésre vonatkozó iránymutatása kulcsfontosságú. Amikor új alkalmazásprogramozási interfészt integrál, vagy más felhőszolgáltatásra tér át, a kockázati kontextus megváltozik. Ennek ki kell váltania a meglévő biztonsági követelmények felülvizsgálatát annak biztosítására, hogy azok továbbra is megfelelőek legyenek. Ez összhangban áll az ISO/IEC 27005:2024 szabvánnyal (folyamatos kockázatkezelés), és az alkalmazásbiztonságot egyszeri projekt helyett folyamatos gyakorlattá alakítja.

A kontroll-ökoszisztéma kibontása

Egy ISO kontroll soha nem létezik elszigetelten. A hatékony biztonság egymással összekapcsolt intézkedések hálójára támaszkodik. A 8.26 kontroll valódi ereje akkor érvényesül, ha megértjük más kontrollokkal való kapcsolatát; ezt a nézőpontot a Zenith Controls részletezi.

A 8.26 kontroll megelőző kontrollként van besorolva, ugyanakkor a teljes biztonságos fejlesztési folyamat központi csomópontjaként működik, és az alábbiakhoz kapcsolódik:

• 8.25 - Biztonságos fejlesztési életciklus: Ez az átfogó keretrendszer. A 8.26 kontroll biztosítja a konkrét mit (a követelményeket), amelyet be kell építeni a hogyanba (az SDLC-folyamatba).
• 8.27 - Biztonságos rendszerarchitektúra és mérnöki alapelvek: A követelmények irányítják az architekturális döntéseket, biztosítva, hogy a biztonság alapvető elem legyen.
• 8.28 - Biztonságos kódolás: Miután a követelmények meghatározásra kerültek (például „SQL-injektálás megelőzése”), a biztonságos kódolási szabványok biztosítják a fejlesztők számára azokat a technikákat, amelyekkel a követelmény teljesíthető.
• 8.29 - Biztonsági tesztelés fejlesztés és átvétel során: Ez a kontroll ellenőrzi, hogy a 8.26-ban meghatározott követelményeket megfelelően valósították-e meg.
• 5.34 - A személyes információk (PII) védelme és adatvédelme: Ha egy alkalmazás személyes adatokat kezel, a 8.26-ból eredő követelményeknek magukban kell foglalniuk a beépített adatvédelem elveit.
• 5.19 és 5.20 - Információbiztonság a beszállítói kapcsolatokban: Beszerzett vagy kiszervezett alkalmazások esetében a 8.26 kontroll előírja, hogy a biztonsági követelményeket az ellátási láncra is ki kell terjeszteni.

Ha ezeket a kontrollokat ellenőrzőlista helyett ökoszisztémaként kezeli, többrétegű, igazolható biztonsági helyzetet tud kialakítani.

Az auditor nézőpontja: felkészülés a vizsgálatra

Az auditorok bizonyítékokban gondolkodnak. A felkészüléshez érteni kell, hogy milyen különböző nézőpontokból közelíthet egy auditor. A Zenith Controls auditmódszertani szakasza előre számol ezekkel a különböző megközelítésekkel.

E nézőpontok megértése lehetővé teszi egy átfogó bizonyítékportfólió előkészítését, amely élő, működő, a szervezetbe beágyazott folyamatot mutat be.

A keresztmegfelelési iránytű: egy folyamat, több keretrendszer

Egy Maria cégéhez hasonló szervezet számára a DORA, GDPR és NIS2 teljesítése kötelező. A kontrollok manuális megfeleltetése ismétlődő munkához és megfelelési hiányosságokhoz vezet. A központosított, keresztmegfelelési megközelítés jelentős értéket teremt. Az alkalmazásbiztonsági követelmények meghatározása a modern szabályozásokat megalapozó „tervezésbe épített biztonság” elvének gyakorlati végrehajtása.

Az ISO/IEC 27002:2022 szabványon alapuló, robusztus alkalmazásbiztonsági követelménykezelési folyamat bevezetésével egyidejűleg bizonyítékokat is épít e többi szabályozás jelentős részének teljesítéséhez. Nem csupán „ISO-t csinál”; általánosan megfeleltethető biztonsági programot épít.

A káosztól a kontrollig: az út előre

Maria története pozitív kimenettel zárult. A fizetési portállal kapcsolatos incidenst a változás katalizátoraként használta. A Clarysec világos szabályzati keretrendszerével és gyakorlati bevezetési útmutatójával felvértezve összehozta a fejlesztési, biztonsági és termékcsapatokat. A Zenith Blueprint módszertanát alkalmazva utólag meghatározták a portál követelményeit, és a helyesbítő intézkedéseket kockázat alapján priorizálták.

Ennél is fontosabb, hogy új működési modellt hoztak létre. A „biztonsági ellenőrzőlistát” együttműködésen alapuló tervezési alkalmak váltották fel. Amikor a DORA auditorok megérkeztek, Maria nemcsak biztonságos alkalmazást tudott bemutatni nekik, hanem érett, megismételhető folyamatot is igazolt arra, hogy minden jövőbeli alkalmazás biztonsági alapokra épül.

Az alkalmazásbiztonsági helyzet átalakítása egyetlen, strukturált lépéssel kezdődik. Az út előre egyértelmű:

1. Irányítás kialakítása: Vezessen be formális szabályzatot az alkalmazásbiztonsági követelmények meghatározására. Sablonjaink, például az Alkalmazásbiztonsági követelmények szabályzata, auditkész kiindulópontot biztosítanak.
2. Gyakorlati keretrendszer alkalmazása: Használja a Zenith Blueprint módszertant a biztonsági követelmények közvetlen fejlesztési életciklusba integrálására, hogy azok végrehajthatók, tesztelhetők és visszakövethetők legyenek.
3. A teljes kontextus megértése: Használja a Zenith Controls anyagot annak áttekintésére, hogyan kapcsolódik ez a kritikus kontroll a szélesebb biztonsági ökoszisztémához, és hogyan feleltethető meg a DORA, NIS2, GDPR és más keretrendszerek között.
4. Kiterjesztés a portfólióra: Miután a megközelítés egy alkalmazásnál működik, terjessze ki a teljes portfólióra úgy, hogy a biztonsági követelménysablont beépíti a standard projektindítási ellenőrzőlistákba, agilis sablonokba és beszerzési folyamatokba.

Ha fel szeretné gyorsítani ezt az átalakulást, a Clarysec előre elkészített szabályzatokat, bevezetési ütemterveket és keresztmegfelelési megfeleltetéseket biztosít, amelyekkel a széttöredezett erőfeszítésektől eljuthat egy bizonyíthatóan érett és auditkész programig. Ne kezelje tovább az alkalmazásbiztonságot végső kapus ellenőrzésként. Építse be mindannak a tervrajzába, amit létrehoz.