Bezpečnostní incident

Bezpečnostní incident je událost v IS, která způsobila narušení důvěrnosti, integrity, dostupnosti nebo neodmítnutelnosti informace v důsledku selhání bezpečnostních opatření nebo porušení bezpečnostní politiky.

Za bezpečnostní incident se často považuje i podezření na porušení bezpečnostní politiky nebo pokus o překonání bezpečnostních opatření. Bezpečnostní incident má obvykle tento průběh: detekce incidentu – analýza incidentu – reakce na incident. Detekce může být automatická na základě informace z nějakého monitorovacího systému nebo manuální tzn., že incident někdo nahlásí. Společnost, která má zájem bezpečnostní incidenty efektivně řešit, by měla vydat odpovídající bezpečnostní standard a vhodnou formou s ním seznámit všechny zaměstnance. Dalším krokem je sestavení týmu, který bude za příjem hlášení, evidenci a šetření incidentů zodpovědný. Zahraniční literatura používá pro označení takového týmu zkratku ISIRT neboli Information Security Incident Response Team. Počet členů ISIRT závisí na počtu incidentů a velikosti organizace. Je zřejmé, že pokud má takový ISIRT fungovat, musí disponovat i odpovídajícím vybavením a pravomocemi.

V bezpečnostním standardu by mělo být uvedeno:

• co je to bezpečnostní incident, vhodné je uvést ve formě přílohy i nějaké příklady bezpečnostních incidentů.
• komu se má bezpečnostní incident hlásit. (Měla by být uvedena adresa na intranetu, e-mail, telefon i adresa pracoviště, protože  je třeba počítat s tím, že síťová infrastruktura nemusí fungovat.)
• jakou formu má hlášení o bezpečnostním incidentu mít. Standard by měl obsahovat ve formě přílohy formulář pro hlášení bezpečnostního incidentu.

U bezpečnostních incidentů bychom měli evidovat:

• kdy k incidentu došlo – vzhledem k tomu, že incident může souviset s jinou událostí, je vhodné vždy zjistit přesný čas.
• kde k incidentu došlo – přesné určení místa a jeho popis umožní vyšetřovacímu týmu rychle reagovat.
• kdo incident spáchal – identitu útočníka může být někdy obtížné zjistit, přesto bychom se měli pokusit získat o něm co nejvíce relevantních informací.
• jak k incidentu došlo – někdy nemáme dostatek informací, nicméně měli bychom se pokusit alespoň o pravděpodobný scénář popisu průběhu incidentu.
• co bylo cílem útoku – měli bychom také rozlišit, zda byl systém přímo cílem útoku nebo sloužil k přípravě na další útok.
• jaký atribut bezpečnosti byl narušen – tzn. zda byla narušena integrita, důvěrnost, dostupnost nebo neodmítnutelnost.
• jaký byl charakter narušení  – zda narušení bylo úmyslné nebo neúmyslné. A pokud neúmyslné, tak zda plynulo z nedbalosti nebo z neznalosti bezpečnostní politiky.
• jaké opatření bylo překonáno – zda bylo překonáno opatření na úrovni fyzické, logické, organizační, personální nebo technické bezpečnosti.
• jaké aktivum bylo narušeno – hardware, software (operační systém, aplikace, databáze), síť, data.
• jak vysoká je pravděpodobnost, že se incident bude znovu opakovat – spíše nízká, střední, vysoká, jistá.

Samotnou otázkou zůstává na základě čeho stanovit závažnost incidentu. Nabízí se několik řešení. Závažnost incidentu můžeme stanovit na základě hodnoty dopadu. V takovém případě se ptáme, jaký finanční nebo nefinanční dopad incident na danou společnost měl nebo by mohl mít. Jiným řešením je stanovit závažnost incidentu podle počtu a odbornosti lidí, kteří se na řešení incidentu podíleli. Lze předpokládat, že na řešení různých incidentů se bude podílet různý počet osob nebo týmů s různou úrovní znalostí.

Zjednodušený postup při šetření bezpečnostního incidentu:

1. identifikovat, kde k bezpečnostnímu incidentu došlo,
2. co nejrychleji zamezit dalším škodám,
3. analyzovat příčinu a zajistit stopy pro další analýzu,
4. odstranit příčinu a obnovit funkčnost,
5. zhodnotit škody,
6. navrhnout a implementovat vhodná opatření k zamezení opakování tohoto incidentu,
7. seznámit ostatní s výsledky šetření.

V praxi bývá dost často problém se splněním bodu 3, protože management většinou požaduje okamžitou obnovu provozu a na zajištění důkazů a zjištění příčin tak nezbývá čas. Ignorováním bodu 3 však máme značně ztížené podmínky v bodu 6, kdy bychom měli navrhnout vhodná opatření pro zamezení opakování incidentu. Volba vhodného opatření je v takových případech velice obtížná a společnosti nezbývá nic jiného než doufat, že se incident znovu nevyskytne.

Vybavení ISIRT:

• tým by měl mít vypracované postupy pro šetření jednotlivých typů incidentů a tyto postupy by měl aktualizovat s ohledem na nové typy incidentů,
• tým by měl mít vypracovaný komunikační plán, aby bylo zřejmé, kdo má koho informovat, kdo rozhoduje o dalším postupu atd.
• tým by měl mít k dispozici společnou místnost (war room), kde bude možné se v případě incidentu sejít a dohodnout se na dalším postupu,
• tým by měl mít k dispozici odpovídající SW a HW prostředky, aby si mohl např. pořídit kopii konfigurace, logů a případně i celého diskového oddílu napadeného systému.

Poznámka: Proces řízení bezpečnostních incidentů je popsán v mezinárodní normě ISO/IEC TR 18044 Information technology – Security techniques – Information security incident management. Stejně tak je možno použít Computer Security Incident Handling Guide od NIST.

A jak bezpečnostní incidenty zvládáte ve vaší společnosti vy?

Štítky: bezpečnostní incident, informační bezpečnost

Diskuse na tomto webu je moderována. Pod článkem budou zobrazovány jen takové komentáře, které nebudou sloužit k propagaci konkrétní firmy, produktu nebo služby. V případě, že chcete, aby z těchto stránek vedl odkaz na váš web, kontaktujte nás, známe efektivnější způsoby propagace.