Az IT audit előtt a legfontosabb tudnivaló a jelenlegi rendszerről az, hogy pontosan mely eszközök, szerverek és szoftverek tartoznak hozzá, ki fér hozzájuk, és milyen dokumentáció létezik ezekről írásban. Egy audit akkor lesz gyors és eredményes, ha a cég előre összegyűjti ezeket az alapadatokat, nem pedig az auditor helyszíni kérdéseire próbál rögtönzött válaszokat adni. Az esetek jelentős részében az audit elhúzódásának oka nem a rendszer bonyolultsága, hanem az, hogy a cégen belül senki nem tudja pontosan, mi is fut jelenleg a háttérben, és ki felelős az egyes elemekért. Egy jól előkészített audit ezzel szemben nemcsak gyorsabb, hanem sokkal pontosabb képet is ad a valós kockázatokról.

Milyen alapadatokat kell összegyűjteni az audit megkezdése előtt

Az audit megkezdése előtt össze kell gyűjteni a rendszerek, szerverek, munkaállomások és szoftverlicencek pontos listáját, a hálózati topológia alapvázlatát, valamint a jelenlegi hozzáférés-kezelési és jogosultsági struktúrát. Az esetek jelentős részében ezek az adatok részben léteznek, de szétszórtan, különböző munkatársak fejében vagy régi, elavult dokumentumokban, nem egy helyen, naprakészen összegyűjtve.

Az általunk vizsgált esetekben azt tapasztaltuk, hogy azok a cégek, amelyek egy egyszerű, de naprakész eszköz- és rendszerleltárral rendelkeztek az audit előtt, átlagosan lényegesen rövidebb idő alatt jutottak el a végeredményig, mint azok, ahol az auditornak menet közben kellett feltárnia az alapvető infrastruktúrát. Az IT biztonság és biztonsági mentés szolgáltatás keretében ez a fajta naprakész dokumentáció alapból a napi üzemeltetés része, nem az audit előtti sürgősségi feladat.

Miért fontos a pontos eszköz- és szoftverleltár

A pontos eszköz- és szoftverleltár azért fontos, mert az audit egyik alapkérdése éppen az, hogy mely rendszerek léteznek egyáltalán, és ezek közül melyik rendelkezik naprakész, támogatott szoftverkörnyezettel. Mikor nem elegendő egy régi, papíralapú vagy évek óta nem frissített leltár: ha a cégnél az elmúlt években új eszközök kerültek beszerzésre vagy régiek selejtezésre anélkül, hogy ez a nyilvántartásban is átvezetésre került volna, az auditor téves alapadatokból indulna ki.

A rendszergazdai szolgáltatás keretében a naprakész eszközleltár folyamatos vezetése alapszolgáltatásként szerepel, éppen azért, hogy egy auditra ne kelljen külön, sürgősségi felmérést végezni.

Mit jelent a hozzáférés-kezelési struktúra átláthatósága

A hozzáférés-kezelési struktúra átláthatósága azt jelenti, hogy pontosan dokumentálva van, mely felhasználók milyen rendszerekhez és milyen szintű jogosultsággal férnek hozzá, és ez a dokumentáció visszakereshető, nem csak a rendszergazda fejében élő tudás. Nem ajánlott az auditra úgy érkezni, hogy a jogosultságok pontos listáját menet közben, manuálisan kell összeállítani, mert ez jelentősen megnöveli az audit időtartamát és a hibalehetőséget is.

Milyen dokumentumokat kérnek jellemzően az auditorok

Az auditorok jellemzően a hálózati és rendszerdokumentációt, a biztonsági és mentési szabályzatokat, a korábbi incidensek nyilvántartását, valamint a szoftverlicencek és szolgáltatási szerződések másolatát kérik be. Ha ezek a dokumentumok nem léteznek írásos formában, az audit maga válik azok pótlólagos elkészítésének helyszínévé, ami jelentősen megnyújtja a folyamatot és megnöveli annak költségét is.

A mi tapasztalatunk szerint azok a cégek, amelyek a kért dokumentumok többségét már az első egyeztetés előtt össze tudták állítani, átlagosan a felére csökkentették az audit teljes átfutási idejét azokhoz képest, ahol a dokumentáció menet közben, rögtönözve készült el. A szerver üzemeltetés és szerver karbantartás szolgáltatás körébe illesztett dokumentációs gyakorlat éppen ezt a fajta előre elkészített, auditkész állapotot biztosítja a szerveres rendszerek esetében.

