Microsoft Sentinel laihialaisittain 

Photo by @blankerwahnsinn / Unsplash.com

Sentinel on erinomainen työkalu. Markkinoille puskiessaan silloin vielä Azure Sentinel nimellä kutsuttu SIEM-SOAR -työkalu oli melkoinen paukku, markkinahäiriö. Pilvestä itse käyttöönotettava tehokas työkalu ilman kiinteitä sopimusaikoja. Ja kuinka helppo ja näppärä käyttöönottaa! Meikäläisen tapaan traditionaalisia SIEM-järjestelmiä asentanut taatusti äimistyi. Päivässä Sentinel kukkui ja pureskeli iloisesti dataa. 

Ei ihme, että Microsoft teki Sentinelillä hattutemput ja kipusi esimerkiksi Gartnerin maagisessa kvadrantissa kahdessa vuodessa mitättömyydestä johtajaksi. Tästä lisää MS:n sivuilta.

Entä kustannukset?

Joka kolikolla on kuitenkin kääntöpuolensa ja pilvellä hopeareunuksensa.

Sentinelin tapauksessa helppoutta ja tehokkuutta seuraa se klassisin pilvikrapulan aiheuttaja. Kustannukset siis. Kun rakentaminen on nopeaa, talo nousee hetkessä. Monesti vain unohtuu, ettei talon rakentaminen ikinä ole ilmaista. Eikä tietenkään hienon ja tehokkaan analyysimoottorin rakentaminen pilveenkään ilmaista ole. Toki huomattavasti kustannustehokkaampaa kuin perinteinen tapa niitä rakennella, mutta kyllä kustannuksia yhtä kaikki saa syntymään. Ja jälleen niin tehokkaasti, ikävä kyllä. 

Tässä kynäelmässä olisi tarkoitus jakaa kokemuksia ja oppeja Sentinelin synnyttämien kustannusten hallintaan ja minimointiin. 

Aloitetaan siitä helpoimmasta ja ilmiselvästä, eli hienosti ilmaistuna ostomallista. Sillä tarkoitetaan siis sitä, että Sentinelin kuten useimpien muidenkin Azure-palveluiden ostaminen voi pohjautua moneen eri tapaan. Sentineliin purevat lähinnä sitoutumistasot. Jos Sentinel on tietoturvanne keskiössä ja tärkeä työkalunne, lienee turvallista olettaa sen säilyvän käytössä tovin, jos toisenkin. Valitsemalla nk. sitoumustason (engl. Commitment Tier) päästään alennuksiin, jotka voivat olla melkein 50% maksimissaan.

Toinen erittäin toimiva tapa on arvioida säilytysajan pituutta kriittisesti. Sentinel tarjoaa 90 päivää tietoturvalokien säilytystä ilmaiseksi. Sen jälkeen Sentinelin pohjana oleva Log Analytics tallennustila alkaa tikittää kustannuksia. Perusteltu kysymys on, tarvitaanko Sentinelissä säilyttää dataa yli tuon kolmen kuukauden.

Kas kun vaihtoehtoja on! Log Analytics ei ole säilytystilana niitä halvimpia. Microsoft itse tarjoaa valmista pelikirjaa lokitiedon siirtämiseen edulliseen Blob storageen. Usea asiakas on myös hyödyntänyt muutakin tärkeää tietoa varten järjestettyä arkistointiratkaisua tietoturvalokeille. Forensiikan mahdolliset tulevat tarpeet huomioiva haluaa toki säilyttää tiedot tallessa. Samoin regulaatiot tai sisäisen auditin vaatimukset saattavat pakottaa tarjoamaan hyvin pitkiäkin säilytysaikoja. Vuosien tietoturvadatan hilloaminen Log Analyticsin puolella ei juuri koskaan ole perusteltua.

Kolmas tärkeä peliliike on datanielun huolellinen suunnittelu. Tavallisesti tämä on käytännössä lokivirran kriittistä arviointia. Antaako se mitään lisäarvoa? Esimerkiksi tarkastelu viimeisen 3-6 kk aikajänteen osalta on usein silmiä avaavaa. Jos et kyseisestä datalähteestä ole saanut yhden yhtään hälytystä, on perusteltua kyseenalaistaa sen tärkeys. Ei silti mitään tarvitse menettää! Helppo ja halpa ratkaisu on siirtää verkkolaitteiden tuottaman lokidatan virtaus Log Analyticsin sijaan vaikkapa Basic Logsin puolelle. Näin saavutetaan aivan järkyttäviä kustannussäästöjä. Tuo Basic Logs kun kustantaa vain 1,5% (kyllä, alle kaksi prosenttia!) Log Analyticsin analyysihinnoista. Toki kyselyt ovat rajatumpia ja hälytystukea ei samassa määrin ole.

