Suomalaisten ja pohjoismaisten turvatiimien budjettikeskusteluissa toistuu syksyllä 2026 yksi kysymys: kannattaako lokien keräys ja hälytysten korrelaatio rakentaa avoimen lähdekoodin Wazuhin päälle, vai maksaa siitä markkinajohtaja Splunkille? Kysymys ei ole akateeminen. NIS2-direktiivi on tuonut kriittisen infran ja keskisuurten yritysten pöydälle 24 tunnin ilmoitusvelvollisuuden häiriötilanteista, ja ilman toimivaa SIEM-järjestelmää tätä aikarajaa on käytännössä mahdoton täyttää. Samaan aikaan lokien määrä kasvaa pilvisiirtymän myötä nopeammin kuin turvatiimien budjetit.

Tässä vertailussa käydään läpi Wazuhin ja Splunkin tekniset erot, hinnoittelumallit reaalilukuina, suorituskykyväitteet kolmesta lähteestä, NIS2- ja GDPR-sääntelyn vaikutus valintaan, viisi käytännön esimerkkiä sekä askel askeleelta etenevä migraatio-opas. Luvut perustuvat lokakuun 2026 julkaisutietoihin ja julkisiin hinnoittelulähteisiin, ei markkinointimateriaaliin.

Molemmat tuotteet ratkaisevat samaa perusongelmaa eri filosofialla. Wazuh edustaa ajattelua, jossa turvatiimi omistaa koko pinon alusta loppuun ja maksaa valinnasta työtunteina, ei lisenssimaksuna. Splunk edustaa vastakkaista filosofiaa, jossa organisaatio ostaa valmiin, tuetun kokonaisuuden ja maksaa siitä kulutuksen mukaan, jotta sisäinen tiimi voi keskittyä analyysiin eikä infrastruktuuriin. Kumpikaan filosofia ei ole yleispätevästi oikea, ja juuri tästä syystä vertailu kannattaa tehdä omien reunaehtojen, ei tuotemerkin maineen, perusteella.

Google · Ensisijaiset lähteet

Älä jätä uusia teknologiauutisia huomaamatta Googlessa

Lisää Shattered kerran Google-sovellukseen, niin artikkelimme näkyvät ehdotuksissasi.

Lisää nyt

Mikä SIEM on ja miksi valinta ratkaisee NIS2-aikakaudella

SIEM (Security Information and Event Management) kerää lokit palomuureista, palvelimista, pääteasemista, pilvipalveluista ja sovelluksista yhteen paikkaan, korreloi tapahtumat ja nostaa esiin poikkeamat, jotka vaativat ihmisen huomiota. Järjestelmä on turvatiimin keskushermosto: siitä nähdään, kirjautuiko joku epätavalliseen aikaan, liikkuiko haittaohjelma verkossa sivuttain, tai yritettiinkö tunnettua haavoittuvuutta hyödyntää.

Pohjoismaissa paine SIEM-hankintaan on kasvanut kahdesta suunnasta. Ensimmäinen on NIS2-direktiivi, joka velvoittaa laajan joukon keskisuuria ja suuria toimijoita energiasta terveydenhuoltoon ilmoittamaan merkittävästä häiriöstä valvovalle viranomaiselle 24 tunnin sisällä havainnosta ja täydellisemmän raportin 72 tunnin kuluessa. Sakot essentiaalisille toimijoille voivat nousta jopa 10 miljoonaan euroon tai 2 prosenttiin globaalista liikevaihdosta, kumpi on suurempi. Ilman keskitettyä lokien korrelointia 24 tunnin ikkuna on käytännössä mahdoton täyttää luotettavasti.

Toinen paine tulee itse uhkakentästä. Suomen Kyberturvallisuuskeskuksen (Traficom NCSC-FI) 15. lokakuuta 2026 julkaisema syyskuun kybersää-katsaus nosti esiin useita kriittisiä ja aktiivisesti hyödynnettyjä haavoittuvuuksia nimeltä mainituissa Ciscon, F5:n, Check Pointin ja GitLabin tuotteissa. Tällaiset haavoittuvuudet löytyvät ja niiden hyväksikäyttöyritykset havaitaan käytännössä vain, jos organisaatiolla on jokin SIEM- tai lokien korrelointijärjestelmä käytössä. Kysymys ei siis ole enää siitä, tarvitaanko SIEM, vaan siitä, kumpi kahdesta suurimmasta vaihtoehdosta sopii omaan organisaatioon.

Wazuh lyhyesti: avoimen lähdekoodin XDR-alusta

Wazuh on avoimen lähdekoodin turva-alusta, joka yhdistää SIEM-tyyppisen lokikorrelaation, tiedostojen eheyden valvonnan, haavoittuvuuksien tunnistuksen ja säädöstenmukaisuuden raportoinnin yhteen agenttipohjaiseen ratkaisuun. Projektin uusin vakaa julkaisu on Wazuh 4.14.9, joka ilmestyi 14. lokakuuta 2026, vain muutama viikko sitä edeltäneen 4.14.8-version jälkeen, joka julkaistiin 23. syyskuuta 2026. Dokumentaatiorepositoriossa näkyi lisäksi 6. lokakuuta 2026 merkintä Wazuh 5.0.0 -julkaisukandidaatista, mutta sitä ei ole vielä vahvistettu tuotantokäyttöön tarkoitetuksi vakaaksi versioksi, joten organisaatioiden kannattaa tällä hetkellä pitäytyä 4.14-sarjassa.

Wazuhin arkkitehtuuri perustuu kevyisiin agentteihin, jotka lähettävät lokit ja telemetrian keskitetylle hallintapalvelimelle (manager), josta data indeksoituu Wazuh-indeksoijaan ja näkyy selainpohjaisessa hallintapaneelissa. Koko pino on avointa lähdekoodia: itse ohjelmiston käyttöön ei liity lisenssimaksua, vaan kustannukset syntyvät infrastruktuurista, ylläpidosta ja mahdollisesta kolmannen osapuolen tuesta. Tämä tekee Wazuhista erityisen houkuttelevan pienille ja keskisuurille toimijoille, joilla on sisäistä teknistä osaamista mutta ei suurta ohjelmistobudjettia.

Julkisista lähteistä ei löytynyt lokakuussa 2026 virallista, julkaistua hintataulukkoa Wazuhin kaupallisille pilvi- tai tukipalveluille. Käytännössä tämä tarkoittaa, että jos organisaatio haluaa hallinnoidun Wazuh-palvelun tai maksullisen tukisopimuksen, hinta pyydetään tarjouksena joko Wazuhilta itseltään tai alueelliselta kumppanilta. Tämä ei ole poikkeuksellista avoimen lähdekoodin maailmassa, mutta se tarkoittaa, että suoraa dollari-dollari-vertailua kaupallisen tuen osalta ei voi tehdä ilman omaa tarjouspyyntöä.

Splunk lyhyesti: markkinajohtajan arkkitehtuuri ja hinnoittelulogiikka

Splunk on pitkään ollut SIEM-markkinan oletusvalinta suurissa yrityksissä, ja sen tuoteperhe kattaa Splunk Enterprisen (itse ylläpidetty), Splunk Cloud Platformin (hallinoitu pilvipalvelu) ja Splunk Enterprise Securityn (varsinainen SIEM-sovelluskerros hälytyksille ja korrelaatiolle). Vuonna 2026 Splunk on siirtänyt painopistettä perinteisestä gigatavua-per-päivä-hinnoittelusta kohti joustavampia malleja: työkuormaperusteista hinnoittelua, jossa mittarina on Splunk Virtual Compute -yksikkö (SVC) Splunk Cloudissa tai virtuaaliset prosessoriytimet itse ylläpidetyssä Splunk Enterprisessä, sekä aktiivisuusperusteista hinnoittelua, joka mittaa sekä sisäänottoa että hakuaktiviteettia samaan aikaan. Lisätietoa näistä malleista löytyy Splunkin omasta Cloud Flex -dokumentaatiosta.

Splunk ei julkaise yhtä universaalia hintaa Splunk Cloudille tai Enterprise Securitylle: lopullinen hinta riippuu volyymista, sopimuskaudesta ja valitusta kapasiteettimallista. Käytännössä tämä tarkoittaa, että jokainen tarjous räätälöidään, ja julkiset hinta-arviot ovat suuntaa antavia, ei sitovia listahintoja. Siitä huolimatta kolmannen osapuolen hinnoittelulaskurit antavat riittävän tarkan kuvan siitä, mihin hintaluokkaan organisaation kannattaa varautua.

