Co je bezpečnostní hardening a jak na něj?

Míra zabezpečení, které lze dosáhnout, je specifická pro způsob, jakým platformu používáte. Tento proces se nazývá bezpečnostní hardening.

Jaké platformy lze hardenovat? Všechny. Dnes můžete najít návody na zvýšení zabezpečení prakticky čehokoli, co je široce používáno. Dobrou praxí je řídit se doporučeními renomovaných autorit. Pro tento účel doporučuji využít úložiště kontrolních seznamů pro hardening.

Klíčovou otázkou je, zda je to užitečné a zda to stojí za vynaložené úsilí. Může se zdát, že jde o dávnou praxi. Dnes se totiž o hardeningu příliš nemluví, že? Nestojí nic jiného než úsilí IT specialistů a jeho úspěšnost lze změřit jednoduchým procentem pravidel z kontrolního seznamu, která byla úspěšně implementována. Má však skutečný a hmatatelný dopad na kybernetickou bezpečnost? Rozhodně ano. Každý seznam obsahuje desítky pravidel a každé pravidlo může zabránit některým krokům, které by útočníci mohli podniknout. Každé z nich může narušit celý „kill chain“ (řetězec útoku).

Velmi často lze známé zranitelnosti zneužít pouze tehdy, pokud je systém ponechán ve výchozím stavu bez zohlednění bezpečnostních aspektů. Hardening navíc často brání zneužití dnes ještě neznámých zranitelností. Pokud potřebujete důkaz, navrhuji stáhnout si z výše uvedeného úložiště jakýkoli kontrolní seznam pro svou oblíbenou platformu a přečíst si některá pravidla. Zaručuji vám, že se dozvíte něco o nedostatcích zabezpečení své platformy. Jste manažer? Podívejte se alespoň na checklist pro svůj operační systém Windows, Mac nebo mobilní telefon. Pravděpodobně najdete body, kterým porozumíte i bez hlubokých technických znalostí.

Hardeningu je především o spolupráci ve firmě

Jak zavést proces hardeningu ve firmě? Především musí jít o spolupráci. Pokud jednoduše přikážete IT specialistovi odpovědnému za platformu, aby ji zabezpečil, dostanete ho do velmi nepříjemné situace. Tento člověk je zodpovědný za udržení platformy v provozuschopném stavu a obvykle bývá také zodpovědný za bezpečnost systému. Ale jaká je správná úroveň zabezpečení? Každá změna v hardeningu zvyšuje bezpečnost, ale také zvyšuje riziko výpadku (okamžitého nebo budoucího). Pokud je rozhodování o tom, zda v konkrétním kroku pokračovat, nebo nepokračovat, závislé na jedné osobě, a nikdo jiný nemá stejné detailní znalosti, má tato osoba tendenci zůstat v osobní bezpečné zóně, což ve výsledku znamená slabě zabezpečený systém. Proto je nutné specialistům pomoci. Prvním krokem je zavedení řádného procesu řízení změn, který vypadá následovně: vyhodnocení à testování à nasazení.

Proces. Každý krok hardeningu je potřeba týmově vyhodnotit z hlediska jeho dopadu. Často budete diskutovat o bezpečnostním riziku spojeném s neimplementací daného pravidla. Poté je nutné změnu otestovat v neprodukčním prostředí, pokud je to možné. Až poté by měla být změna nasazena do produkčního prostředí. Proces však nevyřeší všechny problémy spojené s hardeningem. Ten je rizikový, i když je vynaloženo maximální úsilí, protože zvyšování bezpečnosti přirozeně přináší riziko výpadku. Konečná odpovědnost za vyvažování a přijímání těchto rizik spočívá na vedení společnosti. Následující matice ukazuje jeden z možných přístupů k řízení rizik hardeningu.

Riziko. Osa X znázorňuje úroveň hardeningu. Jednoduše reprezentuje počet pravidel z kontrolních seznamů pro hardening, která použijete. „Vysoký“ znamená aplikaci všech dostupných pravidel hardeningových standardů. Osa Y reprezentuje úroveň testovacího úsilí. „Vyhnutí se rizikům“ znamená, že tým vyloučí vše, co by mohlo být z pohledu možného výpadku rizikové. Tento přístup je rychlý, ale výsledkem bude nízké skóre hardeningu. „Diskutovat a testovat?“ znamená, že tým rozhoduje o tom, co stojí za další testování pro účely vyhodnocení (před nasazením změny do testovacího prostředí). „Komplexní testování“ představuje nejkomplexnější přístup. Proveditelnost každého kroku je vyhodnocena testy a nic, co by bylo i jen mírně nejednoznačné, není dopředu odmítnuto.

