V počátcích informatiky nepředstavoval auditing a monitoring informačního systému téměř žádný problém, neboť každá organizace měla zpravidla jen jeden informační systém, ke kterému se uživatelé připojovali prostřednictvím terminálů a vytvářel se tak pouze jeden log. Správce takového systému pak nastavil, které události se mají do logu zaznamenávat, a log pak pravidelně vyhodnocoval. Nyní je však nutné vzhledem k existenci enterprise architektury sbírat, korelovat a analyzovat události ze všech vrstev mnoha různých systémů. Takové vyhodnocování už nelze provádět ručně, a pokud má být tato činnost dostatečně efektivní, je nutné za tímto účelem nasadit specializované řešení, které se nazývá SIEM (Security Information and Event Management).

Poznámka: Auditingem se v tomto příspěvku myslí auditní protokolování neboli zaznamenávání vybraných událostí do logu, rozuměj do souboru. Monitoringem pak vyhodnocování těchto událostí a reakce na ně. Jedná se tedy o dvě naprosto rozdílné aktivity.

Auditing

Prvním krokem je identifikace systémů a zařízení, které budou zapojeny do centrálního monitorovacího systému. To můžete provést například na základě analýzy rizik, kdy určíte, které servery a zařízení obsahují, zpracovávají a přenášejí kritická a citlivá data nebo poskytují důležité služby. Poté musíte vybrat události, které se mají logovat. Jsou systémy, kde se provádí detailní logování všech aktivit, včetně příkazů zadaných uživatelem z příkazového řádku, což znamená disponovat velkou diskovou kapacitou. V neposlední řadě musíte určit dobu, po kterou se budou jednotlivé události uchovávat a způsob jejich archivace. Logování je možné provádět na úrovni:

• operačního systému,
• aplikace,
• databáze,
• sítě a síťových prvků.

V okamžiku, kdy se vám budou vytvářet auditní logy na jednotlivých serverech a zařízeních, musíte zajistit, že jednotlivé události budou přeneseny do centrálního úložiště nebo proběhne jejich záloha dříve, než dojde k jejich přepsání novými událostmi. Nezapomínejte, že informace uvedené v logu jsou nezbytné pro zpětnou rekonstrukci činností uživatele v systému a odhalování bezpečnostních incidentů a jejich šetření. Aby mohly být tyto záznamy uznány jako důkazní materiál, je nutné je chránit před nežádoucí modifikací. Obvykle se to řeší tak, že se logy buď kopírují v původní nezměněné podobě do geograficky vzdálené lokality, nebo se přímo tam vytvářejí. Tento požadavek jsou samozřejmě schopny zajistit i některá specializovaná SIEM řešení. Dodavatel by vám měl být proto schopen odpovědět na otázku, jak se provádí deployment a jak je zajištěna komunikace mezi centrálním serverem a dohlíženými zařízeními. Existují zde určitá rizika, jako podvrhnutí zařízení, modifikace přenášených dat, zahlcení centrálního serveru falešnými událostmi apod. Dle způsobu přenosu logů resp. jednotlivých událostí rozlišujeme řešení:

• s agentem (agent) – aktivní řešení, kdy na každém stroji, který má být dohlížen, je nainstalován agent. Agent může být komerční aplikace nebo může mít podobu skriptu. Agent zasílá všechny nebo vybrané události, které se zapisují do auditního logu na centrální server. Jedná se o metodu push, kdy agent „tlačí“ data na centrální server.
• bez agenta (agent less) – pasivní řešení, kdy se žádný agent neinstaluje, centrální server se připojuje ke konkrétním serverům a zařízením a sám si události z auditního logu načítá. Jedná se metodu pull, kdy agent „tahá“ data z auditních logů.

V obou případech pak na centrálním serveru, ke kterému je připojen velkokapacitní disk nebo diskové pole, dochází ke zpracování jednotlivých událostí v těchto několika krocích:

• agregace (gathering, centralization, collecting) – události z různých systémů resp. z jejich logů jsou stahovány na jedno místo.
• normalizace (normalization) – vzhledem k tomu, že události jsou v logách uloženy v různém formátu a tvaru, musí být nejprve převedeny do stejného formátu a poté mohou být uloženy do příslušných polí v dané DB tabulce.
• korelace (correlation) – nad událostmi, které jsou uloženy v DB v normalizovaném tvaru, je možné provádět nejrůznější SQL dotazy a tím odhalovat bezpečnostní neshody.
• reportování (reporting) – patří sem zasílání alertů na vybrané adresy, generování reportů apod.

Pokud hovoříme o centrálním serveru, nemusí se nutně jednat o jeden server, nýbrž o několik spolupracujících serverů, kdy např. několik serverů provádí agregaci a parsování a ukládá data do DB a další server zase provádí analýzu těchto událostí.

Agregace

Abyste byli schopni stanovit odpovídající požadavky na HW konfiguraci a diskový prostor, musíte alespoň přibližně spočítat:

• jaký bude počet událostí za konkrétní časové období,
• průměrnou velikost události,
• úspěšnost komprese, neboť naprostá většina událostí se opakuje a liší se jen minimálně.

V okamžiku, kdy se budete návrhem architektury a výběrem vhodného řešení zabývat, měli byste vzít v úvahu, že požadavky na logování budou růst, protože budou přibývat uživatelé a systémy. Měli byste se proto ptát, jaká je škálovatelnost daného řešení, zda budete moci použít vlastní DB nebo jen DB dodávanou s daným produktem. Kolik systémů budete moci dohlížet a jaká je cena za licenci? Dost často se platí za počet dohlížených zařízení, tak abyste pak nebyli nemile překvapeni.

Normalizace

Příchozí události se musí normalizovat, protože pokud mají být uloženy ve společné databázi, musí být zajištěno, že se do příslušných databázových polí budou ukládat odpovídající položky. Doporučujeme následující strukturu, tzv. W7 formát, kdy jsou v DB následující pole:

• Who – Kdo je původcem dané události? Účet.
• What – Co se stalo, resp. o jakou událost se jedná?
• When – Kdy se událost vyskytla?
• onWhat – Jakého objektu se daná událost týkala?
• Where – Na jakém stroji k události došlo?
• WhereFrom (Whence) – Odkud událost přišla? Stroj.
• WhereTo – Jaký systém byl cílem události?

Dále byste měli zajistit, aby byl na všech systémech synchronizovaný čas, a bylo možné jednoznačně určit identitu uživatele, neboť na různých systémech může vystupovat pod různými jmény. To ovšem předpokládá nějaké propojení s identity managementem (IAM).

Korelace

V okamžiku, kdy vám začne do DB chodit obrovské množství událostí, měli byste sledovat a vyhodnocovat i souvislosti mezi nimi. Ty nemusí být na první pohled vůbec zřejmé a bez použití SIEM nástroje je prakticky nemožné je odhalit. Pro vyhodnocování souvislostí se používá pojem korelace. Pro sledování souvislostí mezi událostmi si však musíte vytvořit vlastní korelační pravidla. Pokud již SIEM nástroj nějaká korelační pravidla obsahuje, pak zpravidla jen pro síťové prvky, ale už ne pro UNIX, LINUX nebo Windows. Vždy byste se měli ptát, jak snadné je nastavit pravidla pro vyhodnocování souvislostí a zda lze jednotlivé alerty kategorizovat, tj. stanovit jim určitou prioritu. Některá SIEM řešení v rámci korelace provádějí i vyhodnocování souvislostí s jinými událostmi, z jiných organizací, a jsou tak schopni odhalit incident ve vašem systému dřív, než nastane.

Reporting

Způsob, jakým SIEM řešení hlásí podezření na bezpečnostní incidenty je neméně důležitý. Obvykle bývá u každého SIEM řešení k dispozici konzole, na které se zobrazují alerty. Pokud konzole neprovádí deduplikaci, stává se v určitých případech nepoužitelnou. Deduplikace funguje tak, že pokud se objeví stejný alert, tak nepřibude další řádek na konzoli, ale jen se aktualizuje počet udávající četnost výskytu a datum a čas posledního výskytu daného alertu. Další důležitou vlastností je vytváření a automatické generování přehledných reportů a jejich zasílání odpovědným osobám.

Monitoring