Yksi käytännön yksityiskohta kannattaa pitää mielessä: Splunk Cloudin ingest-tilauksessa kapasiteettikatto on karkeasti yksi SVC kymmentä gigatavua kohden päivässä, mikä vaikuttaa suoraan siihen, kuinka paljon hakuja ja dashboardeja voi ajaa samanaikaisesti saman sisäänottovolyymin päällä. Tämä on olennainen ero Wazuhin indeksointimalliin, jossa laskutusta ei sellaisenaan ole, mutta palvelimen mitoitus täytyy tehdä itse.

Tekniset erot taulukossa: 12 ominaisuutta rinnakkain

Seuraava taulukko kokoaa keskeiset tekniset ja kommersiaaliset erot. Tiedot perustuvat Wazuhin ja Splunkin omaan dokumentaatioon lokakuulta 2026.

OminaisuusWazuhSplunk (Enterprise / Cloud)
LisenssimalliAvoin lähdekoodi, ilmainen käyttöoikeusKaupallinen, kvoottiperusteinen sopimus
Uusin versio (loka 2026)4.14.9 (14.10.2026)Jatkuva pilvijulkaisumalli, Cloud Flex 10.6
Hinnoittelun mittariEi laskutusmittaria, kustannus = infra + ylläpitoGB/päivä, SVC-työkuorma tai aktiivisuus
IsännöintivaihtoehdotItse ylläpidetty palvelin/klusteriItse ylläpidetty Enterprise tai Splunk Cloud
Agenttipohjainen keräysKyllä, kevyt oma agenttiKyllä, Universal Forwarder
Sisäänrakennettu SIEM-korrelaatioKyllä (Wazuh-säännöt, Elastic-pohjainen indeksointi)Erillinen sovelluskerros: Enterprise Security
HaavoittuvuusskannausSisäänrakennettu moduuliVaatii erillisen integraation
Tiedostojen eheyden valvonta (FIM)SisäänrakennettuVaatii lisäosan
SäädöstenmukaisuusraportitPCI DSS, GDPR, NIST-mallit valmiinaEnterprise Securityn sisällöt ja lisäosat
Skaalautuvuuden vastuuAsiakkaan infratiimi mitoittaaSplunk Cloudissa osin Splunkin vastuulla
Yhteisö ja tukiAvoin yhteisö, kaupallinen tuki tarjouksestaLaaja kumppaniverkosto, SLA-pohjainen tuki
Tyypillinen käyttöönottoaikaPäiviä pienelle ympäristölle, viikkoja suurelleViikkoja-kuukausia, usein kumppanin kanssa

Arkkitehtuuri: agentti vastaan agentti

Molemmat tuotteet nojaavat agenttipohjaiseen keräykseen, mutta filosofia eroaa. Wazuhin agentti on suunniteltu kevyeksi ja sisältää valmiiksi haavoittuvuusskannauksen, tiedostojen eheyden valvonnan ja lokien keräyksen samassa paketissa, joten erillisiä lisäosia ei tarvitse ostaa tai asentaa erikseen. Splunkin Universal Forwarder keskittyy puhtaasti datan siirtoon, ja varsinainen turva-analytiikka (korrelaatiosäännöt, riskipisteytys, tutkinta-työkalut) asuu Enterprise Security -sovelluksessa, joka on oma, erikseen lisensoitava kerros Splunk-alustan päällä.

Integraatiot ja laajennettavuus

Splunkin vahvuus on sen kumppaniverkosto ja sovelluskauppa: tuhansia valmiita integraatioita pilvialustoihin, palomuureihin ja SOAR-työkaluihin. Wazuh nojaa enemmän avoimiin standardeihin, kuten syslogiin ja OpenSearch/Elastic-yhteensopivaan indeksointiin, minkä ansiosta se taipuu hyvin räätälöityihin ympäristöihin, mutta valmiiksi paketoituja kolmannen osapuolen liitännäisiä on vähemmän kuin Splunkin ekosysteemissä.

Tiedonkulku käytännössä: lokista hälytykseen

Molemmissa järjestelmissä tapahtumaketju noudattaa samaa perusrakennetta, mutta toteutus eroaa siinä, missä kohdassa ketjua älykkyys asuu. Wazuhissa agentti normalisoi lokin heti lähteellä, lähettää sen managerille, joka ajaa sisäänrakennetut korrelaatiosäännöt ja kirjoittaa osuman suoraan indeksoijaan. Hälytys syntyy siis yhden järjestelmän sisällä, ilman erillistä sovelluskerrosta. Yksinkertaistettu esimerkki Wazuh-säännöstä, joka nostaa hälytyksen toistuvista epäonnistuneista SSH-kirjautumisista, näyttää tältä:

<rule id="100100" level="10">
  <if_matched_sid>5716</if_matched_sid>
  <same_source_ip />
  <description>Toistuva epäonnistunut SSH-kirjautuminen</description>
  <group>authentication_failures,</group>
  <frequency>8</frequency>
  <timeframe>120</timeframe>
</rule>

Splunkissa vastaava logiikka ei asu raakadatan indeksointikerroksessa, vaan Enterprise Securityn hakupohjaisissa korrelaatiosäännöissä, jotka ajetaan säännöllisesti Search Processing Language -kielellä (SPL) indeksoidun datan päälle. Yksinkertaistettu SPL-haku samaan käyttötapaukseen voisi olla seuraavanlainen:

index=auth sourcetype=sshd action=failure
| stats count by src_ip
| where count > 8

Ero ei ole kosmeettinen. Wazuhin sääntömoottori reagoi lähes reaaliaikaisesti, koska korrelaatio tapahtuu samassa prosessissa kuin lokin vastaanotto. Splunkin hakupohjainen malli on joustavampi ja mahdollistaa monimutkaisemman, usean lähteen yhdistävän analytiikan, mutta hälytyksen viive riippuu siitä, kuinka usein korrelaatiohaku on ajastettu suoritettavaksi. Suurissa ympäristöissä tämä ajastusväli on usein muutaman minuutin luokkaa, mikä on silti riittävän nopea NIS2:n 24 tunnin ilmoitusikkunaan, mutta hitaampi kuin Wazuhin tapahtumakohtainen reagointi.

Henkilöstötarve: kuka ylläpitää järjestelmää arjessa

Hinnoittelutaulukko kertoo vain puolet tarinasta, koska SIEM ei toimi itsestään kummassakaan tapauksessa. Wazuh-ympäristö vaatii organisaatiolta jatkuvaa infraosaamista: palvelinten patchaus, klusterin skaalaus kun lokivolyymi kasvaa, indeksointinodejen seuranta ja sääntökannan ylläpito ovat kaikki sisäisen tiimin tai ostetun kumppanin vastuulla. Käytännössä tämä tarkoittaa, että pienikin Wazuh-käyttöönotto vaatii vähintään yhden henkilön, jolla on riittävä Linux- ja verkko-osaaminen, ja suuremmassa ympäristössä tarvitaan omistettu infratiimi.

Splunk Cloudissa sama infravastuu siirtyy suurelta osin toimittajalle: palvelinten ylläpito, skaalaus ja perusturvallisuus kuuluvat Splunkin SLA-sopimukseen. Tämä ei kuitenkaan poista tarvetta osaavalle analyytikolle, joka osaa kirjoittaa ja virittää SPL-hakuja, rakentaa dashboardeja ja tulkita Enterprise Securityn riskipisteytystä oikein. Monissa pohjoismaisissa organisaatioissa tämä osaamisvaje ratkaistaan ostamalla MSSP-palvelu, jolloin varsinainen analyytikkotyö ulkoistetaan kokonaan, ja sisäiseksi vastuuksi jää vain yhteyshenkilön rooli ja eskalaatioiden käsittely.

Käytännön nyrkkisääntö: jos organisaatiolla ei ole vähintään yhtä kokopäiväistä turva-analyytikkoa tai ostettua MSSP-sopimusta, kumpi tahansa SIEM-tuote jää ennen pitkää vaille hoitoa, sääntökannat vanhenevat ja hälytysten määrä kasvaa hallitsemattomaksi ”hälytysväsymykseksi”, jolloin aidot poikkeamat hukkuvat kohinaan.

Lokien säilytys, retentio ja tietovarastointi

Retentiopolitiikka vaikuttaa suoraan molempien tuotteiden kustannuksiin, vaikka mekanismi on erilainen. Splunkissa pidempi säilytysaika tarkoittaa suoraan suurempaa indeksoitua data-määrää, joka näkyy laskutuksessa sekä GB-perusteisissa että työkuormaperusteisissa malleissa: mitä pidempään data pidetään kuumana hakua varten, sitä enemmän kapasiteettia ja siten SVC-yksiköitä tarvitaan. Monet organisaatiot ratkaisevat tämän siirtämällä vanhemman datan kylmään, halvempaan tallennustilaan, josta haku on hitaampaa mutta joka täyttää vielä compliance-vaatimukset.