Matice ukazuje reziduální bezpečnostní riziko. Cílem hardeningu je samozřejmě dosáhnout co nejnižšího reziduálního bezpečnostního rizika. Mějte na paměti, že téměř nulové riziko v praxi znamená, že byla aplikována všechna známá proveditelná pravidla hardeningu. Ani dokonale hardenovaná platforma však není zcela bez bezpečnostních rizik.

Rychlost. Matice rovněž souvisí s rychlostí procesu hardeningu. Vysoké reziduální bezpečnostní riziko také znamená, že proces je rychlý, zatímco dosažení téměř nulového reziduálního bezpečnostního rizika je velmi pomalý proces. Rychlý přístup může být v praxi dobrý nápad. Mějte na paměti, že chcete hardenovat všechny platformy ve svém prostředí. Zatímco se snažíte snížit riziko u jedné platformy, ostatní v pořadí mohou představovat nesrovnatelně vyšší riziko, pokud zůstanou zcela nedotčeny. Nejlepší přístup je zde proto vrstvený. Nejprve dosáhnout základní úrovně hardeningu napříč celým prostředím a poté pokračovat s hlubším hardeningem ve druhém a třetím kole. Může se stát, že se zaváděním nových platforem do prostředí nebudete schopni při konstantních kapacitách  IT týmu pokročit dále. Tento proces zatím nejspíš nelze delegovat na umělou inteligenci. Dalším trikem, jak proces urychlit, je hardenovat několik platforem současně.

Práce s výjimkami

Samozřejmě, že žádný hardening nelze provést na 100 %. V prostředí vždy zůstanou výjimky, a je důležité je všechny dokumentovat, aby s nimi bylo možné v budoucnu pracovat. Jaké výjimky lze očekávat?

Nezabezpečené platformy. Jak již bylo zmíněno, měli byste hardenovat téměř vše ve svém prostředí. Čas a zdroje jsou však omezené. Proto některé platformy nebudou hardenovány po dlouhou dobu, protože jiné mají vyšší prioritu. Všechny by měly být zdokumentovány (zaznamenány) co nejdříve, abyste měli jasný přehled o rizikových částech svého prostředí. Další výjimkou může být platforma, která bude brzy vyřazena z provozu. I tyto by měly být zdokumentovány. Priority se mění a to, co je nyní „brzy“, se může změnit na „někdy v budoucnu“. Nejméně pravděpodobným důvodem pro výjimku nezabezpečené platformy je, že pro ni neexistuje kontrolní seznam. Pokud tomu tak je, pravděpodobně už ale hovoříme o něčem, co by mělo být vyřazeno z provozu, že?

Neimplementovaná pravidla. Toto je nejzřejmější vrstva výjimek. Pokud je například 85 % pravidel plně implementováno, pak 15 % představuje určité výjimky. Je třeba dokumentovat každé neimplementované pravidlo spolu s odůvodněním, proč nebylo implementováno. Pravděpodobně půjde o jeden z těchto dvou případů: „Víme, že by to něco narušilo.“ nebo „Nevíme, zda by to něco narušilo, a měli jsme důvod to netestovat (nedostatek znalostí, testovacího prostředí, zdrojů, času atd.).“

Pravidla neimplementovaná ve všech instancích. Dokonce i našich 85 % pravděpodobně nebude 85 %, pokud některá pravidla nejsou implementována ve všech instancích stejné platformy. Konečné měření, které uzavírá hardeningovou aktivitu, se často provádí na jedné instanci platformy, zatímco mohou existovat další instance, kde některá pravidla nebyla implementována. Je třeba zdokumentovat všechny instance, kde konkrétní pravidlo nebylo implementováno.

Jaké zde mohou být důvody? Například Windows Server 2022 A není totéž, co Windows Server 2022 B. Každý server má jinou roli a každý může dosáhnout jiné úrovně hardeningu. Obecně doporučuji rozdělit skupiny platforem co nejvíce a hardenovat je v oddělených proudech. I s tím však budou nevyhnutelné rozdíly například mezi webovým serverem A a B. Na úrovni jednotlivých instancí platformy každopádně budou s největší pravděpodobností existovat výjimky, a to bez ohledu na to, jak daleko zajdete s rozdělením platforem (podle jejich role) do skupin.

Vzdělávací aspekt

Pokud je hardening prováděn správně, jde o vysoce edukativní činnost pro všechny zapojené IT specialisty. Hardening nejenže zabezpečuje platformy, které jsou předmětem procesu, ale také umožňuje specialistům intuitivně zabezpečovat nové platformy, které budou spravovat v budoucnosti. Lidé zapojení do procesu budou spokojeni s tím, že jejich platformy jsou bezpečnější. Budou také spokojeni s bezpečnostními dovednostmi, které se během procesu naučí.

Autor: Petr Mojžíš, Security Architect ve společnosti ANECT