Dost často se v praxi rozlišují dva druhy monitoringu. Tzv. provozní, který si IT většinou dělá samo, nebo který outsourcuje a dále bezpečnostní monitoring, který bývá provozován odděleně a u kterého dost často není jasné, kdo by ho měl vlastně provádět. V případě, že je provozní a bezpečnostní monitoring realizován odděleně, mohou nastat situace, kdy se šance na včasné odhalení incidentu výrazně snižují. V praxi narazíte na problém, že nevíte, zda to, že žádný incident nebyl detekován, není proto, že by daná událost vůbec nenastala, ale proto, že server někdo kompromitoval, agenta deaktivoval nebo změnil rozsah auditování.

V případě některých společností může být auditing a monitoring vyžadován přímo legislativou, jedná se např. o požadavky definované v BASEL II, SOX, HIPPA, FISMA nebo PCI DSS.

Provozní monitoring

Provozní monitoring spočívá ve vyhodnocování aktuálního stavu systému, tzn., že se sleduje zatížení CPU, množství dostupné paměti, volného místa na disku, počet I/O operací, zatížení sítě. Tyto parametry se sledují především proto, že překročení některé z hodnot často vede k nedostupnosti služby a porušení SLA. A nedostupnost na rozdíl od narušení důvěrnosti a integrity uživatel zjistí obvykle hned. Samozřejmě se mohou vyskytovat i krátkodobé peaky, na které není třeba bezprostředně reagovat, ale je o nich dobré vědět, protože tyto informace mohou být velice cenné v rámci kapacitního plánování (capacity planning).

Bezpečnostní monitoring

Cílem bezpečnostního monitoringu je odhalit pokusy o překonání bezpečnostních opatření. Spoléhá se tedy na nastavení auditingu a události, které se objeví v auditním žurnálu a které jsou následně uloženy v centrální databázi, nad kterou probíhají vlastní dotazy a vyhodnocování souvislostí. Na tomto místě bych rád zdůraznil, že žádné SIEM řešení nemůže splnit svůj účel, pokud není správně nastaven auditing. Nezapomínejte, že SIEM pouze pracuje s událostmi, které se objeví v auditním logu.

Alert

V případech, kdy je detekován nestandardní stav nebo podezřelá událost, je vygenerován alert. Tím se zpravidla rozumí hlášení na obrazovce, ale může se jednat i o zaslání mailu nebo SMS na vybranou adresu nebo telefonní číslo. Alert může být generován již po prvním výskytu události nebo při splnění určitých podmínek. Např. v okamžiku, kdy počet událostí nebo nějaká hodnota překročí tzv. threshold. Reakce na alert může automatická ze strany systému nebo vyžaduje nějakou interakci ze strany lidské obsluhy. Z těchto důvodů je vhodné, aby bylo možné jednotlivým alertům přidělit nějakou závažnost (severitu), která určuje prioritu řešení. Jinými slovy stanovuje, jakému alertu by se měl operátor věnovat nejdříve.

Závěr: V praxi se ukazuje, že ani nástroje, které jsou označovány jako SIEM nepokrývají všechny potřeby organizace a spoustu věci je nutné doprogramovat, což představuje dodatečné náklady. Mnohé organizace také v minulosti nakoupily nějaký SIEM nástroj, ale nedokázaly ho již plně využít, protože nebyly schopny vydefinovat, jaké události a odkud se mají sbírat a jak se mají vyhodnocovat. A pokud se jim to podařilo, tak zase neurčily osobu nebo útvar, který by se o SIEM staral a dál ho rozvíjel. Je třeba si uvědomit, že SIEM, pokud má splnit svůj účel, je nutné průběžně upravovat, aby dokázal reagovat na měnící se podmínky. Ideální by bylo takové SIEM řešení, které by dokázalo spolupracovat s DLP, IAM, EZS a docházkovým systémem. S takovým řešením však dosud žádný dodavatel nepřišel. Výzvou do budoucna pro SIEM nástroje je tedy vyšší míra integrace a porozumění informacím hlášených z různých typů zdrojů tak, aby systém byl schopen reagovat proaktivně na potencionální hrozby.

No related posts.

Asi zde nemá smysl sáhodlouze vysvětlovat, že phishing či chcete-li rhybaření je podvodná technika, mající za cíl získat citlivé údaje, například údaje o vaší platební kartě včetně PINu. Oběť obvykle obdrží mail, který se tváří jako důvěryhodný a snaží se jí přesvědčit, aby klikla na odkaz, který ji přesměruje na pro tento účel vytvořené webové stránky, které obsahují formulář sloužící k zadání citlivých údajů (obvykle jméno a heslo apod.). Takto nasbírané údaje pak bývají hned zneužity nebo dále prodávány na černém trhu.

V případě phishingu sami a zcela dobrovolně tyto údaje poskytnete, většinou v domnění, že mail pochází od dané firmy a, že se nacházíte opravdu na jejich stránkách. Ono totiž odhalit pravé stránky od phishingových bývá mnohdy velmi obtížné a pokud se vám toto podaří a přihlásíte se např. do pravého e-shopu, ještě nemusíte mít vyhráno, stejně jako Karel v následujícím příběhu.

Karel je běžný uživatel internetu ve středních letech. Má ženu, dvě děti a konečně našel to, co hledal – vytoužený přípravek pro vylepšení intimního soužití. Za takto nízkou cenu ho nabízí pouze jeden e-shop. Ano, e-shop vypadá trochu podezřele, nabízí neuvěřitelné množství produktů za bezkonkurenční ceny. Má sice ruskou doménu, ale za trochu riskování to snad stojí, ne? Už tyto skutečnosti by měly zodpovědného uživatele odradit od nákupu.

Karel objednává zboží a k uhrazení částky použije svoji platební kartu. Bez mrknutí oka zadá číslo karty, datum exspirace i CVV2 kód a už se těší na dodaný preparát. Za několik dní skutečně přijde objednané zboží. Zdá se, že vše proběhlo naprosto v pořádku, avšak jen do té doby, než Karel obdrží zvláštní email. V e-mailu Karla vybízí osoba vystupující jako bezpečnostní expert, aby kontaktoval banku a policii, protože údaje o jeho platební kartě byly zcizeny. Aby Karel skutečně uvěřil, že se jeho údaje dostaly do nepravých rukou, jsou tyto údaje v e-mailu uvedeny jako důkaz.

Skutečně je to tak, jak si myslíte. Na e-shop byl proveden útok, a útočník hacknutím serveru získal obsáhlou databázi. Nezapomínejte, že údaje o Karlově platební kartě, tedy údaje, které umožní provést platbu na internetu, byly uloženy v databázi e-shopu. (Nemysleli jste si doufám, že by tento e-shop dodržoval požadavky uvedené v PCI DSS?)  Karel by tedy měl neprodleně požádat banku o zablokování platební karty.

Tentokrát to dopadlo naštěstí dobře. Karel kartu včas zablokoval a má i zboží, které si objednal. Když si ale připočte k ceně zboží poplatek za vydání nové karty, už svůj nákup za tak výhodný nepovažuje a u daného e-shopu, který nedostatečně ochránil jeho data, si už nikdy nic nekoupí.

Výše popsaný příběh se skutečně stal. Jedná se o techniku používanou v rámci konkurenčního boje mezi firmami, které nabízejí zboží, které v mnoha státech není volně v prodeji nebo se dokonce nesmí prodávat vůbec. Jestliže tyto firmy nemají zábrany na prodeji tohoto zboží vydělávat, nemají ani zábrany najmout si hackery, aby zaútočili na jejich konkurenci, stáhli DB jejich klientů a těm následně rozeslali e-mail o tom, že daný e-shop byl hacknut a jejich údaje byly ukradeny. Je zřejmé, že příjemci mailu použijí příště jiný e-shop, třeba ten, který se ve výsledcích vyhledávání doposud objevoval níže. Ten, co byl na prvních místech, již zcela ztratil jejich důvěru.

No related posts.

Nejen domácnosti ale i firmy problematiku likvidace dat velice často podceňují. Velmi se pak podivují, když se stanou obětí nějakého útoku. Šetřením se navíc ukáže, že právě v PC nebo notebooku, který byl dán do bazaru nebo věnován jakési organizaci v rámci charitativní akce v době, kdy firma nahrazovala zastaralou výpočetní techniku novou, se nacházela citlivá data. Pokud nemáte proces likvidace dat spolehlivě ošetřen, tak vás ani sebelepší DLP řešení neochrání.