Wazuhissa retentio on puhtaasti infrastruktuurikysymys: säilytysaika rajoittuu siihen levytilaan, jonka organisaatio on itse varannut indeksointinodeille. Tämä antaa enemmän kontrollia, mutta siirtää myös vastuun oikein mitoittamisesta kokonaan sisäiselle tiimille. NIS2- ja GDPR-tutkinnoissa säilytysajalla on suora merkitys: jos häiriö havaitaan viikkoja tapahtuman jälkeen, mutta lokit on jo poistettu lyhyen retentioikkunan takia, täyttä tapahtumaketjua ei voida jälkikäteen rekonstruoida ilmoitusta varten. Tämän vuoksi monet pohjoismaiset turva-arkkitehdit suosittelevat vähintään 12 kuukauden kuuman tai lämpimän säilytysajan kriittisimmille lokilähteille, riippumatta siitä, kumpi alusta on käytössä.

SOAR-automaatio ja vasteen nopeus

Hälytyksen havaitseminen on vain puoli työtä: toinen puoli on se, kuinka nopeasti organisaatio reagoi. Tässä Splunkin kypsä kumppaniekosysteemi näkyy selvimmin, sillä Enterprise Security integroituu suoraan useisiin SOAR-alustoihin (Security Orchestration, Automation and Response), joiden avulla tietyt vastetoimenpiteet, kuten käyttäjätilin lukitseminen tai IP-osoitteen eristäminen palomuurisäännöllä, voidaan automatisoida kokonaan ihmisen käsin tekemän työn ulkopuolelle. Tämä lyhentää merkittävästi aikaa havainnosta torjuntaan, mikä on erityisen tärkeää kiristyshaittaohjelmatapauksissa, joissa minuuteilla on väliä.

Wazuhissa vastaava automaatio toteutetaan activa-vasteiden (active response) kautta, joka on sisäänrakennettu ominaisuus ja mahdollistaa esimerkiksi IP-osoitteen automaattisen eristämisen suoraan agentin tasolla ilman erillistä SOAR-lisenssiä. Toiminnallisuus on suppeampi kuin täysimittaisen SOAR-alustan, mutta se kattaa monen pienemmän organisaation perustarpeet ilmaiseksi. Suuremmissa ympäristöissä Wazuh voidaan myös yhdistää erilliseen avoimen lähdekoodin SOAR-työkaluun, mutta tällöin integraatiotyö jää kokonaan oman tiimin vastuulle.

Kubernetes ja pilvinatiivit ympäristöt

Pilvisiirtymä on muuttanut sitä, millaista dataa SIEM-järjestelmän täytyy ymmärtää. Perinteisten palomuuri- ja palvelinlokien rinnalle on tullut Kubernetes-klusterien audit-lokit, konttien ajonaikainen telemetria ja pilvialustojen omat hallintatason lokit, kuten AWS CloudTrail tai Azure Activity Log. Molemmat tuotteet tukevat näitä lähteitä, mutta käyttöönottotapa eroaa: Wazuh-agentti voidaan ajaa DaemonSet-muodossa Kubernetes-klusterissa, jolloin se kerää lokit suoraan solmuilta, kun taas Splunkiin data tuodaan tyypillisesti erillisten keräinten tai pilvialustan omien lokinviejien kautta Splunk HTTP Event Collectoriin.

Kustannusvaikutus on merkittävä pilvinatiivissa ympäristössä, koska konttiorkestroinnin lokivolyymi kasvaa nopeasti, kun palveluita skaalataan automaattisesti kuormituksen mukaan. Splunkin GB-perusteinen tai SVC-perusteinen hinnoittelu reagoi suoraan tähän kasvuun, kun taas Wazuhissa kasvava volyymi näkyy vain lisääntyvänä levy- ja laskentatarpeena, ei suoraan laskussa. Tämä on yksi keskeinen syy, miksi monet pilvinatiivit startupit ja kasvuyritykset päätyvät Wazuhiin: epävarman, nopeasti vaihtelevan lokivolyymin hinnoittelematon malli on ennustettavampi kuin kulutusperusteinen laskutus.

Konttiympäristöissä korostuu myös lyhytikäisyys: yksittäinen kontti voi elää vain minuutteja, jolloin perinteinen, pysyvään isäntään sidottu agenttimalli ei riitä. Molemmat tuotteet ovat vastanneet tähän kevyemmillä, sidecar-tyyppisillä keräystavoilla, mutta käytännön kattavuus vaihtelee klusterin mukaan, joten orkestrointikerroksen lokikattavuus kannattaa testata erikseen ennen laajaa tuotantokäyttöönottoa.

Riskit ja sudenkuopat molemmissa ratkaisuissa

Wazuhin suurin riski ei ole tekninen vaan organisatorinen: koska ohjelmisto on ilmainen, sen käyttöönotto aliarvioidaan helposti projektina, ja tiimi huomaa vasta tuotannossa, että klusterin skaalaus, varmuuskopiointi ja sääntökannan ylläpito vievät enemmän työtunteja kuin odotettiin. Toinen riski on osaamisen keskittyminen yhteen tai kahteen henkilöön: jos ainoa Wazuh-asiantuntija vaihtaa työpaikkaa, organisaatio voi jäädä ilman kykyä ylläpitää järjestelmää tehokkaasti.

Splunkin suurin riski on kustannusten karkaaminen käsistä. Koska hinnoittelu on kulutusperusteista ja monimutkaista, lokivolyymin odottamaton kasvu, esimerkiksi uuden sovelluksen käyttöönoton tai virheellisesti konfiguroidun lokitason takia, voi johtaa laskuun, joka ylittää budjetin merkittävästi ilman ennakkovaroitusta. Toinen riski on toimittajalukkiutuminen: kun kaikki korrelaatiosäännöt, dashboardit ja raportointityö on rakennettu Splunkin SPL-kielelle ja Enterprise Securityn sisälle, siirtyminen pois alustasta on työläs ja hidas prosessi, kuten aiemmin kuvattu migraatio-opas osoittaa.

Hinnoittelu euroina ja dollareina: mitä kummasta todella maksaa

Kummallakaan tuotteella ei ole yhtä yksinkertaista hintalappua, mutta suuntaa antavat luvut auttavat budjetointia. Alla oleva taulukko perustuu SIEMCostCalculator.comin lokakuun 2026 hinta-analyysiin ja on tarkoitettu suuntaa antavaksi, ei sitovaksi listahinnaksi, koska Splunk ei julkaise universaalia hintaa.

Malli ja volyymiSuuntaa antava hinta / vuosi
Splunk Cloud, 5-9 GB/päivä~2 049,30 $ / GB / vuosi
Splunk Cloud, 50-99 GB/päivä~1 265 $ / GB / vuosi
Splunk Cloud, 100-199 GB/päivä~1 012 $ / GB / vuosi
Splunk Cloud, 5 000+ GB/päivä~764,75 $ / GB / vuosi
Splunk Enterprise, 1 GB/päivä~2 277 $ / GB / vuosi
Splunk Enterprise, 50-99 GB/päivä~961,40 $ / GB / vuosi
Splunk Enterprise, 5 000+ GB/päivä~575 $ / GB / vuosi
Enterprise Security -lisäosa, 50 GB/päivä+noin 96 % perushinnasta
Enterprise Security -lisäosa, suuret volyymit+noin 55-75 % perushinnasta
Wazuh, itse ylläpidetty0 € lisenssi, infra- ja ylläpitokustannus erikseen
Wazuh, kaupallinen tuki/pilviTarjouspyynnöstä, ei julkista listahintaa

Luvut kertovat selvän tarinan: mitä enemmän dataa organisaatio syöttää Splunkiin, sitä edullisemmaksi gigatavun hinta muuttuu, mutta absoluuttinen laskutus kasvaa silti suuremmaksi volyymin myötä. Enterprise Security -lisäosan osuus on erityisen tärkeä huomata, koska se on juuri se kerros, joka tekee Splunkista varsinaisen SIEM-tuotteen eikä vain lokivarastoa. Pienellä 50 GB/päivä -volyymilla lisäosa voi lähes kaksinkertaistaa kokonaiskustannuksen verrattuna puhtaaseen data-alustaan. Wazuhin puolella tilanne on päinvastainen: ohjelmisto on maksuton, mutta kaikki mitoitus, redundanssi ja virheenkorjaus jäävät sisäisen tiimin tai ostetun tukisopimuksen vastuulle, eikä tätä kustannusta voi arvioida yleispätevästi, koska se riippuu täysin organisaation omasta infrastruktuurista ja henkilöstökustannuksista.

