Ki ne találkozott volna már azzal a kifejezéssel, hogy audit? Ez a szó általában ráfagyasztja a mosolyt a becsületes munkavállaló arcára; hiszen ez sok munkát, esetleges nem megfelelősségek napvilágra kerülését, majd felelősségre vonást eredményezhet.

A GDPR rendelet hatályba lépésével még sűrűbbé váltak az auditok, presszionálva az informatikai biztonsági rendszereknek a megfelelését. Az auditnak több formája létezik a teljesség igénye nélkül; belső vagy külső audit, kötelező jogszabály által előírt audit, saját magunk által végrehajtott (belső) audit. Még hosszan sorolhatnánk, de jelen cikkünkben csak az IT biztonsági auditokra koncentrálunk. Ezek a sorok nem az éves zártsági auditokon pallérozódott információbiztonsági felelősöknek, tanácsadóknak, IT auditoroknak íródtak; hanem azoknak a kollégáknak, akik nyakukba kapják a majdnem ismeretlen feladatot és fel kell készülni; le kell koordinálni, meg kell úszni az ellenőrzést (minőségügyi munkatársként, informatikusként, IT vezetőként).

Az audit folyamatot három fázisra bontjuk:

1. felkészülés,
2. végrehajtás,
3. nem megfelelősségek javítása.

Most egy külső, más Szervezet vagy tanácsadó cég által végrehajtott auditot járunk körbe; mert a belső auditoknak szakmai tapasztalatunkból kiindulva alacsony a hatékonysága, ha auditról van szó. Inkább tervezzünk rá budget-t és csináltassunk egy független külső értékelést. Vegyük sorra tehát a 3 fázist.

Felkészülés az IT biztonsági auditokra

Ez a legfontosabb része az audit folyamatnak. Ne halogassuk, ne akarjunk 1 hét alatt felkészülni! Lássuk hát a felkészülés folyamatát lépésről lépésre.

1. Lépés

Az audit folyamat úgy kezdődik, persze típusától függően, hogy megvizsgáljuk minek kell megfelelni. Törvényi előírásnak (41/2015. (VII. 15.) BM rendelet, 42/2015. (VII. 15.) BM rendelet)

Esetleg valamely szabvány megfelelősség a cél (ISO/IEC 27001)? Vagy a NAV típusszabályzatának 5. számú melléklete az irányadó? Tulajdonképpen mindegy, hiszen van egy Jolly Joker a kezünkben; ez pedig a NIST 800-53 rev4 (Security and Privacy Controls for Federal Information Systems and Organizations). Ez kell, hogy sorvezetőnk legyen, természetesen az audit típusától és mélységétől függően kell nekünk is beleásnunk magunkat a kontrollokba.

2. Lépés

Miután feltérképeztük minek is kell megfelelni, mi a célunk, végeznünk kell egy önellenőrzést. Használhatunk divatos terminológiát, – GAP elemzésről beszélünk -; aminek segítségével meghatározzuk, hogy hol állunk most az audit követelményeihez képest; (ez később kikristályosodik, mi alapján, hogyan csináljuk) és hova kell eljutnunk az audit időpontjáig, hogy megfeleljünk.

Bár a módszertanok nem nagyon szeretik, mégis azt mondjuk, hogyha nincs meg a megfelelő Szervezet ismeretünk, rutinunk még; szedjük elő az előző éves jelentést, audit anyagokat és tanulmányozzuk. Ha nincs előző évi anyagunk, hagyjuk ki ezt a lépést.

Az előző évi audit anyag tanulmányozásánál különös figyelmet szenteljünk az esetleges nem-megfelelősségeknek és az azóta bekövetkezett Szervezeti vagy technikai változásoknak. Ha idáig eljutottunk kell legyen valami fogalmunk a scope-ról és egy sugallatunk, hogy hogyan is fogjuk ezt az auditot „lehozni”. De itt az idő, hogy megbeszéljük milyen témákat is nézzünk át.

Amikor felkészülünk az auditra, hogy kellemetlen percek, hosszú hallgatások, mellébeszélés (bár ez nagyon hasznos tud lenni 😊 ) nélkül is magabiztosan üljünk a székünkben és „megvegyük” az auditort az ellenőrzés során.

A feladatok sorrendje tetszőleges, de felkészítések során mi a következő 30 pontos checklistet alkalmazzuk:

