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.

A nezapomínejme přitom na to, že jsou minimálně dvě skupiny uživatelů tohoto nástroje, ti co incidenty hlásí a ti co je řeší. Incident může být uživatelem nahlášen telefonicky, mailem nebo přes webové rozhraní, což je z pohledu řešitele ta nejlepší varianta a z pohledu uživatele mnohdy ta nejhorší, bohužel. Bez ohledu na to, jakým způsobem je incident nahlášen, vždy by měl být spuštěn proces, jehož výsledkem by mělo být vyřešení daného incidentu. Proto také incident management zavádíme. 

Životní cyklus incidentu

Incident se během svého životního cyklu obvykle nachází v jednom z níže uvedených stavů. Vzhledem k tomu, že nástrojů na incident management je mnoho (a jeden je lepší než druhý), jsou tyto stavy pojmenovány různě, a proto musíme provést určité zobecnění.

• Detected – incident je někým nebo něčím detekován. V tomto stavu incident existuje mimo systém a ještě nebyl nahlášen na helpdesk.
• Registered – incident je v nástroji něčím nebo někým zaevidován
• Assigned – helpdesk incident vyhodnotil a přidělil ho k řešení konkrétní osobě nebo řešitelskému týmu
• Confirmed – pokud bylo přidělení incidentu helpdeskem správné, daná osoba nebo řešitelský tým incident přijetí incidentu potvrzuje
• Refused – pokud bylo přidělení incidentu helpdeskem chybné a daná osoba nebo řešitelský tým není kompetentní k řešení incidentu daného typu, tak incident odmítá. Incident se v takovém případě buď vrací na helpdesk, který musí provést nové přiřazení nebo ho může sama řešitelská skupina poslat na jinou z jejich pohledu vhodnější skupinu.
• Analyzed – incident je řešitelským týmem analyzován a je hledáno to nejrychlejší možné řešení. Cílem je, aby co nejvíce incidentů vyřešila první úroveň podpory a na další úrovně podpory se dostávalo incidentů co nejméně.
• Suspended – někdy řešitelský tým potřebuje doplnit od uživatele určité informace a po tuto dobu, co se čeká na informace od uživatele, se incident nachází v tomto stavu
• Solved – v okamžiku, kdy řešitelská skupina najde řešení daného incidentu, označuje incident za vyřešený
• Accepted – řešení je uživatelem akceptováno
• Rejected – řešení je uživatelem odmítnuto
• Closed – poté, co je řešení uživatelem akceptováno, může být incident uzavřen.

U všech stavů by mělo být definováno, jak dlouho se může incident v daném stavu nacházet. A u jednotlivých incidentů by mělo být možné tuto dobu změnit. Minimálně by měla být stanovena maximální doba řešení incidentu, resp. kdy nejpozději by měl incident přejít do stavu Closed. Je otázka, zda v okamžiku, kdy byl již incident jednou uzavřen, umožnit jeho znovuotevření, anebo založit incident nový s odkazem na ten původní. V okamžiku, kdy je čas řešení incidentu překročen, měl by na to být příslušný pracovník upozorněn.

Intuitivní rozhraní

Jestliže chcete, aby vám uživatelé hlásili incidenty prostřednictvím webového formuláře, musí být takovéto rozhraní naprosto intuitivní. Pokud uživatelské rozhraní (GUI) nebude intuitivní, nebude takovýto systém uživateli přijat a budou ho odmítat. A vězte, že ke zlepšení situace nepomůže ani sebelepší školení. Uvědomte si, že vzhledem k tomu, že uživatel obvykle nehlásí incident každý den, musí ihned pochopit, co a kam má přesně zapsat. Pokud chcete, aby uživatelé váš nástroj používali, nemělo by být k jeho použití nutné absolvovat nějaké školení nebo studovat dlouhý manuál. Jinými slovy, nástroj sám by měl uživatele vést a upozorňovat ho na to, co a kam má zapsat. Dovoluji si tvrdit, že drtivá většina uživatelů, kteří vám budou incident tímto způsobem hlásit, s počítačem běžně pracuje a je zvyklá, že určité věci fungují ve většině aplikací stejně a očekávají, že nejinak tomu bude i ve vaší aplikaci. Ovládací prvky by proto měly být na obvyklých místech. Bohužel nezřídka se ta stává, že nejen uživatelé, ale i řešitelské týmy mají problémy s danou aplikací pracovat. 