Kolmas vertailukohta tulee Senseonin Splunk-hinnoittelun erittelystä, joka vahvistaa saman peruslogiikan: Splunkin ingest-, työkuorma- ja aktiivisuusperusteiset mallit tähtäävät siihen, että organisaatio maksaa tarkemmin sen mukaan, mitä se oikeasti käyttää, mutta samalla hinnoittelu muuttuu vaikeammaksi ennustaa etukäteen kuin yksinkertaisessa per-gigatavu-mallissa.

Suorituskyky ja skaalautuvuus: mitä kolme lähdettä kertovat

Suoraa, molemmille tuotteille yhteistä tapahtumaa-sekunnissa-benchmarkkia ei lokakuussa 2026 ollut julkisesti saatavilla yhdestä riippumattomasta lähteestä, eikä tässä vertailussa esitetä lukua, jota ei voida jäljittää todelliseen mittaukseen. Sen sijaan kolme lähdettä antavat yhdessä realistisen kuvan skaalautumisen logiikasta.

  • Wazuhin oma dokumentaatio: klusteroitu manager-arkkitehtuuri on suunniteltu horisontaaliseen skaalaukseen lisäämällä indeksointinodeja, kun agenttien määrä kasvaa; organisaatio vastaa itse kapasiteetin mitoituksesta.
  • Splunkin Cloud Flex -dokumentaatio: SVC-kapasiteetti on sidottu noin yhteen SVC-yksikköön kymmentä gigatavua kohden päivässä, mikä tarkoittaa, että haku- ja dashboard-kuorma kasvaa suoraan sisäänottovolyymin mukana, ellei organisaatio osta erikseen lisää laskentatehoa.
  • SIEMCostCalculator.comin analyysi: hinnan lasku suurilla volyymeilla (575 $/GB 5 000+ GB/päivä -tasolla verrattuna 2 277 $/GB yhden gigatavun tasolla) viittaa siihen, että Splunkin infrastruktuuri on optimoitu suurille, vakiintuneille organisaatioille, ei pienille piloteille.

Käytännön johtopäätös on, että kumpikaan tuote ei ”voita” suorituskykyä yleispätevästi irrallisella luvulla. Oikea tapa testata on ajaa oma pilottiympäristö molemmilla: syötä samat Windows-, Linux-, palomuuri-, identiteetti- ja pilvilokit sisään ja mittaa sisäänoton viive, haun vasteaika ja hälytyksen syntymisnopeus omassa ympäristössä. Tämä on myös se lähestymistapa, jota turva-arkkitehdit yleisesti suosittelevat ennen lopullista hankintapäätöstä, koska markkinointibenchmarkit harvoin vastaavat todellista sekalaista lokiympäristöä.

2026 haavoittuvuudet, joita SIEM paljastaa: neljä tapausta

SIEM-valinnan merkitys näkyy parhaiten konkreettisten haavoittuvuuksien kautta. Syksyllä 2026 CISA:n tunnettujen hyödynnettyjen haavoittuvuuksien (KEV) listalle on lisätty useita kriittisiä tapauksia, joiden havaitseminen ympäristössä edellyttää toimivaa lokikorrelaatiota riippumatta siitä, kumpaa alustaa organisaatio käyttää.

CVE-tunnisteKohdeCVSSTyyppi
CVE-2026-76504Cisco Catalyst SD-WAN Manager9.8Todennuksen ohitus
CVE-2026-102255SonicWall SMA 100010.0SSRF
CVE-2026-76465Cisco Nexus-kytkimet9.8Etäkoodin suoritus
CVE-2026-102764BeyondTrust Remote Support ≤26.2.3Kriittinen (CISA KEV)Todennuksen ohitus huijaamalla

Kaikki neljä on lisätty CISA:n KEV-listalle, mikä tarkoittaa vahvistettua aktiivista hyödyntämistä luonnossa. Yhteinen nimittäjä on, että jokainen niistä jättää jäljen lokeihin: epätavallinen hallintaliikenne SD-WAN-hallintaan, poikkeava sisäverkon pyyntö SSRF-haavoittuvuuden kautta, odottamaton prosessin käynnistys kytkimellä tai epäonnistunut mutta toistuva todennusyritys etätukisovelluksessa. Sekä Wazuh että Splunk pystyvät havaitsemaan tällaiset poikkeamat, kunhan korrelaatiosäännöt ja hälytyskynnykset on viritetty oikein ja lokit todella virtaavat kyseisistä järjestelmistä SIEM:iin asti. Juuri tämä on syy, miksi Traficomin Kyberturvallisuuskeskus nosti Cisco-, F5-, Check Point- ja GitLab-haavoittuvuudet esiin syyskuun 2026 kybersää-katsauksessaan: ilman keskitettyä näkyvyyttä näitä poikkeamia ei huomata ajoissa.

NIS2, GDPR ja pohjoismainen sääntely-ympäristö

NIS2-direktiivi on muuttanut SIEM-valinnan luonnetta liiketoimintapäätöksestä osittain lakisääteiseksi velvoitteeksi. Direktiivin piiriin kuuluvat essentiaaliset ja tärkeät toimijat energiasektorilla, terveydenhuollossa, liikenteessä, digitaalisessa infrastruktuurissa ja julkishallinnossa, ja niiden on ilmoitettava merkittävästä poikkeamasta valvovalle viranomaiselle 24 tunnin sisällä havainnosta sekä toimitettava täydellisempi raportti 72 tunnin kuluessa. Maksimisakot essentiaalisille toimijoille voivat nousta 10 miljoonaan euroon tai 2 prosenttiin globaalista vuosiliikevaihdosta.

Tämä aikaraja on käytännössä mahdoton täyttää manuaalisella lokien tarkastelulla. Organisaatio tarvitsee järjestelmän, joka kokoaa tapahtumat yhteen, korreloi ne automaattisesti ja antaa turvatiimille riittävän ajoissa tiedon siitä, että jotain merkittävää on tapahtunut. Sekä Wazuh että Splunk tarjoavat tähän valmiita säädöstenmukaisuusmoduuleja: Wazuhissa PCI DSS-, GDPR- ja NIST-yhteensopivat säännöstöpohjat on sisäänrakennettu avoimen lähdekoodin pakettiin, kun taas Splunkissa vastaavat sisällöt tulevat Enterprise Securityn ja erillisten lisäosien kautta, mikä nostaa jo aiemmin mainittua kokonaiskustannusta.

GDPR-näkökulmasta valinnalla on myös tietosuojaulottuvuus. Itse ylläpidetty Wazuh-asennus antaa organisaatiolle täyden kontrollin siitä, missä lokit ja henkilötiedot fyysisesti sijaitsevat, mikä voi helpottaa tietosuojaselvityksiä ja data-residenssivaatimuksia. Splunk Cloud sen sijaan tarjoaa hallinnoidun palvelun, jossa vastuu infrastruktuurista siirtyy toimittajalle, mutta organisaation on silti varmistettava sopimusteitse, missä konesaleissa data käsitellään ja säilytetään. Kummassakaan tapauksessa SIEM ei automaattisesti ratkaise GDPR-velvoitteita, mutta se on edellytys sille, että tietomurron laajuus ja vaikutus voidaan ylipäätään selvittää 72 tunnin ilmoitusajassa, jota GDPR edellyttää henkilötietojen tietoturvaloukkauksista.

Kenelle Wazuh sopii: viisi käyttötapausta

  • Pieni tai keskisuuri yritys tiukalla budjetilla: kun ohjelmistolisenssiin ei ole varaa, mutta sisäistä teknistä osaamista on, Wazuh antaa täyden SIEM- ja haavoittuvuusskannaustoiminnallisuuden ilman lisenssimaksua.
  • Startup tai pelistudio kasvuvaiheessa: infrastruktuuri on usein jo pilvipohjainen ja automatisoitu, joten Wazuh-agenttien käyttöönotto konttien ja virtuaalikoneiden rinnalle on suhteellisen nopeaa, eikä kasvava lokivolyymi aiheuta yllättäviä laskutuspiikkejä.
  • Korkeakoulu tai tutkimuslaitos: opetus- ja tutkimusympäristöissä avoin lähdekoodi mahdollistaa alustan muokkaamisen ja opiskelijoiden pääsyn koodiin, mikä on harvoin mahdollista kaupallisissa suljetuissa tuotteissa.
  • Organisaatio, joka vaatii täyttä data-residenssikontrollia: kun lokeja ei saa viedä oman konesalin ulkopuolelle sääntelysyistä, itse ylläpidetty Wazuh-klusteri on suoraviivaisempi ratkaisu kuin pilvipohjainen SIEM.
  • Teollisuusyritys OT-ympäristön valvonnassa: kevyt agentti ja sisäänrakennettu tiedostojen eheyden valvonta sopivat tuotantoympäristöihin, joissa laitteiden resurssit ja verkkoyhteydet ovat rajallisia.

