Doporučení pro reakci na incidenty zabezpečení

Platí pro doporučení k kontrolnímu seznamu zabezpečení azure Well-Architected Framework:

SE:12	Definujte a otestujte efektivní postupy reakce na incidenty, které pokrývají celou řadu incidentů, od lokalizovaných problémů až po zotavení po havárii. Jasně definujte, který tým nebo jednotlivec provádí proceduru.

Tato příručka popisuje doporučení pro implementaci reakce na incidenty zabezpečení pro úlohu. Pokud dojde k ohrožení zabezpečení systému, systematický přístup k reakci na incidenty pomáhá zkrátit dobu potřebnou k identifikaci, správě a zmírnění bezpečnostních incidentů. Tyto incidenty můžou ohrozit důvěrnost, integritu a dostupnost softwarových systémů a dat.

Většina podniků má centrální tým operací zabezpečení (označovaný také jako Security Operations Center (SOC) nebo SecOps). Úkolem týmu pro operace zabezpečení je rychle detekovat potenciální útoky, určit jejich prioritu a určit jejich prioritu. Tým také monitoruje telemetrická data související se zabezpečením a zkoumá porušení zabezpečení.

Zodpovídáte ale také za ochranu vašich úloh. Je důležité, aby všechny aktivity komunikace, vyšetřování a proaktivního vyhledávání byly společným úsilím mezi týmem úloh a týmem SecOps.

Tato příručka poskytuje doporučení pro vás a váš tým úloh, která vám pomůžou rychle zjišťovat, analyzovat a prošetřovat útoky.

Definice

Období	Definice
Výstrahy	Oznámení obsahující informace o incidentu.
Věrnost upozornění	Přesnost dat, která určují výstrahu. Výstrahy s vysokou věrností obsahují kontext zabezpečení, který je potřeba k provedení okamžitých akcí. Upozornění s nízkou věrností neobsahují informace nebo obsahují šum.
Falešně pozitivní výsledek	Výstraha, která indikuje incident, který se nestal.
Incident (Incident)	Událost, která označuje neoprávněný přístup k systému.
Reakce na incidenty	Proces, který detekuje rizika spojená s incidentem, reaguje na ně a zmírní je.
Třídění	Operace reakce na incidenty, která analyzuje problémy se zabezpečením a určuje prioritu jejich zmírnění.

Klíčové strategie návrhu

Vy a váš tým provádíte operace reakce na incidenty, když se zobrazí signál nebo upozornění na potenciální ohrožení zabezpečení. Výstrahy s vysokou věrností obsahují dostatek kontextu zabezpečení, který analytikům usnadňuje rozhodování. Výstrahy s vysokou věrností vedou k nízkému počtu falešně pozitivních výsledků. Tato příručka předpokládá, že systém upozornění filtruje signály nízké přesnosti a zaměřuje se na výstrahy s vysokou přesností, které mohou znamenat skutečný incident.

Přiřazení oznámení o incidentu

Výstrahy zabezpečení se musí spojit s příslušnými lidmi ve vašem týmu a ve vaší organizaci. Vytvořte v týmu úloh určené kontaktní místo, které bude dostávat oznámení o incidentech. Tato oznámení by měla obsahovat co nejvíce informací o napadeném prostředku a systému. Upozornění musí obsahovat další kroky, aby váš tým mohl akce urychlit.

Doporučujeme protokolovat a spravovat oznámení a akce incidentů pomocí specializovaných nástrojů, které udržují záznam pro audit. Pomocí standardních nástrojů můžete zachovat důkazy, které by se mohly vyžadovat pro případná právní šetření. Hledejte příležitosti k implementaci automatizace, která může odesílat oznámení na základě odpovědnosti odpovědných stran. Udržujte jasný řetězec komunikace a hlášení během incidentu.

Využijte výhod řešení siEM (Security Information Event Management) a řešení SOAR (Security Orchestraation Automated Response), která poskytuje vaše organizace. Alternativně můžete pořídit nástroje pro správu incidentů a doporučit organizaci, aby je standardizovala pro všechny týmy úloh.

Prošetřování s využitím týmu pro určení priorit

Člen týmu, který obdrží oznámení o incidentu, zodpovídá za nastavení procesu posouzení, který zahrnuje příslušné osoby na základě dostupných dat. Tým třídění, často označovaný jako tým mostu, se musí dohodnout na režimu a procesu komunikace. Vyžaduje tento incident asynchronní diskuze nebo volání mostu? Jak by měl tým sledovat průběh vyšetřování a komunikovat ho? Kde může tým získat přístup k prostředkům incidentu?