Efektivní workflow

Nástroj by měl umožňovat snadné předávání incidentu mezi jednotlivými řešitelskými skupinami. Přeposlání incidentu na další řešitelskou skupinu musí být stejně jednoduché, jako když přeposíláte e-mail. Krátce po nasazení nástroje na incident management je třeba počítat s tím, že první úroveň podpory bude některé incidenty směrovat na špatné řešitelské skupiny. Pokud helpdesk neanalyzuje, kdo nakonec incident daného typu řešil, může se stát, že bude incident přiřazovat pořád špatně. V opačném případě by se měl počet chybně přiřazených incidentů v delším časovém horizontu postupně snižovat. Předpokladem však je, že vybraný nástroj umí budovat databází znalostí (knowledgebase) a efektivně v ní vyhledávat již jednou řešené incidenty. Vždy by měla být stanovena osoba dohlížející na vyřešení incidentů v rozumném čase. Pokud není stav řešení incidentů v systému nikým monitorován, hrozí, že jednotlivé řešitelské skupiny budou jim přidělené incidenty odmítat nebo si ho budou mezi sebou přeposílat jako „horký brambor“. 

Komunikace s uživatelem

Incident by měl být v systému evidován pod jedním číslem, pouze by se měl měnit jeho status a řešitelská skupina. Uživatel, který incident nahlásil, by měl mít možnost sledovat, v jakém stavu se incident nachází. Měl by proto dostat e-mail obsahující číslo incidentu a odkaz, na kterém může stav řešení incidentu sledovat. V okamžiku, kdy se incident dostane do stavu Vyřešeno (Solved), měl by uživatel dostat e-mail s požadavkem na akceptování daného řešení. Poté, co je řešení uživatelem odsouhlaseno (Accepted) měl by incident přejít do stavu uzavřen (Closed) a uživateli by měl být zaslán informativní mail o uzavření incidentu. 

E-mailová notifikace řešitelů

Nástroj by měl umět zaslat notifikaci o tom, že řešitelské skupině byl přiřazen incident. Není možné počítat s tím, že člen řešitelského týmu se bude celý den sledovat frontu, jestli se tam náhodou něco neobjevilo. Možnost zasílání této informace by měla být zpřístupněna všem uživatelům vybraného nástroje, a měli by mít možnost si to sami nastavit. Je zřejmé, že tým, který je plně alokován na řešení incidentů a přijde mu jich několik za hodinu asi žádnou e-mailovou notifikaci potřebovat nebude, protože by ho jen vyrušovala. Avšak tým, kterému chodí jeden incident za den nebo za týden ano, protože jinak nebude reagovat v požadovaném čase. Notifikace nemusí být jen mail, může se jednat i o ikonu v tray, která se změní svůj status nebo popup okno, které se objeví v okamžiku, kdy je incident dané řešitelské skupině přidělen.

Vyhledávání

Dalším velice častým problémem některých nástrojů je, že se v nich velice špatně vyhledává. Víte, že podobný incident jste již jednou řešili, ale pochopitelně si již nepamatujete jeho číslo. Nástroj by tedy měl umožnit sestavit takový dotaz, aby bylo možné zadat klíčové slovo, jméno řešitele nebo řešitelské skupiny a případně období, kdy jste incident řešili.

Závěr: Uvědomte si prosím, že uživateli je jedno, kolik řešitelských týmu na řešení jeho incidentu spolupracuje a jak je řešení jeho incidentu náročné. Uživatel svou povinnost splnil v okamžiku, kdy vám incident nahlásil a to způsobem, který ho stál určité úsilí. Přiznejme si, že pro většinu uživatelů je mnohem jednodušší a pohodlnější zvednout telefon a incident nahlásit tímto způsobem. Vyplňování jakéhokoliv formuláře uživatele obtěžuje. Když už vám uživatel incident prostřednictvím webové aplikace nahlásil, řešte ho. Nevracejte mu incident s tím, že tam něco špatně vyplnil. Vůbec nejhorší je, když řešitelský tým vrátí incident uživateli v nejzazším možném termínu s tím, že něco špatně vyplnil. Když víte, že uživatel něco špatně vyplnil – opravte si to a neobtěžujte ho s tím. S největší pravděpodobností uživatel podobný problém v nejbližší době stejně hlásit nebude, takže argumentovat tím, že to děláte proto, aby to uživatel vyplnil příště správně, je nesmysl. Když už máte potřebu uživatele poučovat, udělejte to v okamžiku, kdy je jím nahlášený incident vyřešen.

