Jak dosáhnout bezchybné správy oprav

Je tedy překvapující, že většina organizací stále nezajišťuje účinnou správu oprav, přestože si myslí, že tak činí. Zde jsou některé běžné důvody, proč správa oprav nefunguje dobře.

1. Neopravuje se to, co je potřeba

Nejvýznamnějším problémem instalace oprav je, že se aplikace s nejvyšším rizikem neopravují jako první. Téměř v jakémkoli prostředí najdete stovky až tisíce věcí, které je nutné opravit, ale jen málo typů softwaru se napadá zdaleka nejvíce. Ty je důležité opravit jako první, nejlépe a nejrychleji.

V klientských počítačích dochází nejvíce k útokům na následující čtyři typy softwaru: doplňky internetových prohlížečů, internetové prohlížeče, operační systémy a aplikace pro produktivitu (např. aplikace sady Office).

V případě serverů dochází nejvíce k útokům na následující typy softwaru: software webového serveru, software databázového serveru, operační systém a konečně software pro vzdálenou správu serveru.

Tyto třídy softwaru tvoří méně než 5 % všech softwarových zranitelností, ale ještě důležitější zprávou je, že dokud se nešíří aktivní exploit, nemusíte mít obavy.

Během mnoha desetiletí se ukázalo, že pokud neexistuje veřejně se šířící kód exploitu, je nepravděpodobné, že ke zneužití zranitelnosti dojde. Jen cca 2 % všech veřejně oznámených zranitelností skončí volným šířením exploitu.

Řešení: Software s největší pravděpodobností zneužití opravujte jako první, nejlépe a nejrychleji.

2. Nadměrné zaměření na poměr oprav

Jen zřídkakdy se najde podnik, který by netvrdil, že má nějaký doslova neuvěřitelný poměr instalace oprav zranitelností – jako třeba 99 %. Na druhou stranu se v nich obvykle nenajde alespoň jedno zařízení, kde byly nainstalované veškeré opravy, a zařízení, které by neobsahovalo kritickou zranitelnost. Jaká je příčina tak velkého rozdílu?

Jimi citovaný „99% poměr nainstalovaných oprav“ obvykle znamená, že instalují opravy na 99 % aplikací společnosti Microsoft na většině svých zařízeních, ale i to je jen zřídka pravda.

Pokud se zkontroluje, zda mají nějaký zranitelný software pro vzdálenou správu nebo zranitelné verze doplňků internetových prohlížečů, bývá odpověď obvykle ano. Někdy se najde pět různých verzí stejného programu a žádná z nich není správně opravená.

Důležitější ale je, že ono jedno procento systémů, které není opravené, představuje právě zranitelnosti s největším rizikem. Znamená snad, že pokud máte 99% poměr nainstalovaných oprav, minimální celkové riziko zabezpečení, když naopak máte téměř 0% poměr u toho, co může být zneužité s největší pravděpodobností? Samozřejmě neznamená, a přesto tento scénář přesně popisuje, co je vidět ve většině prostředí.

Řešení: Nezabývejte se celkovým poměrem úspěšně nainstalovaných oprav, ale soustřeďte se hlavně na ty důležité.

3. Nedostatečná rychlost instalace oprav

Všechny pokyny k dodržování směrnic stanoví, že kritické zranitelnosti se mají opravovat včas, ať už to znamená cokoliv. Mělo by to však znamenat, že k nim nainstalujete opravy do několika dnů a nejvýše do jednoho týdne.

Jasně že mnoho lidí počká den až tři, zda se ve vydané opravě nevyskytuje nějaká vážná chyba, ale lze se setkat i s organizacemi, které mají sepsané zásady, že oprava se má nainstalovat během jednoho měsíce. To je šílené.

V době, kdy zločinci využívají dostupné nejnovější opravy k úspěšnému vytvoření exploitů s červí metodou šíření za několik minut po vydání takové opravy, přece nelze čekat měsíc, než nainstalujete opravu důležité komponenty, zejména když jde o ty, na které se útočí nejvíce.

Pokud použijete „in-line opravy“ k zastavení hrozeb, jež se snaží zneužít tyto neopravené zranitelnosti, měly by se takové signatury aktivovat okamžitě.

Řešení: Nejdéle do týdne instalujte opravy komponent s nejvyšší pravděpodobností útoku.

4. Není jasné, kdo je odpovědný za opravy

Jen v málo případech nese jedna osoba nebo tým zodpovědnost za veškeré opravy v celé organizaci. Obvykle jedna osoba nebo tým nesou zodpovědnost za nějakou velkou část, ale někdo je zodpovědný za instalování oprav do zařízení, jiný za instalaci oprav serverových aplikací a další za opravy databázových serverů atd.

Zřídka se lze setkat s organizací, které by nechybělo mnoho oprav v jejich počítačích. Když se pak řeší, proč se to děje, začnou ukazovat prstem. „Mám na starosti uživatelské počítače, ale ne servery,“ nebo „na ty a ony servery nesmím sahat“ nebo „správci DNS se rozhodli, že se záplata nyní nebude instalovat, protože přestane fungovat blabla…“

Takové výmluvy létají stejně rychle, jako se objevuje ukazování prstem. Jediným problémem je, že máte mnoho chybějících oprav a nikdo nenese odpovědnost za jejich instalaci.

Řešení: Stanovte jednu osobu či oddělení, které budou exkluzivně odpovědné za veškeré instalace oprav.

5. Opravy nejsou otestované před instalací

