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:
- identifikovat, kde k bezpečnostnímu incidentu došlo,
- co nejrychleji zamezit dalším škodám,
- analyzovat příčinu a zajistit stopy pro další analýzu,
- odstranit příčinu a obnovit funkčnost,
- zhodnotit škody,
- navrhnout a implementovat vhodná opatření k zamezení opakování tohoto incidentu,
- 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
K článku “Bezpečnostní incident” se zde nenachází žádný komentář - buďte první.
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.