Vaativampi toteutus on esiprosessoida dataa ennen Sentineliin vientiä. Etenkin 80- tai 90-luvuilta peräisin olevien tietoturvalokitusmuotojen suhteen olen havainnut, että varsinaisen arvokkaan tietoturvatiedon mukana tulee hurja määrä kaikkea silsaa ja täysin irrelevanttia dataa. Tähän törmätään tyypillisesti verkkolaitteiden CEF- ja Syslog-muotoisten datavirtojen kanssa toimiessa. Vastuullinen SIEM-hallinta valitsee suurivolyymisille datalähteille – jotka pääsääntöisesti ovat vielä tuottamaltaan arvolta niitä vähäisimpiä – kustannustehokkaimman tavan käsitellä ja säilöä niitä. Helppoudesta pitävälle Basic Logs ja datan käpistelyn mestari ehkä valitsee esiprosessoinnin tien. Kaikkein helpoin kustannustarkastus on kuitenkin sen palomuurin tai yhteyslaitteen lokitusasetusten läpikäynti. Haluatko todellakin jokaisen session avaamisen menevän Sentinelin kummasteltavaksi. Mitä edes teoriassa sieltä voisi löytyä?

Neljäs tärkeä muistettava asia on Microsoft-näkyvyyden osalta holistinen kustannusarviointi huomioiden eri lisensoinnit ja palvelukokonaisuudet. Esimerkiksi E5-paketointi sisältää myös ”Sentinel-analytiikkaa” jokaisen käyttäjän osalta. Eli Sentinelin kyvykkyyksiä paljon käyttävän organisaation osalta ei ero E3- ja E5-lisenssien kustannuksissa olekaan niin yksinkertaisesti laskettavissa. Ja mikäli liität vaikkapa 100 palvelinta Sentinel-näkyvyyteen, vaihtoehtoja on monia. Vanhojen SIEM-järjestelmien tyyli, jossa virtautetaan eventtitiedot ja tietoturvalokit joka palvelimelta tulee useita kymmeniä kertoja kalliimmaksi kuin modernimpi lähestyminen, jossa ”hubitetaan” palvelimet esimerkiksi Azure Arcin ja Defenderin kautta.

Ja lopuksi

Raskaan käyttölinjan Sentinel-toteutuksille on sitten omat erikoisuutensa, kuten esimerkiksi dedikoitujen Log Analytics klustereiden käyttö. Samoin suuremman organisaation kannattaa jaotella Sentinelinsä maanosittain ja rakentaa näiden välille näkyvyys. En keskity järeimmän luokan kustannusten optimointiin tässä kirjoituksessa. Mikäli Sentinel-kulusi ylittävät vaikkapa satatuhatta vuodessa, ota ihmeessä yhteyttä. Otetaan erillinen sessio kustannustesi leikkaamisesta. Voimme hoitaa homman vaikka nk. success fee -pohjaisesti!

Lopuksi muistutan vielä ”ilmaisannoksista”. Sentinelin saa käyttöön 31 päivän ajaksi ilmaiseksi. Tuon ajan sisällä on hyvä kytkeä kaikki himoitsemasi näkyvyysalueet eli lokilähteet ja arvioida kustannuksia turvallisesti, euroakaan polttamatta.

 PS. Älä IKINÄ anna ”ysäritietoturvaajan” suunnitella Sentineliäsi. Jos siis secujätkäsi horisee vaikka EPSeistä tai verkon turvallisuudesta, ennuste on TODELLA huono.

Photo by @kylejglenn / Unsplash.com

Virtuaalipalvelimen koventaminen ja suojaaminen Azuressa ihan oikeasti

Tehoa palvelinten päivitysprosesseihin

Kuva: @simmerdownjpg / Unsplash.com

Havainnoi haavoittuvuuksia Defender for Cloudin avulla