Kenelle Splunk sopii: viisi käyttötapausta

  • Finanssialan toimija PCI DSS -vaatimusten alla: Splunkin kumppaniverkosto ja Enterprise Securityn valmiit sisällöt nopeuttavat auditointiraportointia, kun ulkoinen tarkastaja vaatii valmiiksi dokumentoituja kontrolleja.
  • Suuri konserni usealla maayksiköllä: kun lokivolyymi on jo satoja gigatavuja päivässä, Splunkin suurten volyymien hinnoittelu (575 $/GB 5 000+ GB/päivä -tasolla) muuttuu suhteellisesti edullisemmaksi kuin pienen organisaation hinnoittelu.
  • MSSP tai SOC-palveluntarjoaja usealle asiakkaalle: Splunkin moniasiakasarkkitehtuuri ja laaja integraatiokirjasto helpottavat kymmenien erilaisten asiakasympäristöjen hallintaa samasta alustasta.
  • Julkishallinnon organisaatio, joka tarvitsee SLA-tukea: kun sisäistä 24/7-päivystystä ei ole, Splunkin kaupallinen tuki ja kumppaniverkosto tarjoavat sopimuspohjaisen takuun vasteajoista, joita avoimen lähdekoodin yhteisötuki ei voi antaa.
  • Organisaatio, joka tarvitsee valmiita SOAR-integraatioita: kun turvatiimi haluaa automatisoida vastetoimenpiteitä suoraan hälytyksestä, Splunkin valmiit liitännät palomuureihin, EDR-tuotteisiin ja lippujärjestelmiin säästävät merkittävästi integraatiotyötä.

Viisi reaalimaailman esimerkkiä käytöstä

Seuraavat esimerkit kuvaavat tyypillisiä tilanteita, joissa valinta Wazuhin ja Splunkin välillä ratkeaa käytännön reunaehtojen perusteella, ei tuotemerkin perusteella.

  • Kuntayhtymän terveyspalvelu: NIS2:n piiriin kuuluva terveydenhuollon toimija rakentaa oman SOC:n rajallisella budjetilla. Wazuh-klusteri kolmella palvelimella kattaa noin 500 päätelaitetta, ja säästyneet lisenssikulut käytetään sisäisen analyytikon palkkaamiseen.
  • Pankki tai vakuutusyhtiö: PCI DSS- ja finanssivalvonnan vaatimukset edellyttävät auditoitua, SLA-tuettua ratkaisua. Splunk Cloud valitaan, koska Enterprise Securityn valmiit compliance-sisällöt lyhentävät auditointiin kuluvaa aikaa merkittävästi verrattuna siihen, että sisällöt rakennettaisiin itse.
  • MSSP, joka palvelee 40 pientä asiakasyritystä: palveluntarjoaja käyttää Splunkin moniasiakasarkkitehtuuria yhden hallintapaneelin alla, koska asiakkaiden erilliset Wazuh-klusterit vaatisivat moninkertaisen ylläpitotyön.
  • Pelistudio kasvuvaiheessa: startup, jolla on 25 työntekijää ja pilvi-infrastruktuuri AWS:ssä, ottaa Wazuhin käyttöön konttiklusterin rinnalle ilman erillistä SIEM-budjettia, ja agentit asennetaan osana olemassa olevaa infra-as-code-putkea.
  • Teollisuuskonserni OT/IT-rajapinnassa: tuotantolaitoksen valvomoverkko ja toimistoverkko yhdistetään yhteen näkyvyyteen Wazuhin kevyillä agenteilla, kun taas konsernin IT-pääkonttori ajaa rinnakkain Splunk Cloudia liiketoimintasovellusten lokien analytiikkaan.

Edut ja haitat: Wazuh

  • Edut: ei lisenssimaksua, sisäänrakennettu haavoittuvuusskannaus ja tiedostojen eheyden valvonta, täysi data-residenssikontrolli, aktiivinen avoimen lähdekoodin yhteisö, nopea pilotointi pienessä ympäristössä.
  • Haitat: koko infrastruktuurin mitoitus ja skaalaus jää organisaation vastuulle, kaupallisen tuen hinnoittelu ei ole julkista, valmiita kolmannen osapuolen integraatioita on vähemmän kuin Splunkin ekosysteemissä, suurten ympäristöjen klusterointi vaatii syvää sisäistä osaamista.

Edut ja haitat: Splunk

  • Edut: laaja kumppani- ja integraatioekosysteemi, valmiit säädöstenmukaisuussisällöt, SLA-pohjainen kaupallinen tuki, joustavat hinnoittelumallit suurille volyymeille, Splunk Cloud siirtää infrastruktuurivastuun pois sisäiseltä tiimiltä.
  • Haitat: Enterprise Security -lisäosa voi lähes kaksinkertaistaa kustannuksen pienillä volyymeilla, hinnoittelu on tarjouspohjaista ja vaikea ennustaa etukäteen, pienelle organisaatiolle per-gigatavu-hinta on korkea, täysi toiminnallisuus vaatii useiden erillisten tuotteiden ostamisen.

Migraatio-opas: siirtyminen Splunkista Wazuhiin tai päinvastoin

SIEM-alustan vaihtaminen on aina riskialtis projekti, koska turvatiimi ei saa menettää näkyvyyttä hetkeksikään siirtymän aikana. Seuraava vaiheistus toimii suuntaan kuin suuntaan, vaikka yksityiskohdat eroavat sen mukaan, kumpaan järjestelmään siirrytään.

Ennen migraatiota: kartoitus ja rinnakkaisajo

  1. Listaa kaikki nykyiset lokilähteet: palomuurit, pääteasemat, pilvipalvelut, sovellukset ja identiteettijärjestelmät.
  2. Tunnista nykyisen järjestelmän korrelaatiosäännöt ja hälytykset, jotka täytyy rakentaa uudelleen kohdejärjestelmään.
  3. Pystytä kohdejärjestelmä (Wazuh-klusteri tai Splunk-ympäristö) erilliseen testiympäristöön ensin.
  4. Aja molempia järjestelmiä rinnakkain vähintään 4-6 viikon ajan samoilla lokilähteillä.

Migraation vaiheet

  1. Asenna agentit (Wazuh-agentti tai Splunk Universal Forwarder) kriittisimpiin järjestelmiin ensin, kuten verkon reunalaitteisiin ja tunnistautumispalvelimiin.
  2. Rakenna uudelleen tärkeimmät korrelaatiosäännöt ja vertaa hälytysten laukeamista molemmissa järjestelmissä rinnakkain.
  3. Siirrä säädöstenmukaisuusraportit (PCI DSS, GDPR, NIS2) uuteen järjestelmään ja validoi, että auditointijäljet säilyvät eheinä.
  4. Kouluta analyytikot uuden käyttöliittymän ja hälytyslogiikan käyttöön ennen täyttä siirtymää.
  5. Siirrä loput lokilähteet vaiheittain, aloittaen matalariskisimmistä järjestelmistä.
  6. Pidä vanha järjestelmä vain luku -tilassa vähintään 90 päivän ajan tutkinta- ja auditointitarpeita varten, ennen kuin se otetaan kokonaan pois käytöstä.

Tärkein yksittäinen virhe migraatioissa on vanhan järjestelmän sammuttaminen liian aikaisin. Jos NIS2- tai GDPR-tutkinta kohdistuu siirtymää edeltävään ajanjaksoon, vanhan järjestelmän lokien täytyy olla edelleen saatavilla, jotta ilmoitusvelvollisuus voidaan täyttää luotettavasti.

Esimerkki: kiristyshaittaohjelman havaitseminen vaihe vaiheelta

Teoreettinen vertailu konkretisoituu parhaiten yhden tapahtumaketjun kautta. Oletetaan, että hyökkääjä on päässyt sisään varastetulla VPN-tunnuksella ja yrittää levittää kiristyshaittaohjelmaa tiedostopalvelimelle. Wazuh-ympäristössä tapahtumaketju etenee näin: agentti tiedostopalvelimella havaitsee tiedostojen eheyden valvonnan (FIM) kautta poikkeuksellisen määrän tiedostojen uudelleennimeämisiä lyhyessä ajassa, sääntö nostaa hälytystason korkeaksi välittömästi, ja jos active response -toiminto on konfiguroitu, agentti voi eristää koneen verkosta automaattisesti sekunneissa, ennen kuin analyytikko on edes avannut hälytystä.

