Vytvořte si metriky i pro zabezpečení

Stal jsem se velkým fanouškem různých metrik. Nebylo tomu tak vždy, ale během své kariéry v oblasti zabezpečení informací jsem měl šéfy, kteří po mně nějaké formy ukazatelů vyžadovali, a já své dovednosti zlepšoval. Nyní jsem přesvědčený, že mnou shromažďované metriky jsou dostatečně užitečné a splňují požadavky na konkrétnost, smysluplnost, využitelnost, opakovatelnost a časovou závislost.

Například jednou za čtvrt roku vytvářím zprávu o stavu instalace oprav a aktuálnosti antivirové ochrany v naší demilitarizované zóně a produkční infrastruktuře. Informuji také o počtu zjištěných nespravovaných zdrojů.

Tyto metriky nebyly nikdy zpochybněné, protože jsou velmi konkrétní, vyjadřují riziko (jsou smysluplné), existují jasné kroky, které lze na základě nich udělat (jsou využitelné), metoda jejich shromažďování a reportování každé čtvrtletí je jasná (opakovatelnost) a měří riziko v průběhu času (závislost na čase).

Některé ukazatele obvykle reportuji jen jednou či dvakrát za rok. Například tak rád oznamuji výši rozpočtu na zabezpečení v přepočtu na jednoho zaměstnance, množství pracovníků naší divize jako podíl veškerého personálu IT a také výši rozpočtu na zabezpečení jako výši procent na celém rozpočtu na IT.

Potom tato čísla srovnávám s čísly svých oborových kolegů a s dalšími ukazateli od oborových analytiků jako například od Gartneru. Nemám příliš mnoho metrik, ale ty, které používám, mají dobrou vypovídací hodnotu a reprezentují zdravotní stav zabezpečení a rizik našeho podniku.

Nové metriky

Nyní, když naše centrum zabezpečení zahájilo svůj provoz a funguje, jsem chtěl vytvořit nějaké další a samozřejmě smysluplné metriky, které by měřily efektivitu jeho fungování.

Jak jsem zmínil v jedné ze svých předchozích epizod, jedním z problémů, které máme s naším outsourcovaným provozním centrem, je vysoká úroveň falešných poplachů v souvislosti s malwarovými incidenty.

Aby se zabránilo vysoké míře reakcí na falešné poplachy a předešlo napětí mezi oddělením zabezpečení a linkou technické podpory, instruoval jsem analytiky první úrovně, aby předávali incidenty specialistům třetí úrovně na ověření.

Pokud tento expert zjistí, že je malwarová událost falešným poplachem, okomentuje ji a odpovídajícím způsobem vyškolí analytiky první úrovně. Dokud se počet falešných poplachů nesníží na zvládnutelnou úroveň, smí vytvořit žádost o reakci na malwarový incident jen analytik třetí úrovně, více o tom níže.

Systém žádanek pro linku technické podpory v naší společnosti není dostatečně propracován, aby sledoval podrobnosti, které mě zajímají vzhledem k bezpečnostním incidentům.

Proto používám seznam v Microsoft SharePointu k zachycení různých prvků bezpečnostního incidentu. Například naši analytici okomentují, jak došlo ke zjištění incidentu, což zahrnuje náš systém SIEM, agenty ochrany koncových bodů, zaměstnance, zákazníky, zástupce policie nebo další třetí stranu.

Pokud incident souvisí s malwarem (jako tomu je u většiny našich incidentů), zaznamená se oddělení, ke kterému uživatel patří. Pokud se incident ukáže být falešným poplachem, musí analytici označit tento incident jako falešný poplach.

Zaznamenáváme, pokud je incident výsledkem phishingového útoku nebo instalace aplikace, a také to, zda malware patří do kategorie rootkit, trojský kůň, zloděj informací, objekt BHO (Browser Helper Object) nebo je to nějaký jiný potenciálně nežádoucí program. Sleduje se také, kdy došlo ke zjištění incidentu a kdy na tom začali analytici skutečně pracovat.

Uchováváme uvedené informace a řadu dalších aspektů incidentu, aby bylo možné časem sledovat a vyhodnocovat skutečnosti jako například, jaké oddělení má tendenci být zdrojem malwarových infekcí, aby bylo možné se soustředit na odpovídající školení zvyšující povědomí o bezpečnosti.

Sleduji rovněž, jaké jsou zdroje incidentů, takže pokud například vidím rostoucí počet incidentů z phishingových útoků, můžeme udělat kontrolu naší strategie obrany. Sleduji i časový rozdíl mezi začátkem práce analytika na incidentu a samotným výskytem incidentu. Je to klíč k určení doby reakce na incident. Pokud to trvá příliš dlouho, pak to představuje pro organizaci vážné riziko.

Cílem je jednoduchost

Vytvořil jsem seznam v SharePointu, tak aby bylo vyplnění záznamu o incidentu jednoduché a nezabíralo více než jen pár minut. Používám hodně rozevíracích nabídek a zaškrtávacích políček a snažím se minimalizovat počet textových polí pro vyplnění slovním popisem.

Na seznamech SharePointu je hezké, že je lze snadno exportovat do Excelu a vytvořit kontingenční tabulky představující různé metriky, které používáme k měření efektivity fungování provozu zabezpečení a různých trendů v rámci podniku.

Jakmile jednou vytvořím kontingenční tabulky, mohu pomocí prosté aktualizace získat nejaktuálnější data. Když vypadají kontingenční tabulky dobře, jednoduše je zkopíruji a vložím do snímku PowerPointu nebo je zpřístupním na informačním panelu našeho šéfa ředitele.

Tento příspěvek do Zápisníku manažera pro bezpečnost napsal skutečný manažer bezpečnosti, který zde vystupuje jako Mathias Thurman. Jeho pravé jméno ani jméno zaměstnavatele z pochopitelných důvodů neuvádíme.