Fyzická likvidace

Firmy by měly přijmout zásadu, že v okamžiku, kdy jakýkoliv nosič informací definitivně opouští prostory jejich firmy, tak musí být fyzicky zlikvidován nebo musí být data na něm uložená bezpečným způsobem odstraněna. S likvidací optických medií a disket firmy obvykle nemívají problém a proces likvidace zapracovaly do svých interních instrukcí, neboť je v celku prostý. Takové médium stačí vhodit do skartovačky nebo zlomit. S HDD je to bohužel horší, ale i zde existují jednoduchá řešení. Pokud nechcete likvidaci provádět sami, tak na trhu je dost firem, které vaše média za úplatu rádi zlikvidují, mnohdy i ekologicky. Taková likvidace pak spočívá v rozebrání HDD na jednotlivé díly, sešrotování a roztavení. Pravda, některé z těchto firem se s nějakým rozebíráním nezdržují a na drcení HDD používají několika tunový skartovací stroj a vzniklou drť pak roztaví v peci a vydají o celém procesu likvidace, kterému může přihlížet i zákazník, certifikát.

Přepsání náhodnými daty

Pokud nechcete médium fyzicky zlikvidovat, narazíte zpravidla na problém, jak data bezpečně odstranit. Prosté smazání souborů totiž obvykle nestačí, neboť např. Windows soubory nemažou, ale pouze pozmění hlavičku souboru a v alokační tabulce a označí příslušné místo jako volné. Takto smazaná data není příliš velký problém obnovit, neboť na internetu je k dispozici spousta nástrojů, které to hravě zvládnou. Ty, co jsou zdarma, nejsou vždy úspěšné a všechny smazané soubory neobnoví, nicméně lze si připlatit a zakoupit profesionální řešení, které si s tímto problémem snadno poradí.

Demagnetizace

Kromě fyzické likvidace médií nebo bezpečného přepsání dat náhodnými daty je možné použít i demagnetizátor (degausser). Jedná se o nejrychlejší metodu, jak data z HDD spolehlivě odstranit. Je třeba si však uvědomit, že HDD se poté stává prakticky nepoužitelným, protože kromě dat dojde i ke zničení informací, které byly na disk zapsány v továrně při nízko-úrovňovém formátování (Low-Level Format zkr. LLF). Mimochodem, víte o tom, že se vyrábí i demagnetizátory, které se montují přímo do počítačové skříně?

Několikanásobné přepsání náhodnými daty

Jediný způsob, jak data bezpečně odstranit, je přepsat celý disk náhodnými daty. Podrobný návod na likvidaci obsahuje např. US Standard DoD 5220.22-M nebo NIST 800-88 Guidelines for Media Sanitization. Na internetu lze stejně jako v případě nástrojů na obnovu dat najít i nástroje na jejich bezpečnou likvidaci, např. Darik’s Boot and Nuke, KillDisk nebo Eraser. Pozor, pouhý jeden přepis trvá několik hodin a doporučovaný několikanásobný přepis např. Gutmannovou metodou, vyžadující přepis 35násobný, může v případě velkokapacitních disků trvat dokonce i několik dní. Tvrzení, že pouze několikanásobný přepis je dostatečnou zárukou, že data již nebude možné obnovit, spoustu firem odradilo a  na bezpečnou likvidaci dat zcela rezignovaly. Data na médiu nepřepsaly ani jednou a spokojily se s pouhým smazáním nebo zformátováním. Zde je jasně vidět, k čemu vedou přehnané požadavky na bezpečnost.

Je opravdu nutný několikanásobný přepis?

Pokud používáte nový HDD, tak již není nutné provádět několikanásobný přepis média, aby data byla spolehlivě odstraněna a nemohla již být obnovena. Je třeba si uvědomit, že doporučení provádět několikanásobný přepis vzniklo v době, kdy se používal krokový motorek, hustota záznamu byla nízká a okolo každého bitu se vyskytovala oblast, která reprezentovala předešlý zápis. Změřením analogového signálu přímo na plotně tak bylo možné zjistit původní data (rozuměj, zda se tam nacházela jednička nebo nula). Dokonce i NIST (The National Institute of Standards and Technology) prohlásil, že většinu současných HDD stačí přepsat pouze jednou a toto tvrzení bylo nezávisle potvrzeno i několika dalšími experty. Rozdíl mezi tím, jak byla data na HDD ukládána dříve a nyní je zachycen na tomto vtipném videu od firmy Hitachi.

Který způsob likvidace dat je nejlepší?

Pokud potřebujete bezpečně zlikvidovat data, máte několik možností, jak toho dosáhnout. Můžete fyzicky zlikvidovat dané médium, použít degausser nebo médium jednou přepsat náhodnými daty. Fyzická likvidace je jediná metoda, u které si můžete být jisti, že vaše data si již nikdo nepřečte. U ostatních metod musíte věřit, že produkt dělá to, co jeho výrobce deklaruje, protože není tak snadné ověřit, že data na médiu opravdu nejsou. Kdo je nedůvěřivý, tak si může data na médiu náhodnými daty přepsat sám. Ať už budete likvidovat data jakýmkoliv způsobem, dejte pozor, abyste neudělali kozla zahradníkem. Osoba likvidací dat pověřená by si mohla data před přepsáním zkopírovat nebo si HDD odnést domu, podle rčení: „Co je doma, to se počítá.“

Přesun výpočetní techniky v rámci firmy

V rámci firmy není nutné pevné disky likvidovat, ale data na HDD byste měli před předáním PC novému uživateli raději přepsat, nikdy nevíte, kdo daný PC dostane a kdo ho měl předtím. Pokud HDD obsahuje jen jednu partišnu a před přidělením PC novému uživateli se systém reinstaluje, což silně doporučujeme, je pravděpodobné, že dojde i k přepsání většiny dat. Pokud však vaše IT rozděluje HDD na 2 partišny, kdy se na jedné nachází systém a druhá je určena výhradně pro uživatelská data, je bezpečná likvidace dat zcela na místě.

Pozor, HDD nejsou jen v počítačích

Nezapomínejte, že počítače nejsou jediná zařízení, která obsahují data, ale že ta se nachází i v paměti smartphonů a na HDD některých velkokapacitních tiskáren a multifunkčních zařízeních (MultiFunction Device, zkr. MFD). Problém je mnohem závažnější, než se na první pohled zdá. Jde o to, že na HDD některých MFD mohou být uloženy i citlivé informace, které měl sice autorizovaný uživatel právo vytisknout, ale které se již neměly dostat nikomu jinému do rukou. Že tomu tak ale kolikrát není, je zachyceno na následujícím videu.

Poznámka: Ukazuje se, že problematice bezpečnosti tiskáren se stále nevěnuje dostatečná pozornost. Červi jako Blaster nebo Sasser jsou názorným příkladem toho, že mohou představovat vážné riziko i pro síťové tiskárny. Ostatně není se čemu divit, když uvážíme, že některé tiskárny běží na skutečném operačním systému (např. Xerox WorkCenter) a je celkem jedno, zda se jedná o Windows nebo Linux. Je zřejmé, že i samotné tiskárny je třeba zabezpečit a SW v tiskárnách (firmware, OS a vlastní aplikaci) aktualizovat. Obzvlášť, když počet odhalených zranitelností u síťových tiskáren rok od roku roste. Nejde jen o to, že útočník může získat přístup k důvěrným dokumentům, ale může z těchto tiskáren vést poměrně snadno díky přítomnosti plnohodnotného OS jakýkoliv útok. Několik možných útoků na tiskárny Xerox předvedl již před drahnou dobou např. Brendan O’Connor na Black Hat konferenci v Las Vegas.

No related posts.

Hashovací funkce je jednosměrná/jednocestná/irreversibilní funkce, které můžeme jako parametr předat libovolně dlouhou zprávu a na jejím výstupu pak obdržíme tzv. hash nebo-li otisk o délce x-bitů. Důvod, proč se o této funkci hovoří jako o jednocestné, je ten, že z výstupu této funkce nejsme schopni zpětně vygenerovat vstup, který byl jejím parametrem. Jinými slovy, z hashe nelze odvodit původní zprávu.

Trocha teorie

