Vain yksi Incident Response Playbook kaikkien tietoturvatapahtumien hallitsemiseksi – viisas lähestymistapa?

Incident response playbook

Kun esitän yrityksen CISO:lle ideoita tietoturvatapahtumien rakenteellisesta ja kategorisesta käsittelystä, ja erityisesti niihin oleellisesti liittyviin Incident Response-toimintaohjeisiin, niin hyvin usein minulta kysytään: ”Selvä homma, ymmärrän kyllä näiden tarpeen, mutta kuinka monta tällaista tarvitsemme?”

Yhden, yhden per hyökkäystyyppi, vai jotakin muuta?

Vaikka kysymys itsessään on hyvä, selkeä ja suoraviivainen, niin siihen vastaaminen on kaikkea muuta kuin suoraviivaista. Joten tutustutaanpa hieman syvällisemmin Incident Response Playbookien maailmaan. Ennen kuin pääkysymykseen pystyy vastaamaan, pitää ymmärtää mistä tietoturvapoikkeamien ja -loukkausten torjunta alkaa ja mihin se päättyy. Käytän tähän USA:n hallinnon viraston NIST CSF 1.1 (National Institute of Standards and Technology Cyber Security Framework 1.1, nist.gov) kuvaaman viitekehyksen viittä toiminta-aluetta:

Kuva: NIST CSF 1.1:n mukaiset toiminta-alueet

Tietoturvapoikkeaman tai -hälytyksen torjunta käynnistetään, kun SOC-analysti, tai muu operatiivinen tietoturvavastaava toteaa, että saatu hälytys on todellinen. CSF-viitekehyksen mukaisesti tämä tehdään Detect-toiminnolla. Detect-toiminto on riippuvainen asianmukaisesti tunnistetuista riskeistä, joita on mitigoitu yhdellä tai useammalla suojaustoiminnolla.

Keskitytään tarkemmin tietoturvariskiin. Riskien hallinnassa on monta vaihetta riskien tunnistamisesta aina niihin toimenpiteisiin, mitä riskin toteutuessa pitäisi tapahtua. Toimenpiteiden suunnittelu laiminlyödään usein, koska luullaan, että operatiivinen SOC kyllä tietää täysin, mitä sen on tehtävä. Tämä pitää harvoin paikkaansa. Yleensä tietoturva-analystit tietävät, miten hälytys voidaan validoida, ja mitä mahdollisia vastatoimenpiteitä poikkeamaa vastaan voidaan toteuttaa. Usein he kuitenkin tarvitsevat apua, mitä kaikkia muita reaktiota ja tehtäviä tarvitaan. Itse asiassa operatiivisen SOCin vastuulla ei ole turvata järjestelmiä ja niissä olevia tietoja, se on muiden tehtävä. SOC voi toimia vain sille annettujen rajojen puitteissa. Nämä rajat on määriteltävä jo riskin tunnistamisen yhteydessä. Useimmille tunnistetuille riskeille on olemassa yksi tai useampi turvakontrolli, jolla riskin toteutuminen havaitaan ja/tai estetään. Nämä turvavalvontakeinot voivat rajoittaa sitä, mitä SOC todellisuudessa voi tehdä ja mitä ei.

Myös havaintoja seuraavalla tietoturvapoikkeamiin ja -hälytyksiin reagoivalla prosessilla on selkeästi määritellyt rajat. SANS Institute:n julkaiseman toimintaohjekirjan mukaan tietoturvapoikkeamiin ja -hyökkäyksiin reagoiminen on hyvin tarkkaan määritelty prosessi, jossa on tiukat tarkistuspisteet, joiden jälkeen vasta voidaan siirtyä prosessin seuraavaan vaiheeseen:

Kuva: SANS:in kuvaama Incident Response-prosessi

Kyseinen lähestymistapa on ihan hyvä, paljon käytetty ja rakenteellisesti hyvin selvä, ja myös itse sitä useasti suositan. Kuitenkin se on puhtaasti teoreettinen.

Seuraavaksi keskitytään enemmän itse riskielementtiin. Kukin määritelty riski on mahdollista yhdistää uhkakategoriaan. Tätä kirjoitusta varten rakensin oheisen taulukon, jossa on määritelmät eri hyökkäystyypeille ja niiden uhkakategorioille. Taulukon rakentamisessa käytin apuna tiettyjä hyväksi havaittuja lähteitä, joten täysin oma se ei ole. Tämä taulukko toimikoon vain yhtenä esimerkkinä mahdollisista uhkakategorioista:

Kuva: Uhkakategoriat ja hyökkäystyypit

