Security monitoring is the practice of continuously watching network activity, system logs, and user behaviour to detect and respond to cyber threats before they cause damage. It matters for the 200-201 exam because you must understand how a Security Operations Centre (SOC) operates, what tools analysts use, and how alerts are triaged to protect an organisation's assets.
Jump to a section
A simple way to picture Security Monitoring Fundamentals
Backstage at a massive music festival, during the headliner's set.
The stage manager is the Security Operations Centre. They never touch a guitar or sing a note. Instead, they sit in a room full of screens showing live video feeds from every corner of the venue. One screen shows the crowd barrier — it's holding steady. Another shows the generator fuel level — normal. A third shows a heat map of the WiFi network — suddenly, a cluster of phones near the VIP tent starts sending strange data packets, like a crowd all shouting the same nonsense at the same time.
The stage manager doesn't run over to the VIP tent themselves. They alert the on-site security team: 'Check the VIP tent, possible credential theft attempt.' The team radios back: 'Someone plugged a rogue device into the network port. We've removed it.' The stage manager logs the incident, notes the time, updates the security dashboard, and reviews the alert rules to see why the system didn't flag this behaviour automatically.
The festival runs smoothly because the stage manager monitors everything without leaving their chair. That's exactly what a SOC does for a company's network. They watch logs, traffic patterns, and alerts from firewalls and servers, then triage issues, escalate threats, and improve defences — all to keep the 'show' (the business operations) running without interruption.
Security monitoring is the organised, continuous observation of an organisation's digital environment to identify suspicious or malicious activity. Think of it as a 24/7 security camera system for a company's entire computer network, but instead of watching people walk down hallways, the cameras watch data packets travel between servers, user logins, file accesses, and application behaviours.
At the heart of security monitoring is the Security Operations Centre, or SOC (pronounced 'sock'). The SOC is a dedicated team of security analysts, engineers, and managers who work in shifts to monitor, detect, analyse, and respond to cybersecurity incidents. A SOC is not a piece of software — it is a physical or virtual room where people sit at consoles reviewing alerts from various detection tools. Many modern SOCs operate remotely, but the concept is the same: a centralised hub for defence.
Why do organisations need security monitoring? Because cyber attacks are not one-off events that announce themselves loudly. Attackers often spend weeks or months inside a network, moving quietly from one system to another, escalating privileges, and stealing data in small chunks. Without monitoring, an organisation might only discover a breach months later, when a customer reports fraud or a ransomware note appears on a server. Security monitoring aims to reduce that 'dwell time' — the period between when an attacker first compromises a system and when the organisation detects them.
The SOC relies on several foundational tools and concepts:
Logs: Every device on a network — servers, firewalls, routers, laptops, cloud applications — records events in a log file. A log entry might say 'User jsmith logged in from IP 203.0.113.7 at 14:32:05'. Security monitoring collects these logs into a central system called a Security Information and Event Management (SIEM) platform. The SIEM (pronounced 'seem') ingests millions of log entries per day and analyses them for patterns that match known attack signatures or anomalous behaviour.
Alerts: When the SIEM or other detection tools find something suspicious, they generate an alert. For example, if a single user account tries to log in from 15 different countries within 10 minutes, the SIEM might create a 'brute force attack' alert. Analysts then triage the alert — they decide whether it is a true threat (a real attack), a false positive (the system being over-cautious), or a benign anomaly (an employee using a VPN while travelling).
Triage: This is the process of prioritising alerts by severity. A 'critical' alert about a potential ransomware deployment gets immediate attention. A 'low' alert about an outdated antivirus definition might be queued for the next shift. Triage ensures the team doesn't waste time on noise while missing a real emergency.
Escalation: If an analyst confirms a genuine threat, they escalate it to a more senior team member or an incident response team. This triggers a formal process to contain, eradicate, and recover from the attack.
Security monitoring replaces the old model of 'reactive security' — waiting for someone to notice something broken and then calling IT. Instead, it is proactive and continuous, designed to catch threats in real-time or near-real-time. It also replaces manual log checking with automated correlation. In the past, an administrator might glance at logs once a week. Today, with thousands of devices, that is impossible. Monitoring tools do the heavy lifting, and humans focus on judgement and response.
The SOC operates on a 'tiered' model. Tier 1 analysts triage alerts and handle common issues like phishing emails or failed login attempts. Tier 2 analysts investigate deeper — they analyse malware samples, examine network traffic captures, and decide if a threat is real. Tier 3 analysts are experts who handle advanced persistent threats (APTs) and develop new detection rules. This hierarchy ensures that the most difficult problems are handled by the most experienced people, while routine work keeps the junior team busy and learning.
Finally, security monitoring relies on good 'visibility' — the ability to see all parts of the network. If a company has a server that sends no logs, it is a blind spot. Attackers love blind spots because they can hide there. A key job for SOC analysts is to ensure that all critical systems are sending logs, that the SIEM is properly configured, and that monitoring coverage is as complete as possible.
Log Ingestion
All devices (servers, firewalls, cloud apps, endpoints) send their event logs to a central SIEM platform. This creates a single source of truth for all activity. Without this step, the SOC has no data to analyse.
Alert Generation
The SIEM applies rules or machine learning models to the ingested logs. When a pattern matches a known attack signature or anomaly (e.g., 10 failed logins from the same IP in 1 minute), it creates an alert. This automation is critical because humans cannot manually search through millions of log entries.
Triage and Prioritisation
A Tier 1 SOC analyst reviews the alert queue, sorted by severity (critical, high, medium, low). They look at the context — source IP, user account, time, asset involved — and decide if the alert warrants further investigation or can be closed as a false positive. This step prevents the team from wasting time on noise.
Investigation and Escalation
If the Tier 1 analyst confirms the alert is a genuine threat, they escalate it to Tier 2 along with all relevant evidence (logs, packet captures, screenshots). Tier 2 performs deeper analysis — such as examining malware behaviour or threat intelligence correlations — to understand the scope of the incident.
Containment and Response
Once the threat is confirmed and understood, the SOC coordinates with incident response teams or uses automated tools to contain the attack — for example, quarantining an infected workstation, blocking an IP address on the firewall, or disabling a compromised user account. The goal is to stop the attacker from causing further damage.
Post-Incident Review and Rule Tuning
After the incident is resolved, the SOC conducts a retrospective. They update the SIEM rules to reduce false positives for similar alerts in the future, and document lessons learned. This step closes the loop, improving the monitoring process over time.
Meet Priya, a Tier 1 SOC analyst at a mid-sized retail company called ShopEase. ShopEase runs an e-commerce website, a warehouse management system, and a customer database — all hosted partly in the cloud and partly in a physical data centre. Priya starts her shift by logging into the SIEM dashboard, which shows a list of alerts generated in the last eight hours. There are 342 alerts. Her job is to process them according to the company's triage policy.
Priya sorts the alerts by severity. The first critical alert is flagged as 'Multiple failed logins followed by a successful login for admin account on database server'. This pattern suggests a brute-force attack may have succeeded. Priya follows the standard operating procedure (SOP) for this alert:
She checks the source IP address of the successful login. It originates from an IP known to be associated with a threat intelligence feed.
She looks at the database server logs and sees that the admin account executed a 'SELECT * FROM customers' query immediately after logging in — an abnormal action for that time of night.
She escalates the alert to Tier 2 with a note: 'Confirmed brute force on DB admin. Source IP in threat feed. Data exfiltration possible. Immediate containment required.'
Priya then moves to a cluster of medium-severity alerts: 'Unusual outbound traffic from workstation to an external IP on port 443.' She reviews the workstation hostname — it belongs to the marketing department. She checks the employee's schedule and sees they were on annual leave during the time of the traffic. This could mean the employee's machine is compromised and being used to send data to a command-and-control (C2) server. She places a containment action: quarantine the workstation from the network via the endpoint protection platform. That blocks any further traffic while her Tier 2 colleague investigates the malware involved.
By midday, Priya has processed 80 low-severity alerts. Most are false positives — like an employee's personal phone connecting to the guest WiFi with an outdated operating system. She documents each one, closes them in the SIEM, and moves on. She also notes that the alert rule for 'unusual outbound traffic' is generating too many false positives from mobile devices. She submits a recommendation to fine-tune the rule to ignore guest WiFi ranges.
At 2 p.m., the SOC manager runs a daily operations review. Priya reports that she escalated two critical incidents, quarantined one endpoint, and recommended one rule change. The manager reviews the metrics: 'time to triage' (how long from alert creation to first action) is averaging 4 minutes, which is within the service-level agreement (SLA). 'Time to escalate' for critical alerts is 12 minutes — also acceptable. The team finishes the shift by checking threat intelligence feeds for new indicators of compromise (IOCs) such as new malware hashes or phishing domains, and updates the SIEM rules if needed.
This daily workflow shows that security monitoring is not about heroic hacking — it is about methodical review, clear procedures, and consistent communication between team members. Priya never writes code or penetrates systems (that is a penetration tester's job). She reads logs, follows playbooks, and makes judgement calls under time pressure. That is the reality of a SOC role.
The 200-201 exam tests your understanding of security monitoring fundamentals through multiple-choice questions that focus on definitions, processes, and the role of SOC tools. You will not be asked to configure a SIEM or analyse a real packet capture. Instead, the exam checks whether you can correctly identify the purpose and function of each monitoring component.
Key concepts the exam loves to test:
The difference between a SIEM and a log management system: A SIEM correlates logs from multiple sources and generates alerts based on rules and analytics. A log management system simply stores logs for retrieval. The exam may present a scenario and ask which tool is appropriate. If the scenario mentions 'real-time alerting' or 'correlation', the answer is SIEM. If it just mentions 'storage and search', it is a log management system.
The role of a SOC and its tiers: Know that Tier 1 triages and escalates, Tier 2 analyses and investigates, and Tier 3 handles advanced threats and creates new rules. The exam may describe an action and ask which tier performs it.
The concept of 'dwell time' and 'mean time to detect' (MTTD) and 'mean time to respond' (MTTR): Dwell time is how long an attacker is present before detection. MTTD is how long it takes to detect an incident. MTTR is how long to contain and fix it. The exam may test which metric is most important for improving security posture — typically reducing MTTD and MTTR is the goal.
Indicators of Compromise (IOCs) vs Indicators of Attack (IOAs): IOCs are forensic evidence of a breach that already happened — a suspicious file hash, a known malicious IP address. IOAs are signs of an attack in progress — unusual login patterns, abnormal data transfers. The exam may present a list of observations and ask which are IOCs and which are IOAs.
False positives vs false negatives: A false positive is when the system alerts on benign activity (crying wolf). A false negative is when the system fails to alert on a real attack (missing the wolf). The exam asks which is more dangerous — false negatives, because they allow attacks to go undetected.
Common traps in the exam:
Traps about 'the SOC analyst's first action': Beginners might think it is 'turn off the server' or 'call the police'. The correct first action is always to validate the alert, check the context (source IP, user, time), and follow the standard operating procedure. Panic containment is never the first step — assessment comes first.
Traps about SIEM vs firewall: A firewall blocks traffic based on rules. A SIEM does not block traffic — it only monitors and alerts. If the question asks 'which device blocks malicious IP addresses', the answer is firewall, not SIEM.
Traps about 'alerts are always attacks': The exam will test whether you understand that alerts need triage. Not every alert is a real incident. Choosing 'automatically block the IP' without analysis is wrong.
Key definitions to memorise:
SOC: A team that monitors and responds to security incidents.
SIEM: A platform that aggregates logs and generates alerts for suspicious activity.
Alert: A notification from a security tool about a potential threat.
Triage: The process of prioritising alerts based on severity.
Escalation: Passing a confirmed threat to a higher-tier analyst or team.
False positive: An alert that incorrectly signals a threat where none exists.
False negative: A real threat that the system fails to detect.
IOC: Evidence of a compromise having occurred.
IOA: Evidence of an attack currently taking place.
Security monitoring is the continuous observation of logs, network traffic, and user behaviour to detect threats in real-time, not after the damage is done.
The SOC is a team of people who triage alerts, not a piece of software or a firewall.
A SIEM collects logs from multiple sources and correlates them to generate alerts, but it does not block attacks by itself.
The three SOC tiers ensure that routine alerts are handled by junior analysts while complex threats are escalated to senior experts.
Dwell time, MTTD (mean time to detect), and MTTR (mean time to respond) are key metrics that measure the effectiveness of security monitoring.
False negatives (missing a real attack) are far more dangerous than false positives (crying wolf) because they leave the organisation vulnerable.
Alerts are not proof of an attack — they are signals that require human triage to determine legitimacy.
These come up on the exam all the time. Here's how to tell them apart.
SIEM (Security Information and Event Management)
Correlates logs from multiple sources to detect patterns and generate alerts
Provides real-time or near-real-time analysis for threat detection
Requires rule configuration and tuning to minimise false positives
Log Management System
Stores logs for compliance and forensic retrieval without correlation
Primarily used for historical searches, not live threat detection
Less complex to deploy but does not actively identify threats
False Positive
An alert that incorrectly signals a threat where no attack exists
Wastes analyst time and can lead to alert fatigue if too frequent
Less dangerous than false negatives because no actual attack is missed
False Negative
A real threat that the system fails to detect
Leaves the organisation vulnerable because no action is taken
More dangerous than false positives because the attacker proceeds undetected
IOC (Indicator of Compromise)
Evidence that a breach has already occurred
Examples: suspicious file hash, known malicious IP, altered registry key
Used for forensic investigation and post-incident analysis
IOA (Indicator of Attack)
Signs that an attack is in progress or about to happen
Examples: unusual login times, spike in outbound traffic, privilege escalation attempts
Used for real-time detection and early intervention
Tier 1 SOC Analyst
Triages alerts and determines if they are real or false positive
Handles high volume of low to medium severity alerts
Escalates confirmed threats to Tier 2 with evidence
Tier 2 SOC Analyst
Conducts deep investigation of escalated threats
Analyses malware, packet captures, and threat intelligence
Develops recommendations for containment and rule improvements
Mistake
Security monitoring means the SOC analyst is constantly hacking or 'fighting' attackers in real time like in movies.
Correct
SOC analysts primarily read logs, triage alerts, and follow playbooks. Direct confrontation with attackers is extremely rare and handled by specialised incident response teams.
Movies portray cybersecurity as a high-speed battle on a keyboard. The reality is methodical analysis of text logs, which feels boring but is effective.
Mistake
A SIEM automatically stops attacks by itself once it detects something bad.
Correct
A SIEM is a monitoring and alerting tool — it does not have the ability to block traffic, shut down servers, or disconnect users. Those actions are performed by other systems like firewalls, endpoint protection, or manual intervention by the SOC.
People assume that because SIEM is a 'security' tool, it must be active. In fact, SIEM is purely observational. Separating detection from response is a common source of confusion.
Mistake
If a SOC generates an alert, it means an attack definitely happened and the company is compromised.
Correct
An alert is only a signal that something unusual occurred. Many alerts are false positives — for example, a legitimate administrator running a script that looks like malware. Every alert must be triaged to confirm whether it is a real threat.
Beginner IT students often think of alerts as absolute truth, like a smoke alarm that only goes off for fire. In cybersecurity, alarms are noisy and unreliable, requiring human judgement to interpret.
Mistake
Security monitoring only needs to cover the company's internal network devices.
Correct
Modern security monitoring must cover cloud services, remote workers' endpoints, mobile devices, third-party applications, and even physical security systems like badge readers. Anything that touches the organisation's data needs monitoring.
Many beginners come from a traditional network admin background where 'the network' meant routers and switches inside a building. Today, the perimeter is gone, and monitoring must be cloud-aware.
Mistake
A SOC analyst's main job is to install and configure security tools.
Correct
The SOC's primary job is to monitor and respond to alerts. Tool configuration and maintenance is typically done by a separate engineering team — the SOC uses the tools, not builds them.
The job title 'analyst' sounds like an analytical position, but beginners conflate it with 'engineer' or 'administrator' because both roles involve security. The division of labour between build and run is not obvious to newcomers.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No. The 200-201 exam tests your understanding of what a SIEM does, its components (like correlation rules and dashboards), and its role in the SOC — not how to configure any particular vendor's tool. You only need conceptual knowledge.
No. A SOC analyst monitors and responds to ongoing threats as they appear. A penetration tester is hired to proactively simulate attacks to find vulnerabilities. They have different goals, though both roles are in cybersecurity.
A log is a raw record of an event, like 'User X logged in at time Y'. An alert is a notification generated by a tool like a SIEM when logs match a rule indicating suspicious activity. Logs are data; alerts are actionable signals.
Many small businesses operate without a dedicated SOC, but they should still have some form of security monitoring, such as using a managed detection and response (MDR) service that acts as an outsourced SOC. Doing nothing is risky.
The industry average dwell time is around 200 days for large organisations, but top-performing SOCs can reduce it to hours or minutes. The goal of security monitoring is to shrink that time as much as possible.
That is a serious issue called a false negative. It can lead to a breach. SOCs mitigate this risk with peer reviews, automated validation checks, and post-incident audits. Mistakes are analysed to improve processes and training.
You've finished Security Monitoring Fundamentals. Continue through the 200-201 study guide to build a complete picture of the exam.
Done with this chapter?