SIEM a SOC pro střední firmu: kdo řeší výstrahy po zavírací době?

01SIEM je technologie, SOC zajišťuje bezpečnostní provoz

SIEM sbírá bezpečnostně významné události, pomáhá je propojovat, vyhledávat a vyhodnocovat. SOC je bezpečnostní dohled a lidé s postupy pro prověření a řešení podezření. Firma může mít vlastní tým, externí službu nebo kombinaci. Nákup technologie sám nevytvoří zastupitelnost ani odpovědnost za zásah.

Příkladem technologie je Microsoft Sentinel, který nabízí konektory, analýzu, spojování výstrah do incidentů a navazující automatizaci. Přínos konkrétního nástroje závisí na zdrojích dat, nastavení a způsobu používání. Název produktu neprokazuje pokrytí celé firmy.

Antivirová ochrana či EDR sleduje jiné části prostředí než samotný přehled přihlášení do cloudu. SIEM je může propojit, ale musí dostávat potřebné události. Při nabídce služby si proto nechte vysvětlit, co přesně znamená monitoring, prověření, aktivní reakce a pomoc s obnovou.

Stejně ověřte pracovní dobu. Výraz SOC automaticky nezaručuje nepřetržitou lidskou obsluhu, zásah do vašich systémů ani řešení každého typu incidentu. Potřebujete konkrétní rozsah služby, kontakty, časy a pravomoci.

02Vyberte scénáře podle dopadu na firmu

Začněte tím, co by firmu skutečně poškodilo: převzetí e-mailového účtu, zneužití správce, únik zákaznických údajů nebo zastavení provozu. Ke scénáři přiřaďte dotčené systémy, dostupné události a možnou reakci. Seznam všeho, co umí konektor načíst, není náhradou za tento výběr.

• Převzetí účtu: podezřelé přihlášení, změna metody ověření a neobvyklá práce s poštou.
• Zneužití správce: nové oprávnění, zásah do bezpečnostního nastavení nebo použití nouzového účtu.
• Podezřelý export: neobvyklé množství dat, kontext účtu a cílový systém.
• Ohrožené zařízení: nález ochrany koncového bodu, aktivita uživatele a další spojení.
• Výpadek dohledu: chybějící události, nefunkční agent nebo vypršelý přístup konektoru.

Databáze MITRE ATT&CK popisuje techniky chování útočníků a může pomoci uspořádat scénáře. Vybarvená technika v přehledu ale ještě neznamená ověřenou detekci. Pro každý důležitý scénář potřebujete prokázat, že jej vaše data a pravidla zachytí v očekávaném kontextu.

U exportu zákazníků například zvažte běžné měsíční zpracování pro účetnictví. Bez znalosti této práce může monitoring vyvolávat plané výstrahy. Výjimku však omezte na konkrétní účel a účet. Plošné ignorování všech administrátorů by odstranilo část potřebného dohledu.

03Připojte správné události a hlídejte jejich kvalitu

Obvyklý začátek tvoří správa identit, e-mail, koncová zařízení, vzdálený přístup a kritická aplikace. U vlastní aplikace přidejte události, které infrastruktura nezná: změnu role, export dat, odmítnutí oprávnění nebo zásah do důležité konfigurace. Pro tento návrh slouží OWASP Logging Cheat Sheet.

Událost má umožnit zjistit kdy, kdo, co, kde a s jakým výsledkem provedl. Sjednoťte čas a identifikátory. Pokud jedna služba uživatele vede e-mailem a druhá náhodným číslem bez vazby, analýza bude obtížnější. U přeposílaných dat sledujte i zpoždění mezi událostí a jejím přijetím.

Do bezpečnostních logů běžně nepatří hesla, přístupové tokeny ani celé citlivé dokumenty. Vyberte potřebný kontext a omezte přístup k záznamům. Monitoring jinak může vytvořit další úložiště citlivých informací, které firma neumí spravovat.

Otestujte také ticho. Konektor může po změně oprávnění přestat posílat data a prázdný přehled bude působit klidně. Dokumentace monitoringu konektorů Sentinel ukazuje kontrolu stavu, posledních událostí a odchylek sběru. Podpora konkrétního mechanismu se liší podle konektoru.

Kvalitu záznamů zahrňte do kontroly bezpečnosti aplikace před spuštěním. Nová funkce nebo změna identity může ovlivnit i pravidla monitoringu. Při předání vývoje proto předejte popis událostí a test, který ověří jejich přijetí.

04Rozhodněte, kdo dohled skutečně provozuje

