CompTIA SY0-701: Beveiligingsoperaties, Monitoring & Detectie — Studiegids
Onderdeel van de CompTIA Security+ SY0-701 — Studiegids. Oefen met geverifieerde antwoorden in het CompTIA-examencentrum, of doe getimede oefentests op ExamRoll.io.
Moderne security-operaties zijn afhankelijk van het vermogen om signalen waar te nemen, te correleren en erop te reageren, die afkomstig zijn uit alle hoeken van de onderneming: endpoints, netwerkapparaten, identity providers, cloud-workloads en applicaties. Een volwassen detectieprogramma is niet één enkel product, maar een ecosysteem van telemetriepijplijnen, analyse-engines, menselijke analisten en geautomatiseerde respons-workflows, ontworpen om de tijd tussen compromittering en indamming te verkorten.
SIEM en Gecentraliseerde Log-aggregatie
Een Security Information and Event Management-platform (SIEM) is het bindweefsel van het security operations center. Het neemt logs op van uiteenlopende bronnen — Windows Event Logs, Linux syslog, firewall flow-data, DNS-resolvers, Active Directory, endpoint-agents, SaaS-audittrails — normaliseert deze naar een gemeenschappelijk schema en past correlatieregels toe op de geaggregeerde stroom. De waarde ligt niet alleen in de opslag; het is het vermogen om een mislukte VPN-authenticatie in de ene logbron te correleren met een succesvolle geprivilegieerde aanmelding en laterale SMB-toegang in een andere, wat resulteert in één enkele, zeer betrouwbare alert waar drie geïsoleerde gebeurtenissen als ruis zouden zijn beschouwd.
Veelgebruikte platforms zijn onder meer Splunk, Microsoft Sentinel, IBM QRadar, Elastic Security en Chronicle. In cloudomgevingen dienen native tools zoals AWS CloudTrail in combinatie met CloudWatch en GuardDuty, of Azure Monitor met Log Analytics-workspaces, als de ruggengraat voor logging en voeden ze vaak een upstream SIEM.
Een typische Splunk-correlatiezoekopdracht die de logica over meerdere bronnen illustreert:
index=wineventlog EventCode=4625
| stats count by src_ip, user
| where count > 10
| join user [search index=vpn action=success]
| table _time, user, src_ip, count
De valkuil hier is subtiel: een organisatie kan een SIEM implementeren, terabytes aan data opnemen en toch inbraken missen omdat kritieke logbronnen ontbreken. Als gebeurtenissen over het aanmaken van processen op endpoints (Windows Event ID 4688 of Sysmon Event ID 1) niet worden doorgestuurd, of als ‘deny’-logs van de firewall worden afgekapt, worden hele aanvalsfasen onzichtbaar. Dekkingsgraad van logbronnen — expliciet in kaart gebracht ten opzichte van een raamwerk zoals MITRE ATT&CK — is een voorwaarde voor betekenisvolle detectie.
Endpoint Detection and Response
EDR breidt de zichtbaarheid uit naar de host, waar de meeste activiteit van aanvallers uiteindelijk plaatsvindt. In tegenstelling tot traditionele antivirus, die bestands-hashes en signatures matcht, registreren EDR-platforms zoals CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint en Carbon Black continue telemetrie: processtructuren (process trees), command-line argumenten, registerwijzigingen, netwerkverbindingen en het laden van DLL’s. Deze data maakt zowel real-time gedragsdetectie als retrospectieve threat hunting mogelijk.
Een veelvoorkomend misverstand is om EDR te beschouwen als een preventieve maatregel die gelijkwaardig is aan een firewall. EDR detecteert voornamelijk en assisteert bij de respons — het kan bekend kwaadaardig gedrag blokkeren, maar de grotere waarde ligt in het leveren van het forensische spoor waarmee een analist kan bepalen wat een gecompromitteerd proces heeft gedaan, tot welke credentials het toegang had en waar het zich lateraal heeft verplaatst. Responsacties zoals host-isolatie, beëindiging van processen en het in quarantaine plaatsen van bestanden worden doorgaans geïnitieerd door een analist of een SOAR-playbook, niet door de EDR alleen.
IDS/IPS, Signatures en Baseline-handhaving
Netwerkgebaseerde intrusion detection en prevention systems (IDS/IPS) inspecteren verkeer aan de hand van signatures en gedragsmodellen. Een IDS (zoals Snort of Suricata in monitoring-modus) waarschuwt bij verdachte patronen; een IPS bevindt zich inline en blokkeert overeenkomstig verkeer. Een Snort-regel voor het detecteren van een specifiek exploit-patroon demonstreert op signatures gebaseerde logica:
alert tcp any any -> $HOME_NET 445 (
msg:"SMB Exploit Attempt";
content:"|ff|SMB"; offset:4; depth:4;
content:"|72 00|"; distance:0;
sid:9000001; rev:1;
)
Op anomalieën gebaseerde detectie stelt een gedragsbaseline vast en waarschuwt bij afwijkingen — een werkstation dat plotseling 10× meer DNS-queries doet dan normaal, of een server die voor het eerst uitgaande verbindingen opent op poort 4444, vereisen beide onderzoek, ongeacht of er een signature overeenkomt.
Threat Intelligence en Indicator Management
Threat intelligence transformeert ruwe data in bruikbare kennis over de tactieken, technieken en procedures (TTP’s) van tegenstanders. STIX (Structured Threat Information eXpression) is het standaardformaat voor het weergeven van threat intelligence-objecten — indicatoren, campagnes, dreigingsactoren, aanvalspatronen — terwijl TAXII (Trusted Automated eXchange of Indicator Information) het transportprotocol is om deze te delen. Commerciële en open-source feeds (VirusTotal, AlienVault OTX, MISP, Recorded Future) leveren IP-reputatie, domein-blocklists, bestands-hashes en YARA-regels die direct kunnen worden opgenomen in SIEM- en firewall-platforms.
Indicators of Compromise (IoC’s) — kwaadaardige IP-adressen, bestands-hashes, domeinnamen, registersleutels — zijn de meest direct bruikbare informatie, maar ook de meest vluchtige; aanvallers wisselen snel van infrastructuur. Indicators of Attack (IoA’s) richten zich op gedragingen in plaats van op artefacten: een proces dat een child-shell start, een gecodeerd PowerShell-commando, of een service die met een willekeurige naam wordt aangemaakt. Detectie op basis van IoA’s is moeilijker te omzeilen omdat het zich richt op de techniek, niet op de specifieke tool.
Praktijkscenario: Detectiekloof door Ontbrekende Logbronnen
Een financiële dienstverlener implementeerde een SIEM en nam logs op van de perimeter-firewall, Windows Security event logs en de e-mailgateway. Tijdens een red team-oefening verkreeg het team initiële toegang via een phishing-e-mail (gedetecteerd), maar gebruikte vervolgens WMI voor laterale verplaatsing en PowerShell Remoting voor het uitvoeren van commando’s — geen van beide genereerde Windows Security-events in de standaardconfiguratie. Het red team bereikte het treasury-werkstation en exfiltreerde een gesimuleerd bestand voor een bankoverschrijving zonder een enkele SIEM-alert te triggeren na de initiële phishing-detectie. De kloof: Sysmon was niet geïmplementeerd, PowerShell script block logging was niet ingeschakeld en WMI-activiteitenlogging vereiste extra configuratie. De oefening toonde aan dat de dekking van een SIEM slechts zo goed is als de logbronnen die het voeden — een les die moet worden gevalideerd door middel van purple team-oefeningen, en niet moet worden aangenomen op basis van documentatie van de leverancier.
← Netwerkbeveiliging · Alle domeinen · Incidentrespons →
Oefen deze vragen → · Getimede oefening op ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Slaag voor je examen →