Splunk-ympäristössä sama tapahtuma näkyy ensin raakalokina Universal Forwarderin kautta indeksissä, ja Enterprise Securityn korrelaatiohaku poimii poikkeavan tiedostomuutosmäärän seuraavalla ajastetulla suorituskerralla, joka on tyypillisesti muutaman minuutin välein. Analyytikko saa hälytyksen Enterprise Securityn Notable Events -näkymään, tutkii tapahtumaketjun SPL-hakujen avulla ja laukaisee vastetoimenpiteen manuaalisesti tai integroidun SOAR-työnkulun kautta. Molemmat tiet johtavat samaan lopputulokseen, verkosta eristettyyn koneeseen, mutta Wazuhin reitti on lyhyempi ja nopeampi pienessä, yksinkertaisessa ympäristössä, kun taas Splunkin reitti antaa analyytikolle enemmän kontekstia ja työkaluja, jos tapahtuma osoittautuu monimutkaisemmaksi kuin yksittäinen tartunta.

Jälkikäteisessä tutkinnassa, joka NIS2:n 72 tunnin raportin laatimiseksi tarvitaan, molemmat järjestelmät mahdollistavat koko tapahtumaketjun rekonstruoinnin, kunhan lokit on säilytetty riittävän pitkään ja korrelaatiosäännöt olivat virittyneinä oikein ennen hyökkäystä. Tämä on syy, miksi kumpaa tahansa tuotetta käyttävän organisaation kannattaa testata juuri tällaisia skenaarioita säännöllisesti punaisen tiimin harjoituksissa, eikä luottaa siihen, että oletuskonfiguraatio riittää.

Muut SIEM-vaihtoehdot lyhyesti: miksi vertailu rajattiin näihin kahteen

Wazuh ja Splunk eivät ole markkinan ainoat vaihtoehdot. Microsoft Sentinel on pilvinatiivi SIEM, joka kiinnostaa erityisesti organisaatioita, jotka ovat jo syvällä Microsoft-ekosysteemissä ja käyttävät Azuren identiteettipalveluita laajasti. Elastic Security rakentuu samalle OpenSearch/Elastic-pohjalle, jota Wazuhkin osittain hyödyntää, ja houkuttelee organisaatioita, jotka haluavat enemmän joustavuutta kuin Wazuhin valmiit moduulit tarjoavat, mutta eivät halua maksaa Splunkin hintaa.

Tämä vertailu keskittyy nimenomaan Wazuhiin ja Splunkiin, koska ne edustavat selkeintä ääripäätä samalla akselilla: toisessa päässä täysin avoin, ilmainen, itse hallittava alusta, ja toisessa päässä markkinan vakiintunut, kaupallinen, laajasti tuettu jättituote. Jos organisaation reunaehdot osoittavat tarpeen johonkin näiden välimaastoon, kuten syvään Azure-integraatioon tai Elasticin joustavuuteen, kannattaa ottaa näitä vaihtoehtoja mukaan omaan tarjouspyyntökierrokseen Wazuhin ja Splunkin rinnalle.

Tarkistuslista ennen hankintapäätöstä

Ennen kuin organisaatio sitoutuu kumpaan tahansa alustaan, seuraavat kysymykset kannattaa käydä läpi sisäisesti ja mahdollisen kumppanin kanssa.

  • Kuinka monta gigatavua lokidataa organisaatio tuottaa päivässä tänään, ja kuinka paljon volyymin arvioidaan kasvavan seuraavan kolmen vuoden aikana?
  • Onko sisäisessä tiimissä riittävä Linux-, verkko- ja tietokantaosaaminen ylläpitämään itse hallittua klusteria, vai tarvitaanko ulkoinen kumppani joka tapauksessa?
  • Mitä säädöstenmukaisuusraportteja (NIS2, GDPR, PCI DSS, ISO 27001) organisaatio tarvitsee valmiina, ja kuinka paljon työtä niiden rakentaminen itse veisi?
  • Kuinka nopeasti organisaation on pystyttävä reagoimaan kriittiseen hälytykseen, ja riittääkö hakupohjainen korrelaatio, vai tarvitaanko tapahtumakohtaista reaaliaikaisuutta?
  • Mikä on organisaation riskinsietokyky kulutusperusteisen laskutuksen suhteen verrattuna ennustettavaan, mutta työvoimaintensiiviseen itse ylläpidettyyn malliin?
  • Onko olemassa jo sopimuksia MSSP-palveluntarjoajan kanssa, joka tukee vain toista alustaa, mikä voi vaikuttaa päätökseen suoraan?

Tietoturvan kypsyystaso: milloin organisaatio on valmis kumpaankaan

SIEM-valinta kannattaa sitoa organisaation tietoturvan kypsyystasoon, ei vain budjettiin. Organisaatio, jolla ei ole vielä dokumentoitua häiriönhallintaprosessia, nimettyjä vastuuhenkilöitä tai perustasoista lokien keräystä lainkaan, ei hyödy täysimääräisesti kummastakaan tuotteesta ennen kuin perusasiat ovat kunnossa. Tällaisessa tilanteessa kannattaa ensin määritellä, mitkä tapahtumat organisaatiossa ylipäätään lasketaan turvapoikkeamiksi, kuka ottaa hälytyksen vastaan ja mitä tehdään seuraavaksi, ja vasta sen jälkeen valita työkalu, joka automatisoi tämän jo olemassa olevan prosessin.

Keskitasoisen kypsyyden organisaatio, jolla on jo nimetty turvavastuuhenkilö ja perustason lokienhallinta esimerkiksi palomuurista ja keskeisistä palvelimista, hyötyy useimmiten Wazuhin nopeasta pilotoinnista: järjestelmä saadaan tuottamaan arvoa päivissä, ja investointi voidaan kasvattaa asteittain sitä mukaa, kun kypsyys ja budjetti kasvavat. Korkean kypsyyden organisaatio, jolla on jo oma SOC, dokumentoidut vasteprosessit ja ulkoisia auditointivelvoitteita, hyötyy useammin Splunkin valmiista sisällöistä ja laajasta integraatioekosysteemistä, koska se säästää aikaa, joka muuten kuluisi jo olemassa olevien prosessien uudelleenrakentamiseen uuteen työkaluun.

Tämä kypsyyspohjainen ajattelu selittää myös, miksi osa organisaatioista vaihtaa suuntaa kasvaessaan: pieni startup, joka aloitti Wazuhilla, voi päätyä myöhemmin Splunkiin, kun sääntelyvaatimukset ja asiakasauditoinnit kasvavat, kun taas suuri konserni voi siirtää osan ympäristöstään Wazuhiin kustannussyistä, kun sisäinen osaaminen on kasvanut riittävän vahvaksi kantamaan infravastuun itse.

Markkinatrendi: avoin lähdekoodi haastaa kaupallisen SIEM:n

Lokakuun 2026 pohjoismaisessa kyberturvallisuusmarkkinassa toimii yli 5 400 indeksoitua turva-alan yritystä, mikä kuvaa, miten kilpailtu ja pirstaloitunut markkina tällä hetkellä on. Tässä ympäristössä kustannuspaine ohjaa yhä useamman pienen ja keskisuuren organisaation harkitsemaan avoimen lähdekoodin vaihtoehtoja, koska Splunkin Enterprise Security -lisäosan kustannus voi lähes kaksinkertaistaa kokonaishinnan pienillä volyymeilla. Samaan aikaan Splunk vastaa siirtämällä hinnoittelua kohti joustavampia työkuorma- ja aktiivisuusperusteisia malleja, joiden tarkoitus on sitoa kustannus tarkemmin todelliseen käyttöön eikä vain raakaan sisäänottovolyymiin.

Tämä ei tarkoita, että avoin lähdekoodi syrjäyttäisi kaupallisen SIEM:n nopeasti. Suurilla, sääntelyn alla toimivilla organisaatioilla SLA-pohjainen tuki ja valmiit compliance-sisällöt ovat usein tärkeämpiä kuin lisenssikustannus. Pienemmille ja teknisesti osaavammille organisaatioille kustannusero on sen verran suuri, että Wazuhin kaltainen ratkaisu kannattaa aina vähintään pilotoida ennen kaupallisen sopimuksen allekirjoittamista.

Pohjoismainen näkökulma: Suomi, Ruotsi, Norja ja Tanska