Pro firmu bez vlastních bezpečnostních analytiků může být externí dohled vhodný. Pořád však potřebuje interního partnera, který zná aplikace a umí zjistit, zda je aktivita oprávněná. Dodavatel nemusí vědět, že právě probíhá schválená migrace nebo mimořádná práce účetních.

Ve smlouvě odlište přijetí výstrahy, první prověření, informování firmy a provedení zásahu. Když je slíbeno „rychlé řešení“, požádejte o konkrétní význam. Reakční doba na zprávu a doba obnovení služby jsou různé věci.

05Od výstrahy k zásahu vede předem dohodnutý postup

Výstraha potřebuje prioritu, vlastníka a další krok. Analytik ověří souvislosti, určí možné dopady a rozhodne o eskalaci. Potvrzený incident pak musí mít člověka, který koordinuje technické zásahy, provoz, komunikaci a dokumentaci.

Současná doporučení NIST k reakci na incidenty propojují přípravu, detekci, reakci a obnovu s řízením rizik. Prakticky proto připravte postup už před první krizí. Seznam telefonů nestačí, pokud nikdo neví, kdo smí vypnout důležitou službu.

• Podezřelý účet: kdo ověří uživatele, pozastaví přístup a prověří další aktivitu.
• Ohrožené zařízení: kdo může omezit jeho komunikaci a jak zachová potřebné podklady.
• Únik dat: kdo zjistí rozsah, zapojí odpovědné osoby a posoudí oznamovací povinnosti.
• Obnova: kdo rozhodne, že je bezpečné vrátit službu, a ověří její funkčnost.

Automatizaci nejdřív použijte pro kroky s předvídatelným dopadem, například založení případu a doplnění kontextu. Blokování účtu nebo zařízení může zastavit pracovní postup. Před zapnutím ověřte podmínky, výjimky, oprávnění a způsob návratu.

Dohodněte náhradní komunikaci pro případ kompromitovaného e-mailu. Útočník v poštovní schránce může sledovat domluvu o zásahu. Kontakty, telefonní čísla a alternativní kanál musejí být dostupné i tehdy, když běžné pracovní účty nefungují.

06Náklady a uchovávání dat potřebují vlastní pravidla

Rozpočet zahrnuje sběr, uložení, vyhledávání, licence, práci analytiků a údržbu integrací. V cloudové službě může mít vliv objem a typ načítaných dat. Microsoft popisuje účtování Sentinel podle zvolené konfigurace. Nezaměňujte počáteční cenu s nákladem úplného provozu.

V pilotu změřte skutečný objem zdrojů a případné špičky. Do nabídky přidejte, co se stane při překročení předpokladu, připojení nové aplikace nebo nutnosti delšího vyšetřování. Nesnižujte náklady slepým vypnutím záznamů, které jsou potřebné pro prioritní scénáře.

Dobu uchování navrhněte podle účelu, potřebného vyšetření a příslušných povinností. Určete, kdo může záznamy číst, exportovat a odstraňovat. U externího dodavatele prověřte umístění dat, další příjemce a pravidla práce s osobními údaji. Monitoring není oprávnění sledovat zaměstnance bez hranic.

Zabezpečení infrastruktury a dohledu doplňuje ochranu serveru a cloudu. Zkontrolujte účty konektorů, přístup analytiků i integritu záznamů. Široké administrátorské oprávnění pro sběr dat nepřidělujte jen z pohodlnosti, pokud stačí užší přístup.

07Pilot zakončete testem, ne zapnutým konektorem

1. Určete rizika a vlastníky. Vyberte důležité služby, scénáře a odpovědnost za zásah.
2. Připojte potřebné události. Ověřte obsah, čas, zpoždění a signalizaci výpadku sběru.
3. Nacvičte prověření a reakci. Bezpečně vytvořte dohodnuté testovací události a sledujte celý postup.
4. Vyhodnoťte provoz a rozpočet. Upravte pravidla, kontakty a rozsah podle zjištěných nedostatků.

Sledujte, zda se testovaný případ zachytil, kolik času potřebovalo prověření a zda zásah provedl správný člověk. U planých výstrah zjišťujte opakující se příčinu. Samotný pokles jejich počtu nemusí být zlepšení, pokud jste příliš široce vypnuli detekci.

Přehled pro vedení má ukazovat pokrytí prioritních scénářů, významné případy, nefunkční zdroje a otevřené nápravné kroky. Pokud report obsahuje jen celkový počet událostí, firma neví, zda dohled pomohl snížit konkrétní riziko.

08Časté otázky k SIEM a SOC