Miért kérik be szinte mindig a mentési és biztonsági szabályzatot

A mentési és biztonsági szabályzatot szinte minden auditor bekéri, mert ez az egyik legjobb mutatója annak, hogy a cég mennyire tudatosan kezeli az üzletmenet-folytonossági kockázatokat, nem csak a napi üzemeltetést. Kinek nem elegendő egy szóbeli, dokumentálatlan mentési gyakorlat bemutatása: minden olyan cégnek, amely komolyan veszi az audit eredményét, mert az auditorok a szóbeli állításokat írásos bizonyíték nélkül nem tudják elfogadni.

Mennyire részletesnek kell lennie a korábbi incidensek nyilvántartásának

A korábbi incidensek nyilvántartásának annyira kell részletesnek lennie, hogy visszakövethető legyen, mikor, milyen jellegű probléma merült fel, hogyan kezelték, és milyen intézkedés történt a megismétlődés megelőzésére. Mielőtt összeállítanád ezt a nyilvántartást az audit előtt: érdemes tisztázni, hogy az elmúlt egy-két évben történt-e olyan esemény, amelyet korábban esetleg nem dokumentáltak formálisan, mert ennek utólagos pótlása hitelesebb, ha időben megtörténik.

Szempont	Felkészületlen cég auditkor	Előre felkészült cég auditkor
Eszközleltár állapota	Hiányos vagy elavult	Naprakész, dokumentált
Hozzáférés-kezelés átláthatósága	Csak egy-két fejben él	Írásban rögzített, visszakereshető
Audit átfutási ideje	Jelentősen elhúzódik	Lényegesen rövidebb
Mentési szabályzat megléte	Gyakran hiányzik vagy szóbeli	Írásos, tesztelt gyakorlat
Auditor bizalmi szintje	Alacsonyabb, több utókérdés	Magasabb, kevesebb visszakérdezés

A táblázatból is látszik, hogy az audit előtti felkészültség nem csak az időt, hanem az audit eredményének megbízhatóságát is jelentősen befolyásolja: egy dokumentálatlan rendszer auditja gyakran több feltételezésre, mint tényre épül.

Mielőtt belevágnál egy IT auditba: érdemes tisztázni, mely dokumentumok léteznek már most, írásban, és melyeket kell még pótolni, mert ha ezt a felmérést az audit előtt elvégzed, jelentősen csökkentheted mind az időt, mind a költséget.

Az audit előtti felkészülés lépései a gyakorlatban:

1. Össze kell állítani a teljes eszköz- és szoftverleltárt, naprakész állapotban.
2. Dokumentálni kell a jelenlegi hozzáférés-kezelési és jogosultsági struktúrát.
3. Össze kell gyűjteni a meglévő mentési, biztonsági és incidenskezelési szabályzatokat.
4. Fel kell mérni a korábbi incidenseket, és pótolni kell a hiányzó dokumentációt.
5. Ki kell jelölni egy belső kapcsolattartót, aki az auditor kérdéseire gyorsan tud válaszolni.

A nemzetközi gyakorlatban elterjedt informatikai kockázatkezelési alapelvek is kiemelten kezelik a dokumentált, visszakövethető folyamatok szerepét egy megbízható audit alapjaként.

A leggyakoribb hiba, amit kisvállalkozásoknál látunk, hogy az audit előkészítését az utolsó pillanatra hagyják, és a hiányzó dokumentációt próbálják meg sietve, gyakran pontatlanul pótolni, ahelyett hogy ezt folyamatosan, az üzemeltetés részeként vezetnék.

Az audit előtt érdemes rendszeresen ellenőrizni az alábbi elemeket:

• naprakész-e az eszköz- és szoftverleltár
• visszakereshető-e írásban, ki milyen rendszerhez fér hozzá
• létezik-e dokumentált, tesztelt mentési és biztonsági szabályzat
• van-e nyilvántartás a korábbi incidensekről és azok kezeléséről

Ha a cég az audit előkészítését szélesebb kontextusban szeretné átgondolni, érdemes az IT tanácsadás és IT üzemeltetés szolgáltatás keretében felmérni a teljes rendszert, mert az audit gyakran csak egy pillanatfelvétel a szélesebb üzemeltetési gyakorlatból. A weboldal is gyakran az audit része: a weboldal karbantartás és üzemeltetés szolgáltatás körébe tartozó dokumentáció ugyanolyan fontos, mint a szerveres rendszerek nyilvántartása.

