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?

Pokud vás tento příspěvek zaujal, sdílejte ho!
Email this to someone
email
Share on LinkedIn
Linkedin
Tweet about this on Twitter
Twitter
Share on Facebook
Facebook
Print this page
Print

Štítky: ,


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.

Přihlášeným uživatelům se tento formulář nezobrazuje - zaregistrujte se.

Jméno:(požadováno)
E-mail:(požadováno - nebude zobrazen)
Web:

Text vaší reakce: