Kiberbiztonsági projektek megközelítése az ITIL 4 Continual Improvement Model alapján

GRC tanácsadóként az ITIL 4 Foundation vizsgámra való felkészülés során sokszor felmerült bennem, hogy a keretrendszer elemei és ajánlásai nagy mértékben – ha nem egészében – alkalmazhatóak a kiberbiztonságra is. Az egész keretrendszerből a Continual Improvement Model tetszett a legjobban és ezt találtam a leginspirálóbbnak, pedig nincs benne extra tartalom és újdonság, csupán jól fel van építve és logikusan tartalmazza azokat az összefüggéseket, amelyekről a mindennapokban hajlamosak vagyunk megfeledkezni.
Ebben a cikkben a saját gondolataimat kívánom megosztani arról, hogy a kiberbiztonsági projektekben hogyan lehet és érdemes alkalmazni a Continual Improvement Model-t és annak milyen előnyei lehetnek. Elsőre úgy tűnhet, hogy sok triviális – józan ésszel is magyarázható – elem szerepel az írásomban, de a saját tapasztalatom az, hogy sokszor távolról, az alapoktól kell kezdeni, hogy a célok, a kontextus és az összefüggések biztosan érthetőek legyenek.

Security – service

A bevezetőben azt állítottam, hogy az ITIL 4 ajánlásai nagy mértékben alkalmazhatóak a kiberbiztonságra. Akár egy szervezet belső, a CISO által irányított security csapatáról, esetleg egy vállalatcsoportot kiszolgáló Cyber Defence Centerről, vagy a szervezet által megbízott külső tanácsadóról van szó. Az közös bennük, hogy a kiberbiztonsági tevékenységeikkel szolgáltatást nyújtanak az adott szervezet számára. Ezek pontos köre és az általuk előállított érték sokrétű és a szolgáltatástól függ, de végső soron az adatok bizalmasságának és sértetlenségének védelmét, az üzleti és támogató funkciók működőképességének és ellenállóképességének biztosítását, valamint a megfelelést említhetjük.

Continual Improvement Model

A continual improvement, vagyis a folyamatos fejlesztés nem újkeletű dolog, a minőségügyi és egyéb kapcsolódó szabványok visszatérő és központi eleme. A megközelítés ITIL 4-ben is több helyen visszaköszön: service valuce chain activity-ként, practice-ként és a jelenleg tárgyalt modellként egyaránt. A Continual Improvement Model a folyamatos fejlesztés iteratív megközelítését támogatja, a munkát menedzselhető darabokra osztja külön célokkal, amelyeket fokozatosan lehet elérni.

A cikk gondolatmenetének vezetése érdekében egy egyszerű minta projekten keresztül szemléltetem a Continual Improvement Model egyes elemeit. A minta projekt célja egy szervezet incidenskezelési folyamatainak kidolgozása. (A megfelelő védelem kialakításához ez önmagában kevés, de a példának érthető okokból egyszerűnek kell lennie.)

What is the vision?

Első lépésként a víziót és a célokat kell meghatározni, amelyeket a projekt megvalósításával akarunk elérni. Ez biztosítja a kontextust minden későbbi döntéshez, és összekapcsolja az egyedi cselekvéseket a szervezet jövőképével.
A minta projektünk esetén a fő ösztönző a valódi kockázatok kezelése. A szervezet a globális fenyegetési jelentések (pl. Verizon Data Breach Investigation Report, ENISA Threat Landscape), illetve a kifinomult és súlyos támadások hírei alapján megállapította, hogy maga is bármikor áldozat lehet, ezért valamit tennie kell, hogy megfelelően tudjon reagálni a fenyegetésekre. Az a víziója, hogy fejleszti az incidenskezelési képességeit és előre felkészül a támadásokra, mert így sokkal jobb esélyekkel védekezhet egy anyagi veszteségeket és reputációvesztést okozó támadás ellen. Ezek alapján dokumentált biztonsági incidenskezelési folyamatok kialakítását és az incidenskezeléssel foglalkozó személyek kiképzését tűzi ki célul. A szervezet a célkitűzés során megállapította, hogy ez a cél nagyban támogatja az üzleti céljait is, hiszen ez növeli az ellenállóképességét és megvédheti a kritikus funkcióit.
Sok esetben a valós kockázatok kezelése mellett a megfelelési nyomás is hasonló ösztönző lehet, ami szintén támogatja a szervezet üzleti céljait és vízióját, mert enélkül gyakran nem is működhet egy olyan vállalat, amely erősen szabályozott környezetben folytatja a tevékenységét, vagy jövedelmező üzleti lehetőségektől esik el.

Where are we now?

Az incidenskezelési képességek kialakítása során az első lépés a jelenlegi, kiinduló (as is) állapot felmérése. Az ITIL 4 egy találó példát hoz ehhez a lépéshez: a javulás felfogható úgy, mint egy utazás A pontból B pontba és az utazást nem lehet feltérképezni, ha a kiindulási pont nem ismert.
A minta projektünkben – és sok hasonló esetben is – egy gap assessmenttel lehet meghatározni a kiinduló állapotot. A gap assessment – amelynek nem igazán van magyar kifejezése – célja a baseline-tól való eltérés(ek) megállapítása. Fontos, hogy ne csak a best practice-kre, hanem a kötelező elvárásokra is gondoljunk, amelyeket jogszabály vagy szerződés támaszthat. Az incidenskezelési képességnél maradva a baseline lehet az ISO 27001:2022 incidenskezelésre vonatkozó kontrolljainak felmérése, de alapul vehetjük a NIST Cybersecurity Framework (CSF) Respond biztonsági funkciójához tartozó kontrollokat is.
Ha jól csináltuk, akkor a scope-ba tartozó kiinduló helyzet felmérésének az outputjaként van egy részletes információkat tartalmazó dokumentumunk és egy összefoglalónk, amely pontosan megmutatja, hogy a szervezet hány darab kontrollnak felel meg teljesen, részlegesen vagy egyáltalán nem. Ha meg akarjuk könnyíteni a későbbi munkánkat, akkor a hiányosságokat – vagy eltéréseket – priorizáljuk.

Where do we want to be?

Az előző lépésben leírt ITIL 4-es hasonlatnál maradva az aktuális lépés az elérendő állapot (to be), az úticél, vagyis a B pont meghatározása, amely nélkül szintén nem tudjuk megtervezni az utazásunkat. Nagyon fontos, hogy a baseline kiválasztásával egy kicsit már az elérendő állapotot is meghatározzuk, hiszen az előző lépésben az ettől való eltérést vizsgáljuk, persze ez nem ilyen egyszerű.
A gap assessment által feltárt hiányosságok közül ebben a lépésben kell pontosan meghatározni a prioritást élvező feladatokat, intézkedéseket, amelyeket a projekt során el kell végezni, le kell szállítani. A minta projektünkben prioritásként feltárásra került, hogy a szervezetnek nincs egy egységes, széleskörben ismert incidens definíciója, az incidenskezeléssel kapcsolatos szerepkörök és felelősségek hiányosak, továbbá nincsenek scenario-specifikus incidenskezelési tervek (IRP) sem, például adathalászat, malware fertőzés, külső behatolás esetére, valamint a tapasztalatok (lessons learnt) nem kerülnek elemzésre és beépítésre.
A szervezet a magasszintű céljához kapcsolva, alacsonyabb szintű célként kitűzte a felsorolt, prioritásként azonosított hiányosságok megoldását és a felelős személyek képzését a megoldás részleteire vonatkozóan.

A szervezetek a projekt kritikus sikertényezőjeként, vagyis a kívánt eredmények eléréséhez szükséges előfeltételekként határozta meg az alábbiakat:

• Kiberbiztonsági incidens definíciójának és kategóriáinak meghatározása
• Kiberbiztonsági incidenskezeléssel kapcsolatos szerepkörök és felelősségek azonosítása, részletes kifejtése,
• Kiberbiztonsági incidenskezelési tervek (3 db) adathalászat, malware fertőzés, külső behatolás esetére
• Ellenőrzőlista a kiberbiztonsági incidenskezeléssel kapcsolatos tapasztalatok elemzésére és működésbe való beépítésére

Ha a szervezetnek megvan az érettsége és a szándéka, akkor a kritikus sikertényezők teljesülését KPI-val mérheti. A KPI mérőszám, amelyet a cél elérésének sikerének értékelésére vagy teljesítménymérésre használnak. Gyakorlati példákból kiindulva, rendkívül érdekes lenne, ha egy szervezetnek projekt eredménytermékek leszállítására vonatkozó mérőszáma lenne. Incidenskezeléssel kapcsolatban sokkal közelebb állna a valósághoz, ha az SLA-k betartására, vagy kiberbiztonsági incidensek detektálására (Mean Time To Detect – MTTD) és azokra történő reagálásra (Mean Time To Respond – MTTR) vonatkozó mérőszámot alakítanának ki. A KPI-k kialakítása során számos körülményt kell figyelembe venni és meghatározni, amelyek ismertetése nem célja a jelen cikknek.
Különös gondot kell fordítani a megfelelő célok és mérőszámok kialakítására, hiszen a projekt az előrehaladása és lezárása során ezek alapján lesz értékelve. Előfordulhat, hogy a szervezet nem elég érett ahhoz, hogy mérőszámokat alkalmazzon. Ebben az esetben fontosnak tartom az elérendő célok pontos meghatározását, amelyek elérését vagy elérésének kudarcát egyértelműen meg lehet állapítani.

How do we get there?

Ha megvan a kiinduló pontunk és az úticélunk, akkor meg kell terveznünk az utazást. A minta projekt csapat ebben a lépésben kell megtervezi a célok elérésével járó konkrét feladatokat, kijelölni a résztvevőket, a feladatok felelősét és a határidőket. A tervezés során alaposan kell eljárniuk: figyelembe kell venniük a kapacitásaikat, az előfeltételeket és a függőségeket is. Valószínűleg nem az incidenskezelési tervekkel fognak kezdeni, amíg nem határozzák meg az incidens definícióját és azoknak a feladatait, akik a kezelésükkel foglalkoznak majd.