Milyen szerepe van a hálózati topológia dokumentációjának egy auditban

A hálózati topológia dokumentációja megmutatja, hogyan kapcsolódnak egymáshoz a rendszerek, szerverek és eszközök, milyen szegmensekre oszlik a hálózat, és hol húzódnak a biztonsági határvonalak. Egy auditor számára ez a dokumentáció az egyik legfontosabb kiindulópont, mert nélküle nem tudja megítélni, mennyire izolált egy esetleges biztonsági incidens hatása, vagy mennyire terjedhetne szét egy fertőzés a teljes rendszeren.

Az esetek jelentős részében a cégek rendelkeznek valamilyen hálózati vázlattal, de az évek során bekövetkezett változásokat – új eszközök, áthelyezett szerverek, megszűnt kapcsolatok – nem vezetik át rajta, így az audit idejére a dokumentáció már nem tükrözi a valós állapotot.

Miért okoz problémát egy elavult hálózati vázlat az audit során

Egy elavult hálózati vázlat azért okoz problémát, mert az auditor téves alapfeltevésekből indulhat ki, ami vagy hamis biztonságérzetet kelt egy valójában sérülékeny kapcsolat esetén, vagy feleslegesen aggályosnak minősít egy már megszüntetett, elavult összeköttetést. Mikor nem elegendő egy évekkel korábban készült, azóta nem frissített vázlat: ha a cég infrastruktúrája az elmúlt egy-két évben bármilyen jelentős változáson ment keresztül, mint például felhőbe költözés vagy új telephely nyitása.

A rendszergazdai szolgáltatás keretében a hálózati dokumentáció folyamatos karbantartása alapszolgáltatásként szerepel, hogy egy auditra ne kelljen külön, sürgősségi frissítést végezni rajta.

Mit érdemes tartalmaznia egy auditra alkalmas hálózati dokumentációnak

Egy auditra alkalmas hálózati dokumentációnak tartalmaznia kell az összes szerver, munkaállomás és hálózati eszköz elhelyezkedését, a köztük lévő kapcsolatokat, a tűzfalszabályokat és a hálózati szegmensek közötti határvonalakat. Nem ajánlott olyan dokumentációval érkezni az auditra, amely csak a fő eszközöket tünteti fel, de a köztük lévő tényleges kapcsolati logikát nem mutatja be részletesen.

Hogyan mérje fel a cég a jelenlegi szoftverkörnyezet kockázatait audit előtt

A szoftverkörnyezet kockázatainak felmérése azt jelenti, hogy a cég áttekinti, mely szoftverek futnak jelenleg, ezek közül melyek rendelkeznek még gyártói támogatással, és melyek azok, amelyek elavultsága miatt biztonsági kockázatot jelentenek. Az esetek jelentős részében az auditok éppen azért tárnak fel súlyos hiányosságokat, mert a cég nem tudta előre, hogy egyes rendszerei már nem kapnak biztonsági frissítést.

A mi tapasztalatunk szerint azok a cégek, amelyek rendszeresen áttekintették a szoftverkörnyezetük támogatási státuszát, lényegesen kevesebb kritikus megállapítást kaptak az auditon, mint azok, amelyek ezt a felmérést csak az audit hatására végezték el először.

Miért kritikus tudni, mely szoftverek futnak gyártói támogatás nélkül

A gyártói támogatás nélkül futó szoftverek azért kritikusak, mert ezekhez már nem érkeznek biztonsági javítások, így minden újonnan felfedezett sérülékenység tartósan nyitva marad rajtuk, amíg le nem cserélik vagy frissítik őket. Mi mehet rosszul, ha ez a felmérés elmarad: az auditor olyan súlyos sérülékenységet találhat, amelyről a cég korábban egyáltalán nem tudott, mert soha nem vizsgálta meg a szoftverei támogatási állapotát.

Hogyan rangsorold a feltárt szoftverkockázatokat a javítás előtt

