Virtuális CISO · Intézkedési terv
Minden hiányosságból feladat lesz: felelőssel, határidővel és bizonyítékkal
Az a hiányelemzés, amelyik jelentéssel ér véget, nem megoldotta a problémát, csak arrébb tette. Nálunk kidolgozott terv lesz belőle: minden megállapításból olyan feladat, amit valaki fel tud venni és el tud végezni, olyan ütemezésben, amennyit a szervezet egy negyedévben tényleg elbír, és addig követve, amíg a bizonyíték rá nem kerül.
A feladat módszer, nem egy sor egy teendőlistán
A „vezesse be a hozzáférés-kezelést” megállapítás, nem utasítás. Annak, akinek lépnie kell, azt mondja meg, miben hibázott, nem azt, hogy mit csináljon — így marad egy intézkedési terv érintetlenül egy negyedévig, majd írják újra. Itt minden feladat azzal kezdődik, mire való az adott kontroll, utána pedig számozott eljárást ad a bevezetéséhez: úgy megírva, hogy át lehessen adni, ne értelmezni kelljen.
Az általános lépések alatt ott van az, amit nem lehet generálni: a vCISO jegyzete az Önök környezetéről. Melyik rendszerükre vonatkozik, mi van már meg belőle részben, mi hangzott el a workshopon, és mi a következő lépés. Ez a jegyzet a különbség egy módszer és egy olyan sablon között, amin csak a logójuk van.
- Mire való a kontroll — még azelőtt, hogy bármit mondana a teendőről
- Számozott eljárás, hogy senkinek ne kelljen keretrendszeri előírást munkára fordítania
- Prioritás kritikustól alacsonyig, és becslés a ráfordításra
- A vCISO jegyzete ott, ahol az általános lépéseken változtatni kell az Önök környezetéhez
Egy része a miénk, egy része soha nem lesz az
A governance-rész a miénk, és nem házi feladatként kerül vissza Önökhöz: a szabályzatok, az eljárásrendek, a mögöttük álló nyilvántartások, a bizonyítéktár, az auditra való felkészülés. Ami viszont éles rendszert módosít, az nem a miénk, mert azt a változtatást olyannak kell elvégeznie, akinek hozzáférése van hozzá — nekünk pedig szándékosan nincs.
A határvonal feladatonként húzódik, és a hónap kezdete előtt húzzuk meg, nem félúton derül ki. Ahol a munka külső informatikai szolgáltatóhoz tartozik, ő a saját szervizdeskjében lévő jegyből dolgozhat, amely az itteni feladathoz van kötve, így ahhoz, hogy a terv része legyen, nem kell valaki más portáljában élnie. Hét elterjedt ügyfélszolgálati és jegykezelő rendszerhez érhető el beépített, kétirányú integráció; minden más a portál saját API-ján keresztül megy, ami fejlesztési munka, nem beállítás.
- Minden feladatnak megnevezett felelőse van, és az Ön saját munkatársainak is lehet fiókja — a számuk nincs korlátozva
- A szabályzat-, eljárásrend-, nyilvántartás- és bizonyítékmunka a miénk, és el is végezzük
- A konfigurációs változtatás azé, akinél a jogosultság van; mi leírjuk, ütemezzük és végigkísérjük
- A külső szolgáltató a saját szervizdeskjéből dolgozhat, az állapot, a megjegyzések és a bizonyítékok pedig visszakerülnek a feladatra
Rövid-, közép- és hosszú táv — valódi határidőkkel azon, aminek először kell mozdulnia
Kétszáz feladat súlyosság szerint rendezve nem terv, csak ugyanaz a lista jobb rendezéssel. Az ütemterv három időtávra osztja a munkát, ahhoz mérten, amennyit a csapatuk és a keretük egy év alatt elbír.
- 01
Rövid táv
Egy hónaptól egy negyedévig. A kritikus megállapítások, amivel egy auditor kezdeni szokott, és azok a szerkezeti lépések, amelyek most olcsók, később drágák. Ezeken van határidő, és a heti egyeztetést ezekhez mérjük.
- 02
Középtáv
Egy negyedévtől egy évig. Ami költségkeretet, beszerzési ciklust vagy karbantartási ablakot igényel — és ami csak akkor értelmes, ha a rövid távú feladatok már alatta vannak.
- 03
Hosszú táv
Egy éven túl. Képesség, nem javítás: azok a tételek, amelyekhez szervezeti változás, platformváltás vagy létszámdöntés kell, mielőtt egyáltalán rendesen tervezhetők lennének.
Hat állapot, és közülük csak egy mozdítja a pontszámot
Nem kezdődött el, folyamatban, ellenőrzés alatt, kész, elhalasztva, vagy nem releváns. Az utolsó három között van az érdekes különbség, mert ott dől el, hogy a terv őszinte marad-e, vagy csendben megszűnik tervnek lenni.
A validált megfelelési pontszámot csak a „Kész” állapotú feladat módosítja. A „Folyamatban” állapotból csak ellenőrzés után kerülhet ebbe az állapotba: a vCISO megnézi a munkát és a mögötte lévő bizonyítékot, mielőtt az bármit érne.
Az elhalasztva azt jelenti, hogy a kockázatot elfogadták ahelyett, hogy megszüntették volna. A feladat nem kér több figyelmet, maga a kockázat viszont a kockázati nyilvántartásban marad, és továbbra is megjelenik a szervezet kockázati kitettségében — a halasztás döntés, nem eltűnés. A nem releváns valóban hatókörön kívülit jelent, az indoklás pedig rákerül a feladatra, mert a magyarázat nélküli „nem releváns” az, amibe egy auditor a legkönnyebben beleköt.
A bizonyíték a feladaton van, nem egy mappában, amit valakinek meg kell találnia
Egy auditor ritkán azt kérdezi, van-e szabályzatuk. Azt kérdezi, meg tudják-e mutatni, hogy a dolog megtörtént — a megtartott felülvizsgálatot, a lefuttatott tesztet, a jóváhagyott dokumentumot — és mikor. Ezért a bizonyíték ahhoz a feladathoz tartozik, amelyik létrehozta: a fájl csatolva, mellette a dátum, amikor megérkezett.
Ebből következik, hogy az audit kezdetekor nincs mit összegyűjteni. A nyom a munka melléktermékeként keletkezik, nem egy postafiókokban töltött hétből, és minden feladat azt is magával viszi, mire volt: melyik szabályzatot szolgálja, melyik keretrendszernek felel meg, és melyik kockázatot viszi lejjebb.
A jogosultság-felülvizsgálat és a visszaállítási teszt ütemezve van, nem fejben
Amit egy keretrendszer kér, annak jó része nem egyszeri változtatás. A jogosultságokat felül kell vizsgálni, a mentéseket vissza kell állítani annak bizonyítására, hogy visszaállíthatók, a szabályzatokat újra jóvá kell hagyni, a beszállítókat újra kell értékelni — és mindegyik olyan kontroll, amelyik abban a pillanatban elbukik, amikor elmegy az, aki eddig fejben tartotta.
Ezért ismétlődő feladatként vannak beállítva, saját ritmussal, a bizonyíték pedig ciklusról ciklusra gyűlik, nem az audit előtti héten. Egyébként is ez az egyetlen változat, amelyik egy értékelőnek működő kontrollt mutat, nem olyat, ami egyszer létezett.
A késznek jelölt feladat, amit egy vizsgálat még mindig jelez, visszakerül ellenőrzésre
A kész jelölés állítás, és ami kívülről látszik, arra az állítás ellenőrizhető. A vizsgálatok megállapításait visszaolvassuk a feladatlistára, és az a megállapítás, amelyik a feladat lezárása után is megvan, visszahozza a feladatot ellenőrzésre — ahelyett, hogy egy külön jelentésben ülne, amit senki nem vet össze a tervvel.
Kis mechanizmus egy drága hibatípus ellen: a változtatás, ami az egyik szerveren megtörtént, a másikon nem; a beállítás, ami a következő telepítésnél visszaállt; a kivétel, amit valaki két éve egy hétre vett fel.
Gyakran ismételt kérdések
A biztonsági és IT-vezetőktől leggyakrabban kapott kérdések.
Nem találja, amit keres? Kérdezzen tőlünk közvetlenül
Nem, és az ütemterv éppen az a hely, ahol ez le van írva, nem pedig feltételezzük. Mi adjuk a feladatot, az eljárást és az ütemezést; magát a változtatást az végzi el, akinél a rendszerhez tartozó jogosultság van — az Önök informatikai csapata vagy a szolgáltatójuk. Minden, ami irányítás és nem konfiguráció, a miénk, és el is készítjük, nem visszaadjuk: a dokumentumok, a nyilvántartások, a bizonyítéktár, a próbaaudit, az emberek felkészítése az auditinterjúkra. Amikor egy feladat készre vált, előtte átnézzük — és ez az átnézés tartja őszintén a két oldalt egymással szemben.
Nem feltétlenül. A feladat leképezhető jegyként a szolgáltató saját szervizdeskjébe, és a jegy az itteni feladathoz kötve marad, így ott dolgozik, ahol eddig is — a kapcsolat pedig oda-vissza működik: a jegyen rögzített állapotváltás, megjegyzés vagy bizonyítékfájl visszakerül a feladatra. Hét ügyfélszolgálati és jegykezelő rendszerhez van beépített integráció, és ez a legtöbb szolgáltatót lefedi, akivel találkozunk: ConnectWise, ServiceNow, Autotask, HaloPSA, Kaseya, NinjaOne és Atera. Minden más a portál saját API-ján keresztül köthető be, ami fejlesztési munka, nem beállítás. Két dolgot érdemes tudni mindkét esetben: a szinkron ütemezetten fut, nem a változás pillanatában, tehát a tisztességes elvárás az „egy órán belül”, nem a „valós idejű” — és ahol senki nem akar semmit bekötni, a feladat akkor is eljut hozzájuk, e-mailen és a heti egyeztetésen.
Döntésnek — feltéve, hogy az volt. A feladat elhalasztása ugyanaz a cselekedet, mint az alatta lévő kockázat elfogadása: indoklás, név és dátum tartozik hozzá, a kockázat pedig a valós értékén marad a nyilvántartásban, nem tűnik el csendben a képből. Egy auditor ebből vezetői döntést olvas ki, amivel egyetérthet vagy nem — az beszélgetés. Amit keres, az a másik változat: a feladat, amelyik indoklás nélkül elhallgatott, vagy a megállapítás, amelyik „nem releváns” jelzést kapott, és utána nem áll semmi. Ez a két legolcsóbb megállapítás bármelyik auditon, és mindkettő elkerülhető nagyjából egy-egy perc alatt, akkor és ott.
Egy év alatt senki nem csinálja végig, és az a terv, amelyik ezt feltételezi, nem terv. Két dolog teszi kezelhetővé a számot. Először is bármelyik kiinduló lista nagy része nem vonatkozik Önökre — a kártyás fizetések elfogadásához kapcsolódó kontrollok, ha nem fogadnak kártyát; a fejlesztésbiztonsági kontrollok, ha nem írnak szoftvert —, és ezek kijelölése, indoklással együtt, valódi munka, ami az első hetekben megtörténik. Másodszor: ami marad, az nem felsorolva van, hanem rendezve. A kritikus és rövid távú feladatokon határidő van, a többi időtávokban áll, amelyeket negyedévente átnéznek ahhoz képest, ami ténylegesen mozdult. A vezetőség soha nem a listát nézi át. Hanem a következő negyedév döntéseit.
Hol tart most, és mi következik
Kockázati döntések
Mit javítunk, mit fogad el, és kinek a neve áll a döntés mellett.
Vizsgálatok
A külső támadási felület és a belső címtár biztonsági állapotának rendszeres vizsgálata.
Üzletmenet-folytonosság
Kritikus folyamatok, megengedhető kiesési idők és a kiesés becsült havi vesztesége.
Készen áll a kezdésre?
Dolgozzon együtt a Spirity Enterprise-zal, hogy a szervezetéhez illő biztonsági és IT-megoldások valósuljanak meg.