Reakce na incidenty je zásadním důvodem k udržování dokumentace v aktuálním stavu, jako je architektonické rozložení systému, informace na úrovni komponent, klasifikace ochrany osobních údajů nebo zabezpečení, vlastníky a klíčové kontaktní body. Pokud jsou informace nepřesné nebo zastaralé, tým mostu plýtvá drahocenným časem tím, že se snaží pochopit, jak systém funguje, kdo je za každou oblast zodpovědný a jaký může mít událost dopad.

Pro další šetření zapojte příslušné osoby. Můžete zahrnout manažera incidentů, pracovníka zabezpečení nebo potenciální zákazníky zaměřené na úlohy. Chcete-li zachovat zaměření na třídění, vylučte osoby, které jsou mimo rozsah problému. V některých případech incident zkoumají samostatné týmy. Může existovat tým, který nejprve prošetřuje problém a snaží se incident zmírnit, a další specializovaný tým, který může provádět forenzní operace pro hloubkové šetření, aby zjistily rozsáhlé problémy. Prostředí úloh můžete umístit do karantény, aby mohl forenzní tým provádět šetření. V některých případech může celé šetření zpracovat stejný tým.

V počáteční fázi je tým pro posouzení zodpovědný za určení potenciálního vektoru a jeho vlivu na důvěrnost, integritu a dostupnost systému (označuje se také jako CIA).

V rámci kategorií CIA přiřaďte počáteční úroveň závažnosti, která udává hloubku poškození a naléhavost nápravy. Očekává se, že se tato úroveň bude v průběhu času měnit, protože se v úrovních třídění objeví další informace.

Ve fázi zjišťování je důležité určit okamžitý postup a plány komunikace. Došlo k nějakým změnám ve spuštěném stavu systému? Jak lze útok zabránit dalšímu zneužití? Potřebuje tým rozeslat interní nebo externí komunikaci, jako je například zodpovědné zveřejnění informací? Zvažte detekci a dobu odezvy. Ze zákona můžete být povinni nahlásit některé typy porušení předpisů regulačnímu orgánu v určitém časovém období, což je často několik hodin nebo dnů.

Pokud se rozhodnete systém vypnout, další kroky povedou k procesu zotavení po havárii (DR) úlohy.

Pokud systém nevypnete, určete, jak incident napravit, aniž by to mělo vliv na funkčnost systému.

Zotavení z incidentu

Zacházejte s incidentem zabezpečení jako s havárií. Pokud náprava vyžaduje úplné obnovení, použijte správné mechanismy zotavení po havárii z hlediska zabezpečení. Proces obnovení musí zabránit pravděpodobnosti opakování. V opačném případě se problém obnoví obnovením z poškozené zálohy. Opětovné nasazení systému se stejnou chybou zabezpečení vede ke stejnému incidentu. Ověřte kroky a procesy převzetí služeb při selhání a navrácení služeb po obnovení.

Pokud systém zůstane funkční, vyhodnoťte vliv na spuštěné části systému. Pokračujte v monitorování systému, abyste se ujistili, že implementace správných procesů snížení výkonu a dalších cílů spolehlivosti a výkonu splní nebo se nastaví. Neohrožujte ochranu osobních údajů kvůli zmírnění rizik.

Diagnostika je interaktivní proces, dokud není identifikován vektor a potenciální oprava a záložní řešení. Po diagnostice tým pracuje na nápravě, která identifikuje a použije požadovanou opravu v přijatelné době.

Metriky obnovení měří, jak dlouho trvá oprava problému. V případě vypnutí může existovat naléhavost týkající se doby nápravy. Pokud chcete systém stabilizovat, instalace oprav, oprav a testů a nasazení aktualizací nějakou dobu trvá. Určete strategie omezování, abyste zabránili dalším škodám a šíření incidentu. Vyvíjet postupy eradikace k úplnému odstranění hrozby z životního prostředí.

Kompromis: Mezi cíli spolehlivosti a dobou nápravy existuje kompromis. Během incidentu pravděpodobně nesplňujete jiné nefunkční nebo funkční požadavky. Během vyšetřování incidentu můžete například muset zakázat části systému nebo dokonce muset celý systém převést do režimu offline, dokud neurčíte rozsah incidentu. Pracovníci s rozhodovací pravomocí ve firmě musí explicitně rozhodnout, jaké jsou přijatelné cíle během incidentu. Jasně určete osobu, která je za toto rozhodnutí odpovědná.

