Security Operations in 2025: waarom ik mijn SOC-aanpak compleet heb omgegooid

Security Operations in 2025, mijn blik op het speelveld

Ik heb dit jaar mijn hele security-visie herzien. Niet omdat ik vond dat het moest, maar omdat de realiteit me simpelweg inhaalde. Laat ik je meenemen in wat ik zie gebeuren en wat dat betekent voor hoe ik security operaties inricht.

Het begon met een gesprek met een CISO die me vertelde dat zijn SOC inmiddels meer alerts van AI-systemen kreeg dan van alle endpoints bij elkaar. Hij wist niet goed wat hij ermee moest, de SIEM was er niet voor gebouwd, de playbooks dekten het niet, en zijn analisten hadden geen idee wat een "adversarial example" was. Dat moment was voor mij het signaal: security is niet meer wat het was.

Wat er in 2025 écht veranderd is

Drie dingen komen tegelijk op me af, en dat is precies waarom het anders voelt dan voorgaande jaren.

Ten eerste zijn aanvallen slimmer geworden door AI. Niet alleen sneller of groter, maar fundamenteel anders. Aanvallers gebruiken generatieve AI om phishing te personaliseren tot op het niveau van jouw koffiebestelling van vanochtend. Ze maken deepfakes die je eigen moeder niet van echt zou onderscheiden. En ze richten zich niet meer alleen op systemen, ze richten zich op de logica van de AI-modellen die jouw bedrijf aansturen.

Ten tweede bouwen we zelf systemen die actie ondernemen zonder dat een mens ertussen zit. Agent-to-Agent (A2A) protocollen, Multi-Agent Control Panels (MCP), als jij denkt dat dit ver van je bed staat, kijk dan eens naar de automations die jij al draait. Die agents zijn er, of we het nu zo noemen of niet. En elke agent heeft een identiteit, credentials, en rechten. Dat zijn niet-menselijke identiteiten, en die groeien exponentieel.

Ten derde is de wetgever wakker geworden. NIS2, EU AI Act, dit zijn geen papieren exercities meer. De AI Act vereist dat ik aantoonbaar kan loggen wat mijn AI-systemen doen, onveranderlijk, traceerbaar. Dat is geen compliance-vinkje, dat is een architectuureis.

Mijn strategie: vier dingen die ik nu doe

Identiteit als nieuwe perimeter. Ik ga niet meer uit van een netwerk dat ik kan verdedigen. Die grens is allang vervaagd. De echte vraag is: wie of wat vraagt toegang, en waarom? Of het nu een medewerker is, een microservice, of een AI-agent, ik vertrouw niets en verifieer alles. Dat klinkt als een cliché, maar in de praktijk betekent het dat ik voor elke niet-menselijke identiteit een lifecycle-management heb, met kortlevende certificaten en just-in-time rechten. Geen API-sleutels die drie jaar geldig zijn.

AI-specifieke verdediging. Mijn EDR en SIEM zijn blind voor wat er in mijn AI-systemen gebeurt. Data poisoning, model evasion, prompt injection, die dreigingen opereren op een laag die deze tools niet zien. Ik ben gaan loggen op de AI-laag zelf: wat gaat er in een model, wat komt eruit, en wijkt dat af van normaal gedrag? Dat betekent dat ik mijn logging-specificaties heb moeten herbouwen.

Governance als techniek, niet als document. De EU AI Act dwingt me om robuustheid, transparantie en traceerbaarheid in te bouwen in de architectuur van mijn AI-systemen. Dat is geen Excel-sheet voor de jurist. Het betekent immutable logging, modelversionering in de CI/CD-pijplijn, en een audit trail die een inspecteur kan volgen van input tot output. Compliance is naar links verschoven in de ontwikkelcyclus, ik bouw het in, niet erachteraan.

SOC op machinesnelheid. Mijn traditionele SOC werkt niet meer. De snelheid en schaal van AI-gedreven aanvallen dwingt me om zelf een agentic model te omarmen. Ik bouw een intern SOC-MCP dat security-alerts routeert naar gespecialiseerde agenten: één voor dreigingsinformatie, één voor log-analyse, één voor containment. Een incident is een taak die automatisch wordt afgehandeld. De menselijke analist doet waar hij goed in is: strategisch jagen en incidentanalyse.

Roadmap in vogelvlucht

Ik werk in vier blokken van drie maanden.