Nejznámější a nejpoužívanější hashovací funkce jsou z rodiny SHA (Secure Hash Algorithm) a číslo za pomlčkou udává délku hashe, který tyto funkce generují, tzn. že algoritmus SHA-256 generuje hash o délce 256 bitů, SHA-384 o délce 384 bitů atd. Pro úplnost dodejme, že hashovací funkce SHA-0 a SHA-1 generují hash o délce 160 bitů a MD5 (Message-Digest algorithm 5) o délce 128 bitů. Ale dost již teorie, podívejme se raději na konkrétní příklad, kdy budeme chtít vytvořit otisk pro slovo „hash“ a „hesh“, které předáme jako parametr funkci MD5.

MD5(‘hash‘) = 0800FC577294C34E0B28AD2839435945
MD5(‘hesh‘) = AD8E9EC499F16542D9AC8873DDEF9AFE

Vidíme, že výsledkem výše uvedené funkce je hash, který je dlouhý přesně 32 znaky a pouhá změna jednoho písmene (v tomto případě záměna „a“ za „e“) způsobila vygenerování naprosto odlišného hashe. Všimněte si, že hash je reprezentován zápisem v hexadecimální (šestnáctkové soustavě), kdy nám na vyjádření jednoho znaku z množiny 0123456789ABCDEF stačí pouhé 4 bity (2^4=16). Vynásobíme-li počet znaků hashe (32) počtem bitů (4), dostaneme 128 bitů. Chtěl bych podotknout, že pokud známe délku hashe, můžeme pouze hádat, jaký algoritmus byl použit.

Praktické využití

V praxi se využívá obou vlastností hashovacích funkcí a to, že pro libovolně dlouhý text je možné vytvořit jedinečný a přitom poměrně krátký hash a dále, že z hashe nelze zjistit původní zprávu. Hashovací funkce tak lze využít pro kontrolu integrity dat a pro uložení hashů hesel. V prvním případě se pro příslušná data spočte hash a ten se uloží na bezpečné místo a v okamžiku, kdy potřebujeme ověřit, zda se daná data nezměnila, spočteme hash znovu. Pokud se hashe neshodují, je zřejmé, že integrita dat byla narušena. Ve druhém případě si uživatel zadá heslo, spočte se pro něj hash a ten je pak následně uložen v systému. Výhoda spočívá v tom, že z hashe není možné zjistit, jaké heslo si uživatel zadal.

Další případ, kdy se běžný uživatel může s otisky setkat, je např. v okamžiku, kdy stahuje nějaký SW ze serveru a ten vedle odkazu na stažení daného souboru uvádí i odpovídající hash. Pokud uživatel stahuje z nedůvěryhodného zdroje, byť by se jednalo o mirror, měl by se vždy snažit získat hash z oficiálních stránek výrobce a po stažení daného souboru ho pro daný soubor spočítat a hashe porovnat. Mohlo by se totiž stát, že ten kdo daný SW ke stažení poskytuje, do něj přidal malware (škodlivý kód) – častý to případ nejrůznějších cracknutých verzí drahých komerčních produktů v P2P sítích a internetových úložištích. (Zde navíc ani nemáte možnost hash proti čemu porovnat, protože poskytovaný soubor musí být už z principu jiný než originál.) Pokud budete kontrolu vámi vygenerovaného hashe provádět proti hashi, který jste našli na stejném serveru, ze kterého jste stahovali daný soubor nebo proti hashi, který byl uveden ve staženém archivu, je to naprosto zbytečné. Protože pokud útočník soubor pozměnil, vygeneroval k němu nejspíš i odpovídající hash.

Jiný případ je, že byste chtěli ověřit, zda nebyla pozměněna integrita souborů, které se již nachází na vašem počítači nebo serveru. Za tímto účelem se používají programy na kontrolu integrity, které on-line počítají hash pro jednotlivé soubory a porovnávají je proti již dříve vypočteným hodnotám získaných ihned po instalaci.

Poznámka: Je vhodné sledovat, které hashovací funkce se podařilo prolomit a ty již raději nepoužívat. V současné době by se již neměly používat např. algoritmy MD5 a SHA-1. Vzhledem k tomu, jak hashovací funkce fungují, může se stát, že dvě naprosto různé zprávy budou mít stejný hash. Nemělo by se to stát, ale může, a o této skutečnosti se pak hovoří jako o kolizi. Cílem autorů hashovacích funkcí tedy je, aby pravděpodobnost vzniku těchto kolizí byla co nejmenší. Pokud by bylo snadné vygenerovat dvě různé zprávy, které by měly stejný hash, mohlo by být této vlastnosti zneužito k nejrůznějším podvodům.

No related posts.

Oba tyto případy jsme si již popsali. Na trhu je několik firem, které DLP řešení nabízejí. V principu se ale nejedná o nic převratného. Snaha zabránit uživatelům, kteří přijdou do styku s citlivými informacemi v jejich zneužití, je stará jako lidstvo samo a v historii se tento požadavek řešil různě.

Datové ploty

Nejinak tomu bylo i v oblasti počítačové bezpečnosti, kdy se první řešení objevila již někdy v 80. letech minulého století. Tato řešení, nazývaná datové ploty, umožňovala zkopírovat data jen na předem schválená média (diskety), kde byla navíc zašifrovaná, takže uživatel si je mimo firmu nemohl přečíst a v případě ztráty média se k datům též nikdo nedostal. Ve své době se však toto řešení nijak výrazně neuchytilo a v okamžiku, kdy se na trhu objevila velkokapacitní média a stále více firem se začalo připojovat do internetu, se od datových plotů upustilo úplně. Nejspíš proto, že data bylo možné zcizit mnohem pohodlnějším způsobem.

DLP

Nyní zažívá řešení, které by mělo úniku citlivých informací zabránit, jakousi renesanci. Je otázka, do jaké míry to souvisí s hospodářskou krizí a snahou zaměstnanců se odškodnit zcizením dat, ke kterým mají v rámci své pracovní činnosti legitimní přístup. (Této problematice jsme se věnovali v příspěvku Řízení informační bezpečnosti v době krize). Dále se musíme ptát, zda jsou to opravdu zaměstnavatelé, kteří chtějí tuto situaci nasazením nějakého produktu řešit anebo sami výrobci těchto produktů, kteří této situace chtějí využít a přicházejí na trh s datovými ploty ve verzi 2.0 s krycím názvem DLP. Ať už je to ale jakkoliv, lze v zásadě rozlišit dvě DLP řešení a to host based a network based. Tato řešení, která mohou být nasazena samostatně nebo spolupracovat, si dále stručně popíšeme.

Host based DLP

Host based DLP (hostitelská), jak již název sám napovídá, se instalují na koncových zařízeních ve vnitřní síti. Tím je možné sledovat, jak uživatel s citlivými informacemi zachází a detekovat tak každý pokus o zkopírování citlivých informací na USB flash disk, vypálení na optický disk, vytisknutí na tiskárně, přenos přes sériový či paralelní port nebo bluetooth. Toto DLP řešení obvykle detekuje i pokus o printscreen nebo zkopírování dat přes schránku a vložení do nového dokumentu a zašifrování tohoto souboru. Je asi zbytečné zdůrazňovat, že pokud má být ochrana pomocí tohoto DLP řešení účinná, musí být tento produkt nainstalován na každém zařízení.

Network based DLP

Network based DLP (síťová) se instaluje na vyhrazený server v perimetru, který analyzuje veškerý webový a e-mailový provoz a snaží se detekovat, zda ze společnosti touto cestou neunikají citlivá data. Toto řešení má nižší TCO, neboť ho není nutné instalovat na všechny koncové stanice, ale logicky není schopno pokrýt všechny cesty, kterými mohou informace unikat.

Úskalí implementace DLP

Bez ohledu na to, jaké DLP řešení a od jakého výrobce se nakonec rozhodnete nasadit, narazíte na jeden problém a tím je definice pravidel. Jedná se o vůbec nejnáročnější fázi implementace DLP řešení a dost často také nejhůře provedenou a značně podceňovanou. Pravidla totiž nelze nastavit stylem nastav a zapomeň. Někdo se tomu musí opravdu věnovat a pravidla přizpůsobovat aktuálním potřebám firmy, reagovat na měnící se podmínky a vyhodnocovat jejich účinnost.