Vaikka NIS2-direktiivi on EU-laajuinen, kansallinen toimeenpano eroaa maittain, ja tämä vaikuttaa epäsuorasti SIEM-valintaan. Suomessa Kyberturvallisuuskeskus toimii kansallisena valvovana viranomaisena ja julkaisee säännöllisesti kybersää-katsauksia, joissa nimetään ajankohtaisia haavoittuvuuksia; tämä tekee ajantasaisen uhkatiedon seurannasta ja oman ympäristön vertailusta julkaistuihin haavoittuvuuksiin erityisen tärkeää, riippumatta siitä, kumpaa SIEM-alustaa organisaatio käyttää. Ruotsissa ja Norjassa vastaavat kansalliset kyberturvallisuusviranomaiset painottavat osin samoja raportointivelvoitteita, mutta valvontakäytännöt ja sakkojen käytännön soveltaminen vaihtelevat maakohtaisesti.

Tanskassa ja Norjassa julkisen sektorin hankinnat kulkevat usein tarkkaan säänneltyjen kilpailutusprosessien kautta, joissa avoimen lähdekoodin ratkaisun kokonaiskustannuslaskelma (mukaan lukien henkilöstö- ja ylläpitokustannukset) täytyy dokumentoida yhtä tarkasti kuin kaupallisen tuotteen lisenssikustannus. Tämä tasapuolistaa vertailua tarjouskilpailussa, mutta vaatii organisaatiolta kykyä laskea Wazuhin ”piilokustannukset” realistisesti, jotta vertailu kaupalliseen vaihtoehtoon on rehellinen. Suomalaisille ja pohjoismaisille organisaatioille yleispätevä suositus on sama: oman kokonaiskustannuksen laskeminen kolmen vuoden aikajänteellä, henkilöstökulut mukaan lukien, kertoo enemmän kuin kummankaan toimittajan markkinointimateriaali.

Yhteenveto taulukkona: milloin valitset kumman

Seuraava yhteenveto kokoaa koko vertailun yhteen tiiviiseen päätöksentekotaulukkoon.

TilanneSuositus
Tiukka budjetti, vahva sisäinen tekninen osaaminenWazuh
Suuri lokivolyymi (5 000+ GB/päivä), vakiintunut organisaatioSplunk
Tarve valmiille PCI DSS- tai ISO 27001 -compliance-sisällölle nopeastiSplunk
Tiukka data-residenssivaatimus, ei saa viedä dataa pilveenWazuh
Ei sisäistä 24/7-päivystystä, tarvitaan sopimusperusteinen SLA-tukiSplunk
Startup tai pelistudio nopeasti vaihtelevalla lokivolyymillaWazuh
MSSP, joka hallinnoi kymmeniä erillisiä asiakasympäristöjäSplunk
OT/teollisuusympäristö rajallisilla laiteresursseillaWazuh

Lopullinen verdikti: data puhuu puolestaan

Jos budjetti on tiukka, sisäistä teknistä osaamista on riittävästi, ja data-residenssi on tärkeä vaatimus, Wazuh on looginen valinta: 0 euron lisenssihinta ja sisäänrakennetut compliance-moduulit kattavat ison osan NIS2- ja GDPR-tarpeista ilman erillisiä lisäostoja. Jos organisaatio tarvitsee SLA-tuettua kaupallista tukea, laajaa integraatioekosysteemiä ja valmiita auditointisisältöjä, ja budjetti kestää 50-99 GB/päivä -tasolla noin 1 265 dollarin per-gigatavu-vuosihinnan päälle tulevan Enterprise Security -lisämaksun, Splunk on perustellumpi valinta erityisesti suuren volyymin ja usean sidosryhmän ympäristöissä.

Käytännön nyrkkisääntö pohjoismaiselle organisaatiolle: alle 50 hengen yritys tai startup, jolla on oma DevOps-tiimi, säästää merkittävästi Wazuhilla. Yli 500 hengen organisaatio, joka toimii säännellyllä toimialalla ja tarvitsee ulkoisen auditoinnin tueksi valmiita sisältöjä, maksaa Splunkista mutta saa vastineeksi nopeamman auditointiprosessin ja laajemman tukiverkoston. Kumpikaan valinta ei ole universaalisti oikea, mutta molemmille on nyt olemassa riittävän tarkka hintadata, jotta päätös voidaan perustaa lukuihin eikä mielikuviin.

Konkreettinen esimerkki havainnollistaa eron. Organisaatio, joka tuottaa 20 gigatavua lokidataa päivässä, maksaisi Splunk Cloudissa karkeasti 50-99 GB/päivä -hintaluokan mukaan noin 1 265 dollaria gigatavulta vuodessa, mikä tarkoittaa noin 25 300 dollarin vuosikustannusta pelkästä ingest-oikeudesta, ennen Enterprise Security -lisäosaa, joka tällä volyymitasolla voi lisätä kustannusta kymmenillä prosenteilla. Samalla organisaatiolla Wazuhin suorat lisenssikustannukset ovat nolla, mutta vastineeksi tarvitaan palvelinkapasiteettia ja arviolta vähintään puolen henkilötyövuoden verran ylläpitoa vuodessa, jonka todellinen kustannus riippuu täysin paikallisesta palkkatasosta ja infrastruktuurivalinnoista. Kumpi vaihtoehto on halvempi, riippuu siis siitä, onko organisaatiolla jo olemassa tarvittava osaaminen talon sisällä, vai pitäisikö se rekrytoida tai ostaa erikseen.

SIEM osana laajempaa turva-arkkitehtuuria

Kumpaakaan tuotetta ei valita tyhjiössä, vaan osaksi laajempaa turvatyökalupakkia, johon kuuluu tyypillisesti päätelaitesuojaus (EDR/XDR), palomuurit, identiteetin- ja pääsynhallinta sekä mahdollinen erillinen haavoittuvuusskanneri. SIEM:in tehtävä on toimia kaiken tämän kokoavana kerroksena: se vastaanottaa hälytykset ja lokit kaikista näistä järjestelmistä ja antaa analyytikolle yhden näkymän koko ympäristöön sen sijaan, että hälytyksiä pitäisi tarkistaa kymmenestä erillisestä konsolista.

Tämä integraationäkökulma vaikuttaa suoraan valintaan. Jos organisaatiolla on jo käytössä kaupallinen EDR-tuote ja palomuuri, joiden valmistaja tarjoaa suoran integraation Splunk Enterprise Securityyn, käyttöönotto nopeutuu huomattavasti verrattuna siihen, että samat integraatiot pitäisi rakentaa itse Wazuhiin avoimien rajapintojen kautta. Toisaalta, jos organisaation turvapino on jo rakennettu avoimen lähdekoodin työkalujen varaan, kuten OpenSearchiin tai Suricataan perustuvaan verkkovalvontaan, Wazuhin integrointi samaan ekosysteemiin on usein suoraviivaisempaa, koska tietomallit ja rajapinnat ovat yhteensopivampia keskenään.

Käytännön testi tälle on yksinkertainen: kun organisaatio listaa kaikki nykyiset turvatyökalunsa ja tarkistaa, kuinka moneen niistä on olemassa valmis, dokumentoitu integraatio kummallekin SIEM-ehdokkaalle, lista paljastaa usein nopeasti, kumpi alusta vaatii vähemmän räätälöintityötä omassa ympäristössä. Tämä harjoitus kannattaa tehdä kirjallisesti ennen tarjouspyyntöä, koska se antaa myös neuvotteluvaltin, kun kumppanin kanssa keskustellaan siitä, mitkä integraatiot sisältyvät perushintaan ja mitkä laskutetaan erikseen lisätyönä.

Yleisimmät virheet käyttöönotossa

Molemmilla alustoilla toistuu samat perusvirheet, vaikka ne ilmenevät eri tavalla. Yleisin virhe on se, että käyttöönottoprojekti keskittyy pelkkään tekniseen asennukseen ja unohtaa sääntöjen virittämisen omaan ympäristöön sopivaksi. Oletuskorrelaatiosäännöt, jotka tulevat suoraan Wazuhin tai Splunk Enterprise Securityn mukana, on suunniteltu yleiskäyttöön, ja ne tuottavat usein liikaa vääriä positiivisia hälytyksiä, kunnes niitä on säädetty organisaation todellisen liikenteen ja käyttäjäkäyttäytymisen mukaan. Tämä viritystyö voi viedä useita viikkoja, ja monet organisaatiot aliarvioivat sen keston projektisuunnittelussa.

