Így vágj bele egy ISMS bevezetési projektbe

Minden projektnek megvannak a maga szépségei, sajátosságai és nehézségei, ez az ISO 27001 szabványon alapuló Information Security Management System (ISMS) bevezetési projekteknél sincs másképp. A cikksorozatom folytatásaként az ISMS projektek általános jellemzőiről, ajánlott indításáról írok a korábbi tapasztalatokat összegezve.
Az ISMS tévhitekről itt írtam, míg arról hogyan add el a menedzsmentnek itt.
Ha az előző cikk alapján sikerült meggyőzni a szervezet vezetését az ISMS fontosságáról és megszületett a döntés a bevezetési projekt indításáról, felvetődik a kérdés, hogy hogyan érdemes belevágni az egész munkába. Semmiképpen sem szeretném túlmisztifikálni a szabványt és a témakört, de azzal tisztában kell lenni, hogy csupán a szabvány egyes követelményeire vonatkozó sablonok kitöltésére és szabályzatok gyártására szorítkozva nem lehet ISMS-t kialakítani.

ISMS bevezetés, mint formális projekt

Az ISO 27000-es szabványcsalád első pár szabványát (pl. 27000, 27001, 27002) olvasva nagyon hamar egyértelművé válhat, hogy a szervezet nem egy könnyű, de egyébként abszolút reális és megvalósítható feladatra vállalkozik. Az ISMS bevezetése hosszú, összetett feladatokból áll, számtalan függőséggel, amelyeken nagyon könnyű elcsúszni. A hagyományos IT projektektől eltérően itt nem csak az IT, hanem az üzleti és a támogató szervezeti egységek, illetve harmadik felek is érintettek, ami azt eredményezi, hogy több szereplőt nehezebb koordinálni, összefogni.
A fenti okok, illetve a későbbiekben részletesen kifejtett okok szükségessé teszik, hogy a szervezet formális projektként, szervezett keretek közt vezesse be az ISMS-t. Maga a feladat aktív projektmenedzsment tevékenységet és részletes tervezést igényel.

Scope

A projekt előkészítésének első lépése a scope, más néven hatókör vagy alkalmazási terület meghatározása. A scope-ot több dimenzióban lehet és kell értelmezni: szervezeti egységek és üzleti folyamatok, IT és fizikai lokációk szerint. Szervezeti egységek és üzleti folyamatok szempontjából nem minden ISMS terjed ki az adott szervezet egészére. Nagyobb méretű szervezetek esetén jellemző, hogy csupán egy-egy szakmai terület vagy bizonyos szolgáltatás nyújtásában érintett területek tartoznak az ISMS scope-ba. Nagy szervezeteknél a best practice egyébként is azt javasolja, hogy elsőként csak egy meghatározott területen kerüljön bevezetésre az ISMS, majd a megfelelő érettség után ki lehet terjeszteni, ha „kiforrta magát”. Kis szervezeteknél természetesen célszerű lehet az egész szervezetre kiterjeszteni a hatókört, ha ez ellen nem szól semmilyen érv. Az ISO 27001 szabvány erre vonatkozóan nem ír elő követelményt, csupán azt, hogy meg kell határozni és dokumentálni kell a scope-ot.

IT szempontból azok a rendszerek, alkalmazások és hardverek tartoznak a scope-ba, amelyek a scope-ba tartozó üzleti folyamatokat támogatják, azokban felhasznált adatokat kezelik. Az IT scope meghatározásakor a CMDB-t és a szolgáltatáskatalógust lehet felhasználni.
Fizikai lokációk szempontjából a scope-ba beletartozhat egy vagy több teljes telephely, vagy akár irodaházak esetében kijelölt emeletek, vagy korlátozott esetekben csak néhány kijelölt iroda, szerver terem, amelyek szintén a meghatározott üzleti folyamatokat támogatják.