A feltárt szoftverkockázatokat érdemes aszerint rangsorolni, hogy az adott rendszer mennyire kritikus a napi működés szempontjából, és mekkora a sérülékenység tényleges kihasználhatósága. Kinek nem elegendő az összes hiányosság egyszerre történő javítása: minden olyan cégnek, ahol korlátozottak az erőforrások, mert egy átgondolatlan, egyszerre mindenre kiterjedő javítási kísérlet gyakran újabb üzemzavarokat okoz.

Milyen gyakori hiányosságokat tár fel egy IT audit kisvállalkozásoknál

Az IT auditok kisvállalkozásoknál leggyakrabban a hiányzó vagy elavult dokumentációt, a túl széles körű, indokolatlan jogosultságokat, a tesztelés nélküli mentési rendszereket és a rendszeresen nem frissített szoftverkörnyezetet tárják fel. Ezen hiányosságok egyike sem újdonság a szakma számára, mégis évről évre ugyanezek a problémák kerülnek elő a legtöbb auditjelentésben.

Ezt az összefüggést több projekten megfigyeltük: azok a cégek, amelyeknél ezek a hiányosságok fennálltak, jellemzően nem azért, mert nem volt elég technikai tudás a cégen belül, hanem mert soha nem szánt rá senki elegendő időt, hogy ezeket rendszerszinten, dokumentáltan kezelje.

Miért ismétlődnek évről évre ugyanazok a hiányosságok

Ugyanazok a hiányosságok azért ismétlődnek évről évre, mert az audit után gyakran csak a legégetőbb, azonnal látható problémákat javítják ki, a mögöttes szervezési és dokumentációs hiányosságot nem. Nem ajánlott az audit eredményét pusztán egy egyszeri hibalistaként kezelni, mert enélkül a következő audit ugyanazokat vagy hasonló problémákat fogja feltárni.

Milyen hosszú távú intézkedés akadályozza meg a hiányosságok visszatérését

A hiányosságok visszatérését az akadályozza meg, ha a cég nem egyszeri javításban, hanem folyamatos, dokumentált üzemeltetési gyakorlatban gondolkodik, amelyben a jogosultságok, a mentés és a szoftverfrissítések rendszeresen, nem csak audit előtt kerülnek felülvizsgálatra. Az IT tanácsadás és IT üzemeltetés szolgáltatás keretében ez a folyamatos felülvizsgálat épül be az együttműködés alapjába, nem csak eseti feladatként jelenik meg.

Hogyan válassz külsős partnert, ha az audit eredménye alapján kell fejlesztened

Az audit eredménye alapján történő partnerválasztásnál érdemes olyan szolgáltatót keresni, amely nem csak a feltárt hiányosságok pontszerű javítására vállalkozik, hanem a mögöttes, rendszerszintű okokat is kezeli, hogy a következő audit ne ugyanazokat a problémákat találja. Nem ajánlott olyan partnert választani, amely csak egyszeri, gyors javításokat kínál anélkül, hogy a hosszú távú üzemeltetési gyakorlatot is átgondolná.

A mi tapasztalatunk szerint az a cég jár a legjobban, ahol az audit után választott IT-partner ugyanaz marad hosszú távon, mert így a fejlesztések folyamatosan épülnek egymásra, nem különálló, egymással néha ütköző beavatkozásokként valósulnak meg.

Milyen kérdéseket érdemes feltenni egy auditálás utáni ajánlat értékelésekor

Egy auditálás utáni ajánlat értékelésekor érdemes megkérdezni, hogyan kezeli a partner a feltárt hiányosságok rendszerszintű okait, milyen dokumentációt vezet be a jövőbeli auditok megkönnyítésére, és milyen ütemterv szerint valósítja meg a szükséges fejlesztéseket. Mielőtt aláírnál egy szerződést: érdemes tisztázni, hogy az ajánlat csak a jelenlegi hiányosságokra reflektál, vagy hosszú távú, fenntartható üzemeltetési modellt is kínál.

Megéri-e ugyanazt a partnert megbízni a javítással, aki az auditot végezte

Megéri-e ugyanazt a partnert megbízni a javítással, aki az auditot is végezte? Ez a gyakorlat összeférhetetlenséget okozhat, mert az auditornak érdemes függetlennek maradnia a javítási munkától, hogy a következő ellenőrzés objektív maradjon; ezzel szemben egy külön, mint az IWS, kiszervezett IT-üzemeltetési partner bevonása a javításra tisztább, átláthatóbb felelősségi struktúrát biztosít.