Bez klasifikace informací to nejde
Jestliže má systém detekovat snahu o zcizení citlivých dat, musí někdo definovat, co jsou to vlastně ta citlivá data a jak reagovat v případě, že k pokusu o jejich zcizení dojde. Znamená to tedy v první řadě klasifikovat data a definovat klíčová slova, které má systém vyhledávat. Kromě toho tato pravidla a klíčová slova musí stanovit business, neboť nikdo jiný to za něj neudělá. Nemůže to udělat ani firma, která DLP řešení dodává, ani ICT, které ho bude spravovat a dokonce ani pracovník informační bezpečnosti, protože ten o businessu obvykle také nic neví. Tihle všichni mohou businessu jen pomoci.

Pravidla vytvářejte rozumně
Nezapomínejte také na to, že mnoho informací uniká jen z pouhé nedbalosti a nevědomosti, takže to, že se zaměstnanec snaží poslat citlivé informace na freemail, nemusí být nutně proto, že by je chtěl ukrást, ale proto, že mu jeho poštovní program jako první nabídnul adresu kolegy nikoliv na firemním mail serveru, ale na internetu a daný zaměstnanec si toho nevšiml. V takovém případě by se měl systém zaměstnance dotázat, zda tuto akci chce opravdu provést a zobrazit mu vysvětlení, proč by to dělat neměl. Toto pravidlo však může fungovat jen v případě, že si někdo s nastavením jednotlivých pravidel dá práci a varovné hlášky se objevují, jen když to má smysl. Pokud taková hláška vyskakuje na uživatele v podstatě pořád, uživatel ji už ani nečte a naopak ji zcela automaticky odklikává.

Otestujete si důkladně vybrané DLP řešení
Důrazně doporučujeme vámi zvolené řešení před vlastním nasazením důkladně otestovat v reálném prostředí, protože v minulosti měly některé produkty se zajištěním ochrany citlivých informací problémy. Data bylo možné vynést např. díky nástroji pro synchronizaci dat s mobilním telefonem nebo pouhým vytisknutím na tiskárně.

Závěr: Ani na DLP řešení se nelze plně spolehnout a znovu je třeba připomenout, že celý systém je tak bezpečný, jak silný je jeho nejslabší článek. Např. v okamžiku, kdy zaměstnanci nic nebrání v tom, aby si do sítě společnosti připojil svůj vlastní notebook, může si citlivá data na svůj notebook prakticky bez jakéhokoliv omezení zkopírovat, neboť dané DLP řešení je v tuto chvíli zcela mimo hru. Zde názorně vidíme, proč je bezpečnost třeba řešit komplexně a implementovat vhodná opatření na úrovni fyzické, logické i organizační bezpečnosti a usilovat o tzv. přístup security-in-depth nebo chcete-li multilayered security.

No related posts.

Zamysleme se nejdříve nad původem tohoto slova. Vzhledem k tomu, že se internet na nejrůznějších obrázcích znázorňuje jako mrak nebo chcete-li oblak a stále více společností nabízí své služby na internetu a přes internet jsou i jejich služby dostupné, je vznik tohoto slova celkem logický. Z pohledu uživatele je tak vše, co se nachází mimo jeho síť, oblak (cloud).

Paralela se skutečným mrakem je též na místě. Mrak se pohybuje a mění a množství srážek se dá jen odhadnout. A stejně je to i s cloud computingem. Množství počítačů v oblaku, jejich umístění, celkový výkon a zdroje, ke kterým přes internet přistupujeme, se též mění stejně jako počasí. Kromě toho nevíme, kde se jednotlivé stroje, které poskytují dané zdroje, fyzicky nacházejí, ani jak jsou zabezpečeny. Také architektura celého řešení zůstává našim zrakům skryta. Jedná se o supercomuter, cluster nebo grid?

Vznik cloud computingu

Myšlenka využít výpočetní výkon a zdroje jiných počítačů je sice zajímavá, ale rozhodně není nová, jak se nás snaží mnohé firmy přesvědčit. Služba vznikla tak, že některé velké společnosti zjistily, že výpočetní kapacita jejich datového centra je nevyužita, obzvláště v noci, kdy jejich servery zahálí, zatímco na opačné straně zeměkoule, kde je den, by mohly být účelně využity a tak se rozhodly volnou výpočetní kapacitu a zdroje nabízet. Tím vznikli první poskytovatelé cloud computingu neboli CSP (Cloud Service Provider).

Typy cloud computingu

Podle toho, jak moc je společnost, která služeb CSP využívá, odstíněna od vlastní správy IT zdrojů, můžeme rozlišit několik typů cloud computingu.

• SaaS – Software-as-a-Service – softwarové aplikace jsou poskytovány přes web, jako je např. Google Apps nebo Salesforce. Bezpečnost je řešena na úrovni aplikací. Tím, že je aplikace používána spoustou uživatelů na celém světě, je lákavým cílem hackerů, a proto je obvykle i dobře zabezpečena.
• PaaS – Platform-as-a-Service -  poskytuje nástroje pro vývoj webových služeb, IDE, runtime aplikační platformu, vše pro zajištění SDLC bez nutnosti cokoliv vlastnit. Bezpečnost je řešena na úrovni middleware.
• IaaS – Infrastructure-as-a-Service -  jsou za úhradu poskytovány IT zdroje (operační paměť, procesorový čas, diskový prostor). Platí se za množství uložených dat, spotřebovaný procesorový čas. Uživatel má plnou kontrolu nad infrastrukturou.

Bezpečnost v cloudu a rizika

Pokud hovoříme o jednotlivých typech cloud computingu, máme tím především na mysli poskytované IT zdroje a služby přes internet a za úplatu. Cloud computing je úžasná věc, ale je třeba se bavit i o bezpečnosti a rizicích, která vyplývají ze samé podstaty této služby. Např. možnost dynamicky přidělovat potřebné zdroje pouhým odebíráním a přidáváním serverů v cloudu vede k tomu, že CSP může být někdo jiný, než ten, kdo skutečně spravuje dané fyzické servery a jejich zdroje, které jsou v rámci cloudu využívány. Zamysleme se proto nad tím, jak je v cloudu zajištěna dostupnost, důvěrnost a integrita.

Dostupnost

Dostupnost služby je pro business obvykle kritická. CSP však dostupnost služby nemůže dost dobře garantovat, protože závislost na internetové konektivitě a politické a ekonomické situaci v nejrůznějších zemích na světě je značná. Připomeňme DDoS útok na cloud botnetem Bredolab, který zahltil více než 700 000 uživatelů Facebooku nebo DDoS útoky vedené proti Estonsku a Gruzii. Kromě toho může dojít k problémům přímo u CSP. Uvědomte si, jak tato služba vznikla – domácnosti a společnosti daly dobrovolně část své výpočetní kapacity k dispozici ostatním. V okamžiku, kdy porostou vaše požadavky, nemusí je být schopen CSP uspokojit, protože nebude disponovat potřebnými zdroji. Někdy zase můžete zjistit, že kvůli rychlé odezvě je žádoucí, aby byl cloud relativně blízko k uživatelům. Také dost často zmiňovaná podpora 24/7 je v podstatě nutnost, aby vůbec tahle služba mohla fungovat a byla dostupná přes internet prakticky z celého světa a z různých časových pásem.

Důvěrnost

Kde jsou vlastně uložena vaše data, jak je k nim řízen přístup, nemůže se k nim dostat jiný zákazník, který služeb stejného CSP využívá? Kolik zaměstnanců CSP má k datům přístup? Jak je na tom CSP s fyzickou, logickou a administrativní bezpečností? Jak jsou virtuální stroje, na kterých celé řešení běží bezpečné? Jak jsou data na cloud přenášena? Řešením je sdílet data jen nezbytně nutná, šifrovat je a nasadit DRM. Ale co se s daty stane v okamžiku, kdy se rozhodnete ukončit smlouvu? Budou data v cloudu opravdu smazána? To znamená, budou smazána z disku a prostor označený jako volné místo bude přepsán náhodnými daty nebo bude jen zrušen link do úložiště a smazán účet?

Integrita

