Bezpečnostní pravidla jsou někdy k ničemu

Ignorování bezpečnostních politik způsobuje problémy. Firmu ohrožují pirátské přístupové body i neadekvátní hl


Ignorování bezpečnostních politik způsobuje problémy. Firmu ohrožují pirátské
přístupové body i neadekvátní hlášení incidentů.
Tento týden jsem řešil dva problémy a oba byly důsledkem rutinního ignorování
bezpečnostních politik definovaných v naší firmě. První z nich se týkal naší
bezdrátové infrastruktury LAN.
Ačkoliv pracuji mimo naše hlavní datové centrum, často navštěvuji sídlo vedení
firmy, kde se centrum nachází. Při těchto příležitostech využívám iPaq Pocket
PC a software firmy AirMagnet ke skenování nepovolených přístupových bodů (AP
Access Point) ve WLAN. Instalace neautorizovaných AP představuje přetrvávající
problém, takže když jsem dnes opět našel další z nich, nebylo to pro mne žádné
velké překvapení.
Síla signálu dosahovala 70 %, což bylo dost na to, abych učinil závěr, že se
nejedná o přístupový bod umístěný mimo kanceláře firmy. K AP jsem se mohl bez
problémů připojit, otevřít okno prohlížeče a získat informace z firemního
intranetu. Na zařízení nebylo nastaveno žádné šifrování a vysílalo SSID
(Service Set Identifier Code); po připojení mi přidělilo IP adresu, která
nebyla z našeho firemního rozsahu.

Hledání
Zavolal jsem správcům sítě a poskytl jim údaje o MAC (Media Access Control)
adrese a místě, kde se nacházím. Domníval jsem se, že budou schopni přihlásit
se k přepínači, který má na starosti obsluhu daného místa, vyhledat moji MAC
adresu, port a pak i konkrétní přípojku k síti. V minulosti se mi podařilo
nepovolené přístupové body tímto postupem úspěšně najít.
Nicméně v daném případě nebyli správci schopni moji MAC adresu vyhledat.
Dokonce i když jsem nechal síťového inženýra zkontrolovat některé okolní
přepínače, nevedlo to k úspěchu. Poté jsem zkusil využít utilitu Find od firmy
AirMagnet, která funguje jako měřič síly signálu, a pomáhá tak při lokalizaci
přístupového bodu. Takto jsem se dříve dostával hodně blízko, nicméně stejně
bylo nutné nahlédnout do kanceláří jednotlivých zaměstnanců, konferenčních
místností, odpočíváren a podobně, aby bylo možné přístupový bod vizuálně
odhalit. Během takového postupu se ovšem někteří zaměstnanci rozčilovali a
začínali si stěžovat.
Tentokrát to ale fungovalo výjimečně dobře. Po chvíli jsem zahlédl onen
přístupový bod, jak leží na monitoru jednoho ze zaměstnanců.
Zmíněným zařízením byl WLAN router, což vysvětlilo, proč se moje MAC adresa
neobjevila na portu některého přepínače. Jelikož daný přístupový bod fungoval
jako směrovač, nikoliv jako hub, MAC adresa nebyla na přepínači registrována.
Dotyčný zaměstnanec nebyl v kanceláři přítomen, takže jsem požádal správu
budovy, aby jeho kancelář odemkla. Poté jsem přístupový bod odpojil a na místě
zanechal lístek se zdůvodněním, proč bylo zařízení odpojeno.
Zaměstnanec mi později sdělil, že přístupový bod nainstaloval, protože s tím
jeho šéf souhlasil. Ani jeden z nich nečetl směrnice o přístupu k našemu
intranetu, které zakazují připojování neautorizovaných přístupových zařízení k
firemní síti. Je evidentní, že naše školení o bezpečnostních pravidlech stále
nefungují. Odeslal jsem mu proto alespoň e-mailem odkaz na stránku, kde se daná
směrnice nachází.

