Sdílet prostřednictvím


Krok 5. Vývoj a testování případů použití

Platí pro:

  • Microsoft Defender XDR

Doporučené metody nasazení Microsoft Defender XDR ve službě Security Operations Center (SOC) závisí na aktuální sadě nástrojů, procesů a dovedností týmu SOC. Udržování kybernetické hygieny napříč platformami může být náročné kvůli obrovskému množství dat pocházejících z desítek, ne-li stovek zdrojů zabezpečení.

Nástroje zabezpečení spolu vzájemně souvisejí. Zapnutí jedné funkce v bezpečnostní technologii nebo změna procesu může zase narušit jinou funkci. Z tohoto důvodu Microsoft doporučuje, aby váš tým SOC formalizoval metodu pro definování a stanovení priorit případů použití. Případy použití pomáhají definovat požadavky a testovací procesy pro operace SOC napříč různými týmy. Vytvoří metodiku pro zachycení metrik, která určí, jestli jsou správné role a kombinace úkolů sladěné se správným týmem se správnou sadou dovedností.

Vývoj a formalizace procesu použití

SoC by měl definovat vysoký standard a proces pro vývoj případů použití, který by byl regulován týmem soc pro dohled. Tým soc pro dohled by měl spolupracovat s vašimi obchodními, IT, právními, personálními a dalšími skupinami, aby upřednostnily případy použití soc, které se nakonec dostanou do runbooků a playbooků týmu SOC. Priorita případů použití vychází z cílů, jako je dodržování předpisů nebo ochrana osobních údajů.

Mezi aktivity dohledu SOC související s vývojem případů použití patří:

  • Požadavky
  • Personální nebo školicí potřeby
  • Softwarové licence
  • Dodavatel uzavíruje smlouvy
  • Správa plánu
  • Správa registru případů použití
  • Údržba/aktualizace šablon

Pokud chcete usnadnit vytváření runbooků a playbooků, vytvořte rozhodovací strom případů použití. Tento obrázek ukazuje příklad.

Proces rozhodování o případu použití

Po definování a schválení standardu případů použití na vysoké úrovni je dalším krokem vytvoření a otestování skutečného případu použití. V následujících částech se jako příklady používají scénáře kontroly útoků phishing a hrozeb a ohrožení zabezpečení.

Příklad použití 1: Nová varianta útoku phishing

Prvním krokem při vytváření případu použití je nastínit pracovní postup pomocí panelu scénáře. Tady je příklad základního scénáře pro nové oznámení o zneužití phishingu pro tým analýzy hrozeb.

Pracovní postup případu použití pro anti-phishing kampaň

Vyvolání pracovního postupu případu použití například 1

Po schválení panelu scénáře je dalším krokem vyvolání pracovního postupu případu použití. Tady je příklad procesu pro anti-phishing kampaň.

Podrobný pracovní postup případů použití pro anti-phishingovou kampaň

Příklad použití 2: Kontrola hrozeb a ohrožení zabezpečení

Dalším scénářem, ve kterém je možné použít případ použití, je kontrola hrozeb a ohrožení zabezpečení. V tomto příkladu soc vyžaduje, aby se hrozby a ohrožení zabezpečení napravovaly proti prostředkům prostřednictvím schválených procesů, které zahrnují kontrolu prostředků.

Tady je příklad scénáře vysoké úrovně pro Microsoft Defender Správa zranitelností prostředků.

Pracovní postup pro případ použití pro Threat and Vulnerability Management

Vyvolání pracovního postupu případu použití pro příklad 2

Tady je příklad procesu kontroly hrozeb a ohrožení zabezpečení.

Podrobný pracovní postup případu použití pro Threat and Vulnerability Management

Analýza výstupu případu použití a získaných poznatků

Po schválení a otestování případu použití by se měly identifikovat mezery mezi vašimi bezpečnostními týmy spolu s lidmi, procesy a Microsoft Defender XDR technologiemi. Microsoft Defender XDR technologie by měly být analyzovány, aby se zjistilo, jestli jsou schopné dosáhnout požadovaných výsledků. Ty je možné sledovat pomocí kontrolního seznamu nebo matice.