Data v cloudu nebo i aplikace mohou být pozměněny neoprávněnou osobou. Mohli bychom si zde položit stejné otázky jako v předchozích bodech a stejně obtížně bychom na ně hledali odpověď, protože u CSP je obecně omezená možnost provádět kontrolu a audit. A navíc neexistuje ani žádná norma pro cloud computing. To se však snaží změnit Cloud Security Alliance (CSA), která na vytvoření bezpečnostních norem pro cloud computing pracuje. Je otázka, jak budou tyto normy v praxi dodržovány a kontrolovány.

Když se však nad jednotlivými riziky zamyslíme, musíme si položit otázku, zda se nejedná o stejná rizika, jako když společnost svěří správu svého IS jiné společnosti (outsourcing) a své výpočetní středisko přesune do jiné země, kde je to pro ni ekonomicky výhodnější (offshoring). V podstatě ano, byť určité rozdíly zde jsou. Společnost, která se rozhodne využít služeb CSP, nemá obvykle dostatek finančních prostředků a schopností, aby mohla cestovat přes půlku světa a provést audit CSP a dohodnout specifické podmínky, za kterých jí bude služba poskytována a musí vzít za vděk obecnými podmínkami, které pro ni nemusí být výhodné. Velká společnost si to však může dovolit a uzavřít odpovídající SLA.

Je cloud computing výhodný?

Společnost, která se rozhodne využít služeb CSP, nemusí vlastnit prakticky žádný HW a SW, neboť ten jí poskytne právě CSP. Nemusí zaměstnávat početné IT týmy, které by se staraly o správu infrastruktury. Tomu potom společnost platí za využité služby a zdroje (typicky v desítkách centů za uložený gigabajt dat, hodinu práce CPU či za použití aplikací). Ve své podstatě se nejedná o nic jiného, než o klasický outsourcing a offshoring. Vzhledem k tomu, že společnost nemusí investovat své finanční prostředky do budování vlastního výpočetního střediska a pořizování drahého HW a SW vybavení, může tímto způsobem výrazně snížit své náklady. Další úspora spočívá v tom, že platí pouze za využité služby a zdroje. To, že platí pouze za zdroje skutečně spotřebované, je podstatné, protože její požadavky na zdroje se budou v průběhu roku měnit. Zde je nutné zdůraznit, že tradiční přístup neumožňuje společnosti řešit tuto situaci jinak, než že si pořídí dostatečně výkonný server, který je v době mimo špičku nevyužit. Ale i společnosti, které na trhu již nějakou dobu fungují a často mají svůj (většinou proprietární) SW, mohou zvážit, zda se jim některý z typů cloud computingu nevyplatí. Pokud budeme chtít posoudit, zda je některý z typů cloud computingu pro nás výhodný či nikoliv, měli bychom se zaměřit na zhodnocení bezpečnosti, nákladů a použitelnosti u jednotlivých CSP. 

Bezpečnost

Posouzení, jak je zajištěna důvěrnost, integrita a dostupnost u jednotlivých CSP, může být v praxi obtížné a dost často se budeme muset spokojit s čestným prohlášením jednotlivých CSP, protože možnost ověření těchto tvrzení je značně komplikované.

Náklady

Platí se čistě za spotřebovaný čas a zdroje, což je většinou výhoda. Je otázka, zda se služba od určitého objemu dat a požadavků na zdroje neprodraží nebo zda nenarazíme na nějaký limit, který bychom v případě, že bychom měli vlastní řešení, nemuseli řešit. Řešení je samozřejmě vysoce škálovatelné, ale CSP nemusí být schopen nebo ochoten včas reagovat na vaše požadavky.

Použitelnost

Služby cloudu jsou dostupnost v podstatě odkudkoliv a business tak může být snadno přesunut do jakékoliv destinace na světě, ovšem je otázka, zda by byl stejně snadný i přechod k jinému CSP. Obávám se, že nikoliv, neboť i zde může vzniknout situace označovaná jako vendor lock-in.

Poznámka: K napsání tohoto příspěvku mě inspirovala přednáška Dr. Eugene Schultz a Dr. Joss Wright o bezpečnosti cloud computigu, kteří vystoupili na 11. ročníku mezinárodní konference Information Security Summit, která se konala ve dnech 26. – 27. 05. 2010 na Novoměstské radnici v Praze. Dr. Eugene Schultz předpokládá, že poroste počet incidentů v cloudu a zákazníci budou požadovat vyšší bezpečnost a firmy se jí budou snažit nabízet. Cena poskytovaných služeb cloud computingu se bude snižovat. Servery však nebudou vzhledem k četným útokům vždy dostupné a firmy budou přehodnocovat, zda nižší náklady stojí za to riziko a budou se vytvářet regionální cloudy. Dr. Joss Wright je v otázce dalšího vývoje prosazování cloud computingu mírně optimističtější, byť též upozorňuje na mnohá rizika spojená především s právní otázkou zajištění soukromí a ochrany osobních údajů, které však domácí uživatele většinou netrápí a řešení tohoto problému vidí mimo jiné v nasazení homomorfního šifrování.

A kacířská myšlenka na závěr. Není nakonec ten cloud comupting mnohdy zabezpečen lépe, než datová centra mnoha různých firem, které si jen namlouvají, že mají ochranu svých systémů a dat pod kontrolou?

No related posts.

Tento příspěvek vznikl na základě hysterie, která se rozpoutala kolem úniku hesel ze serveru RockYou.com. V tomto příspěvku však nechci řešit, jak je možné, že se útočník k heslům dostal, zda byla či nebyla v DB uložena v otevřeném tvaru, kdo za to nese odpovědnost apod. Ne, chtěl bych se spíš věnovat tomu, jak byl tento incident mnohými bezpečnostními experty vyhodnocen a k jakým dospěli překvapujícím závěrům. A závěr bezpečnostních expertů byl naprosto jednoznačný. Uživatelé bezpečnost podceňují a používají slabá hesla. Ostatně, pokud na prvním místě, co se týká četnosti použití, figuruje heslo 123456, tak snad není ani možné dospět k jinému závěru, že. Neexistuje ale i nějaké jiné vysvětlení?

Heslo 123456 je super

Pojďme se podívat se na celou tu hysterii kolem slabých hesel z pohledu uživatele. Jestliže je uživatel nucen se na kdejakém webu registrovat jen kvůli tomu, aby se dostal k tomu, co potřebuje, tak co udělá? Stiskne prostě klávesy, které jsou nejblíže. A  zadání posloupnosti 123456 na numerické klávesnici se přímo nabízí. Že je to slabé heslo tyto uživatele vůbec netrápí, protože i kdyby dané heslo někdo uhádnul, tak k čemu mu bude? Bude moci hlasovat v anketě, dostane se na články jen pro registrované uživatele, bude moci psát urážlivé komentáře v diskusi pod článkem, změnit vzhled profilu. Přijde tím snad oprávněný uživatel účtu k nějaké újmě? Těžko. Na internetu totiž málokdo používá skutečnou identitu, a jedna fyzická osoba má dost často i několik různých identit pro nejrůznější účely. A ty se slabými hesly používá právě pro weby, které ho s registrací otravují.

Homo economicus

Bezpečnostní experti sice bijí na poplach a pozastavují se nad tím, jak je možné, že se tolik uživatelů chová tak nezodpovědně a používá slabé heslo. Nechová se ale naopak většina uživatelů naprosto racionálně a ekonomicky? Řekl bych, že ano. Což ještě neznamená, že se chovají vždy správně. Proč by měl ale uživatel vyvíjet nějaké úsilí za účelem vytvoření a zapamatování si bezpečného hesla, když mu to nepřináší vůbec žádný užitek? Problém je v tom, že registrace je často vyžadována nikoliv kvůli bezpečnosti, ale z čistě marketingových účelů. Uživatele proces takovéto účelové registrace značně obtěžuje a nevidí jediný rozumný důvod, proč by se měl autentizovat jen proto, aby se dostal k informaci nebo službě, která by z jeho pohledu měla být dostupná všem. Dle našich průzkumů uživatel volí slabá hesla dokonce i tam, kde se za obsah a službu platí. Pro mnohé je toto zjištění překvapující, ale důvod je opět prostý. V okamžiku, kdy přihlašovací údaje uživatele použije někdo jiný, tak užitek oprávněného a platícího uživatele se tím nijak nesníží. Škoda vznikne pouze a jenom provozovateli dané služby, který přijde o příjem, který by mu generoval nový klient.

Slabé heslo