Related posts:

1. Bezpečnostní incident: Drahý incident management
2. Bezpečnostní incident: stanovení závažnosti incidentu
3. Bezpečnostní incident

Kvantitativní analýza rizik je náročnější na zdroje a její provedení trvá mnohem déle než kvalitativní analýza rizik. Je tomu tak proto, že hodnotu aktiva je nutné vyjádřit v penězích stejně jako možnou škodu v případě realizace konkrétní hrozby. Vyjádření škody ve finančních jednotkách však umožňuje jednodušší rozhodování ve fázi zvládání rizik, kdy vybíráme vhodná opatření.

Kvalitativní analýza rizik je méně náročná na zdroje a trvá kratší mnohem kratší dobu než kvantitativní analýza rizik. Především proto, že hodnotu aktiva není nutné vyjadřovat v penězích stejně jako možnou škodu v případě realizace konkrétní hroby. To však vede k horší kontrole nákladů ve fázi zvládání rizik, kdy vybíráme vhodná opatření.

Vyjádření škody ve finančních jednotkách má jednu obrovskou výhodu a to, že nám umožňuje porovnat výši škody a celkové náklady na opatření. To u slovního popisu rizika není dost dobře možné, protože chápaní stupňů nízký, střední, vysoký nebo kritický, může být značně subjektivní. V takovém případě totiž nevíme, jak velkou finanční škodu tyto stupně vlastně vyjadřují. Následující tabulka se snaží zachytit výhody a nevýhody kvantitativní a kvalitativní analýzy rizik. 

Pokud jste teď začali počítat plusy a mínusy ve snaze zjistit, která metodika je lepší, zapomeňte na to. Výše zmíněné metodiky nestojí proti sobě, ale vzájemně se doplňují. Kvalitativní analýzu rizik obvykle provádíme v okamžiku, kdy potřebujeme rychle zhodnotit a určit největší rizika, která společnost ohrožují. Jakmile tato rizika známe, můžeme je začít detailně zkoumat. V tuto chvíli je již použití kvantitativní metodiky na místě.

Poznámka: To, že kvantitativní analýza rizik poskytuje poměrně přesné, nikoliv zcela přesné výsledky, je uvedeno záměrně, protože i zde dochází k odhadu pravděpodobnosti výskytu dané hrozby a výše škody.

Závěr: V předchozích příspěvcích jsme si uvedli, jak provést kvalitativní a kvantitativní analýzu rizik. V tomto příspěvku jsme si popsali výhody a nevýhody těchto metodik. Obě metodiky, ač jsou v této podobě ve světě běžně používány, obsahují jednu zásadní slabinu, která při kvantifikaci rizika nebo vyjádření výše škody může být příčinou značně nepřesných nebo zavádějících výsledků. To, že lze analýzu rizik provést i jinak a tuto slabinu eliminovat, je uvedeno v knize „Řízení informačních rizik v praxi“.

Related posts:

1. Analýza rizik: kvantitativní analýza rizik
2. Analýza rizik: kvalitativní analýza rizik
3. Analýza rizik: Jemný úvod do analýzy rizik

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.

Kvalitativní analýza rizik je založena na expertním odhadu jednotlivých aktiv, hrozeb a zranitelností a pro jejich vyjádření používá slovního nebo číselného hodnocení. Umožňuje tak poměrně snadno a rychle identifikovat ta největší rizika.

Analýza aktiv

