Miten SOC toimii?
SOC eli Security Operations Center on tietoturvavalvonnan ja -reagoinnin toimintamalli. Yksinkertaisimmillaan SOC ottaa vastaan tietoturvahälytyksiä, analysoi niiden merkityksen ja käynnistää tarvittavat toimenpiteet.
Kirjoittaja
Tuomas Karhula
Ensisilmäyksellä
SOC tehtävä on tunnistaa tietoturvapoikkeamat suuresta määrästä tapahtumadataa ja erottaa aidot uhat normaalista kohinasta. SIEM-, MDR- ja XDR-ratkaisut lähestyvät tätä eri tavoin, mutta niiden keskeinen ero on siinä, mistä tietolähteistä havaintoja kerätään ja miten niitä yhdistetään. Lopulta ratkaisevaa ei ole pelkkä hälytyksen syntyminen, vaan kyky analysoida tilanne ja käynnistää oikeat toimenpiteet.
Teknisesti SOC ei kuitenkaan ole yksi järjestelmä tai yksittäinen valvontanäkymä. Se on kokonaisuus, joka muodostuu valvottavista tietolähteistä, tapahtumien keruusta, analytiikasta, automaatiosta ja ihmisasiantuntijoiden tekemästä tulkinnasta.
Tässä kirjoituksessa avaan, mistä SOC hälytykset syntyvät, miten SIEM-, MDR- ja XDR-pohjaiset toteutukset eroavat toisistaan ja miksi toteutustavalla on iso vaikutus sekä näkyvyyteen, reagointikykyyn että kustannuksiin.
SOC ei ole yksi teknologia
SOC on tietoturvassa termi, joka yleistyy jatkuvasti. Samalla se herättää monenlaisia mielikuvia. Joillekin SOC tarkoittaa valvomonäyttöjä ja punaista vilkkuvia hälytyksiä. Toisille se tarkoittaa ulkoistettua tietoturvatiimiä, joka tarkkailee ympäristöä kellon ympäri.
Molemmat mielikuvat voivat olla osittain oikein, mutta teknisesti SOC kannattaa ymmärtää prosessina.
SOC tehtävä on käsitellä tietoturvaan liittyvää tapahtumatietoa. Tapahtumia syntyy jatkuvasti: käyttäjät kirjautuvat sisään, laitteet ottavat yhteyksiä verkkoon, tiedostoja avataan, prosesseja käynnistyy, sähköposteja vastaanotetaan, palomuurit sallivat ja estävät liikennettä, pilvipalvelut kirjaavat hallintatoimia ja identiteetinhallinta tuottaa tietoa tunnusten käytöstä.
Suurin osa tästä on täysin normaalia. Osa on turhaa kohinaa. Pieni osa voi olla merkki aidosta uhasta.
SOC arvo syntyy siitä, että se pystyy erottamaan nämä toisistaan riittävän nopeasti ja käynnistämään oikean vasteen silloin, kun tilanne sitä vaatii.
Mitä SOC tekee teknisesti?
SOC taustalla on yleensä tekninen käsittelyketju, jossa suuri määrä tapahtumia muutetaan käsiteltäviksi hälytyksiksi.
Ensin tarvitaan tietolähteet. Näitä voivat olla esimerkiksi päätelaitteiden EDR-havainnot, Microsoft 365 -kirjautumiset, Entra ID tapahtumat, palomuurilogit, VPN-yhteydet, palvelimet, pilviympäristöt ja erilaiset tietoturvatuotteet.
Seuraavaksi tapahtumat kerätään keskitetysti. Pelkkä lokien kerääminen ei kuitenkaan vielä riitä, koska eri järjestelmät tuottavat tietoa eri muodossa ja eri tarkkuudella. Tapahtumia pitää pystyä vertailemaan ja yhdistämään.
Tämän jälkeen tapahtumia rikastetaan. Kirjautumistapahtumaan voidaan esimerkiksi liittää tieto käyttäjän normaalista sijainnista, laitteen hallintatilasta, IP-osoitteen maineesta tai siitä, onko samaa tunnusta käytetty hetkeä aiemmin toisesta maasta.
Varsinainen arvo syntyy korrelaatiossa. Yksittäinen epäonnistunut kirjautuminen ei välttämättä tarkoita mitään. Mutta jos samaan aikaan havaitaan poikkeava kirjautuminen, MFA-haasteen hyväksyntä, postilaatikon edelleenlähetyssäännön luonti ja poikkeavaa tiedostojen latausta, kokonaisuus alkaa näyttää aidolta uhalta.
Kun uhka todetaan aidoksi, käynnistyy vaste. Se voi tarkoittaa esimerkiksi käyttäjätunnuksen lukitsemista, salasanan nollausta, istuntojen katkaisua, laitteen eristämistä verkosta, haitallisen prosessin pysäyttämistä tai tiketin luomista jatkotoimenpiteitä varten.
Yksinkertaistettuna SOC tekninen ketju näyttää tältä: Tietolähde → tapahtumien keräys → rikastus → korrelaatio → hälytys → analyysi → vaste → jatkotoimenpiteet.
SIEM – laaja näkyvyys, enemmän määrittelyä
Perinteisesti tietoturvahälytyksiä on pyritty havaitsemaan erilaisista loki- eli tapahtumalähteistä. Näitä ovat esimerkiksi palomuurit, identiteetinhallinnan järjestelmät, virustorjunnat, palvelimet ja kirjautumislogit.
SIEM eli Security Information and Event Management on järjestelmä, johon näitä tapahtumia kerätään keskitetysti. SIEMin tehtävä ei ole itsessään suojata ympäristöä, vaan kerätä, yhdistää ja analysoida tapahtumatietoa.
SIEMin suurin vahvuus on näkyvyys. Kun eri järjestelmien tapahtumat saadaan samaan paikkaan, voidaan havaita tapahtumaketjuja, joita yksittäinen tietoturvatuote ei näkisi.
Esimerkiksi palomuuri voi nähdä poikkeavan yhteyden ulospäin. Identiteetinhallinta voi nähdä kirjautumisen oudosta sijainnista. Päätelaite voi nähdä epäilyttävän prosessin. Yksittäin nämä eivät välttämättä vielä riitä varmaan johtopäätökseen. Yhdessä ne voivat muodostaa selkeän kuvan käynnissä olevasta hyökkäyksestä.
SIEM-pohjaiset SOC ovat yleensä joustavia ja niitä voidaan räätälöidä asiakkaan ympäristön mukaan. Se on samalla myös haaste. Jotta SIEMistä on hyötyä, pitää tietää mitä sinne kerätään, miksi sitä kerätään, mitä sillä halutaan havaita ja miten havaintoihin reagoidaan.
Huonosti toteutettu SIEM on helposti kallis lokivarasto. Hyvin toteutettuna se tarjoaa laajan näkyvyyden ympäristöön ja mahdollistaa monimutkaisten hyökkäysketjujen tunnistamisen.
MDR – kevyempi malli, rajatumpi näkyvyys
MDR eli Managed Detection and Response on usein ketterämpi ja kustannustehokkaampi tapa toteuttaa valvontaa ja reagointia.
MDR on yleensä sidottu tiettyyn teknologiaan. Usein sen taustalla on päätelaitteiden suojaus- tai EDR-toimittaja, joka kerää uhkatietoa suoraan omilta agenteiltaan ja sensoreiltaan.
MDR tekninen tehokkuus perustuu siihen, että toimittaja tuntee oman teknologiansa erittäin hyvin. Kun päätelaitteelta havaitaan haitallinen prosessi, epäilyttävä komentorivikäyttö, tunnettu hyökkäystekniikka tai poikkeava käyttäytyminen, vaste voidaan käynnistää nopeasti.
Rajoite syntyy siitä, että havaintoja saadaan vain sieltä, missä kyseinen teknologia on käytössä.
Jos hyökkäys näkyy päätelaitteella, MDR toimii hyvin. Jos hyökkäys taas tapahtuu identiteetin väärinkäyttönä, pilvipalvelun asetusten muutoksena tai sähköpostin edelleenlähetyssääntönä, pelkkä päätelaitenäkymä ei välttämättä riitä.
Siksi MDR ei automaattisesti tarkoita, että koko IT-ympäristö on kattavasti valvottu. On tärkeää ymmärtää, mistä palvelu oikeasti näkee tapahtumia ja mihin se pystyy reagoimaan.
XDR – yhdistelmä keveyttä ja laajempaa korrelaatiota
XDR eli Extended Detection and Response pyrkii yhdistämään MDR keveyden ja SIEMin laajemman näkyvyyden.
Käytännössä XDR tuo yhteen havaintoja useammasta lähteestä, kuten päätelaitteilta, sähköpostista, identiteetistä, pilvipalveluista ja verkkotasolta. Tavoitteena on, että järjestelmä ei näe vain yksittäisiä hälytyksiä, vaan pystyy muodostamaan niistä kokonaisemman kuvan.
Esimerkiksi käyttäjän tunnus kirjautuu poikkeavasta sijainnista. Hetkeä myöhemmin samalta tunnukselta hyväksytään MFA-pyyntö, tehdään muutoksia postilaatikon sääntöihin ja päätelaitteella käynnistyy epäilyttävä prosessi. XDR hyöty syntyy siitä, että nämä tapahtumat voidaan sitoa yhteen samaan tutkintatapaukseen.
XDR kääntöpuoli on se, että kattavuus riippuu tuetuista integraatioista. Kaikkia järjestelmiä ei voi liittää mukaan, kaikista lähteistä ei saada yhtä syvää dataa eikä kaikkiin järjestelmiin voida kohdistaa vastekomentoja.
Siksi XDR ei automaattisesti tarkoita kaikkea kattavaa näkyvyyttä. Se on vahva niissä ympäristöissä ja tietolähteissä, joita se tukee hyvin.
Automaation ja ihmisen rooli
SOC-palveluissa automaatio on välttämätöntä, koska hälytyksiä ja tapahtumia syntyy valtavia määriä. Automaatio voi suodattaa turhia hälytyksiä, rikastaa havaintoja lisätiedoilla, priorisoida tapauksia ja käynnistää sovittuja ensivasteita.
Automaattinen vaste voi tarkoittaa esimerkiksi käyttäjätunnuksen lukitsemista, aktiivisten istuntojen katkaisua, päätelaitteen eristämistä verkosta tai tiketin luomista jatkotoimenpiteitä varten.
Automaatio ei kuitenkaan poista asiantuntijaa. Kaikki tilanteet eivät ole yksiselitteisiä. Jos käyttäjä kirjautuu yöllä toisesta maasta, kyse voi olla hyökkäyksestä, työmatkasta, VPN-ratkaisusta tai poikkeavasta mutta hyväksyttävästä toiminnasta.
Hyvä SOC yhdistää automaation ja ihmisen tekemän tulkinnan. Automaatio hoitaa toistuvat ja selkeät tehtävät nopeasti. Asiantuntija tekee arvion silloin, kun tilanne vaatii kontekstia ja harkintaa.
Vastuurajat ratkaisevat käytännön hyödyn
Tekninen valvonta on vain osa kokonaisuutta. Yhtä tärkeää on tietää, missä kohtaa vastuu siirtyy analyysistä käytännön tekemiseen.
Keveimmillään SOC käsittelee hälytyksiä ja muodostaa niistä häiriötikettejä. Tiketit ohjautuvat asiakkaan omalle IT tai IT-kumppanille, joka vastaa jatkotoimenpiteistä.
Seuraavalla tasolla SOC analysoi hälytyksiä ja tekee myös ensireagointeja. Näitä voivat olla esimerkiksi käyttäjätunnuksen lukitseminen, salasanan nollaus, istuntojen katkaisu tai työaseman eristäminen verkosta.
Laajemmassa mallissa SOC on integroitu IT-ylläpitoon. Tällöin hälytys ei jää vain tietoturvatiimin havainnoksi, vaan se voidaan viedä käytännön toimenpiteiksi asti: käyttäjä voidaan kontaktoida, laite siivota, tunnukset suojata ja ympäristöön tehdä tarvittavat muutokset.
Ei ole suurta hyötyä SOC-palvelusta, joka reagoi minuuteissa ja hälyttää kellon ympäri, jos varsinainen korjaava tekeminen tapahtuu vasta seuraavana arkipäivänä.
Palveluiden väliset kuilut ovat virtuaalimaailman pattereita, joiden väliin pallot valitettavan usein jumittavat.
Frendyn tapa toteuttaa SOC
Frendyn palveluissa tietoturvahälytysten käsittely kuuluu lähtökohtaisesti osaksi ylläpitopalvelua silloin, kun kyseinen komponentti on Frendyn ylläpidon piirissä. Käytännössä Frendy ottaa vastaan hälytyksiä ja tietoturvatiimi käsittelee niitä palveluaikana.
Tietoturvapoikkeamat eivät kuitenkaan noudata toimistoaikoja. Siksi tietoturvahälytysten valvontaa ja ensivastetta on järkevää laajentaa ympärivuorokautiseksi erityisesti niissä ympäristöissä, joissa käyttäjätunnukset, päätelaitteet ja pilvipalvelut ovat liiketoiminnan kannalta kriittisiä.
Frendyn tapa toteuttaa 24/7 SOC ei ole perinteinen malli, jossa rakennetaan maailman parasta teknistä toteutusta. Lähdemme siitä, että teemme ratkaisuita, jotka oikeasti tukevat yrityksen liiketoimintaa.
Useimmille yrityksille järkevin SOC ei ole raskain mahdollinen toteutus, vaan sellainen, joka tuo hyvän näkyvyyden kriittisimpiin hyökkäyspintoihin: käyttäjätunnuksiin, päätelaitteisiin ja pilvipalveluihin.
Frendyn vahvuus on siinä, että SOC ei jää irralliseksi hälytyspalveluksi. Kun sama kumppani tuntee asiakkaan IT-ympäristön, ylläpitomallin ja käytännön toimintatavat, hälytykset voidaan kytkeä suoraan jatkotoimenpiteisiin: tunnusten suojaamiseen, laitteen eristämiseen, käyttäjän auttamiseen, ympäristön koventamiseen ja tarvittaessa laajempaan selvitystyöhön.
Lopuksi
SOC tekninen toteutus ratkaisee, mitä ympäristöstä nähdään ja mihin voidaan reagoida.
Siksi SOC-palvelua ei kannata arvioida pelkästään sen perusteella, onko valvonta ympärivuorokautista. Vähintään yhtä tärkeää on ymmärtää, mistä lähteistä havaintoja kerätään, miten niitä yhdistetään ja mitä vasteita palvelu pystyy käynnistämään.
Hyvin rakennettu SOC ei ole vain hälytyskeskus. Se on tekninen ja operatiivinen ketju, joka muuttaa tapahtumadatan havainnoiksi, havainnot päätöksiksi ja päätökset toimenpiteiksi.
Psst. Kiinnostaako tietoturva-aiheiset sisällöt? Ota IT-kaverin somekanavat seurantaan!
Julkaisemme somessa tietoiskuja ja mielenkiintoisia tietoturvauutisia.
