Jos ukkospilvet yllättää: pohdintoja Microsoft Sentinelistä

Ulkona sataa, muutaman (lyhyen) hellepäivän jälkeen. Ukkosilmoja ei ole luvattu, vaikka niihin kesän aikana aina hieman varautuukin. Olen joskus pohtinut pilvipalveluihin käyttöönottoa ja kypsyyttä vuosikellon avulla: kaukana on alkuvuoden tahmeus ja uutuudenviehätys ja juuri nyt pilvipalveluiden osalta tuntuu olevan sopiva suhde kuumuutta ja realismia. Vähän kuten kesäkuun säätiedotteet juuri ennen kesälomia: ei sada, mutta ehkä kuitenkin parempi ottaa sateenvarjo mukaan.

Nykyaikaiset tietojärjestelmät suoltavat holtittoman paljon dataa ulos – lokitietoja, telemetriaa ja muita signaaleja. Eipä sillä, välillä vastaan tulevat iäkkäätkin ”itse koodasin, säästin”-järjestelmätkin generoivat niin tehokkaasti lokia temppihakemistoon kuin levytila olisi menossa pois muodissa.

Osin tähän tarpeeseen – datan keräämiseen, analysointiin ja sitä kautta tietoturvaamiseen – on Microsoft Sentinel. Kun palvelu alunperin julkaistiin 2019, olin innoissani – vihdoinkin pilvessä natiivisti toimiva ratkaisu, joka varmasti kehittyy ripeästi ja taipuu minkä tahansa asiakkaan tarpeisiin! Jälkiviisaana voi todeta, että palveluna Microsoft Sentinel on kyllä vastannut omiin odotuksiini, jotka tosin olivat vielä tuolloin melko perinteiset – ”kerää lokitiedot, ja kerro missä palaa.”

Tiivistäen ja rajusti yksinkertaistaen – Microsoft Sentinel kerää tiedon yhteen, tunnistaa tietoturva-uhat, ja mahdollistaa niihin reagoimisen automaattisesti.

Nyt muutaman vuoden Microsoft Sentinelin kanssa työskenneltyämme ajattelimme summata yhteen havaintoja, oppeja ja uskaltaisin väittää myös pieniä valaistumisia matkan varrelta.

Miksi Microsoft Sentinel?

Microsoftilla on yrityksenä ällistyttävä kyky yksinkertaistaa monimutkaisia toiminnallisuuksia ja tarpeita selkeisiin hallintanäkymiin ja ratkaisuihin. Toisinaan kuulen, että Microsoft Sentineliin suhtaudutaan kuin litran maitopurkkiin ennen lauantai-illan pannukakkutaikinan tuunaamista: ”lisätään Sentinel tähän arkkitehtuuriin huomenna ja sitten ylihuomenna konffataan Kubernetes..” Ehkä tämä noinkin voi hyvin rajatuissa ympäristöissä ja tilanteissa toimia.

Sen sijaan, että Microsoft Sentinel otetaan käyttöön asenna-ja-unohda-mallisena, onnistumisen tärkeimpänä kriteerinä näen, että palvelu määritellään ja positioidaan selkeästi. Mitä turvataan, ja miksi? Ennen vanhaan tällaista pohdintaa kuvattiin tekniseksi suunnitteluksi.

Yhteenvetona: Määrittele Microsoft Sentinel-arkkitehtuurin onnistumisen kriteerit.

Mitä (ja miksi) kerätään?

Jokaisessa Microsoft Sentinel-urakassa on hyvä pohtia mitä lokitietoa ja dataa kerätään – ja tämän myötä ratkaista ne käyttötapaukset, joihin valmista data connectoria ei suoraan löydy. Onko tällä nyt sitten oikeasti merkitystä? Eikö vain voida nakutella kaikki tarvittavat data connectorit kehiin – enemmän dataa on varmasti parempi tilannekuva, eikö? Kyllä näinkin mutta myös kohinan ja turhan tiedon määrä lisääntyy. Sen sijaan, että luetaan (jo hyvin) turvatusta SQL-palvelimesta tuhansia rivejä lokia joka minuutti, on järkevämpää ja kokonaistaloudellisesti tehokkaampaa keskittyä laajempaan tilannekuvaan. Muutoin tämä yksi SQL-palvelin voi pahimmillaan generoida miljoonia signaaleja vuorokaudessa, jotka ovat pääosin tarpeettomia. Garbage in, garbage out.