V tomto kroku bychom měli identifikovat všechna pro společnost kritická aktiva a následně stanovit jejich hodnotu. Uvědomte si, že v případě nežádoucího zpřístupnění, změny nebo zničení informací nejenže přijdete o zisk, ale budete muset i zaplatit pokutu nebo penále, protože např. nebudete schopni poskytovat své služby v souladu s SLA. Obvykle se nejprve sepíší všechna aktiva a poté se slovně ohodnotí jejich důležitost pro společnost např. jako nízká, střední, vysoká nebo kritická. Kolik stupňů používáte pro stanovení hodnoty aktiva vy a na základě čeho tuto hodnotu stanovujete?

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

Analýza hrozeb

V tomto kroku bychom měli analyzovat hrozby, kterým je společnost vystavena. U každé hrozby bychom měli stanovit pravděpodobnost jejího výskytu tzv. probability nebo likelihood. Jestliže se hrozba vyskytuje minimálně jedenkrát ročně, můžeme hovořit o tom, že pravděpodobnost výskytu hrozby je jistá. Pokud se daná hrozba prakticky nevyskytuje, můžeme hovořit o tom, že pravděpodobnost výskytu dané hroby je nízká. Kolik stupňů používáte pro stanovení pravděpodobnosti hrozby vy a na základě čeho ji stanovujete?

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

Analýza zranitelností

V tomto kroku bychom se měli zamyslet nad tím, jaká je míra zranitelnost daného aktiva vůči působení dané hrozby. V okamžiku, kdy stanovujeme míru zranitelnosti, již bereme v úvahu implementovaná opatření, která účinnost hrozby snižují. V případě, že víme, že žádné opatření ke snížení zranitelnosti nasazeno není, můžeme míru zranitelnosti daného aktiva označit jako kritickou. Pokud se obáváme, že opatření spíše selže, můžeme zranitelnost označit jako vysokou. Pokud doufáme, že opatření spíše neselže, můžeme zranitelnost označit jako střední. A konečně, pokud jsme přesvědčeni, že opatření nikdy neselže, můžeme zranitelnost daného aktiva označit jako nízkou. Kolik stupňů používáte pro stanovení míry zranitelnosti vy a na základě čeho ji stanovujete?

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

Stanovení výše rizika

V okamžiku, kdy známe hodnotu dopadu (A), pravděpodobnost hrozby (T) a hodnotu zranitelnosti (V), můžeme přistoupit ke stanovení rizika (R). Oproti kvantitativní analýze rizik, kde je způsob výpočtu víceméně daný a nikdo ho nezpochybňuje, tak v případě kvalitativní analýzy rizik neexistuje pouze jediná možnost, jak se dobrat výsledku. Možnost zvolit si v podstatě jakoukoliv stupnici pro stanovení hodnoty aktiv, hrozeb a zranitelností představuje sice na jednu stranu výhodu, ale na stranu druhou to komplikuje srovnávání výsledků AR provedených nejrůznějšími společnostmi.

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

Poznámka: V mezinárodních standardech se dočtete, že jediná podmínka je, aby metodika výpočtu rizika byla uvedena, poskytovala porovnatelné a měřitelné výsledky a v případě, že dojde ke změně hodnoty aktiva, hrozby nebo zranitelnosti, tak aby došlo i ke změně hodnoty rizika. To vede k tomu, že kromě asi nejčastěji používaného vzorce, kde se riziko počítá jako součin jednotlivých veličin (R=A*T*V), je možné použít i vzorec, který stejné veličiny sčítá (R=A+T+V), neboť i ten splňuje výše uvedený požadavek. Že v obou případech dojdeme při použití stejných měřítek k rozdílnému výsledku, snad není nutné zdůrazňovat.

Závěr: V praxi musíme učinit několik zcela zásadních rozhodnutí a to, jakou metodiku výpočtu použít a kolik použít stupňů pro hodnocení aktiv, hrozeb, zranitelností a výsledného rizika. Dále, pokud máme rizika prioritizovat, musíme určit, nejen kolik úrovní rizik budeme používat, ale i kde budou jednotlivé úrovně začínat a končit resp. jakých hodnot mohou jednotlivé úrovně rizik nabývat. Ale o tom si povíme někdy příště. 

Related posts:

1. Analýza rizik: kvantitativní analýza rizik
2. Analýza rizik: kvantitativní vs. kvalitativní
3. Analýza rizik: Jemný úvod do analýzy rizik

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.