Například v příkladu anti-phishingového scénáře mohly týmy SOC provést zjištění v této tabulce.

Tým SOC Požadavek Lidé pro splnění požadavků Proces splnění požadavku Relevantní technologie Zjištěná mezera Protokol změn případů použití Výjimka (Y/N)
Tým analýzy hrozeb a analýzy Zdroje dat správně dodávají moduly analýzy hrozeb. Analytik/inženýr analýzy hrozeb Stanovené požadavky na datový kanál, triggery analýzy hrozeb ze schválených zdrojů Microsoft Defender for Identity, Microsoft Defender for Endpoint Tým analýzy hrozeb nepoužil automatizační skript k propojení rozhraní MICROSOFT DEFENDER XDR API s moduly pro analýzu hrozeb Přidání Microsoft Defender XDR jako zdrojů dat do modulů hrozeb

Aktualizace runbooku případů použití

N
Monitorovací tým Zdroje dat správně dodávají řídicí panely monitorování Analytik SOC vrstvy 1,2 – monitorování & výstrah Pracovní postup pro generování sestav Skóre zabezpečení & dodržování předpisů Centra dodržování předpisů Zkoumání výstrah v Microsoft Defender XDR

Monitorování skóre zabezpečení

Žádný mechanismus, který by analytici SOC mohli hlásit úspěšnou novou detekci variant phishingu za účelem zlepšení skóre zabezpečení

Zobrazení sestav zabezpečení e-mailu na portálu Microsoft Defender

Přidání procesu pro sledování vylepšení skóre zabezpečení do pracovních postupů generování sestav N
Technický tým a tým SecOps Aktualizace ovládacích prvků změn se provádějí v runbookech týmu SOC. Inženýr SOC vrstvy 2 Postup oznámení o změně řízení pro runbooky týmu SOC Schválené změny v bezpečnostních zařízeních Změny Microsoft Defender XDR připojení k technologii zabezpečení SOC vyžadují schválení. Přidání Microsoft Defender for Cloud Apps, Defender for Identity, Defender for Endpoint, Security & Compliance Center do runbooků SOC A

Týmy SOC navíc mohly provést zjištění uvedená v následující tabulce s ohledem na výše uvedený scénář správy ohrožení zabezpečení programu Defender:

Tým SOC Požadavek Lidé pro splnění požadavků Proces splnění požadavku Relevantní technologie Zjištěná mezera Protokol změn případů použití Výjimka (Y/N)
SoC – Dohled Všechny prostředky připojené ke schváleným sítím jsou identifikovány a zařazeny do kategorií. Dohled nad SOC, vlastníci BU, vlastníci aplikací, vlastníci IT prostředků atd. Centralizovaný systém správy prostředků pro zjišťování a výpis kategorií a atributů prostředků na základě rizika ServiceNow nebo jiné prostředky.

Inventář zařízení Microsoft 365
Bylo zjištěno pouze 70 % prostředků. Microsoft Defender XDR sledování nápravy platí pouze pro známé prostředky Vyspělé služby správy životního cyklu aktiv, které zajišťují Microsoft Defender XDR 100% pokrytí N
Engineering & SecOps Teams Velký dopad a kritická ohrožení zabezpečení v prostředcích se napravují podle zásad. Technici secOps, analytici SOC: Ohrožení zabezpečení & dodržování předpisů, inženýrství zabezpečení Definovaný proces kategorizace vysoce rizikových a kritických ohrožení zabezpečení řídicí panely Microsoft Defender Správa zranitelností Defender for Endpoint identifikoval zařízení s vysokým dopadem a vysokou výstrahou bez plánu nápravy nebo implementace aktivity doporučené Microsoftem Přidání pracovního postupu pro oznámení vlastníkům prostředků, když se vyžaduje nápravná aktivita do 30 dnů pro každou zásadu Implementujte systém lístků, který bude informovat vlastníky prostředků o nápravných krocích. N
Monitorování Teams Stav hrozeb a ohrožení zabezpečení se hlásí přes intranetový portál společnosti. Analytik SOC vrstvy 2 Automaticky generované sestavy z Microsoft Defender XDR zobrazující průběh nápravy prostředků Zkoumání výstrah v Microsoft Defender XDR

