Máme incident!
Ako splniť oznamovaciu povinnosť a vyhnúť sa pokute

roman.fulop@nethemba.com

pavol.luptak@nethemba.com

Taxonometria incidentov

• Spôsoby incidentov:
  • hackerským útokom na informačné systémy
  • stratou počítača (tabletu, smartfónu, laptopu)
  • stratou analógových nosičov (papier, dokumenty)
• Páchatelia incidentov:
  • hackeri (priemyselná či iná špionáž)
  • interní zamestnanci
  • automatizované boty/malware
• Predmety incidentov
  • Únik osobných informácií
  • DDoS

Identifikácia incidentov

• Môže byť náročná (veľa incidentov je odhalených až po pár mesiacoch, niektoré nikdy)
• Ak útočník použije 0-day exploity (ešte nezverejnené), tak útok je možné realizovať aj na kompletne zabezpečnom a aktualizovanom systéme, pre ktorý ešte neexistujú dostupné bezpečnostné záplaty
• Ak útočník nezanechá stopy (resp. ich zmaže), útok je veľmi ťažké detegovať
• Ak útočník pristupuje z anonymizačnej siete (Tor/I2P), je častokrát úplne nemožné zistiť jeho skutočnú identitu
• Vo väčšine prípadoch sa zákazník dozvie o úniku až keď má kompromitovaný web (tzv. "defacement"), od svojich už kompromitovaných zákazníkov, prípadne keď sa mu začne útočník vyhrážať (DDoS) alebo ho vydierať (krypto)

Nahlasovanie incidentov

• Podľa GDPR legislatívy je nutné kontaktovať Úrad na ochranu osobných údajov do 72 hodín od samotného incidentu
• Nahlásenie musí byť okamžité a bezodkladné
• Identifikovať čas incidentu môže byť veľmi ťažké, kedže pri veľa incidentov sa o tom zákazník môže dozvedieť až po pár týždňoch alebo mesiacoch
• Incident štandardne nahlasuje DPO (Data Protection Officer) - Inšpektor ochrany údajov
• Ak ho nemá, tak akýkoľvek iný na to poverený človek (CISO, CTO, CIO, ...)

Môžeme veriť štátu?

• Podľa štatistík historicky došlo k mnohým porušeniam a únikom informácií priamo v slovenských a českých inštitúciách, vrátane Slovenského Národného Bezpečnostného Úradu(!)

• Pre mnoho spoločností, ktoré nedôverujú vláde a jej schopnosti ochrániť dáta občanov, môže byť bezpečnejší prístup incidenty vôbec nenahlasovať (a riskovať s tým súvisiacu pokutu)

• Nahlasovanie (=odhalenie veľmi citlivej informácie štátu) môže byť z tohto hľadiska výrazným rizikom ovplyvňujúcim stratu reputácie spoločnosti (nedávny Uber incident, kde to manažment "utajil")

Vzhľadom na riziko poškodenia dobrého mena a neschopnosť vlády chrániť citlivé údaje môžu mnohé spoločnosti kalkulovať s tým, či vôbec dáva zmysel informovať štát v prípade incidentov alebo nie.

Detekcia incidentov

• Využitím SIEM (security information and event management)
  • Akýkoľvek produkt schopný zbierania, analyzovania a prezentovania informácií zo siete a bezpečnostných zariadení
  • Umožnujúci správu prístupov / identít
  • Manažment zraniteľností a nástrojov na overovanie "súladu"
  • Obsahuje nástroje na zbieranie a vyhodnocovanie informácii z operačného systému, databázových, aplikačných a iných logov
• Detekcia tretími stranami (Google vyhľadávač, poškodení/kompromitovaní zákazníci atď.)

Moduly/vlastnosti SIEM

• Agregácia dát - log manažment, ktorý agreguje dáta z viacerých zdrojov, vrátane siete, serverov, databáz, aplikácií, s cieľom konsolidovať uvedené dáta v snahe identifikovať incidenty alebo iné kritické udalosti
• Korelácia - hľadanie spoločných atribútov a ich zmysluplné previazanie na udalosti, ktoré nastali. SIEM nástroje umožňujú aplikovať množstvo korelačných techník na vzájomné integrovanie dát z viacerých zdrojov, v snahe získať čo najviac užitočné informácie. Korelácia je súčasť každého plnohodnotného SIEM riešenia.
• Upozornenia - výsledkom automatizovanej analýzy korelovaných udalostí sú upozornenia o prípadných problémoch, ktoré sa buď zasielajú adresátom priamo (email, messenger, SMS), alebo sú dostupné cez tzv. "dashboard".  