Take action

Ha kész a terv, akkor nincs más hátra, el kell kezdeni a megvalósítást, a feladatok végrehajtását. Elképzelhető, hogy menet közben újra kell tervezni és projektje válogatja, hogy mekkora lépésekben lehet haladni. A minta projekt csapat tagjai átbeszélik a tervek részleteit és megkezdik a munkát.

Did we get there?

A feladatok végrehajtása során monitorozni kell az előrehaladást és értékelni kell a kitűzött célokhoz tartozó kritikus sikertényezők teljesülését, mérőszámok alakulását.
A minta projekt csapat rendszeresen státuszol és igyekszik dinamikusan kezelni a végrehajtás során felmerülő nehézségeket, akadályokat, amelyekből nincs hiány. A csapat végül elkészült a kritikus sikertényezőknél felsorolt dokumentumokkal és sikeresen átadták a tudást az incidenskezelésért felelős személyeknek, így lezárásra került a projekt.

How do we keep the momentum going?

Az ITIL 4 ajánlása alapján, ha sikerült megvalósítani a kitűzött célokat, akkor utána a sikerek marketingjére és a bevezetett új módszerek megerősítésére kell koncentrálni. Ezzel lehet biztosítani, hogy az elért haladás ne vesszen el, támogatást és lendületet adjon a következő fejlesztésekhez és a működés ne essen vissza a projekt előtti állapotba. A szervezeteket ebben a változásmenedzsment és tudásmenedzsment segíti.
A szervezet a minta projekt eredménytermékeit egy tudásbázisban hasznosította, ami minden érdekelt személynek rendelkezésre áll és az új incidenskezeléssel foglalkozó munkatársak is részesülnek a szükséges, korábban megtartott képzésekben.

Continual Improvement Plan és projektmenedzsment

A lépések bemutatása során igyekeztem sugallni, hogy a Continual Improvement Plan egyes lépéseit a projektmenedzsment módszertanok is tartalmazzák, az viszont elképzelhető, hogy más-más ciklusban.
A vízió meghatározása a projekt előtt történik. A szervezeten kívüli és belüli hatások eredményeként tulajdonképpen ebben a lépésben merülhet fel a projekt iránti igény. A vízió és a célok meghatározása a projektmenedzsment módszertanok (pl. Prince 2) szerint a business case-ben történik meg, amit természetesen költségre, megtérülésre vonatkozó részletekkel is ki kell egészíteni. Ez alapján ítélhető meg, hogy a projekt kívánatos, életképes és megvalósítható-e.

Ha a business case elfogadásra került, akkor indulhat a projekt előkészítése és tervezése. Ez más, mint az utazás megtervezése a 4. lépésben, hiszen itt a fejlesztési célok elérése érdekében végrehajtandó, fejlesztési feladatok tervezése történik (pl. kockázatkezelési terv), de addig el kell jutnia a szervezetnek. A projekttervben az összes lépés végrehajtásához szükséges erőforrásokat és ütemezést kell tervezni.
A klasszikus projektmenedzsment módszertan alkalmazása (projekttervezés, eredménytermékek meghatározása, projektindítás, státuszolás, változásmenedzsment stb.) elősegíti a Continual Improvement Plan megvalósítását, de nem valósítja meg szükségszerűen a modell előnyeit. Egy jól előkészített és gördülékenyen lebonyolított projekt is lehet kudarc egy éles helyzetben, ha az szakmailag nem megalapozott és az összefüggések nem lettek figyelembe véve: például üzletmenet-folytonossági terveket nem lehet üzleti hatáselemzés nélkül készíteni (hacsak már nem áll rendelkezésre a kritikus folyamatok és azokat támogató vagyonelemek listája, vagy éppen olyan kis méretű a szervezet, hogy anélkül is be lehet azonosítani a kritikus folyamatokat)

Konklúzió

A cikkben összefoglaltam az ITIL 4 Continual Improvement Model kiberbiztonsági projektekben való alkalmazhatóságát.
Összegzésként egy kérdést igyekszem megválaszolni: Mit adhat nekünk a Continual Improvement Model? Amennyiben röviden kellene válaszolnom, akkor azt mondanám, hogy szakmailag megalapozott projekteket, HA következetesen alkalmazzák.
Ha bővebben kellene válaszolni, akkor azt mondanám, hogy a modell egy strukturált fejlesztési megközelítést ad, amit univerzálisan, szinte bármilyen projektben alkalmazhatunk. Használhatjuk SIEM rendszer bevezetésére irányuló, komplex projekt során is, hiszen a fő lépések és a megközelítés változatlan. A modell következetes felhasználással az ad-hoc, gyakran a buzzword-ök által vezérelt célok helyett valós kockázatokat kezelő, koncepcionálisan megalapozott és jól előkészített projekteket eredményezhet, amelyek nagyobb valószínűséggel végződnek sikerrel.