Váltsa működő védelemre a biztonsági terveket

Négyféle munkát, és ezek nem egymás változatai. Biztonsági platform teljes körű bevezetése — felépítés az Önök saját bérleményében, a naplóforrások bekötése, a detektálási szabályok és a válaszlépés-playbookok megírása, tesztelés, majd működő rendszer átadása. Konfigurációfelmérés és hardening — szerverek, kliensek és hálózati eszközök mérése egy publikált követelményrendszerhez, rangsorolt listával arról, mit kell megváltoztatni. Tűzfal- és hálózati munka — szabályrendszer felülvizsgálata, az alatta lévő zónamodell újratervezése, és az a változáskezelési folyamat, amely megakadályozza, hogy megint elromoljon. És mindezek köré a működési modell: ki üzemelteti utána, milyen felelősségekkel, mi alapján mérve. Hogy melyikre van szükségük, teljes egészében attól függ, mijük van már — ezért az első lépés felmérés, nem árajánlat.

A mélység az IBM és a Microsoft: QRadar és Sentinel, beleértve azokat a részeket is, amelyeket ki szoktak hagyni — egyedi adatcsatlakozók és parserek olyan forrásokhoz, amelyekhez nincs natív integráció; az Önök környezetére írt detektálási tartalom a gyári alapértelmezések helyett; automatizált playbookok; és a betöltési költség kordában tartása. Ezen túl dolgozunk Palo Alto, Fortinet és Sophos eszközökkel, általános tűzfalas munkával — például szabályrendszer-konszolidációval —, valamint Windows és Linux szerverek CIS-alapú hardeningjével. Mondják meg, mit üzemeltetnek valójában, és megmondjuk őszintén, csináltuk-e már. Néha nem — és mindkettőnknek olcsóbb ez az első megbeszélésen kiderülnie, mint a harmadik héten.

Mindkettő — és a határ még a kezdés előtt, írásban van meghúzva, mert ez két különböző vásárlás. A bevezetendő platformon belül mi építünk és konfigurálunk, távolról, az Önök saját előfizetésében. Amit nem teszünk: nem nyúlunk bele a többi éles rendszerükbe. Az ügynökök telepítése a szervereken, a naplótovábbítók beállítása, a naplózás bekapcsolása harmadik felek rendszerein és a gyűjtéshez szükséges tűzfalszabályok megnyitása az Önök csapatának a feladata — a mi útmutatásunkkal és támogatásunkkal. Bizonyos lépéseket nem is tudunk megtenni: azokat, amelyekhez globális rendszergazdai vagy azzal egyenértékű jogosultság kell — ezeket előre jelezzük, hogy az Önök megfelelő jogosultságú kollégája elvégezhesse. A hardening- és tűzfalmunkánál a szétválasztás még élesebb: a szállítandó a felmérés és a javaslat, a végrehajtás az Önök szakembereié, és a javításban csak akkor veszünk részt, ha kérik.

Háromféle alak. Egyetlen platform bevezetése egy már meglévő bérleménybe fix áras, nagyjából három hét: egy hét felmérés és tervezés, egy hét építés és integráció, egy hét tesztelés, hangolás és átadás. Egy teljes SIEM- és biztonsági műveleti építés ráfordítás alapú, szakértői szintenként becsülve, és hónapokban mérhető — az Önök saját munkatársainak óráival együtt megbecsülve, mert általában az a szám szokott meglepetést okozni. Ahol hardver is van, ott hosszabb: az eszközök beszerzési ideje uralja az ütemtervet. Ami következetesen az áron kívül esik: a felhőfogyasztás és a betöltési díjak, a harmadik felek licencei, és az eredmény üzemeltetése az átadás után.

Bevezetésnél működő, éles üzemre készre jelentett rendszert, a hozzá tartozó dokumentációt, és egy átadó alkalmat azoknak, akik üzemeltetni fogják. Hardeningnél szándékosan dokumentumokat: értékelési jelentést, pontozott táblázatot minden eszközről minden kontrollcsoport szerint, a megállapítások mögötti követelményrészleteket, javasolt alapkonfigurációt, valamint egy rövid ellenőrzőlistát, amellyel a rendszerpark maradékát maguk is felmérhetik anélkül, hogy a teljes vizsgálatot meg kellene ismételni. Abból, hogy ezekből megváltozott konfiguráció legyen, külön döntés — és jobban szeretjük, ha ezt tudatosan hozzák meg, mint ha csendben egy projektbe csomagolva találják.