Kuten taulukosta näkyy, useita riskejä on luokiteltu samaan luokkaan. Tämä on käytännöllistä, koska silloin voidaan laatia kyseistä uhkakategoriaa varten oma Incident Response Playbook eli toimintasuunnitelma. Oheisen esimerkin mukaisesti pääsisimme minimissään kuuteen Incident Response-toimintaohjeeseen, ehkä huomattavasti useampaankin. Tietoturvapoikkeamat ovat hyvin erillaisia; kiristyshaittaohjelmaan liittyvä havainto vaatii toisenlaista lähestymistapaa kuin DDoS-palvelunestohyökkäykseen liittyvä havainto.

Yrityksen SOC:lla tai tietoturvaryhmällä on yleensä jo ennalta määritelty ja läpikäyty luettelo erilaisista uhkakategorioista, tai ainakin uhkatyypeistä. Suosittelen saman luettelon käyttämistä laajemminkin koko yrityksen ICT-osastolla. Yhteinen käsitteistö eli kieli helpottaa asioita, koska tällöin kaikki ymmärtävät saman asian samalla tavalla. On myös tärkeää ymmärtää, että uhkakategorioihin perustuvassa tietoturvapoikkeamien ja -hyökkäysten torjunnan ohjeistuskirjoissa tehdään eroja lähinnä poikkeamien rajoittamis- ja hävittämisvaiheessa. Vaiheet ennen ja jälkeen näitä ovat enemmän tai vähemmän aina samat. Tästä syystä modernisti toimivissa SOC-ympäristöissä pitäisi yhä enemmän keskittyä tietoturvatapahtumien käsittelyn automatisointiin. Oikea työkalu tähän on oikein käyttöönotettu SOAR-ratkaisu (Security Orchestration, Automation and Response).

Jos organisaatiolla on oma SOAR-ratkaisu otettu kattavasti käyttöön, voidaan sen avulla hallita kaikkia määriteltyjä tietoturvaloukkauksia yhdellä geneerisellä Incident Response Playbookilla, vaikka se edelleen koostuisi useista eri tietoturvapoikkeamien tai -hyökkäysten käsittelyyn liittyvistä alatoimintaohjeista. Pelkästään tällä on jo iso, yksinkertaistava ja toimintoja nopeuttava vaikutus. Jos taas automatisointia ei ole tehty lainkaan, tarvitaan täydellinen Incident Response Playbook jokaista eri uhkakategoriaa, ja hyökkäystyyppiä varten.

Tätä kirjoitusta lukiessa voi helposti tulla mieleen, että omassa organisaatiossa ei kyllä ole mitään tässä mainittuja osaamisia, toimintoja, työkaluja, tai resursseja. Jos näin on, miten pitäisi toimia, jotta asia saataisiin kuntoon? Ei hätää. Useimmille organisaatioille oman SOC-tiimin ja SOAR-työkalujen pyörittäminen on aivan liian raskasta ja kallista. Secure Cloudilla suositamme melkein aina, että nämä, mukaan lukien SIEM- ja muut analysointiratkaisut kannattaa toteuttaa ostettuna 24×7 palveluna.

Meidän suosituksemme ovat usein yhteistyökumppanimme Arctic Wolfin, modernit, monipuoliset ja kustannustehokkaat Open-XDR tietoturvan operointipalvelut. Nämä kiinteähintaiset ja hyvin laajat tietoturvan operointi- ja reagointipalvelut sisältävät mm. SIEM- ja SOAR-palvelut, kuten myös Incident Response-toiminteet, aina 24×7.

Lopuksi vielä yksi muistutus. Kaikkea tietoturvan operointia ei pidä ulkoistaa, vaan yrityksillä on aina syytä pitää riittävä tietoisuus ja osaaminen Incident Response-asioista ja Playbookeista myös itsellään, koska vain silloin lopputuloksesta voidaan saada hyvä ja käytännössä toimiva.

Mikko Tammiruusu

Mikolla on yli 30 vuoden kokemus verkkomaailmasta. Näistä yli 20 vuotta hän on käyttänyt tietoturvan parissa työskentelyyn, ja tähän matkaan on mahtunut hyvin paljon erilaisia toimenkuvia ja tietoturvateknologioita. Viimeiset kymmenisen vuotta Mikko on pyrkinyt ratkaisemaan pilvimaailman ja -palveluiden haasteita, ja myös hyödyntämään niiden mahdollisuuksia, erityisesti tietoturvan näkökulmasta. Nykyisin Mikon toimenkuvana on toimia SCF:ssä teknologiajohtajana ja Security Advisorina.