Barriere: borg 24/7 opvolging en escalatie van kritieke meldingen. Dit is de eerste stap: zonder centraal verzamelde logs is er niets om op te melden, laat staan om binnen een afgesproken tijd op te volgen.
Logs staan vaak verspreid over servers, applicaties en netwerkapparatuur. Ze worden lokaal en kort bewaard, of overschreven. Bij een incident valt er dan weinig te reconstrueren: je weet niet wat er gebeurd is, wanneer, of via welke weg.
Altijd zinvol. Centrale logverzameling is de randvoorwaarde voor elke manier waarop je detectie organiseert, of je die nu zelf doet, samen met een leverancier, of helemaal uitbesteedt.
Wanneer niet: als losse stap zonder vervolg. Logs verzamelen en er daarna niets mee doen levert een datakerkhof op, opslagkosten zonder zicht. Plan dus meteen wat de volgende stap wordt, ook als die er pas over een half jaar komt.
Logbronnen sturen hun gebeurtenissen via forwarders of agents naar een centrale opslag. Daar worden ze genormaliseerd naar een gemeenschappelijk formaat en volgens een vaste retentietermijn bewaard. Kloksynchronisatie via NTP zorgt dat tijdlijnen over bronnen heen kloppen; zonder dat kun je een aanval niet reconstrueren, ook al heb je alle logs.
De drempel is laag; dit is te starten zonder groot project, en leverancier-onafhankelijk.
Wat het oplevert
Waar je op moet letten
Aan de directie. Zonder centrale logverzameling is er bij een incident geen zicht en geen bewijs van wat er gebeurd is. De investering is beperkt en vormt de basis voor elke verdere stap in detectie.
Aan de informatiemanager. Centrale logverzameling raakt elk systeem dat logs levert. Het standaardiseren van logbronnen en formaten loont, juist met het oog op de vervolgstappen.
Aan het MT. De lijnteams moeten hun logbronnen aanleveren en aangesloten houden. Dat is een terugkerende beheertaak, geen eenmalige actie.
Logverzameling heb je in elke vorm nodig. Wat je erop bouwt is een keuze uit vier routes die elkaar uitsluiten: je organiseert de opvolging op een van deze manieren, niet op meer tegelijk. Wat elke route van je vraagt en oplevert staat in het eigen stuk; hieronder staat waarin ze verschillen, zodat je niet vier pagina's naast elkaar hoeft te leggen.
| Route | Wie draait de dienst | Wat je zelf in huis moet hebben | Waar de regie ligt | Wanneer dit de logische keuze is |
|---|---|---|---|---|
| Co-managed SIEM | jij, met een leverancier ernaast | eigen analisten, geheel of deels | volledig bij jou; eigen data en detectieregels | middelgroot tot groot, en je wilt eigen detectievermogen opbouwen |
| Uitbestede SOC | een externe partij | opdrachtgeverschap en opvolging van meldingen | bij de leverancier; jij stuurt op afspraken | geen eigen SOC te bouwen, en detectie moet snel geregeld zijn |
| MDR-dienst | een externe partij, die ook ingrijpt | een mandaat dat je durft weg te geven | bij de leverancier, inclusief handelen | snelle actieve respons nodig; de duurste van de vier |
| Regionaal of gedeeld SOC | jullie samen | bestuurlijke bereidheid om governance te delen | gedeeld en publiek | klein tot middelgroot, en er is al een samenwerkingsverband |
Twee dingen die de keuze in de praktijk bepalen. Ten eerste: een SIEM zonder mensen die hem bedienen en tunen levert vooral ruis op, en die ruis kost meer dan hij oplevert. Ten tweede: bij een regionaal SOC is de techniek zelden het probleem, maar het delen van governance wel.
Deze handleiding hoort bij barriere soc uit de zelfcheck
aanvalspaden en is daarvan de fundering. Welke vorm
je erop bouwt is een keuze; zie Kiezen tussen de routes
hierboven.
Wat je hiermee aantoont in BIO 2.0, NIST CSF, het Wpg-kader en de AVG staat op Van aanvalspad naar norm.