ICT Security Net Guru Link Podnikové systémy Reseller Channel Link

Banner
GFI - "Šťoural jste se v tom a viděl Vás u toho někdo?" PDF Tisk Email

Na redakční otázky odpovídá Robert Houser, technický ředitel GFI ČR a SR

Robert Houser - GFI1) Které chyby při řízení aktualizací a záplat typicky děláme?

Jejich odkládání na nejzazší možnou míru. To je dle mého názoru možná větší problém, než samozřejmě také špatné, bezhlavé okamžité instalování všeho, co se objeví na aktualizačních serverech. Jakkoliv motivům tohoto jednání celkem rozumím, domnívám se, že pravidelné aktualizování systému i aplikací je menším zlem, i za cenu určitého rizika, že budu muset řešit nějaký problém způsobený aktualizací, než jejich naprosté ignorování. Navíc, pokud se například týden po uvolnění nějaké aktualizace neobjeví na internetových diskuzních fórech lavina reportů a zoufalých žádostí o pomoc po instalaci některé aktualizace, není důvod nezačít takovou aktualizaci nasazovat.

Druhým, velmi častým, nešvarem je aktualizaci sice nainstalovat, ale neustále odkládat potřebný restart serveru. Je třeba si uvědomit, že toto chování může mít na systém velmi devastující účinky, proti kterým je výpadek způsobený potřebným restartem jen slabým odvarem.

2) Jak nejlépe zajistit, abychom měli záplatované a aktualizované skutečně všechny aplikace?

Vzhledem k tomu, že neexistuje „řešení v prášku“ je nutné k této problematice přistoupit z té druhé strany, kterou je Asset Management, sledování zranitelností a nasazení co největší míry automatizace tam, kde tak patch management provádět lze. Tam, kde to možné není, může k odhalení chybějící záplaty pomoci právě systém pro sledování zranitelností. Takže dle mého názoru klasické kolečko: a) asset management, b) sledování zranitelností (vulnerability mgmt) c) zakončené nástrojem pro Patch Management. Pak se na chvíli zamyslet a to celé znovu :-)

3) Jakým způsobem nejlépe otestovat aktualizaci před tím, než ji vpustíme do „ostrého“ systému?

Jakkoliv se přímo nabízí odpověď ve stylu „Otestujte nejprve v laboratorním prostředí…“, obávám se, že ve skutečnosti jediné schůdné řešení je testování aktualizací na menším vzorku počítačů v prostředí ostrém, jakkoliv u kritických aplikací se té laboratoři nevyhneme. Důvodem je to, že většina významných výrobců sice své aktualizace dostatečně testuje, ale většina nedostatků je stejně takového rázu, že se projeví až v produkčním prostředí při použití reálným uživatelem. Výše uvedené samozřejmě neplatí pro tzv. „velké“ aktualizace, typu Service Pack apod. Tam je testování v laboratorním prostředí a následující postupné zavádění pravděpodobně jediná schůdná cesta.

4) Jsou dnešní softwarové systémy Patch Managementu dostatečně kvalitní a chrání odpovídajících způsobem, nebo prostě jen nic lepšího nemáme?

B je správně. Dle mého názoru se obecná roztříštěnost v popisu a dostupnosti aktualizací projevuje právě v tom, že jediná celkem jednotná platforma jsou Microsoft Windows, pro které také existuje množství aplikací (ať už přímo od Microsoftu, či třetích stran – GFI LANguard je jedním příkladem). V případě aktualizací jiných platforem a aplikací se zatím zdá jedinou použitelnou cestou testovat obecné zranitelnosti, vyplývající z existujícího popisu chybného chování aplikace, které jsou součástí know-how společností, které se touto problematikou zabývají, nebo používají obecně dostupné databáze, jako například OVAL nebo SANS.

5) Proč je stále otázka Patch Managementu v oblasti komplexních bezpečnostních řešení tak ignorována či minimálně podceňována?

Jak vyplývá z výše uvedeného, je to trošku píchání do vosího hnízda. Ignorována bych neřekl, nicméně podceňována určitě, možná právě z toho důvodu, že tak jako tak přidává administrátorům práci. Dovolte mi to vysvětlit na příkladu: Řekněme, že se v obecné rovině shodneme, že toto téma je skutečně velmi důležité, čemuž osobně velmi hluboce věřím. Řekněme, že existuje hypotetický produkt, který má ambice vyřešit po technické stránce patch management všech významných průmyslových řešení, navrhněme následující platformy: Windows, Linux (alespoň hlavní distribuce vycházející z Debianu, RedHatu, SlackWare, Ubuntu…), běžně používané aplikace a rozšíření jako Adobe Acrobat, Flash (…), přidáme některé významné výrobce síťového vybavení, zejména Cisco, Juniper, 3Com, zahustíme nějakou vizualizační infrastrukturou (VMware, Citrix…). Vychází mi obrovské množství práce, možná srovnatelné s „výrobou“ antivirových řešení.

A teď otázka: Kolik zákazníků bude toto množství práce, přetavené do ceny licencí, platit? Za současného stavu věcí vidím kolem sebe velké množství administrátorů, kteří co nejdéle otálejí s jakoukoliv změnou stávající infrastruktury (a instalace patchů jí bezpochyby je) přesně v duchu hesla: „…a šťoural jste se v tom? Viděl vás u toho někdo?“

Do značné míry je chápu. Průměrný administrátor vidí podstatně větší riziko ve zcela konkrétním selhání aplikace, infrastruktury, počítače, způsobené aplikací patche, než v zatím poměrně abstraktní rovině zneužití jeho dat či výpočetní kapacity nějakým neznámým útočníkem „tam někde venku“. Ale tady nepomůže technologie, jen osvěta…

Patch management

Joomla Templates and Joomla Extensions by JoomlaVision.Com
 

Přidat komentář


Bezpečnostní kód
Obnovit