Monitorování skóre zabezpečení

Vlastníkům prostředků se nesdělují žádná zobrazení ani sestavy řídicích panelů týkající se stavu ohrožení zabezpečení a ohrožení zabezpečení prostředků. Create automatizační skript, který organizaci naplní stav vysoce rizikového a kritického ohrožení zabezpečení prostředků. N

V těchto ukázkových případech použití testování odhalilo několik mezer v požadavcích týmu SOC, které byly stanoveny jako směrné hodnoty pro odpovědnost jednotlivých týmů. Kontrolní seznam případů použití může být tak komplexní, jak je potřeba, aby byl tým SOC připravený na Microsoft Defender XDR integraci s novými nebo stávajícími požadavky SOC. Vzhledem k tomu, že se jedná o iterativní proces, proces vývoje případů použití a výstupní obsah případů použití přirozeně slouží k aktualizaci a vyzránutí runbooků SOC s využitím získaných poznatků.

Aktualizace produkčních runbooků a playbooků

Jakmile je testování případů použití opraveno pro všechny mezery, získané poznatky a metriky, které v nich byly shromážděny, lze začlenit do produkčních runbooků (provozních procesů) a playbooků (reakce na incidenty a eskalační postupy).

Údržbu runbooků a playbooků týmu SOC je možné uspořádat mnoha způsoby. Každý tým SOC může být zodpovědný za svůj vlastní nebo může existovat jedna centralizovaná verze pro všechny týmy, které budou sdílet v centrálním úložišti. Správa runbooků a playbooků pro jednotlivé organizace je založená na velikosti, sadě dovedností, rolích a oddělení povinností. Po aktualizaci runbooku by měl proběhnout proces aktualizace playbooku.

Použití standardní architektury pro eskalaci

Playbooky jsou kroky, které týmy SOC musí dodržet, když dojde ke skutečné události, a to na základě úspěšné integrace a testování případu použití. Proto je nezbytné, aby SOC postupoval formalizovaným přístupem k reakci na incidenty, jako je standard NIST Pro reakce na incidenty , který se stal jedním z předních standardů pro reakci na incidenty.

Proces reakce na incidenty NIST ve čtyřech krocích zahrnuje čtyři fáze:

  1. Příprava
  2. Detekce a analýza
  3. Uzavření, eradikace a zotavení
  4. Aktivita po incidentu

Příklad: Sledování aktivity přípravné fáze

Jedním ze základních základů playbooku eskalace je zajistit, aby nedošlo k malé nejednoznačnosti, pokud jde o to, co má každý tým SOC dělat před událostí nebo incidentem, během ní a po ní. Proto je vhodné vypsat podrobné pokyny.

Přípravná fáze může například zahrnovat matici úkolů typu if/then nebo XoR. V případě použití nové varianty útoku phishing by taková matice mohla vypadat takto:

Proč je eskalace oprávněná? Další krok
Výstraha v monitorování SOC ohodnocená jako kritická aktivovaná >500/hodina Přejděte na Playbook A, Oddíl 2, Aktivita 5 (s odkazem na oddíl playbooku).
ECommerce oznámil potenciální útok DDoS Vyvolání playbooku B-Section C, Aktivita 19 (s odkazem na oddíl playbooku)
Vedení nahlásilo podezřelý e-mail jako pokus o útok spear phishing Přejděte na Playbook 5, Oddíl 2, Aktivita 5 (s odkazem na oddíl playbooku).

Po dokončení přípravné fáze by organizace měly vyvolat zbývající fáze, jak je nastínil NIST:

  • Detekce a analýza
  • Uzavření, eradikace a zotavení
  • Aktivita po incidentu

Další krok

Krok 6. Identifikace úloh údržby SOC

Tip

Chcete se dozvědět více? Spojte se s komunitou zabezpečení společnosti Microsoft v naší technické komunitě: Technická komunita Microsoft Defender XDR.