EndPoint Security IV:

Endpoint a jeho ochrana: aktuální téma, o kterém toho již bylo hodně napsáno a v budoucnu určitě ještě bude. Pokud se ale podrobněji podíváme na obsah, ve velké většině případů zjistíme, že se stále píše o tom samém a nic nového se již nedozvíme. Zjistíme, že obvyklou snahou je zabránit uživateli připojovat nepovolená zařízení, spustit zakázané aplikace, zabránit antivirové nebo spíše malwarové nákaze, zajistit nutnost auditovat akce, šifrovat data a zařízení, záplatovat systémy, bránit úniku dat atd. Podle jednoho pravidla sice platí, že "opakování je matkou moudrosti", ale podle jiného zase "důvěřuj, ale prověřuj". Nezapomíná se, ať již úmyslně nebo neúmyslně, náhodou na něco, co se jeví jako nedůležité, ale v důsledku a dopadech to je kritické? Co taková ochrana vlastního zabezpečení?
V praxi bychom se totiž neměli ptát jen na to, co naše zabezpečení chrání a řeší, ale také na to, jak je samotná ochrana odolná vůči snahám o její deaktivaci. Je to podobné jako u antivirů. Jakmile se nám povede zastavit on-line ochranu, můžeme mít sebeaktuálnější virovou databázi, sebekvalitnější heuristickou analýzu, ale když systém neběží, jako bychom neměli nic. Zkusme se tedy v krátkosti podívat, na co bychom neměli při řešení ochrany endpointu také zapomínat a co by mělo být jedním z rozhodovacích kritérií při výběru řešení. Alespoň pokud to myslíme se zabezpečením vážně.
Výchozím bodem a první úrovní k zamyšlení je, jakým způsobem ochrana funguje. Když pomineme zabezpečení pomocí standardních možností Windows, setkáme se v praxi se dvěma způsoby: službou a kernelovým driverem. Každá z metod sleduje aktuální požadavky na systém a podle nastavení na ně reaguje. Jako lepší řešení se jeví kernelový driver. Důvodem a výhodou je především to, že o běžící ochraně uživatel neví, protože je skryta hluboko v systému. U služby má většinou možnost zjistit, že běží něco, o čem nic neví a zřejmě to bude důvodem, proč něco nefunguje. A i když je ochrana zastavení nebo deaktivace služby silná, přece jen platí, že o čem nevím, to mě neláká. Chceme-li se spolehlivě chránit i před uživateli s administrátorskými právy, proč jim dávat záminku?
Druhou úrovní zabezpečení je zajištění nemožnosti odinstalace ochrany, a to včetně administrátorů a uživatelů s jejich právy. První možností je použití odinstalačního hesla. Tato ochrana odradí běžné uživatele, ale již nemusí být dostatečná proti těm zkušenějším. Hodně totiž záleží na tom, jakým způsobem s hesly pracujeme. Jakékoliv nedodržování alespoň běžných pravidel používání hesel a možnost vysledovat heslo administrátora třeba při běžné činnosti ochranu degraduje. V tomto případě nezbývá než kontrolovat, zda některá stanice nepřestala komunikovat. Ale zvládnou to všechny nástroje? Co když ochranu na chvilku odinstaluji a pak opět nainstaluji? Jakou další ochranu v tomto případě použít? U pokročilejších nástrojů se setkáváme s tím, že při instalaci dokáží jako další stupeň ochrany skrýt klienta v ovládacích panelech a omezit funkci Přidat/Odebrat, od jednoduchého skrytí tlačítka Odebrat až po úplné odstranění ze seznamu aplikací k odebrání. Ochrana je platná i pro uživatele s administrátorskými právy. Opět podle pravidla, že o čem nevím nebo k čemu nemám přístup, to mě neláká. Výjimkou jsou doménoví administrátoři, pro které tato pravidla většinou neplatí. Pro tento případ a jako nejvyšší stupeň ochrany proti odinstalování se používá systém potvrzení z konzoly pro správu s důsledným auditováním akce. Jinými slovy, klient zažádá o povolení odinstalace, a pokud tato není povolena centrálně správcem zabezpečení, tak se neprovede, bez ohledu na typ uživatele. Akce je auditovaná a je možné kdykoliv ji dohledat, případně na ni včas upozornit.
Poslední úrovní je ochrana před (ne)chtěným narušením systému, především smazáním některé jeho části - souborů, záznamů v registrech atd. Ať již chceme nebo ne, občas se tato akce může udát a neuchrání nás před ní ani sebelepší nastavení přístupových práv. Důvodem může být nutnost přidělit vyšší práva vybraným uživatelům, jiná aplikace, která při instalaci změní nastavení nebo dokonce změnu nastavení sama vyžaduje, anebo jen nekompatibilita různých systémů. V těchto případech se pak může velmi jednoduše stát, že se systém stane nefunkčním. Smazání souboru v "lepším" případě znepřístupní celý sys-
tém tím, že nenaběhne, v horším případě naběhne, ale zabezpečení nefunguje. V tomto stavu pak záleží na schopnosti na něj reagovat. Umí naše zabezpečení alespoň detekovat, že přestal klient komunikovat? Nebo musí správce provést akci "zjisti stav klientů" a teprve pak se dozví, že došlo k výpadku některého z nich? "Lepší" nástroje obsahují pokročilé funkčnosti, které tento stav detekují automaticky a následně jsou schopné poškozené části systému opravit (client hardening) - dohrát chybějící soubory, obnovit nastavení v registrech a automaticky informovat správce.
Všechny popsané vlastnosti a schopnosti se v oblasti bezpečnosti označují pojmem antitampering. V praxi, stejně jako jsme popsali výše, se dělí do různých kategorií, které udávají nejen schopnosti, ale především vhodnost a oblasti nasazení. Obdobně by tomu mohlo být v budoucnu i v oblasti zabezpečení EndPointu. Čím kvalitnější zabezpečení a větší požadavky na bezpečnost, tím kvalitnější a robustnější antitampering by měl systém poskytovat. Jen tak se dá garantovat vysoká konzistence a integrita systému. V případě existence alespoň základních standardů se navíc uleví administrátorům nejen při výběru, ale i při dokazování, že jimi vybraný a spravovaný systém je pro potřeby firmy dostatečný. Nemluvě o různých normách a metodikách pro definici zabezpečení.
Jediné, co nelze žádným způsobem zajistit a ani pro to neexistuje řešení, je situace, kdy se uživateli podaří zničit auditní informace o činnostech uživatelů v případě, kdy jsou mimo síť a ještě nejsou přeneseny na server. V tomto případě je jedinou možností záznam o nekonzistenci dat v logu. Naštěstí se nejedná o narušení systému a jeho funkčnosti, ale "jen" o ztrátu informací, která je detekovatelná chybějícím časovým úsekem nebo přímo zprávou o nekonzistenci dat. A když víme, že něco není v pořádku, nastupuje další stupeň řešení podle interních pravidel a politik. Jako příklad systému s ochranou na nejvyšší úrovni, který může při výběru sloužit pro srovnání s jinými produkty, uveďme na závěr produktovou řadu Sanctuary společnosti SecureWave (www.securewave.cz). Na ní je názorně vidět, že díky své rozšířenosti, zákaznickému portfoliu a požadavkům zákazníků byla antitamperingu věnována velká pozornost. Výběrem tohoto produktu chybu určitě neuděláte.

Pavel Náplava pracuje ve společnosti SITRONICS Telecom Solutions, Czech Republic.

Možnosti odinstalace klienta.
Zákaz odinstalace bez centrálního povolení.
Nastavení funkce "client hardening".