Poučení z incidentu

Incident odhalí mezery nebo zranitelná místa v návrhu nebo implementaci. Je to příležitost ke zlepšení, která vychází z poznatků z aspektů technického návrhu, automatizace, procesů vývoje produktů, které zahrnují testování, a efektivity procesu reakce na incidenty. Udržujte podrobné záznamy incidentů, včetně provedených akcí, časových os a zjištění.

Důrazně doporučujeme provádět strukturované závěrečné kontroly incidentů, jako je analýza původních příčin a retrospektivní akce. Sledujte výsledky těchto kontrol a určete jejich prioritu a zvažte využití získaných informací v budoucích návrzích úloh.

Plány vylepšení by měly zahrnovat aktualizace postupů a testování zabezpečení, jako jsou postupy provozní kontinuity a zotavení po havárii (BCDR). Jako scénář pro provádění postupu BCDR použijte ohrožení zabezpečení. Postupy můžou ověřit fungování zdokumentovaných procesů. Nemělo by existovat více playbooků reakcí na incidenty. Použijte jeden zdroj, který můžete upravit na základě velikosti incidentu a toho, jak je tento účinek rozšířený nebo lokalizovaný. Cvičení jsou založená na hypotetických situacích. Provádějte nácviky v prostředí s nízkým rizikem a zahrňte do nich fázi učení.

Provádějte závěrečné vyhodnocení incidentu nebo posmrtná hlášení, abyste identifikovali slabá místa v procesu reakce a oblasti pro zlepšení. Na základě poznatků, které se z incidentu naučíte, aktualizujte plán reakce na incidenty (IRP) a bezpečnostní prvky.

Odeslat potřebnou komunikaci

Implementujte komunikační plán, který uživatele upozorní na přerušení a informuje interní zúčastněné strany o nápravě a vylepšení. Ostatní lidé ve vaší organizaci musí být upozorněni na jakékoli změny standardních hodnot zabezpečení úlohy, aby se zabránilo budoucím incidentům.

Generovat sestavy incidentů pro interní použití a v případě potřeby pro dodržování právních předpisů nebo právní účely. Osvojte si také sestavu standardního formátu (šablonu dokumentu s definovanými oddíly), kterou tým SOC používá pro všechny incidenty. Před ukončením šetření se ujistěte, že ke každému incidentu je přidružená sestava.

Usnadnění Azure

Microsoft Sentinel je řešení SIEM a SOAR. Jedná se o jediné řešení pro detekci výstrah, viditelnost hrozeb, proaktivní proaktivní proaktivní vyhledávání a reakci na hrozby. Další informace najdete v tématu Co je Microsoft Sentinel?

Ujistěte se, že portál pro registraci Azure obsahuje kontaktní informace správce, aby bylo možné operace zabezpečení informovat přímo interním procesem. Další informace najdete v tématu Aktualizace nastavení oznámení.

Další informace o vytvoření určeného kontaktního místa, které přijímá oznámení o incidentech Azure od Microsoft Defender for Cloud, najdete v tématu Konfigurace e-mailových oznámení pro výstrahy zabezpečení.

Sladění organizace

Cloud Adoption Framework pro Azure poskytuje pokyny týkající se plánování reakcí na incidenty a operací zabezpečení. Další informace najdete v tématu Operace zabezpečení.

Související odkazy

• Automatické vytváření incidentů z výstrah zabezpečení Microsoftu
• Provádění kompletního proaktivního vyhledávání hrozeb pomocí funkce proaktivního vyhledávání
• Konfigurace e-mailových oznámení pro upozornění zabezpečení
• Přehled reakcí na incidenty
• Připravenost na incidenty v Microsoft Azure
• Procházení a vyšetřování incidentů ve službě Microsoft Sentinel
• Řízení zabezpečení: Reakce na incidenty
• Řešení SOAR ve službě Microsoft Sentinel
• Školení: Úvod do připravenosti na incidenty Azure
• Aktualizace nastavení oznámení Azure Portal
• Co je SOC?
• Co je Microsoft Sentinel?

Kontrolní seznam zabezpečení

Projděte si kompletní sadu doporučení.

Kontrolní seznam zabezpečení