Yhteenvetona: Määrittele järjestelmät, tiedot ja tavat jolla tietoa kerätään.

Mitä tämä kaikki maksaa, ja ennen kaikkea kuka tämän kaiken maksaa?

SIlloin 2019, kun Microsoft Sentinel julkistettiin, huomasin tuttavaltani viestin Twitterissä. Hän nosti ongelmaksi hillittömän kovat käyttökulut seuraavalla käyttötapauksella: ”Ennakoimme, että haemme Sentinel-työtilaan dataa lokimuotoisena 2 teratavua vuorokaudessa – tämähän maksaa meille tuhansia euroja päivässä!” No tuota, kyllä. Tässä hyvä tietää, että vielä tuolloin ei ollut täyttä läpinäkyvyyttä nykyiseen kustannusmalliin, jossa commitment tier-mallilla saadaan volyymialennuksia.

Jälleen hyvä pysähtyä miettimään mitä ja miksi tietoa kerätään.

Microsoft Sentinel-ympäristöjen kustannusvaikutukset on hyvä mallintaa etukäteen. Edes määrämuotoisesti sille tasolle, että kokonaistaso on suunnilleen havainnollistettu. Tähän löytyy useita mekanismeja, Excelistä työkirjoihin. Mallinnuksessa suosin itse lisäksi myös hyvin kevyttä prototyyppiä, tai vastaavaa koeponnistusta, jolla tarpeet saadaan selkeämmin todennettua ja tarkennettua.

Ja kuka tämän lystin maksaa? Ilahdun aina, kun projektien yhteydessä päästään keskustelemaan kustannuksista. IT-jargonissa tämä tunnetaan FinOps (Finance Operations)-mallina, joka toisaalta harmillisen usein redusoituu siihen, kuka katsoo kerran kuussa Azuren Cost Management-näkymää. Ei näin! Tapoja ja malleja on tähän jo riittävästi, ja usein kyse on vastuunjaosta, pienestä viitsimisestä ja hyvästä yrityskulttuurista kuluseurannan suhteen.

Yhteenvetona: Budjetoi Microsoft Sentinelin käyttökustannukset, ja seuraa sekä ennusteita että toteumaa. Reagoi tarvittaessa ajoissa.

Montako Microsoft Sentineliä tarvitaan?

Jos et ole varma, yksi. Jos olet täysin epävarma, yksi. Ja jos olet ehdottoman varma, että se ei ole yksi, lähde silti yhdellä liikkeelle. Suomessa harvoin – joskin toisinaan – on täysin legitiimejä syitä rakentaa hajautettuja tai eristettyjä Microsoft Sentinel-ratkaisuja. Vastaavasti useamman Sentinel-ympäristön heijastaminen samaan näkymään on oma lisätyönsä, ja tuo pientä kömpelyyttä kokonaisuuteen.

Jotta edes yhdestä Microsoft Sentinelistä on hyötyä, tulee rakentaa käytännöt lokien ja datan keräämiseen kaikkialta – ja järkevällä tasolla. Monipuolinen data turvattavasti ympäristöistä on aina hyödyllistä. Perinteinen telemetria-tieto (”Kaikki OK”) voi olla hyödyllistä mutta tuo myös turhan paljon sälää ilman etukäteen tapahtuvaa perkaamista.

Yhteenvetona: Rakenna yksi Microsoft Sentinel ja tee se hyvin. Tee useampi, jos tähän on erityisen perustellut syyt.

Kuka Microsoft Sentineliä valvoo, ja kuka reagoi hälytyksiin?

”Matti, luulin että sinä katsot näitä Sentinelin hälyjä?” – harmi vaan, että Matilla on jo työkuormaa kolmen ammattilaisen edestä. Teknisenä harjoitteena Microsoft Sentinelin toteutus on usein selkeä ja suoraviivainen. Tuloksena on usein jo pienissäkin ympäristöissä ”kevyt-SOC” (Security Operations Center), jonka perään täytyy katsoa. Hälytyksiin ja muihin uhkiin tulee reagoida. Löytöjä pitää havainnollistaa. Kerättyä tietoa täytyy louhia, ja uusia uhkia täytyy paikallistaa.

Tämä työ on usein jatkuvaa ja toistuvaa. Usein päivittäin, ja kun hälytyksiä tai muita havaintoja tulee, täytyy niihin reagoida mieluusti välittömästi. Tätä varten voi joko kouluttaa ja rakentaa oman tiimin, tai ulkoistaa valvonnan ja reagoinnin kumppanille. Molemmissa malleissa on oma etunsa. Hyvä ja toimiva malli on myös ottaa hieman molempia, jotta tietoturvaa ja sen valvontaa ei täysin ulkoista itseltä pois.

