Vraag een willekeurige IT-afdeling hoe ze beveiligingsmeldingen afhandelen en het antwoord is bijna altijd hetzelfde: op prioriteit. Rood eerst, oranje als er tijd is, geel zelden. Het klinkt logisch. Er zijn immers veel meer meldingen dan mensen, en de rode zijn per definitie de ernstigste. Toch is het een aanname die in de praktijk niet klopt, en die verklaart waarom organisaties met prima tooling toch verrast worden.
Wat de cijfers uit een SOC laten zien
Wie de meldingen van een druk SOC over een langere periode terugkijkt en ze naast de bevestigde incidenten legt, ziet een patroon dat tegen de intuïtie ingaat. De rode meldingen zijn een klein deel van het totaal en leveren naar verhouding veel bevestigde incidenten op; ze zijn dus efficiënt om als eerste op te pakken. Maar het grootste deel van de incidenten die uiteindelijk echt bleken, begon niet als rode melding. Het begon als een oranje, en een aanzienlijk deel zelfs als een gele: een inlog die net iets afweek, een nieuw geregistreerd apparaat, een script dat op een ongebruikelijk moment draaide. Op zichzelf onschuldig, in samenhang niet.
Dat is ook logisch als je bedenkt hoe moderne aanvallen verlopen. Een aanvaller die met een gestolen sessie inlogt, doet niets wat op malware lijkt. Hij leest mee, maakt een inbox-regel, registreert een app, kijkt rond. Elk van die stappen is op zichzelf een lichte afwijking. De rode melding komt pas als de data al buiten staat, of helemaal niet.
Waarom "alleen de rode" een blinde vlek is
Prioriteren op ernst is een keuze voor efficiëntie, en die keuze heeft een prijs: je ziet de aanval pas als hij zich laat zien. Alles wat traag, gefragmenteerd of vroeg is, valt buiten beeld. Precies daar zit het verschil tussen een incident dat in een uur is afgehandeld en een incident dat weken later als datalek in het nieuws komt.
Het antwoord is niet om alle gele meldingen handmatig te gaan bekijken; dat kan niemand. Het antwoord is samenhang. Een gele melding over een inlog vanuit een ander land, gevolgd door een gele melding over een nieuwe MFA-methode, gevolgd door een gele melding over een inbox-regel, is geen drie gele meldingen. Het is één rode. Die optelsom moet automatisch gemaakt worden, over de bronnen heen: identiteit, cloud, werkplek, netwerk.
Wat dit betekent voor de keuze van een SOC
Bij het beoordelen van een SOC-dienst wordt vaak gevraagd naar reactietijden op kritieke meldingen. Dat is een prima vraag, maar niet de belangrijkste. Stel liever deze:
- Welke bronnen worden gecorreleerd? Alleen werkplekken (EDR) is niet genoeg. De vroege signalen zitten in Entra ID en Microsoft 365: sign-in-risico's, app-toestemmingen, MFA-registraties, mailbox-regels.
- Wat gebeurt er met de oranje en gele meldingen? Worden ze weggefilterd, of worden ze bewaard en in samenhang bekeken? Wie ze weggooit, gooit het begin van de aanval weg.
- Hoe wordt de context toegevoegd? Dezelfde inlog is normaal voor de ene gebruiker en alarmerend voor de andere. Een SOC dat je omgeving niet kent, kan dat verschil niet maken.
- Wat is de eerste ingreep, en hoe snel? Een sessie beëindigen of een account blokkeren moet in minuten kunnen, ook 's nachts, ook zonder dat er eerst iemand belt.
Het gevolg van AI aan de aanvalskant
Deze verschuiving wordt de komende jaren groter, niet kleiner. Automatisering aan de aanvalskant betekent meer campagnes met weinig inspanning, en dus meer lage en middelmatige signalen die het begin van iets echts kunnen zijn. Wie zijn detectie inricht op "wachten tot het rood wordt", zal steeds vaker te laat zijn. Wie de vroege signalen bij elkaar brengt en er automatisch op reageert, is de aanvaller voor.
Dat is de reden dat ons SOC++ niet is gebouwd rond de vraag hoe erg een melding is, maar rond de vraag wat een reeks meldingen samen betekent, met analisten die je omgeving kennen en een eerste ingreep die niet op kantooruren wacht.