A scope fontossága abban rejlik, hogy az ISMS előírásait, kontrolljait a scope-ba tartozó folyamatokban, rendszereken, hardvereken, és területeken maradéktalanul kell alkalmazni. A scope-ba tartozó folyamatok információs vagyonelemeit kell felvenni és menedzselni, a kockázatokat is ezekkel kapcsolatban kell azonosítani, értékelni és kezelni. Az auditok során a scope-ban lévő elemeket ellenőrzik, de ha az előírások nem teljesülnek maradéktalanul, az sikertelen eredményre vezethet.
A scope-on kívül helyezett elemeket célszerű pontosan meghatározni és formálisan ezeket úgy kell(ene) kezelni, mintha harmadik felek lennének, de ez a gyakorlatban sajnos nem mindig valósul meg megfelelően. 

Projekttervezés – szakmai feladatok

Az ISMS projekt lépéseit erősen ajánlott projekttervbe foglalni, amely a bevezetéssel kapcsolatos feladatok lebontását és ütemezését tartalmazza. A projekttervet az elérendő eredmények, állapot alapján mérföldkövekre kell bontani, amelyek részletes szakmai feladatairól a következő cikkem fog szólni.
Az ISMS bevezetési projektek időtervezésére nehéz becsléseket adni, hiszen ahogy a korábbi cikkekben többször kitértem rá, a szervezetek érettségi szintje itt is meghatározó. Példaként kiragadva: nem mindegy, hogy a kockázatkezelési feladatokhoz érve arról kezdünk el beszélgetni, hogy a kockázatkezelésnek milyen módszertanai léteznek, mik az előnyei, kinek kell majd csinálni, vagy esetleg onnan indul a beszélgetés, hogy a risk managerrel áttekintjük a meglévő kockázatkezelési módszertant és csupán kiegészítjük néhány információbiztonsági specifikummal.  Az esetek túlnyomó többségében minden szervezet tanúsítást szeretne, de sajnos erre nem mindegyikük elég érett. Ilyenkor ajánlott egy hosszabb, ISMS-t megelőző felkészülés, az információbiztonság alapok megteremtése, majd ezekre építkezve lehet fókuszáltan az ISMS alkotóelemeit és a kockázatokkal arányos kontrollokat bevezetni. Mindenki a számokra kíváncsi: azt gondolom, hogy egy átlagos kkv. esetén 9-12 hónapnál rövidebb idő alatt nem, vagy rendkívül nehezen lehet működő ISMS-t bevezetni és sikeresen tanúsíttatni. Ezt természetesen sok további tényező befolyásolhatja.

A projekttervben az ütemezésen túl meg kell határozni a feladatok függőségeit is, hiszen vannak olyan feladatok, amelyekkel hatékonyan, párhuzamosan is lehet haladni és természetesen vannak olyan feladatok is, amelyeknél az azt megelőző feladatok értékelését, interjúit, vagy más outputjait kell felhasználni. Ezek a tervezés és szükség esetén az újra tervezés miatt szintén kulcsfontosságúak.

Projekttervezés – általános projektmenedzsment

A projekttervezés előző fejezetben bemutatott szakmai részén kívül természetesen elengedhetetlenek a projekttervezés további, jelen esetben „általánosnak” nevezett elemei, amelyek a Projektalapító Dokumentumban (PAD) kerülnek összefoglalásra.
Az ISMS bevezetési projektek célja egyértelmű: az ISO 27001 szabványon alapuló Information Security Management System (ISMS) kialakítása és a tanúsítás megszerzése. Az előző mondat tartalmazza a sikerkritériumot is, vagyis a sikeres tanúsítást. A tanúsítás megszerzése utáni, annak fenntartása érdekében végzett feladatok már az ISMS üzemeltetésének számítanak.
A PAD másik fontos eleme a projektszervezet és a felelősségek meghatározása, vagyis azoknak a személyeknek az összegyűjtése, akik érintettek a projektben és feladatuk van azzal kapcsolatban. Ezen személyek köre szervezetektől függően változhat, de mégis meg tudunk határozni általános szerepköröket (itt csak a projekt szempontjából legfontosabbakat emelem ki, támogató funkciók nélkül, pl. HR)