Společné znaky
O několik týdnů dříve, právě když doznívala epidemie SQL Hammeru, jeden z
manažerů naší firmy navrhl zlepšovák. Moje malá skupina se měla nově starat o
vyřízení incidentů a jejich nápravu šlo tedy o úkol, který mají na starosti
jiná oddělení a k jehož plnění nejsme vybaveni.
Proto jsem se začal zabývat otázkou, jak tento problém vyřešit. Brzy jsem
zjistil, že skupina mající v kompetenci bezpečnost IT není jedinou, která má k
dispozici psaná pravidla, jak řešit incidenty. Operační skupina v datovém
centru má svůj vlastní, 20stránkový manuál; a oddělení pro správu sítě má také
něco podobného k dispozici. Každý z těchto materiálů obsahuje relevantní
informace s ohledem na optimální postupy při řešení incidentů ale každý z nich
je také specifický pro dané oddělení. To není příjemné zjištění. Ještě více mě
ale znepokojil fakt, že nikdo tyto dokumenty nevyužívá. Jsou prostě založeny v
pořadači na poličce nebo v elektronické podobě na sdíleném disku, kde jsou k
dispozici každému ze zaměstnanců daného oddělení. A to je vše.
Abych to napravil, vytvořil jsem jednostránkový dokument o protokolování
incidentů, který popisuje hlavní body, jež by každé příslušné oddělení mělo při
řešení incidentu podniknout. Mým cílem bylo vytvořit něco, co by bylo možno
vytisknout na malou kartičku a umístit vedle seznamu telefonních čísel,
bezpečnostní karty a SecurID tokenu, který většina těchto zaměstnanců nosí s
sebou. Zaměřil jsem se na čtyři oblasti: na přípravu, identifikaci, odezvu a
ochranu.
Příprava se týká povědomí o tom, koho v případě výskytu incidentu vyrozumět.
Identifikace řeší, jak identifikovat a klasifikovat danou událost a vyhnout se
falešných poplachům. Odezva řeší kroky, které je nutné podniknout v případech,
kdy dojde k incidentu. A ochrana se zabývá tím, jak zamezit, aby incident
napáchal další škody nebo aby dále ovlivňoval síť. Mezi způsoby ochrany patří
například vypnutí portu přepínače nebo implementace seznamu přístupových práv
na routeru.
Chtěl bych, aby tato referenční kartička pomohla zaměstnancům při efektivnějším
a včasném řešení incidentů. V budoucnosti možná vytvoříme formální krizový tým
a budeme v rámci školení provádět simulace problematických událostí.

Nikdo to nechce
I když se situace postupně lepší, stále tu přetrvávají některé běžné problémy.
Jedním z nich je fakt, že nikdo nechce převzít zodpovědnost. Kolem operačního
centra se stále pohybuje spousta manažerů, ředitelů, inženýrů a analytiků,
prohlížejí logy, e-maily a další nástroje a vytvářejí si názor. Ale nikdo z
nich nechce rozhodovat.
Dalším problémem je, že vždy existují pochybnosti o tom, kdo by měl provádět
určité činnosti. Například běžnou a jednoduchou cestou identifikace nějakého
zdroje ve Windows na síti je zadání příkazu nbstat -A. V prostředí našich
firemních desktopů a produkčních serverů tento příkaz obvykle zjistí uživatele
nebo systémový název počítače.
Ale z nějakého důvodu se pořád někdo ptá, kdo by tento příkaz měl zadat.
Opravdu nechápu proč, neboť se jedná o úkol, který zabere pouhých několik
sekund. Doufám, že s využitím psaných pravidel pro řešení incidentů, se kterými
se všichni seznámí, se nám podaří veškeré takové situace řešit standardizovaným
způsobem a řešení incidentů se stane rutinním aspektem chodu firmy.
Řešíte podobné problémy jako Mathias Thurman? Podělte se o svoje zkušenosti s
námi i se čtenáři Computerworldu. Můžete psát na adresu bezpecnost@idg.cz.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.