Některá rizika zde přesto hrozí. A to, že uživatel slabé heslo zadá i na webu, kde by měl použít heslo silné. Ne proto, že by byl tak hloupý a nevěděl jak vytvořit silné heslo, ale protože už je tak zmatený z těch webů, kde požadavek na autentizaci nemá opodstatnění, že si v té chvíli neuvědomí, jaká rizika mu v konkrétním případě hrozí. Paradoxně skutečnost, že je autentizace vyžadována všude, tedy i tam, kde nemá smysl, vede uživatele k tomu, že volí slabá hesla, aby už ten otravný proces registrace měli za sebou.

Poškození dobrého jména

Problém může nastat v okamžiku, kdy daný web změní rozsah poskytovaných služeb a umožní např. zasílání zpráv mezi svými uživateli. V takovém případě by mohl být účet chráněný slabým heslem zneužit pro šíření spamu nebo nežádoucích názorů. A to může v krajním případě vést až zahájení vyšetřování, v rámci kterého pak může být identifikována i skutečná osoba, která si učet na daném webu založila a ta potom hnána k odpovědnosti. Nezapomínejme, že byť je identita virtuální, s větším či menším úsilím lze téměř vždy dohledat konkrétní fyzickou osobu.

Závěr: Uživatelé volí taková hesla, která odpovídají hodnotě informací, které potřebují chránit nebo výši škody, kterou jsou schopni ustát. Jestliže jsou přesvědčeni, že by na daném webu nemusela být autentizace žádná, berou tento požadavek jako zbytečné obtěžování a volí hesla, která se dají snadno zapamatovat a rychle zadat. Pokud chceme hodnotit, zda se uživatelé chovají nezodpovědně, nemůžeme tak činit pouze na základě hesla získaného z nějaké databáze. Vždy se musíme ptát, za jakým účelem byl daný účet vytvořen, jaké je uživatelské jméno, kolikrát byl účet použit a především, jaká rizika z jeho případného zneužití vyplývají pro uživatele.

Related posts:

1. Autentizace: mnoho hesel uživatelova smrt
2. Autentizace: zapomenuté heslo a kontrolní otázka
3. Autentizace: zasuň token

Dnes budeme hledat způsob, jak zabránit úniku dat z nedbalosti. K úniku informací může dojít i z nedbalosti zaměstnance, který únik informací způsobí svým nezodpovědným chováním. Pro úplnost ještě dodejme, že nedbalost může být vědomá i nevědomá. Rozdíl spočívá v tom, že zatímco v prvním případě zaměstnanec věděl, že by svým nezodpovědným chováním mohl způsobit únik informací, tak své chování nezměnil a v nepřiměřené míře spoléhal na to, že k úniku nedojde. Ve druhém případě zase zaměstnanec netušil, že by svým chováním mohl únik informací způsobit.

Je zřejmé, že v obou případech byla podceněna personální a administrativní bezpečnost. Buď byl vybrán pracovník, který má sklon se nezodpovědně chovat a bezpečnostní předpisy obcházet a ignorovat nebo nebyl dostatečně proškolen v tom, jak má s citlivými informacemi zacházet. Stejně tak je ale možné, že bezpečnostní standard jak zacházet s citlivými informacemi nemá daná společnost vypracovaný vůbec. V příspěvku o ILM zaznělo, že informace musí být chráněny během celého jejich životního cyklu a to v úložišti, během přenosu i při samotném používání či případné likvidaci. Pokusili jsem se zformulovat několik doporučení, které by měly v případě, že se jimi budou zaměstnanci řídit, riziko úniku informací výrazně snížit.

1. Šifrujte data

   V okamžiku, kdy zařízení ztratíte, bude vám ukradeno, rozbije se, dáte ho do bazaru, tak se k vašim datům nikdo nedostane. V případě, že byl zvolen dostatečně silný šifrovací algoritmus a byl správně naimplementován, má útočník mizivou šanci, že se k datům dostane.

2. Skartujte data

   Někteří bezpečnostní experti doporučují data místo bezpečného přepisu šifrovat. Tento názor se občas objevuje i v renomovaných periodikách. My ho však nesdílíme a to z jednoho prostého důvodu a to, že data na médiu zůstanou a nikdo neví, zda se třeba za rok neobjeví nějaká zranitelnost v algoritmu, který byl pro šifrování použit. Také výkon PC a jeho komponent v čase roste, což může usnadnit útok hrubou silou (brute force attack). Stejně tak se k datům může dostat i bývalý zaměstnanec, který zná heslo a může data dešifrovat. Likvidujte bezpečně i nosiče informací. Smazání nebo formátování nestačí. Jsme přesvědčeni, že nejspolehlivější formou likvidace dat je jejich přepis, případně fyzická likvidace daného média.

3. Zálohujte data

   Pokud budete mít data pouze na jednom místě, jste vystaveni riziku, že o svá data přijdete v důsledku havárie, ztráty nebo krádeže daného zařízení. Dejte si ale pozor, kam zálohujete. Zálohovat citlivá firemní data do úložiště kdesi na internetu, není zrovna nejlepší nápad. Obliba těchto služeb však mezi uživateli stoupá a mnohými magazíny jsou dokonce doporučovány. Např. jeden redaktor deníku E15 doporučil čtenářce v čísle 133, zálohovat firemní data na internet.

4. Neponechávejte zařízení a média bez dozoru

   Ke ztrátě nebo zcizení může dojít kdekoliv, na pracovišti, doma na cestě. Při přepravě mějte neustále zavazadlo obsahující notebook u sebe. Nenechávejte ho položený na sedadle ani ho nestavte na zem. Je jedno, kde jste, zda ve vlaku, autobusu nebo ve svém autě. Dost krádeží se odehrává na zastávkách a křižovatkách. Notebook můžete přepravovat v kufru, ale nenechávejte ho tam, když auto opustíte.

5. Uzamykejte obrazovku

   V případě, že se potřebujete od svého notebooku vzdálit a nechcete nebo nemůžete ho vzít sebou, uzamkněte alespoň obrazovku.

6. Uklízejte po sobě

   Nevyzvednuté papíry na tiskárně nebo ponechané v zasedací místnosti po skončení prezentace, workshopu nebo jiné akce mohou pro útočníka představovat velice zajímavé informace. Stejně tak nenechávejte tyto dokumenty na svém stole.  Jedná se o zásadu čistého stolu neboli „clean desk policy“. Takový hacker se pohrabe i v koši. Vznešeně se tomu říká „dumpster diving“ a je to naprosto běžná technika, jak se velice snadno a rychle dostat k zajímavým informacím.

7. Zabraňte odpozorování

   V okamžiku, kdy pracujete na veřejném místě, v parku, v kavárně, ve vlaku, kdokoliv se vám může dívat přes rameno. Sedněte si tak, aby to nebylo možné, např. abyste za sebou měli zeď.

8. Nediskutujte na veřejnosti

   Nikdy nevíte, kdo váš hovor může náhodou zaslechnout a pro koho pracuje. Pokud nemáte jistotu, že váš hovor nemůže někdo slyšet a jste si vědomi, že záležitost, o které se svým partnerem hovoříte, by mohla být pro konkurenci zajímavá, zvolte jiné téma hovoru.

9. Nesdílejte citlivá data

   Rozhodně ne prostřednictvím nezabezpečených freemailů, internetových úložišť, webových aplikací, instant messengerů, diskusních fór a sociálních sítí typu LinkedIn nebo Facebook.

Poznámka: Nezapomínejte, že nedbale se může chovat i správce systému, který nastavuje práva a konfiguruje systém, snadno se tak může stát, že svou nedbalostí způsobí, že data, která měla být přístupná jen vybraným uživatelům, jsou najednou přístupná všem. Proto věnujte dostatek času i pravidelné revizi nastavení přístupových oprávnění.

Závěr: Zaměstnavatelé stále častěji v rámci snižování nákladů vybavují své zaměstnance služebními notebooky a vzdáleným připojením. Jaksi si ale neuvědomují, že právě možnost pracovat odkudkoliv sebou přináší i jistá rizika, kterým je nutno čelit nejen technickými prostředky, ale především zvyšováním bezpečnostního povědomí zaměstnanců v této oblasti.

A co vy, kolik z výše uvedených zásad dodržujte a máte zapracováno ve vašich interních předpisech?