Első ilyen szerepkör a menedzsment, vagyis a szervezet felsővezetése, akik elsősorban a projekthez szükséges forrásokat biztosítják, demonstrálják az elkötelezettségüket, részt vesznek és végrehajtják a vezetői átvizsgálást, döntést hoznak az információbiztonsági kockázatokról, célokról, illetve ideális esetben elvárásokat fogalmaznak meg az ISMS-sel és az információbiztonsággal kapcsolatban.
Másik fontos szerepkörbe maga a business, vagyis az üzleti terület döntéshozói tartoznak, akik napi szinten használják a védendő információs vagyont és az információbiztonsági szabályok hatással vannak a munkájukra. Ők rendelkezhetnek jóváhagyási jogkörrel, kockázatokat „birtokolnak” és a saját területükön kikényszerítik a szabályokat. Ők az „első védelmi vonal”, nagy valószínűséggel ők lesznek az információs vagyonelemek „tulajdonosai” és a kockázatelemzésbe és más folyamatokba is célszerű bevonni őket, hogy az elvárásaikat megismerve minél inkább hozzájuk lehessen igazítani az irányítási rendszert.

Az IT vezető(k) és az adminisztrátorok nélkülözhetetlen résztvevői az ISMS projekteknek, releváns információkat birtokolnak. A scope meghatározásában, kontrollok érettségének felmérésében, kockázatok értékelésében és kezelésében is sarkalatos a jelenlétük.
Az információbiztonságért felelős vezető és csapata az IT-hoz hasonlóan nélkülözhetetlen a projekt szempontjából, azzal a különbséggel, hogy nagy valószínűséggel az információbiztonságért felelős vezető lesz az ISMS legfőbb felelőse, ezért a tanácsadók által tőle várható a legtöbb információ és igény, tanácsadók igénybevétele nélkül pedig jellemzően ő projekt fő felelőse.
Nem ISMS sajátosság, hogy legyen egy kijelölt projektgazda vagy szponzor, aki mind szakmailag, mind az általános projektvezetés szempontjából döntéshozatali jogkörrel rendelkezik. Ellenkező esetben a döntések lassan, nehezen fognak megszületni, ami valószínűsíthetően a projekt csúszását idézi elő.

A PAD-ban kerülnek összefoglalásra a projekttel kapcsolatos költségek, amelyekre az előző cikkemben soroltam fel néhány CAPEX, OPEX példát. Szintén a PAD-ban kerülnek röviden összefoglalásra a részletes projektterv mérföldkövei és azok ütemezése.
A leszállítandók vagy másnéven eredménytermékek szintén a PAD-ban kerülnek felsorolásra. Az ISMS projektek leszállítandóit jól elkülöníthető csoportokba tudjuk sorolni. Természetesen ide tartoznak a különféle szabályzatok és eljárásrendek, de vannak „registerek” is, azaz különböző nyilvántartások (pl. információs vagyonelemleltár, kockázati nyilvántartás, CMDB). A feladatok elvégzéséből és a kontrollok üzemeltetéséből előállnak „recordok”, vagyis feljegyzések, ticketek, naplóbejegyzések, amelyeket a dokumentált információ elve alapján meg kell őrizni.
Mint minden projektben, a hatékony és rendszeres kommunikáció létfontosságú. Az operatív feladatokról szóló, fix időpontban tartott, hetente ismétlődő rendszeres státusz meetingek kijelölésével szintén nem mondok újdonságot. Mindenki elfoglalt, különösen a vezetők, de a projekt előrehaladása szempontjából lényeges, hogy lehetőleg mindenki kezelje prioritásként ezeket a státusz meetingeket. Saját tapasztalatból mondhatom, hogy olyan meeting nem igazán lesz, amit le lehet mondani azért, mert nincs miről beszélni. Alapvető tényként elkönyvelhetjük, hogy senki sem szeret e-mailt olvasni, de hosszabb, informatív e-mailekkel csökkenteni lehet a meetingek számát, és alapos kifejtéssel jó néhány felmerülő kérdést meg lehet előzni, amivel további idő nyerhető a meeting elején tartott bevezetésből.

