Vjednom z posledních úvodníků (www.ranum.com ) upozorňoval Marcus J. Ranum, známý odborník na bezpečnost, co považuje za nejhloupější nápady, které byly kdy vymyšleny na poli počítačové bezpečnosti. Jeho přístup jsem shledal docela zábavným a zajímavým, takže jsme se rozhodl, že se s vámi podělím o jeho seznam hloupých nápadů, k němuž doplním své osobní poznámky a komentáře.
Podle Ranuma je prvním problémem přístup implicitního povolení. To znamená dovolit na vašem počítači všechno, co není výslovně zakázáno. Pravděpodobně jste zvědaví, kdo by tímto způsobem uvažoval o nastavení brány firewall? I když mě napadlo několik jmen mých klientů, celkem vzato máte pravdu: V dnešní době pokládáme za samozřejmé, že firewally by měly implementovat zásadu implicitně zakázáno. Vzpomeňte však na sítě bez interní segmentace... Není to právě další forma implicitního povolení? A co operační systémy, které spustí jakoukoli část neznámého kódu, přestože většina uživatelů používá pouze několik aplikací? A to se ani nezmiňuji o veškerém povyku kolem systémů IPS (systémy ochrany proti průnikům): za jejich zvučným názvem stojí obyčejné objekty, které odstraní známé útoky. Jinými slovy, nejedná-li se o známý útok, systém ho nechá projít a to je další příklad implicitního povolení.
Tím se dostáváme k druhému hloupému nápadu Ranuma: výčty špatných věcí. V podstatě se jedná o princip budování vašeho bezpečnostního systému na seznamu špatných věcí, které nechcete, aby se staly. Jako příklad si uveďme viry, spam a trojské koně: proč mrhat svým časem na vytváření seznamu tisíců nových špatných věcí, když byste mohli pouze autorizovat specifické aplikace a nic jiného na vašem počítači nespouštět? Totéž platí pro systémy na filtrování síťového provozu. Obecně lze říct, že bezpečnostní systém je založen na principu výčtů špatných věcí, když váš software neustále potřebuje aktualizace podpisů.
Je-li mottem Googlu Nebuďte zlí, rád bych doporučil, aby naše motto bylo Nebuďte hloupí. Je to těžší, než si dokážete představit, věřte mi.
Třetí hloupý nápad, který Ranum popsal, je přístup proniknout a záplatovat. Tento nápad jsem shledal jako méně přesvědčivý. Na jedné straně souhlasím s předpokladem, že existuje (několik) aplikací, například qmail nebo Postfix, které nemají téměř žádné chyby a zranitelná místa, protože byly vyvíjeny s ohledem na bezpečnost. Takže stejně jako Marcus věřím, že na poli softwarového inženýrství spočívá problém v inverzi tohoto přístupu. Na straně druhé však věřím, že v souvislosti s bezpečností sítí je pro koncového uživatele velmi prospěšné mít někoho, kdo se snaží pomocí testů průniků překonat bezpečnostní systémy. Uživatelé si pak mohou být jisti, že všechno bylo provedeno správně. Možná však nejsem ta správná osoba, která by to měla komentovat – jelikož se tolik mých klientů na to ptá.
Ani čtvrtý hloupý nápad mě nepřesvědčil: Ranum tvrdí, že bychom měli přestat uvažovat o tom, že hackování je skvělé a začít se učit, že dobré inženýrství je lepší. Má odpověď je ano i ne: k vytváření robustního softwaru jeho návrhem potřebujeme inženýry, ale také potřebujeme flexibilní myslitele, kteří zpochybní předpoklady a kteří ukáží, že to, co jsme považovali za nemožné, ve skutečnosti možné je a tím jednají jako hackeři. Samozřejmě bychom měli převrátit význam slova hackeři, pod nímž si lidé většinou vybaví whiz kid nebo guru na technologii, kteří marní své životy pronikáním do systémů prostřednictvím známých zneužití, aby na těchto systémech zpřístupnili svůj warez. Dále souhlasím s tvrzením Ranuma, že toto chování je nesmyslné.
Pátý hloupý nápad přeskočím (vzdělávání uživatelů nefunguje…). Dále bych rád dal Ranumovi osobní radu týkající se šestého hloupého nápadu: Někdy je lepší nedělat vůbec nic, než udělat něco hloupého. Dříve než promrháte desítky tisíc eur na novou a neotestovanou technologii, je lepší vynaložit peníze za člověka s potřebnými znalostmi, který vám pomůže pochopit, co máte udělat. Dříve než začnete propagovat nové bezpečnostní zásady, které zůstanou bez uplatnění, rozhodně stojí za to v první řadě pochopit, co bylo špatně.