Yhteenvetona: Määrittele kuka valvoo, kuka reagoi, ja kenellä on aidosti aikaa valvoa ja käyttää Microsoft Sentineliä.

Kauanko lokitietoja hillotaan, ja miksi?

Vanha ystäväni opetti minulle hillota-verbin perimmäisen olemuksen tietoturvapalveluita suunnitellessa viime vuosituhannella. Kuten aiemmin nostin esiin, Microsoft Sentineliin on äärettömän helppo edelleenlähettää kaikki lokit, kaikkialta. Sen lisäksi että tämä tuo huomattavia lisäkustannuksia, se tuo myös aika paljon kohinaa ja vähentää tätä kautta palvelun varsinaista hyötyä.
Mieti minkälaista lokitietoa palveluun tuodaan. Tuotteista ja palveluista saatava data – esimerkiksi Azure AD:sta ja Microsoft 365:sta – on äärimmäisen hyödyllistä. Rivilokit – eli raakadata – on sen sijaan usein vähemmän arvokasta, ellei jonkinlaista tietojen jalostamista ja rikastamista tehdä matkan varrella. Viittaan jälleen tietokantapalvelimeen, jonka statistiikat generoituvat lokeihin, ja sieltä Microsoft Sentineliin. Tuhansia rivejä tietoa mutta vain hyvin vähän arvokasta tietoturvaan apua tuovaa tietoa.

Erinomainen tapa rakentaa balanssia tähän on Defender for Servers, joka on osana Defender for Cloudia. Vilkaise aiempi juttu täältä.

Toinen haastava pohdinta on lokitietojen säilöntä. Vakiomallissa Microsoft Sentinelin data säilyy 90 vuorokauden ajan. Tätä voi toki pidentää useamman vuoden pituiseksi – mutta mikä on varsinainen liiketoiminnan ja tietoturvatason edellyttämä tarve? Palataanko ikinä vanhoihin datoihin, vai riittäisikö huokeampi ja hieman yksinkertaisempi arkisto esimerkiksi yli vuoden vanhoille datoille?Yhteenvetona: Mieti lokitietojen elinkaaren hallinta. Määrittele selkeästi lokien tarpeellisuus ja mahdollinen rikastaminen etukäteen ennen Microsoft Sentineliin tuomista.

Panosta KQL-kyselyihin ja työkirjoihin

Sitten aavistuksen teknisempi vastuu ja kompetenssi. KQL, eli Kusto Query Language, on usean Azure-palvelun käyttämä kysely- ja visualisointikieli. HIeman kuten tietokantojen SQL, mutta aavistuksen sekavammalla syntaksilla.

Microsoft Sentinelin työkirjat (workbooks) perustuvat KQL-kyselyihin. Näin samaan näkymään voidaan rakentaa visuaalinen raportti tietoturva-uhista, käyttäjistä, kirjautumisista ja muista signaaleista melko vaivattomasti. Tätä varten jonkun – jossain – täytyy osata rakentaa KQL-kyselyitä, koska aivan kuten raporteissa, yksittäisiä tarpeita tulee eteen jatkuvasti. ”Hei, onkos meillä macOS-käyttäjiä joilla on pääsy meidän CRM:ään?” voi olla viaton kysymys, mutta kun samankaltaiset kyselyt toistuvat viikottain, on järkevämpää rakentaa selkeät raportit, mittarit ja ennen kaikkea toleranssirajat hälytyksille.

Yhteenvetona: Opettele KQL:n perusteet. Microsoft Sentinelissä on ällistyttävän paljon valmista, mutta paras hyöty saadaan kun raportit ja näkymät viilataan omaan tarpeeseen sopivaksi.

Lopuksi

Microsoft Sentinel on loistava palvelu, joka yhtäältä helpottaa ja toisaalta tuo viiltävän läpileikkauksen järjestelmien tietoturvan tilaan ja tasoon. Jotta palvelusta saadaan täysi hyöty irti, tulee selkeästi määritellä ja huomioida miksi tehdään, mitä tehdään, kuka tekee ja mitä se muuten maksaa. Autamme mielellämme kaikissa Microsoft Sentineliin liittyvissä tarpeissa ja kysymyksissä – turvataan ympäristöt yhdessä!