• management of the Servers team (around 50 ppl)
• responsibility for the development, conception and cooperation of all entities in the given region
• management of budget, optimization of costs of the department
• setting up the processes and cooperation with other teams in ICT
• close cooperation of the other teams on development of services
• cooperation and negotiations with external suppliers

Požadovaná kvalifikace a další požadavky:

• At least 5 years of proven people management experience in IT copany
• University Degree (preferably ICT)
• Experience with management of bigger teams (30-50 ppl)
• Experience with OS – Windows or Unix
• Knowledge of HW platforms (Intel, Midrange, …)
• Experience with virtualization (VMWare, …)
• Fluent English and Czech

Specific requirements:

• Professional responsibility, self-action, reliability
• Excellent communication and analytical skills
• Creativíty
• Integrity, independente
• Ability to work under pressure

We Offer:

• Work in prestigious international copany
• On-going professional training and development
• Attractive remuneration package and motivating bonus schneme
• Extensive benefits package including five weeks holiday, lunch voucher, laguage courses, contributory pension scheme,contribute to health care, culture and sport activities

Druh smlouvy: permanent
Pracovní úvazek: full time

Related posts:

1. ICT Project Manager – Development for Retail/SME
2. ICT System Analyst – Operations – Prague

• Cooperate with technical expert teams of ICT Operations (Infrastructure, Application Support, Service Desk, Data Centres) in the area of audits carried out in their domains
• Follow-up on all on-going and planned audits, as well as cater for implementation of audit recommendations
• Actively participate in audits carried out in all areas of ICT Operations as konsultant
• Proactively cooperate and check that system security policies are being correctly implemented by all operational teams
• Contribute for increasing the infrastructure security with participating on security policy definitions and reviews
• Support ICT management in dealings related to concrete audit inquiries
• Provide regular reporting on progress achieved in solution of audit recommendations

Požadovaná kvalifikace a další požadavky:

• Thorough knowledge of ICT operations environment (HW, SW, databases, networks)
• Ability to understand and analyze technical issues
• Good negotiation skills and assertiveness combined with common sense
• Initiative, responsibility, and reliability in problem solving
• Emphasis on discipline in quality of outputs in terms of content, timing, and administration
• Knowledge of English on at least intermediate level (both spoken and written)
• Command of standard office software applications (Excel, PowerPoint, Word)
• Master degree recommended

We Offer:

• Work in prestigious international copany
• On-going professional training and development
• Attractive remuneration package and motivating bonus schneme
• Extensive benefits package including five weeks holiday, lunch voucher, laguage courses, contributory pension  scheme,contribute to health care, culture and sport activities

Druh smlouvy: permanent
Pracovní úvazek: full time

Related posts:

1. ICT Manager – Servers
2. ICT Project Manager – Development for Retail/SME

• Participation on ICT development projects – responsibilities for the range of supply, resources, budget, quality and terms during the full life cycle of project
• Planning and preparation of projects-cooperation with Architects and Business Analysts
• Management of internal and external teams and suppliers
• Communication with internal clients, top management of ITC, reporting
• Use of new methods and technologies in ICT and Project Management

Požadovaná kvalifikace a další požadavky:

• At least 4 years of proven project management experience – development projects
• University Degree (preferably ICT or banking)
• Experience with management and realization of bigger ICT projects
• Experience with coordination of external suppliers
• Experience with SCRUM is a big advantage (or other PM metodology -PRINCE2, PMI)
• Good knowledge of ICT and SW development
• Fluent English and Czech necessary

Specific requirements:

• Professional responsibility, self-action, reliability
• Excellent communication skills
• Analytical skills and problem-solving skills
• Team player
• Creative
• Motivated and leading personality
• Flexibility (overtimes)
• Integrity

We Offer:

• Work in prestigious international copany
• On-going professional training and development
• Attractive remuneration package and motivating bonus schneme
• Extensive benefits package including five weeks holiday, lunch voucher, laguage courses, contributory pension scheme,contribute to health care, culture and sport activities

Druh smlouvy: permanent
Pracovní úvazek: full time

Related posts:

1. ICT Manager – Servers
2. ICT System Analyst – Operations – Prague