Ano, instalace oprav může způsobit, že něco přestane fungovat. To však není důvod, aby se neinstalovaly opravy dostatečně rychle. Když instalací opravy dojde k narušení provozu, tak tento stav netrvá navždy.

Je ale pravda, že nikdo nebude povýšen za vyvolání havárie serveru v důsledku instalace opravy zabezpečení. Takže testujte. A „testováním“ myslíme, abyste něco dělali … cokoliv.

Obecně vžitý názor je, že by se všechny opravy měly otestovat pro široké spektrum různých typů zařízení a konfigurací. Teprve po důkladném a kompletním vyzkoušení je možné instalaci oprav povolit a následně vykonat. To zní skvěle, pokud to ale skutečně děláte.

Většina firem totiž instaluje opravy bez jakéhokoli pokusu o testování, a vystavuje se tím riziku kritického selhání, které může jednou nastat v okamžiku, kdy to bude nejméně vhodné. Namísto přístupu k testování stylem „testujeme, či netestujeme“ přejděte na alespoň částečné testování před instalací ve velkém měřítku.

Předem nadefinujte, jaké vaše nestěžejní servery a uživatelské počítače a zařízení budou vašimi „pokusnými králíky“ na plný úvazek, a potom je k tomu používejte, když nastane čas k instalaci oprav.

Opravy do vašich klíčových produkčních testovacích serverů a uživatelských počítačů instalujte den nebo dva po jejich vydání. Počkejte den či dva, abyste zjistili, zda nezpůsobí nějaké problémy, a pokud se vše zdá být v pořádku, začněte s širší instalací, ale nikoli všude najednou.

Nasazení do produkčního prostředí dělejte ve vícedenních vlnách, ale dostatečně rychle, aby veškeré instalace byly nainstalované do zmiňovaného týdne. Začněte v malém a následně záběr rozšiřujte.

Opět platí, abyste neudělali z testování záležitost typu ano/ne. Pokud to nemůžete udělat plně a správně, tak testujte alespoň něco. Připravte si také dobrý plán pro návrat do původního stavu pro případ, že by opravy způsobovaly velké problémy.

Řešení: Testujte opravy před plošnou instalací do produkčního prostředí a připravte si plán návratu pro případ, že by opravy způsobovaly problémy.

6. Tým pro správu oprav nemá žádnou pravomoc

Téměř každý dobrý šéf správy oprav si stěžuje na to, že nese veškerou odpovědnost (pro případy, kdy dojde k úspěšnému útoku v důsledku chybějících oprav), ale že nemá žádnou pravomoc přinutit držitele zařízení, aby instalovali opravy řádně.

Například když byla platforma Java odpovědná za úspěch 90 % všech webových útoků, většina manažerů oprav říkala, že nemohli opravy instalovat, protože blokovaly příliš mnoho legitimních programů.

Protože byla Java nejčastěji instalovaným programem hned po operačním systému, vedlo to hackery k tomu, že se na ni zaměřovali nejvíce.

Je nepřijatelné, abyste nedělali nic, když najdete neopravený důležitý program, k jehož zranitelnosti existuje běžně dostupný exploit. Můžete dělat spoustu věcí, ale nedělat nic mezi to nepatří.

Kdykoliv nějaký program přestal fungovat v důsledku nové opravy, bylo to téměř vždy proto, že programátor udělal něco, co se dělat nemělo. Zajistěte, aby vaši vývojáři (a vývojáři vašeho dodavatele) nebyli líní a nezpůsobovali vám problémy se správou oprav.

Pokud nemůžete nainstalovat opravu programu, zvažte následující:

• Jeho odstranění, pokud není potřebný.
• Odstranění zařízení s chybějícími opravami ze sítě, nebo jeho silnou izolaci, pokud je to možné.
• Použití softwaru k blokaci všech potenciálních hrozeb, které mohou zneužít neopravenou zranitelnost.

Řešení: Použijte alternativní opatření ke zmírnění rizika, pokud nemůžete opravu nasadit.

7. Zranitelnosti opravené jen jednou a pak už nikdy

Instalace oprav není problém, který se dá řešit jednorázově. Správa oprav není nákup pomyslného produktu, který by zajistil, že vše bude opravené – pokaždé a dokonale. Takový produkt prostě neexistuje.

Správa oprav se týká efektivního řízení rizika a udržení kroku s tím, jaké nové hrozby se objevují před vašimi branami.

Řešení: Pověřte zkušeného manažera pro řízení rizik, aby měl na starost vaši správu oprav.

8. Nevhodná metoda odměn manažerů oprav

A konečně, většina šéfů správy oprav, pokud jsou vůbec odměňováni za to, jak dobře zajišťují správu oprav, je hodnocená právě za procento celkového počtu softwarových programů, pro které zajistí včasnou instalaci oprav.

A jaké je? Ano, je to 99 %. Je to vždycky 99 %, a těchto 99 % neříká vůbec nic o skutečném stavu řízení rizik.

Namísto toho je potřebné motivovat manažery správy oprav za to, jak dobře a rychle instalují opravy pro programy, na které se útočí nejvíce.

Pokud počet neopravených programů zneužitých za nějaké období ve vašem prostředí klesá oproti období předchozímu a nedojde k žádným kritickým útokům z důvodu neopraveného softwaru, mělo by se to považovat za úspěch. Takovému šéfovi správy oprav se patří vyjádřit uznání, protože cokoli jiného je jen lhaní prostřednictvím statistických údajů.

Řešení: Zajistěte, aby odměny pro manažera oprav odpovídaly snižování skutečného rizika a neodvíjely se od procenta libovolných oprav.