1. Rendelkezzünk egy aktualizált szervezeti ábrával (IT szervezet, IT biztonság szervezet)
2. Legyen IT biztonságért felelős személy kijelölve (természetesen ez kisebb szervezeteknél lehet halmozva más pozícióval, de ne legyen összeférhetetlen).
3. Szerezzünk, készítsünk egy architektúra ábrát az informatikai rendszer vagy rendszerek elemeiről (ahol az auditor megnézheti az őt érdeklő interfészeket, rendszerelemeket).
4. Vizsgáljuk felül a hatályos szabályzókat (mindent, ami IT biztonsághoz kapcsolódhat: IBSZ, Változáskezelési dokumentumok, Adatvédelmi szabályzók; vagy bármi más, ami kapcsolódhat a vizsgálathoz) keressünk ellentmondásokat, mert ha van, az auditor meg fogja találni.
5. Nézzük meg milyen IT biztonsági vizsgálataink voltak az elmúlt 2 évben (penteszt, belső ellenőri vizsgálat stb.) Ezt kérheti az auditor és jól mutatja az információs biztonság iránti elköteleződésünket.
   
6. Nézzük meg a rendszereinknek milyen kapcsolódási pontjai vannak más, főleg külső rendszerekkel.
7. Járjunk utána mikor ellenőriztük utoljára a céges gépeken telepített szoftvereket (engedélyezett a felhasználó által történő szoftver telepítés? Ha igen ellenőrizzük milyen szoftverek vannak a gépeken és hogy ezek nem tartalmaznak-e valamilyen sérülékenységet). 
8. Használunk-e lejárt támogatású szoftvereket? Vizsgáljuk meg az üzemeltetéssel közösen, hogy mik a cél dátumok; mikorra cseréljük az end-of life szoftvereinket? Ha az auditor kérdez, kész válaszaink legyenek.
9. Nézzük meg a kockázatelemzésünket (Az újonnan feltárt kockázatok benne vannak? Az előző évi megállapításokat kezeltük? Pandémiát beleírtuk? Cselekvési tervünk update? Vannak benne felelősök? Határidők?
10. Nézzük át a kiszervezett tevékenységeket. Szerződések rendben? Az adatvédelmi kiegészítések, információvédelmi követelményeket, elvárásokat, SLA-kat tartalmazza? Ezt ellenőrizzük? Van róla evidencia?
    
11. Az egyik nagy téma, amin nagyot lehet bukni, az a jogosultságkezelés. Az éves jogosultságfelülvizsgálatot megcsináltuk? Jogosultságigénylési folyamattal képben vagyunk? Tudjuk bizonyítani az igénylés, jóváhagyás, változás folyamatait? A szerepköröket időnkét felülvizsgáljuk? Csoportjogokat átnézzük? Technikai felhasználókra odafigyelünk? Névhez kötések megvalósulnak? Mindenki csak olyan és annyi jogosultsággal rendelkezik amire szüksége van? Ezeket a folyamatokat dokumentumokkal, evidenciákkal alá kell támasztani; bemondásra nem működik! A jogosultságkezelés témájáról külön blog posttal jelentkezünk.
12. A következő téma, amivel foglalkoznunk kell az a felhasználók információbiztonsági tudatosságának növelése. Mutassuk be a prezentációkat és persze legyen egy nyilvántartás, hogy ezek az oktatások megtörténtek; akár e-learning akár tantermi formában. Ez az egyik legkönnyebben abszolválható pont; tegyük rendbe a HR területtel karöltve.
13. Ezután a naplózás témája legyen a scope. Ez nagyon sokrétű feladat. Ellenőrizzük, mit naplózunk. Hogyan, ki ellenőrzi, hol szabályoztuk? A naplófájlok sértetlenségét, hogy biztosítjuk? Fontos, hogy tudjunk képernyőképek formájában bizonyítékot mutatni a biztonsági naplózásokról. (A teljesség igénye nélkül: ki-be jelentkezések, hibás bejelentkezések, kiemelt jogú felhasználók tevékenysége, tűzfallal kapcsolatos tevékenységek, admin jogok kiosztása-visszavonása stb.). Ennek szintén egy külön blog bejegyzést szentelhetünk.
14. Vizsgáljuk meg hogyan állunk az üzletmenet-folytonossággal. Vannak üzletmenet-folytonossági terveink (BCP)? Vannak RPO (visszaállítási pont) és RTO (visszaállítási idő) számaink meghatározva? Teszteltünk? Van üzleti hatáselemzésünk (BIA)?
15. Nézzük meg a mentéseinket és adatmentéseinket! Az adatmentés és a mentések tárolása, tárolási időtartama, a személyes adatok védelme szempontjából is fontos. Mit és milyen gyakran mentünk? Milyen tároló kapacitással rendelkezünk mentések vonatkozásában? Hol tároljuk az offline mentést?
    
16. Az adatvisszaállítás tekintetében fontos, hogy megnézzük DRP terveinket, aktualizáljuk azokat! Teszteltük? A teszteredményeket kiértékeltük? Tanultunk belőle? Gyűjtsünk bizonyítékokat, legyünk felkészültek.
17. Át kell gondolnunk azonosítási és hitelesítési folyamatainkat. Használunk PKI-t? Egyéb hitelesítő mechanizmusokat? 
18. Vegyük elő hardver és szoftver leltárunkat. Nézzük, nézessük át az IT-val, aktualizáljuk.
19. Járjunk utána milyen titkosítást, algoritmusokat használunk.
20. Ellenőrizzük az incidensekkel kapcsolatos dokumentációkat. Tudunk reagálni, megvan a folyamatunk? Vannak sablonok, amiket be tudunk vetni? Tudunk reagálni adatvédelmi incidensre és informatikai biztonsági incidensre is külön-külön; ha olyan esemény történik, ami nem érint személyes adatot, de informatikai szempontból incidensnek soroljuk? Milyen incidenseink voltak az elmúlt időszakban? Felvettük a nyilvántartásba? Gyűjtsünk evidenciát, e-mail-eket hogyan kezeltük; ki, hogyan reagált; mi lett a végeredmény; mit tanultunk belőle és amit tanultunk azt bevezettük-e?
    
21. A karbantartásokra is vessünk egy pillantást, Ki jogosult karbantartani, vannak-e listáink, mikor mit csináltak, ki ellenőrizte?
22. Adathordozóinkat hogyan kezeljük, szabályozott-e a hozzáférés, van nyilvántartásunk, mindegyik névhez van kötve?
23. Az IT auditnak szerves része a fizikai környezet vizsgálata is. Nézzük meg vizsgáljuk át, hogyan történik az épületbe a bejutás; ellenőrizzük a kártyahasználatot, kódok használatát és ezek teljes életciklusát (kiadás, használat, visszavétel). Nézzük meg, hogy rendben vagyunk-e katasztrófák elleni védelem vonatkozásában (csőtörés, tűzkár). Ellenőrizzük rendelkezünk-e biztosítással ezekre a kockázatokra és kockázatelemzésünkben számoltunk-e ezekkel.
24. Nézzük meg szervertermünk, hogy áll? Páratartalmat, hőmérsékletet tudjuk ellenőrizni?
25. Meg kell néznünk a személyi biztonság aktuális állapotát is. Hogyan történik a munkavállaló alkalmazása? Van-e kiléptetési folyamatunk és az milyen? A vagyontárgyak visszavétele, jogok megvonása hogyan történik? Gyűjtsünk evidenciát.
    
26. Nézzük meg IT-val közösen a tűzfalak határvédelmi eszközök beállítását. Gondoljunk a távoli hozzáférések szabályozására (VPN jogok, kiemelt felhasználók tevékenysége, szolgáltató kezelése távoli hozzáférésnél).
27. Ellenőrizzük a vírusvédelmi szoftver állapotát, beállításai operációs rendszertől függetlenül.
28. Hogy kezeljük a vírusvédelmi rendszer vagy a határvédelmi rendszer riasztásait? Ki kap értesítést? Mit reagál? Van értesítési lánc?
29. Szedjük össze az ellenőrzéseinket! Mit ellenőriztünk? Mikor?
30. Ha valamit nem tudunk megoldani, szerezzünk be kockázatvállalási nyilatkozatot a vezetőktől. Bármi, ami problémás, enyhíthetjük a bajt, ha a menedzsment tud róla és ezt írásba is adja.

Ha valamit nem tudunk megoldani, szerezzünk be kockázatvállalási nyilatkozatot a vezetőktől. Bármi, ami problémás, enyhíthetjük a bajt, ha a menedzsment tud róla és ezt írásba is adja.

Az audit maga (eljött a várva várt nap)

Az audit maga általában egy vagy esetleg két napos szokott lenni (szervezet méretétől függően). Ha elérkezett az audit időpontja, azt megelőző nap pihenjük ki magunkat és próbáljuk a legjobb formánkat hozni. Ha a 30-as checklist-et nagyjából végrehajtottuk nagy meglepetés már nem érhet bennünket. Informatikai biztonságunk állapotáról hiteles és jó képet tudunk mutatni.

Egy-két jó tanács:

• Várjuk az auditorokat, fogadjuk őket, ezzel időt spórolhatunk.
• Legyen minden előkészítve [a szükséges okmányok, evidenciák, papírok, telefonszámok (ha mi nem tudunk egy választ, akkor tudjuk, hogy ki tudhatja és azt az embert tudjuk is elérni!)].
• Csak az auditor által feltett kérdésre válaszoljunk tömören, érthetően, és csak olyan választ adjunk amire van evidenciánk. A válaszunkba ne keverjünk bele olyan dolgokat, amikre esetleg rákérdezhet és nem tudjuk a választ.
• Az auditra legyen egy helyiségünk, hogy nyugodtan menjen le a vizsgálat.
• Ne kötekedjünk az auditorral, fogadjuk el, hogy a dolgát végzi, segítsük a munkáját.
• Ha végeztünk, kérdezzük meg lát-e olyat, ami akadályozza azt, hogy ez az audit sikeres jelentéssel záruljon.
• Az audit jelentés nem rögtön készül el. Ha úgy érezzük, tudunk valamit pótolni rövid időn belül, érdeklődjünk, hogy megtehetjük-e ezt.
• A végén köszönjük meg a munkáját és a konstruktív hozzáállást! Higgyük el, az auditor is ember. 😊

Mint látható itt már nem írtunk konkrét szakmai feladatokat, mert az audit napja nem erről szól. Ez már kommunikáció része, adjuk el magunkat, legyünk magabiztosak és felkészültek.

Nem-megfelelősségek javítása

Ez már egy kellemesebb történet, hiszen megkaptuk az audit jegyzőkönyvet, nagy valószínűséggel sikerült a vizsgálat. Nincs más dolgunk, mint cselekvési tervet készíteni a nem-megfelelősségekre és kockázatokra; amit az audit feltárt és mindezt a menedzsment felé prezentáljuk. Vegyünk egy nagy lélegzetet és gondoljuk át, mit csináltunk jól és mit fogunk jövőre másképp csinálni.

Záró gondolatok

Természetes, hogy a dörzsölt; minden audit tapasztalattal rendelkező kollégák (a kiberbiztonsághoz mindenki ért, ahogy a GDPR-hoz is) találhatnak hiányosságot jelen cikkben. A nagyobb lélegzetvételű témákról külön bejegyzéseket is írunk; de fontosnak tartjuk megjegyezni, hogy ez azoknak készült első sorban, akik nem csináltak még ilyet; vagy rutintalanok még; esetleg bonyolultnak találják a szakirodalmat; nincs kihez forduljanak segítségért; vagy csak egy gyorsan felhasználható mankót keresnek, hogy felkészüljenek és egy jobb képet nyújthassanak a Szervezet IT biztonságáról. Nekünk pályánk kezdetén sokat segített volna egy lista a felkészülésbe. Nem lettünk volna úgy elveszve, amikor megérkezett a 465 kérdéses auditori kérdőív; hiszen magabiztosabban vágtunk volna bele a felkészülési időszakba is.

A legfontosabb megállapítást a végére tartogattuk. Ha ezekre a témákra év közben is figyelünk; próbáljuk folyamatosan monitorozni a biztonsági környezetet, akkor nagyban megkönnyíthetjük az életünket az audit előtti időszakban. Ha úgy érzed még ez sem elég és segítség kell, fordulj hozzánk bizalommal.

E bizalom megteremtéséhez tudunk segítséget nyújtani szolgáltatásainkkal, akár IT biztonsági auditról vagy felkészítésről; esetleg információbiztonsági felelős pozíció ellátásáról legyen szó.