Hogyan alakítsd ki a végleges, auditkész állapotot a cégednél

A végleges, auditkész állapot akkor jön létre, ha a cég nem az audit előtti hetekben kapkodva állítja össze a dokumentációt, hanem folyamatosan, a napi üzemeltetés részeként vezeti azt: az eszközleltárt, a jogosultsági struktúrát, a mentési szabályzatot és az incidensnyilvántartást egyaránt. Ha ez a négy elem folyamatosan naprakész, egy audit gyakorlatilag bármikor, minimális előkészülettel elindítható, mert nincs mit sietve pótolni.

A mi tapasztalatunk szerint azok a cégek, amelyek a dokumentációt egy külső, kiszervezett IT-partnerrel folyamatosan karbantartották, minden esetben lényegesen gyorsabban és alacsonyabb költséggel jutottak át az auditon, mint azok, amelyek csak az audit bejelentése után kezdtek hozzá a felkészüléshez. A rendszergazdai szolgáltatás keretében ez a folyamatos dokumentáció alapból beépül a napi működésbe, nem külön, auditra szabott projektként jelenik meg.

Mikor nem elegendő az audit előtti egyszeri, gyors felkészülés: ha a cégnél rendszeresen, évente vagy gyakrabban várható valamilyen külső vagy belső ellenőrzés, mert ilyenkor a folyamatos dokumentáció fenntartása hosszú távon lényegesen kevesebb erőforrást igényel, mint az ismétlődő, sürgősségi felkészülések sorozata.

Milyen jelekből ismerhető fel, hogy a céged nincs felkészülve egy váratlan auditra

Azok a jelek, amelyek arra utalnak, hogy a céged nincs felkészülve egy váratlan auditra, a következők: az eszközleltár csak egy régi táblázatban létezik, a jogosultságokról senki nem tud pontos, írásos választ adni, és a mentési szabályzat léte csak szóban, nem dokumentumban él. Mi mehet rosszul, ha ezek a jelek fennállnak: egy váratlanul bejelentett audit vagy egy partneri, biztosítói ellenőrzés jelentős csúszást és költséget okozhat, miközben a hiányos dokumentáció önmagában is negatív megítélést eredményez.

Mi az első lépés, ha most kezdenéd el az auditkész állapot kialakítását

Ha most kezdenéd el az auditkész állapot kialakítását, az első lépés egy gyors, teljes körű eszköz- és jogosultsági felmérés, amely feltárja a jelenlegi állapotot, majd ebből épül fel a hiányzó dokumentáció pótlásának ütemterve. Ez a felmérés jellemzően rövid időn belül elvégezhető, és azonnal láthatóvá teszi, mely területek igényelnek sürgős beavatkozást.

Az alábbiakban a témával kapcsolatos leggyakoribb, brand-független kérdésekre adunk tömör választ.

Kötelező-e minden cégnek rendszeres IT auditot végeztetnie

Magyarországon nincs minden cégre vonatkozó általános kötelezettség a rendszeres IT audit elvégzésére, bizonyos ágazatokban és bizonyos partneri, biztosítási vagy szabályozási elvárások keretében azonban gyakran előírt vagy erősen javasolt követelmény.

Mennyi idő alatt lehet felkészülni egy váratlanul bejelentett auditra

Egy váratlanul bejelentett auditra a felkészülési idő nagyban függ attól, mennyire volt korábban rendezett a dokumentáció; egy alapszintű, sürgősségi felkészülés néhány naptól egy-két hétig terjedhet, míg egy folyamatosan karbantartott rendszernél gyakorlatilag azonnal auditkész az állapot.

Ki végezze el az audit előtti belső felmérést, ha a cégnek nincs saját rendszergazdája

Ha a cégnek nincs saját rendszergazdája, az audit előtti belső felmérést érdemes egy külső, IT-üzemeltetéssel foglalkozó partnerrel elvégeztetni, mert a felmérés szakértelmet és objektív rálátást igényel, amit egy erre nem szakosodott belső munkatárs nehezen tud pótolni.

Milyen következménnyel jár, ha az audit súlyos hiányosságot tár fel

Egy súlyos hiányosság feltárása az audit után jellemzően konkrét javítási határidőt és intézkedési tervet von maga után, súlyosabb esetben szerződéses vagy biztosítási következményekkel is járhat, ha a hiányosság a korábban vállalt biztonsági feltételeket sérti.