Q1: Gap-analyse op NIS2 en AI Act. Inventarisatie van alle AI-systemen in de organisatie. Een formeel AI-governance-programma opzetten met Security, Legal, IT en de business.

Q2: Zero Trust-pilot voor een kritieke A2A-workflow. IAM voor niet-menselijke identiteiten implementeren. Certificaat-gebaseerde identiteiten voor agents.

Q3: AI-logstromen integreren in de SIEM. Incident response playbooks ontwikkelen voor data poisoning, API-misbruik en model evasion.

Q4: Geautomatiseerde SOAR-acties via een beveiligd SOC-MCP. Red team-oefening specifiek gericht op AI-infrastructuur.

Het dreigingslandschap zoals ik het zie

Adversarial Machine Learning. Dit is geen科幻 meer. Evasion attacks, data poisoning, model extraction, het zijn echte technieken die worden ingezet. Een model dat stiekem minder goed presteert op bepaalde inputs is geen bug, het kan een aanval zijn. Ik monitor niet alleen netwerkverkeer maar ook modelgedrag, en ik train modellen adversarial om ze robuuster te maken.

LLM supply chain-risico's. Een LLM dat je via fine-tuning op slechte data traint, heeft een backdoor. Niet in de code, maar in de logica. RAG-systemen kunnen worden vergiftigd via de kennisdatabase. En agentic systemen hebben memory-persistence, een aanvaller kan een agent geleidelijk manipuleren via schijnbaar onschuldige interacties. Low-and-slow, en verdomd moeilijk te detecteren.

De convergentie. Een aanval begint met een klassieke phishingmail (ATT&CK), maar de payload is een adversarial example (ATLAS) dat een AI-filter omzeilt. Een SOC dat maar één raamwerk kent, mist de context. Ik zie steeds vaker dat aanvallers zich richten op de orchestratielaag zelf: compromitteer één hoog-geprivilegieerde agent in een MCP, en je hebt controle over het hele systeem. Living off the land, maar dan op de logische laag.

Zero Trust voor mens én machine

Ik pas Zero Trust nu ook toe op A2A- en MCP-architecturen. Elke agent krijgt een PKI-gebaseerde identiteit met kortlevende certificaten. mTLS voor alle communicatie. ABAC in plaats van RBAC voor fijnmazige toegangscontrole. En execution sandboxing voor elke tool-aanroep, als een agent een plugin gebruikt, draait die in een geïsoleerde container.

Een van de inzichten die ik heb opgedaan: een MCP lijkt verdomd veel op een SOAR-platform. Het routeert taken naar gespecialiseerde agents. Dus waarom zou ik geen security MCP bouwen dat incidenten afhandelt met dezelfde principes? Dat is precies wat ik nu doe.

Wat dit betekent voor incident response

Incident response ziet er anders uit als AI in het spel is. Containment betekent niet alleen een server isoleren, maar ook een model terugrollen naar een schone versie, credentials van een agent intrekken, of verkeer omleiden naar een backup-model. Eradicatie is het hertrainen van een neuraal netwerk met opgeschoonde data. Recovery is het veilig uitrollen van dat model via een MLOps-pijplijn.

Incident response wordt MLOps, en dat betekent dat mijn SOC niet meer zonder data scientists en ML-engineers kan. Ik heb cross-functionele responsteams nodig, met bevoegdheden die verder gaan dan traditionele security.

Compliance in de praktijk

GDPR, NIS2 en EU AI Act, ik vertaal ze niet naar documenten, maar naar technische controles. Artikel 32 GDPR (beveiliging van verwerking) betekent sterke encryptie en toegangsbeheer. NIS2 Artikel 21 betekent leveranciersscreenings, ook op data en modellen. EU AI Act Artikel 15 (robuustheid) betekent dat ik AML-verdediging moet inbouwen. En Artikel 12 (logging) is voor mij de grootste impact: automatische, onveranderlijke logging van elke AI-beslissing.

Tenslotte

Security in 2025 is niet moeilijker dan vijf jaar geleden, maar het is wel fundamenteel anders. De gereedschappen en denkwijzen die ik toen gebruikte, schieten tekort. Ik ben mijn aanpak compleet aan het herbouwen: identiteit als perimeter, AI-specifieke detectie, compliance-by-design, en een SOC dat zelf agentic is.

De grootste fout die ik kan maken? Denken dat het nog wel even duurt. Het is al bezig.