A PAD és a tervezés lényeges eleme a projekttel kapcsolatos korlátok és kockázatok azonosítása. Korlátként fel lehet sorolni olyan komplex feladatokat, amelyek ugyan kapcsolatban vannak az ISMS bevezetéssel, de ha nincsenek betervezve, akkor elvihetik a fókuszt és az erőforrásokat, ezért az ISMS bevezetési projektnek nem lesznek részei. Ilyen feladat lehet a GDPR megfelelés megteremtése,
üzletmenet-folytonosság kialakítása és az IT szolgáltatásmenedzsmenttel kapcsolatos tevékenységek.
A projekt kockázatok körébe azok negatív események tartoznak, amelyek bekövetkezése negatív hatással lehet az ISMS projektre. Projekt kockázat lehet a projekttagok leterheltsége, fizetős és belső projektek összeütközése, pandémia, nem megfelelő szabadság szervezés, vagy éppen a kulcsfontosságú pozíciók betöltetlensége, amelyekre valamilyen módon megoldást kell találni vagy el kell fogadni.
Ha összeállt a PAD, akkor a kick-off meetingen közzé kell tenni és szükség esetén módosítani kell rajta.

Szervezeti változás és kommunikáció

Az előző cikkekben is többször utaltam rá, hogy az ISMS bevezetése egy szervezeti változás, ami az emberi kapcsolatok és a szervezeti működés sajátosságai miatt számos ponton ellenállásba ütközhet.
Ha változásmenedzsmentről van szó, akkor általában John P. Kotter 8 lépéses folyamatmodellje minden esetben megjelenik valamilye formában. A folyamatmodellt külön nem ismertetem, de megfelelő minőségű munkával, szakértelemmel, jó kommunikációval és nyitottsággal minden lépést meg lehet tölteni tartalommal.
Úgy gondolom, hogy a buzzword-dé és közhellyé vált kifejezések helyett arra érdemes koncentrálni, hogy megértsük azt, hogy az adott személy szintjén – nem számít, hogy menedzser vagy üzemeltető – mit tud adni az ISMS, a saját munkája szempontjából, neki konkrétan miért lesz jobb az ISMS szerint működni. Ha ezt megértjük és az ISMS értékeit megfelelően át tudjuk adni részükre, utána a kölcsönös előnyökre alapozva esély lehet egyfajta szövetséget kötni, másrészt talán van rá esély, hogy ennek köszönhetően a nem kevés fáradozás és az elvégzendő munka talán más megítélést kap.

A kommunikáció másik aspektusa a szakmai csapat és a menedzsment rendszeres tájékoztatása mind a projekt, mind az információbiztonság helyzetéről. A kommunikáció tartalmának meghatározásánál figyelembe kell venni a vezetési szinteket és az azokhoz kapcsolódó információigényt. Példaként a kockázatértékelés eredményeinek ismertetésekor a menedzsment tagját elsősorban az fogja érdekelni, hogy a kockázat számszerűsítve milyen esélyekkel és mekkora kárt tud okozni a szervezetnek és azt mennyibe kerül kezelni. Középvezetői, illetve alsóbb szinten természetesen a kockázat kezeléséhez szükséges konkrét intézkedés, a felelős és határidő kijelölése lesz kulcsfontosságú. Számok ismertetésénél külön fontosnak tartom az egyes felmérések módszertanának és a skálák bemutatását, valamint az eredmények következményeit, hiszen ezek nélkül csupán adatokról beszélünk, amiből jó formán semmi sem következik.

Konklúzió

A leírtakból talán mindenki számára világossá válik, hogy az ISMS projektek sikere nagyrészt a tervezésen, valamint kialakított tervek betartásán áll vagy bukik. Természetesen nem lehet mindennel számolni, a változásokat nem lehet elkerülni, de a kompetencia, precizitás, agilitás és egyes soft skillek alkalmazása hozzájárulhat a sikerhez.