Moduly/vlastnosti SIEM

• "Dashboards" - nástroje ktoré umožnujú dáta o udalostiach vizualizovať a meniť do informačných grafov, umožňujúc vyhľadávať rôzne aktivity, ktoré spĺňajú istý štandardný "pattern" alebo nie.
• "Retention" - nástroje na dlhodobé ukladanie historických dát na uľahčenie prípadnej korelácie v čase, častokrát je to podmienka "compliance" (ako napríklad "data retention" zákona)
• Forenzná analýza - schopnosť vyhľadávať v logoch na rôznych uzloch podľa rôznych kritérií v danom čase (ušetrí to nutnosť mať agregovaný log )
• Compliance

Najpopulárnejšie SIEM

• Komerčné SIEM sú obvykle dosť drahé
• 6 najpopulárnejších "open-source" SIEM
  • OSSEC (Open Source HIDS SECurity) 
  • Snort (Network Intrusion Detection & Prevention System)
  • Surricata (Open Source IDS/IPS/NSM engine)
  • ELK (Elasticsearch, Logstash and Kibana)
  • Prelude SIEM
  • OSSIM (Open Source SIEM)

Úniky

• Drvivá väčšina únikov pochádza z kompromitovaných webových aplikácií
  • Potreba analýzy aplikačných a databázových logov
• Menej cez chyby v službách OS
  • Analýza logov OS
• Ešte menej cez chyby v sieťových zariadeniach (ak neuvažujeme jednoduché/slovníkové hesla)
  • "netflow" či iná sieťová analýza

Falošné poplachy

• Definujeme tzv. "false positive"
  • falošný poplach, ktorý bol vyhodnotený ako incident, v skutočnosti ale nikdy nenastal
• Definujeme tzv. "false negative"
  • Incident, ktorý nastal, sme neboli schopní detegovať a teda poplach nenastal, aj keď mal
  • Častokrát je veľmi ťažké rozlíšiť sofistikovaný útok od bežnej sieťovej či aplikačnej prevádzky
• Cieľom je v prípade SIEM riešení úplne minimalizovať množstvo "false positives" a "false negatives" (obvykle jedno je na úkor druhého a naopak) - ich veľké množstvo môže viesť ku kompletnému ignorovaniu SIEM riešenia :-)

Bezpečnostný incident

• SIEM nás informoval o bezpečnostnom incidente
• Jeho vyšetrenie obvykle vyžaduje ľudský faktor:
  • Aké údaje presne unikli? Sú skutočne osobné?
  • Unikli osobné údaje do nekontrolovaného Internetu?
  • Je možné identifikovať páchateľa?
  • Aký dopad majú uniknuté osobné údaje?
• V prípade, že išlo o reálny bezpečnostný incident týkajúci sa osobných údajov, je potrebné kontaktovať behom nasledujúcich 72 hodín Úrad na ochranu osobných údajov (aký má kontakt?)

Ide o údaje závažného citlivého charakteru?

• Vzhľadom k tomu, že šifrovanie minimalizuje pravdepodobnosť potenciálneho zneužitia uniknutých údajov, tak správca dát nemusí podľa GDPR legislatívy kontaktovať svojich zákazníkov (čo môže viesť v tomto prípade napríklad k poškodeniu dobrej reputácie apod.), ani Úrad na ochranu osobných údajov

Bezpečné a redundantné log servery

• Kedže sofistikovaný útočník dokáže plošne kompromitovať všetky servery, používa 0-day exploity a "zadné vrátka", je potrebné logy zo všetkých serverov okamžite preposielať na redundantné log servery:
  • na ktorých nebežia žiadne iné služby (len log service)
  • ktoré ukladajú logy na write-once médiá (CD, DVD)
  • majú pravidelné "offline" zálohy
  • ideálne sú úplne odpojené od Internetu