Toinen toistuva virhe on lokilähteiden osittainen kattavuus. Organisaatio ottaa SIEM:in käyttöön, mutta liittää siihen vain helpoimmat lähteet, kuten palomuurin ja Windows-palvelimet, jättäen esimerkiksi pilvipalveluiden hallintatason lokit, DNS-kyselyt tai sovellustason audit-lokit pois. Tällainen osittainen näkyvyys luo väärän turvallisuuden tunteen: hälytykset näyttävät toimivan, koska yksinkertaiset hyökkäykset näkyvät katettujen lähteiden kautta, mutta kehittyneempi hyökkäys, joka etenee kattamattomien järjestelmien kautta, jää huomaamatta kokonaan.

Kolmas virhe, joka koskee erityisesti Wazuh-käyttöönottoja, on klusterin alimitoitus alkuvaiheessa. Kun pilotti toimii hyvin muutaman kymmenen agentin kanssa, organisaatio olettaa virheellisesti, että sama palvelinkapasiteetti riittää, kun agenttien määrä kasvaa satoihin tai tuhansiin. Tämä johtaa hidastuvaan indeksointiin, viivästyneisiin hälytyksiin ja pahimmassa tapauksessa lokien katoamiseen ruuhkahuippujen aikana. Splunk-puolella vastaava virhe näkyy budjetoinnissa: organisaatio arvioi lokivolyymin kasvun alakanttiin ja saa ikävän yllätyksen laskutuksessa, kun todellinen volyymi ylittää sovitun tilauksen.

Kustannusten hallinta: käytännön keinoja molemmille alustoille

Kustannuksia voi hallita aktiivisesti riippumatta siitä, kumpi alusta on valittu. Splunk-ympäristössä yleisin keino on lokien suodatus ja esikäsittely ennen indeksointia: kaikkea raakadataa ei tarvitse viedä indeksiin täydessä laajuudessaan, vaan vähäarvoinen, toistuva data (kuten rutiininomaiset terveystarkistuspingat) voidaan karsia tai tiivistää ennen sisäänottoa, mikä pienentää suoraan GB-perusteista laskutusta. Toinen keino on tiered storage -malli, jossa vanhempi data siirretään automaattisesti halvempaan, hitaampaan tallennustilaan säilyttäen silti hakukelpoisuuden compliance-tarpeita varten.

Wazuh-ympäristössä kustannusten hallinta tarkoittaa käytännössä infrastruktuurin oikeaa mitoitusta ja automaation hyödyntämistä ylläpidossa. Infrastruktuuri koodina (Infrastructure as Code) -lähestymistapa, jossa klusterin skaalaus ja konfiguraatio on automatisoitu, vähentää manuaalisen ylläpidon tarvetta merkittävästi ja pienentää siten piilevää henkilöstökustannusta. Pilvipohjaisessa ympäristössä myös automaattinen skaalaus kysynnän mukaan, esimerkiksi lisäämällä indeksointinodeja vain ruuhka-aikoina, voi pitää infrastruktuurikustannukset kurissa verrattuna jatkuvasti ylimitoitettuun kiinteään kapasiteettiin.

Molemmissa tapauksissa paras yksittäinen kustannuksia hillitsevä toimenpide on säännöllinen lokilähteiden ja sääntöjen auditointi: kun organisaatio tarkistaa vuosittain, mitkä lokilähteet tuottavat todellista turva-arvoa ja mitkä vain kasvattavat volyymia tai ylläpitotaakkaa ilman hyötyä, kokonaiskustannus pysyy hallinnassa pitkällä aikavälillä kummalla tahansa alustalla.

Usein kysytyt kysymykset

Onko Wazuh täysin ilmainen?
Itse ohjelmisto on avointa lähdekoodia ja maksuton. Kustannuksia syntyy palvelininfrastruktuurista, ylläpidosta ja valinnaisesta kaupallisesta tukisopimuksesta, jonka hintaa ei julkaista yleisesti.

Paljonko Splunk maksaa pienelle organisaatiolle?
Pienillä volyymeilla, kuten 5-9 gigatavua päivässä Splunk Cloudissa, suuntaa antava hinta on noin 2 049 dollaria per gigatavu vuodessa, ja tämän päälle tulee usein Enterprise Security -lisäosa, joka voi lähes kaksinkertaistaa kokonaiskustannuksen pienillä tasoilla.

Kumpi täyttää NIS2:n 24 tunnin ilmoitusvaatimuksen paremmin?
Molemmat voivat täyttää vaatimuksen, kunhan korrelaatiosäännöt ja hälytykset on viritetty oikein ja kaikki olennaiset lokilähteet on liitetty järjestelmään. Ratkaiseva tekijä ei ole tuotemerkki, vaan se, kuinka kattavasti ja oikein järjestelmä on konfiguroitu.

Voiko Wazuhia ja Splunkia käyttää samaan aikaan?
Kyllä, monet organisaatiot ajavat niitä rinnakkain esimerkiksi migraation aikana tai kun eri liiketoimintayksiköillä on erilaiset vaatimukset, kuten OT-ympäristö Wazuhilla ja liiketoimintasovellukset Splunkilla.

Mikä on Wazuhin uusin versio lokakuussa 2026?
Vakain julkaistu versio on 4.14.9, julkaistu 14. lokakuuta 2026. Dokumentaatiossa näkyy myös 5.0.0-julkaisukandidaatti, mutta sitä ei ole vahvistettu tuotantokäyttöön tarkoitetuksi vakaaksi versioksi.

Kuinka kauan Splunkista Wazuhiin siirtyminen kestää?
Pienelle ympäristölle, jossa on muutama kymmenen lokilähdettä, rinnakkaisajo ja migraatio voidaan toteuttaa noin 2-3 kuukaudessa. Suuremmissa, usean sidosryhmän ympäristöissä prosessi kestää tyypillisesti 6-12 kuukautta, kun mukaan lasketaan koulutus ja säädöstenmukaisuuden validointi.

Tarvitseeko molempiin erillisen haavoittuvuusskannerin?
Wazuhissa haavoittuvuusskannaus on sisäänrakennettu moduuli. Splunkissa vastaava toiminnallisuus vaatii erillisen integraation ulkopuoliseen skanneriin, mikä nostaa kokonaisarkkitehtuurin monimutkaisuutta ja kustannusta.

Kumpi sopii paremmin MSSP-palveluntarjoajalle?
Splunkin moniasiakasarkkitehtuuri ja laaja integraatiokirjasto tekevät siitä yleisemmän valinnan palveluntarjoajille, joiden on hallittava kymmeniä erillisiä asiakasympäristöjä samasta hallintapaneelista.

Voiko pienen organisaation Wazuh-asennuksen skaalata myöhemmin suureksi?
Kyllä. Wazuhin manager- ja indeksointinodejen klusterointi on suunniteltu horisontaaliseen skaalaukseen, joten pienestä yhden palvelimen pilotista voidaan kasvattaa monen noden klusteriin lisäämällä laskentaa ja tallennustilaa, kunhan alkuperäinen arkkitehtuurisuunnittelu on tehty skaalautuvaksi alusta alkaen.

Mitä tapahtuu, jos Splunkin lokivolyymi ylittää sovitun tilauksen?
Ylitystilanteessa laskutus kasvaa sovitun hinnoittelumallin (GB/päivä, SVC-työkuorma tai aktiivisuus) mukaisesti, ja ylitykset voivat olla merkittävä yllätyskustannus, jos lokilähteiden määrää tai lokitasoa on muutettu suunnittelematta. Tästä syystä volyymin seuranta ja hälytysrajat omaan tilaukseen kannattaa asettaa osaksi normaalia ylläpitoa.

Voiko Wazuhilla täyttää PCI DSS -vaatimukset ilman Splunkia?
Wazuhin sisäänrakennetut säädöstenmukaisuusmoduulit kattavat suuren osan PCI DSS -valvontavaatimuksista, kuten tiedostojen eheyden valvonnan ja lokien keskitetyn säilytyksen, mutta organisaation on itse varmistettava, että kaikki PCI DSS:n vaatimat tekniset ja hallinnolliset kontrollit on toteutettu, koska pelkkä SIEM-työkalu ei automaattisesti takaa täyttä sertifiointikelpoisuutta kummallakaan alustalla.

Kannattaako pieni organisaatio aloittaa suoraan Splunk Cloudilla välttääkseen infratyön?
Jos sisäistä infraosaamista ei ole lainkaan ja budjetti sallii kulutusperusteisen laskutuksen, Splunk Cloud voi olla järkevä aloitus, koska se poistaa tarpeen rakentaa ja ylläpitää palvelinkapasiteettia itse. Kannattaa kuitenkin mallintaa lokivolyymin kasvu etukäteen, jotta ensimmäinen vuosilasku ei tule yllätyksenä.