Splunk voor cyber security: van logdata naar detectie die werkt
Splunk staat in veel organisaties eerst op de afdeling die niets met security te maken heeft. Het komt binnen om applicatielogs te doorzoeken of een storing te reconstrueren, en pas later ontstaat de vraag: als we al deze data toch hebben, kunnen we er dan ook aanvallen mee opsporen?
Dat kan. Maar splunk cyber security is geen knop die je omzet. Het verschil tussen een platform dat logs bewaart en een platform dat aanvallen opmerkt, zit in de use cases die je erbovenop bouwt, en in de kwaliteit van de data eronder. Dit artikel laat zien welke detecties in de praktijk het meeste opleveren, wat Splunk Attack Analyzer daaraan toevoegt, en waarom een use case zelden werkt zoals hij op papier stond.
Waar Splunk in een security-architectuur zit
Een security-architectuur bestaat grofweg uit sensoren en een plek waar alles samenkomt. Firewalls, endpointagents, identity providers, netwerkdetectie en mailfilters zien elk een deel. Splunk is de plek waar die delen bij elkaar komen, met Splunk Enterprise Security als de laag die er detectielogica, risicoscoring en analistenwerkstroom aan toevoegt.
De waarde zit in de combinatie. Een mislukte login is ruis. Een mislukte login vanaf een onbekend IP, gevolgd door een geslaagde login, gevolgd door een rechtenwijziging, is een verhaal. Geen van de losse bronnen ziet dat verhaal; het ontstaat pas als de gegevens naast elkaar liggen.
Daar hoort een nuchtere kanttekening bij. Splunk maakt een aanval zichtbaar die zich in de data aftekent. Wat je niet binnenhaalt, zie je niet, en het onderdeel dat in de praktijk het vaakst ontbreekt, is niet een exotische bron maar goede identity- en authenticatiedata.
Vijf security use cases die het vaakst iets opleveren
Brute force en password spraying. Veel mislukte inlogpogingen vanaf één bron, of juist enkele pogingen verspreid over veel accounts. Technisch eenvoudig te bouwen, en meestal de eerste detectie die een organisatie live zet. Het onderscheid tussen beide patronen is wat de melding bruikbaar maakt.
Phishing. Meldingen uit je mailbeveiliging koppelen aan wat er daarna gebeurde: is er geklikt, is er ingelogd, is er data benaderd. De losse melding “phishingmail geblokkeerd” is weinig waard; de vraag of iemand het domein alsnog bezocht, is dat wel.
Insider threat. Gebruikers die afwijken van hun eigen patroon: toegang tot systemen die niet bij hun rol horen, downloadvolumes die niet passen bij hun functie, activiteit buiten werktijden. Dit is de gevoeligste categorie, en de reden dat je hem zorgvuldig inricht — inclusief afspraken met de OR en de privacyfunctionaris over wat je wel en niet mag monitoren.
Lateral movement. Een aanvaller die binnen is, beweegt zijwaarts: nieuwe verbindingen tussen systemen die nooit eerder met elkaar praatten, gebruik van beheeraccounts op ongebruikelijke machines, authenticatiepatronen die niet bij de normale werkverdeling horen. Dit is waar de correlatie tussen netwerk-, endpoint- en identitydata het meeste rendement geeft.
Data-exfiltratie. Ongebruikelijk grote uitgaande datastromen, uploads naar onbekende bestemmingen, of een plotselinge toename in toegang tot gevoelige bronnen. Lastig om scherp te krijgen zonder vals alarm, maar de use case met de grootste impact als hij aanslaat.
De volgorde is geen toeval. De eerste twee bouw je met data die je waarschijnlijk al hebt; de laatste drie vragen om normalisatie, om identitydata en om iemand die de omgeving kent.
Wat Splunk Attack Analyzer toevoegt
Detectie levert meldingen op, en meldingen moeten worden beoordeeld. Bij phishing en verdachte bestanden is dat repetitief, tijdrovend en risicovol handwerk: een analist opent een verdachte link of bijlage in een geïsoleerde omgeving en kijkt wat er gebeurt.
Splunk attack analyzer automatiseert die stap. Verdachte URL’s en bestanden worden geautomatiseerd geanalyseerd in een afgeschermde omgeving, waarbij de keten wordt gevolgd, een link die doorstuurt naar een andere link die uiteindelijk op een nagemaakte inlogpagina uitkomt, en er komt een onderbouwd oordeel uit met de bijbehorende indicatoren.
Voor een SOC dat dagelijks tientallen phishingmeldingen verwerkt, is dat het verschil tussen een wachtrij en een werkstroom. Hoe dat er in de praktijk uitziet, staat beschreven in de case SOC overbelast door phishingbedreigingen.
Wat een use case pas bruikbaar maakt
Een detectie die technisch klopt, is nog geen detectie die werkt. Drie dingen bepalen het verschil.
Datakwaliteit gaat voor detectielogica. Een correlation search die op velden zoekt die in de helft van je bronnen anders heten, mist gewoon de helft. Normalisatie volgens het Common Information Model is saai werk en het rendeert meer dan welke extra detectieregel dan ook.
Elke use case heeft een eigenaar nodig. Niet alleen om hem te bouwen, maar om hem te blijven bijstellen als de omgeving verandert. Detecties die niemand onderhoudt, worden binnen een jaar of stil of onbruikbaar luidruchtig.
Weinig detecties die worden opgevolgd, verslaan veel detecties die dat niet worden. De verleiding om een grote set regels in één keer aan te zetten is groot, en het resultaat is voorspelbaar: meldingen die niemand meer leest. Vijf use cases die tot actie leiden zijn meer waard dan vijftig die in een dashboard staan.
Loopt je SOC vol of komt het opvolgen van meldingen er structureel bij in? Dan is dat een gesprek over capaciteit en inrichting, daar kijken we vanuit Managed Services met je naar. Hoe wij het Splunk-platform inzetten voor security lees je op de Splunk-pagina.
