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

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

By Pavol Luptak

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

  • 321
Loading comments...

More from Pavol Luptak