No related posts.

Dost často se jedná i o deset a více hesel. Málokdo je však schopen si všechna svá uživatelská jména a hesla zapamatovat, obzvlášť v případě, když je systémem nucen si volit bezpečná hesla a ta si navíc pravidelně měnit. Uživatel se může snažit vytvořit si všude stejné uživatelské jméno, ale vzhledem k tomu, že většina uživatelů se snaží z důvodu snazšího zapamatování používat uživatelské jméno, které vychází z jejich jména nebo příjmení, poměrně brzo nastane okamžik, že jimi zvolené resp. požadované uživatelské jméno je v daném systému již použito někým jiným a tak si musí zvolit jiné.

Přiznejme si, že uživatel nemá bez použití bezpečného HW tokenu nebo nějakého SW nástroje, ve kterém by měl přihlašovací údaje do mnoha různých systémů uloženy, moc možností, jak tuto situaci řešit. Nabízí se buď používat všude stejné heslo, nebo si hesla někam poznamenávat. A nejde jen o hesla. Uživatel musí také vědět, kde má dané uživatelské jméno a heslo použít.

Nabízí se sice možnost používat stejné heslo do více systémů, ale pokud se nad problémem hlouběji zamyslíme, zjistíme, že tento přístup obsahuje určitá rizika. Jde o to, že v okamžiku, kdy dojde ke kompromitaci hesla, útočník může získat přístup i do dalších systémů, kde uživatel toto heslo používá. Možná vás v tuto chvíli napadlo, že by mohla být jen část hesla stejná a zbytek by byl pro každý systém jiný. Tahle myšlenka není nová a např. na webu  Thebitmill je uveden návod jak takové heslo vytvořit:

For example, using the phrase, “My dog has fleas:” (Mdhf), combined with a “7″, a” /” and “HtMl” might give the password, “Md7hf/HtMl” for your HotMail account (the count of 7 letters in HotMail, plus the consonants in HotMail). Using this system, your Yahoo password would be “Md5hf/Yh”.

Tento způsob tvorby však nemůžeme doporučit, protože pokud se budete řídit výše uvedeným příkladem a útočník získá vaše heslo na Hotmail, tak mu asi nedá moc práce rozlousknout i váš systém tvorby hesla. Na první pohled je vidět, že za lomítkem se nachází Velké písmeno pocházející z názvu serveru a pak následují souhlásky. Takže není problém si odvodit, jak by asi vypadalo heslo takového uživatele třeba do sociální sítě na Facebooku. Md5hf/Fb, Md5hf/FB nebo Md5hf/FcBk? Na poprvé se útočník asi nestrefí, ale po pár pokusech se mu heslo podaří zcela jistě uhádnout.

Problém je, že takové heslo nemá dostatečnou informační entropii, jinými slovy není dostatečně náhodné. Pokud ho útočník odchytí např. v okamžiku, kdy ho použijete pro autentizaci přes nezabezpečený protokol ke své poště kdesi na freemailu, nebude pro něj příliš velký problém odhalit, jaká hesla používáte i na ostatních systémech.

Poznámka: Většina SW nástrojů typu Password Manager / Password Organizers, která lze pro úschovu hesel použít, funguje na podobném principu. Uživateli stačí, když si zapamatuje heslo jen k tomuto nástroji a ten se pak stará o to, aby uložené přihlašovací údaje byly poskytnuty jen po správném zadání hesla označovaném někdy jako master key. Rozdíl mezi SW řešením a HW tokenem spočívá v tom, že HW token je bezpečnější. Mimochodem povolili byste svým zaměstnancům používat nějaký SW nástroj pro správu hesel?

Závěr: Místo obligátního závěru si pro tentokrát dovolím položit následující otázku. Většina z nás obvykle nosí při sobě několik identifikačních a autentizačních předmětů a dalších cenných aktiv. Minimálně klíče od bytu od auta, občanku, řidičský průkaz, průkaz pojištěnce, platební kartu, peněženku, mobil a případně i Opencard a nějaký ten token či identifikační kartu. Z pohledu bezpečnosti se nedoporučuje všechny tyto předměty nosit pohromadě. Jak je tedy přenášíte?

Related posts:

1. Autentizace: proč uživatelé volí slabá hesla
2. Autentizace: zapomenuté heslo a kontrolní otázka
3. Autentizace: Jak vytvořit bezpečné heslo?

Informace musí být odpovídajícím způsobem chráněny během celého jejich životního cyklu (information lifecycle), a to jak v úložišti (data at rest), tak během přenosu (data in motion), tak i při samotném používání (data in use), neboť hrozí, že by mohlo dojít narušení jejich důvěrnosti, integrity a dostupnosti. Odpovídající způsob ochrany vyplývá z jejich kritičnosti a citlivosti. Každá informace by proto měla mít stanoveného svého vlastníka, který provádí její klasifikaci a rozhoduje o tom, kdo k ní bude mít přístup a jaký. Zamysleme se nyní nad tím, jakým způsobem mohou být data chráněna před nežádoucím zpřístupněním, modifikací a smazáním.

Data at rest

K datům v úložišti by měl být řízen přístup, tím by mělo být zajištěno, že se k nim dostane jen oprávněná osoba a bude s nimi moc nakládat jen způsobem, který odpovídá její úrovni prověření. Vzhledem k tomu, že úložiště může být fyzicky ukradeno, měly by být citlivé informace šifrovány. Útočník se však může pokusit data zničit a proto by měla být data zálohována a archivována v geograficky vzdálené lokalitě. Narušení integrity je možné se bránit tím, že se data budou podepisovat nebo se budou vytvářet kontrolní součty. Zapomínat bychom také neměli na bezpečnou likvidaci již nepotřebných informací, aby je útočník nemohl snadno obnovit.

Data in motion

Během přenosu z/do úložiště mohou být data útočníkem odposlechnuta, pozměněna nebo zahozena. Z těchto důvodu je vhodné linku, po které jsou data přenášena, šifrovat, obzvlášť, když se jedná o přenos dat přes veřejnou síť jako je např. internet. Dále je vhodné jednotlivé zprávy číslovat, aby bylo zřejmé, zda dorazily ve správném pořadí nebo zda se někdo nepokusil o tzv. replay attack. Jako ochranu před nežádoucí modifikací je možné data podepsat a tím podvrženou nebo pozměněnou zprávu snadno odhalit.

Data in use

Data jsou vystavena největšímu riziku ze strany uživatele, který data pořizuje a obvykle k nim přistupuje prostřednictvím rozhraní operačního systému, databáze nebo aplikace. Aby uživatel mohl s daty pracovat, potřebuje k tomu nějaké oprávnění. Avšak v mnoha případech uživatel ani nemusí mít právo pro přístup k datům do úložiště, neboť k datům přistupuje prostřednictvím aplikace. Vzhledem, k tomu, že uživatel má k datům v rámci plnění svých pracovních povinností zcela legitimní přístup, kterého však může zneužít, měly by být jeho aktivity v systému auditovány.

ILM

Aby výše uvedená opatření byla účinná, měl by být informační systém provozován na bezpečné infrastruktuře a měla by být přijata odpovídající opatření i na úrovni fyzické a administrativní bezpečnosti. Jiný pohled na životní cyklus informace je zachycen na následujícím obrázku, který vychází ILM (Information Lifecycle Management), tak jak ho definuje společnost Microsoft. Obrázek se snaží zachytit skutečnost, že informace je v určitém čase pořízena a uložena do úložiště, odkud je v případě potřeby načtena a dále zpracovávána, měněna a opět ukládána, sdílena s ostatními uživateli a pokud již není potřeba, tak je z úložiště vyřazena resp. smazána.

Poznámka: Nezapomínejte, že úložištěm může být jakékoliv médium, na které lze uložit informaci (nejen HDD, SSD, flash disk, optický disk, ale i papír).

Závěr: Informace musí být odpovídajícím způsobem chráněny během celého jejich životního cyklu, neboť jsou vystaveny trvalému působení mnoha různých hrozeb. Opovědět na otázku, jaká bezpečnostní opatření zavést a kolik do nich investovat prostředků však není možné bez provedení analýzy rizik.

Related posts:

1. Informační bezpečnost
2. Řízení informační bezpečnosti v době krize
3. Bezpečnost-náklady-použitelnost