Igen — és ennek a munkának az őszinte változata a szabályrendszert tünetként kezeli, nem betegségként. A szabályok átnézése és konszolidálása a látható rész. Alatta ott van a zónamodell, amit a szabályoknak ki kellene fejezniük, és a változáskezelési folyamat, amely eldönti, mi kerül be jövő héten. Ezt a hármat együtt csináltuk már: átállás lapos modellről rétegzett zónákra, dokumentált és jóváhagyott forgalmi mátrixszal — így egy szabály egy modellhez mérhető, nem pedig ahhoz, amire már senki nem emlékszik. E nélkül konszolidálva néhány év múlva egy rendezettebb szabályrendszerük lesz, amit senki nem ért: vagyis ott, ahol most.

Azt, hogy megmérjük, mire van ténylegesen konfigurálva egy eszköz — egy publikált követelményrendszerhez képest, eszközről eszközre —, és pontozzuk az eltéréseket. Három mérce együtt: az adott termék és verzió CIS benchmarkja, az Önökre vonatkozó szabályozás, valamint a gyártói és a saját ajánlásaink — kereszthivatkozva, hogy látható legyen, melyik megállapítás melyik követelményt szolgálja, ne bizalmi alapon kelljen elfogadni. A kontrollcsoportok pirosan, sárgán vagy zölden jönnek vissza, táblázattal arról, melyik eszköz hol áll; a piros az első kör, a sárga beszélgetés tárgya. Százalékos pontszámot is közlünk, de nem hagyjuk, hogy az vezérelje a besorolást — egy százalék az egyik kontrollcsoportban nem ugyanazt jelenti, mint a másikban. És egy első kör célja nem az, hogy mindent a maximumra hardeneljünk, hanem hogy a konfigurációk egységesek legyenek: az egységesség az, amitől minden későbbi változtatás gyors és biztonságos lesz.

Ez a jó kérdés — és a következő történik. Azt a megállapítást, amely egyszerre sok eszközön jelenik meg, lehetséges fals pozitívként vagy tömeges félrekonfigurálásként kezeljük, és ellenőrizzük, mielőtt bárki cselekedne. A valós töréskockázatú változtatásokat inkább elhalasztjuk, mint javasoljuk — a kimenő forgalom korlátozása a host tűzfalakon például csak ott érdemes, ahol a forgalom valóban ismert, és ezt inkább kimondjuk, mint hogy egy listán hagyjuk Önöknek felfedezésre. A platformmunka tesztkörnyezetben épül és ott is teszteljük az éles indulás előtt, utána pedig stabilizációs időszak jön, amikor a figyelem magasan marad a hangolásra és a hibákra. Tűzfalváltozásnál az igénylő teszteli a változtatást, és az a szabály, amelyen még él a forgalom, nem kerül törlésre — jóváhagyással sem —, amíg azt a forgalmat át nem terelték vagy le nem állították. Amit egy weboldalon nem fogunk ígérni, az az általános visszaállíthatóság: hogy mitől visszafordítható egy változtatás, eszközönként és rendszerenként más, és ez az Önök projektjének a tervébe való, nem egy marketingmondatba.

Az átadás valódi végpont, a folytatás pedig külön vásárlás — ezt inkább kimondjuk, mint hogy Önökre hagyjuk a feltételezést. Egy bevezetés az éles indulásnál ér véget, a dokumentációval és azoknak szóló képzéssel, akik üzemeltetni fogják: miattuk van a képzés. A nagyobb programokban ez elé még beékelődik egy néhány hetes stabilizációs szakasz, ahol a szabályokat és a playbookokat valós forgalomra hangoljuk, és a hibákat lezárjuk. Ha nem az építés, hanem az üzemeltetés kell, az a menedzselt észlelés és reagálás — és szándékosan külön szerződés, nem véletlenül.

Mert a gyártó csapata kiváló a saját termékében, és szerkezetileg nem érdekelt abban, hogy az illeszkedik-e a rendszerparkjuk többi részéhez. Írtunk már olyan összehasonlító elemzést, amely olyan termék ellen érvelt, amelyet el is adhattunk volna — ilyen dokumentumot gyártó nem ír. És az eszköz körüli munka ugyanakkora súlyt kap, mint maga az eszköz: a működési modell, a felelősségek, a változáskezelési folyamat, a zónaszabályzat, a ticketing-integráció. Az a biztonsági platform, amelyből sziget lesz az architektúra része helyett, nem lett igazán bevezetve — bármit mond a projekt státusza. Csapatunk jó része két évtizedet töltött ennek a munkának az ügyféloldalán: onnan jön az a hajlam, hogy működő állapotban adjunk át valamit, ne látványosan.