# Monitoring and Security Controls

> Chapter 8 of the Courseiva ISC2-SSCP curriculum — https://courseiva.com/learn/isc2-sscp/monitoring-and-security-controls

**Official objective:** 4.3 — Implement and use monitoring tools and security controls to maintain situational awareness.

## Introduction

Domain 4 of the SSCP exam is all about operational security, and a critical part of that is monitoring and security controls. Without constant vigilance, you are flying blind—you won't know if someone is breaking into your network until it is too late. This chapter explains how IT professionals keep an eye on systems, detect trouble, and respond before a minor hiccup becomes a disaster.

## The Home Security Camera System Analogy

Have you ever wondered how you can trust that your house is safe when you are not there?

You install a security camera system. You place cameras at every door and window, and one in the hallway. These cameras constantly stream video to a central recorder. When the system detects motion, it sends you an alert on your phone. You can log in and watch a live feed to see if the mail has been delivered or if a stranger is lingering. A few weeks later, a package goes missing. You rewind the footage, zoom in on the time stamp, and see exactly who took it. You now have evidence to give to the police.

In IT, the cameras are monitoring tools like network monitors and intrusion detection systems. The central recorder is a security information and event management (SIEM) system. The motion alerts are the system's automatic notifications. Reviewing old footage to solve a crime is forensic analysis of logs. You are not just watching for threats in real time—you are also keeping a permanent record so you can investigate incidents after they happen. This is called maintaining situational awareness: understanding what is normal, spotting deviations, and being able to reconstruct events when something goes wrong.

## Core explanation

Monitoring and security controls are the tools and processes that give you an eagle-eye view of everything happening in an IT environment. Think of them as the dashboard, gauges, and alarms for your digital estate.

At its simplest, monitoring means collecting data from all the different components of a system—servers, routers, firewalls, applications, databases—and centralising that data so you can look for patterns, anomalies, and signs of trouble. The most common way to do this is with logs. A log is a time-stamped record of an event. For example, every time a user logs into a system, the system writes a log entry: 'User jsmith logged in from IP address 192.168.1.10 at 14:32:05.' Every time a firewall blocks a connection, it writes a log: 'Blocked incoming TCP connection from 203.0.113.5 on port 22.' There are millions of these entries every day in a medium-sized company.

To make sense of the noise, organisations use a Security Information and Event Management (SIEM) system. A SIEM collects logs from hundreds of sources, normalises them into a standard format, and uses rules to identify suspicious activity. For instance, if the same user account logs in from two different continents within five minutes, the SIEM can flag that as a possible account compromise. The SIEM also gives you a dashboard—a visual display showing key metrics like number of failed login attempts, unusual network traffic spikes, or malware detections.

Security controls are the actions you take to protect your systems. There are three broad categories:

- Preventive controls stop attacks before they happen. Examples: firewalls that block certain types of traffic, antivirus software that quarantines malicious files, and strong password policies that require complex passwords.
- Detective controls discover attacks that are already happening. Examples: intrusion detection systems (IDS) that scan for known attack patterns, and the monitoring tools we just described.
- Responsive controls kick in after an attack is detected. Examples: incident response plans, automated scripts that isolate a compromised machine, and backup restoration procedures.

All three work together. Monitoring (a detective control) might find a brute-force attack—someone trying thousands of passwords to get into a system. The SIEM alerts the security team, who then use responsive controls to block the attacker's IP address and force password resets. Meanwhile, preventive controls like account lockout policies (which temporarily disable an account after too many bad passwords) reduce the chance that the attack ever succeeds.

Another key concept is 'something like a baseline'. A baseline is a recorded snapshot of normal behaviour. You establish a baseline by monitoring a system when it is known to be healthy—say, for a week—and then you configure alerts for any significant deviation from that baseline. For example, if a web server normally handles 100 requests per second, and suddenly it handles 10,000 per second, that might indicate a distributed denial-of-service (DDoS) attack. Without a baseline, you would not know that 10,000 requests is unusual.

Finally, monitoring is not a one-time setup. It requires constant tuning. You will need to adjust alert thresholds to reduce false positives (alerts that are not actually dangerous) and add new log sources as you bring new systems online. The goal is to achieve a state known as situational awareness—knowing the current state of your security, understanding what threats are present, and being able to make informed decisions quickly.

## Real-world context

Imagine you are a security analyst at a mid-sized e-commerce company called ShopEasy. Your job is to monitor the network and systems for signs of attack.

Your day starts by opening the SIEM dashboard. You see a spike in failed login attempts on the customer database server—normally about 50 per hour, now 1,200 in the last 10 minutes. The SIEM has automatically escalated this as a medium-priority incident.

You drill down into the logs. You see the failed attempts are all using the same username, 'admin', and are coming from a single IP address in a country where ShopEasy does not do business. You note the source IP and the timestamp.

Next, you check the firewall logs. The firewall shows that the IP address has been making repeated connection attempts on port 3306, which is the default port for MySQL databases. You confirm this is a targeted brute-force attack against the database.

You then check the intrusion detection system (IDS) logs. The IDS has not flagged any known malware signatures, so it is likely a manual attack using a script. You perform a quick analysis of the attack pattern: the login attempts are coming at a rate of 2 per second, which suggests an automated tool like Hydra or Medusa.

With this information, you follow your incident response plan:
- You add the attacker's IP address to the firewall block list.
- You enable a temporary account lockout policy that locks the 'admin' account after three failed attempts.
- You notify the database administrator to check for unauthorised changes and to rotate the 'admin' password.
- You create a new SIEM rule to alert on any future login attempts from that IP range.

After the incident is handled, you generate a report summarising what happened, what actions were taken, and what improvements to recommend—such as implementing multi-factor authentication (MFA) for the database admin account.

Later that week, you examine the logs from a different server and discover that a user logged in at 3 a.m. on a Saturday, which is unusual because that user does not work weekends. You open an investigation, find that the user's password was leaked in a phishing email, and you reset their credentials. This is proactive monitoring: catching a small anomaly before it turns into a data breach.

Tools you would use in this scenario include:
- SIEM (e.g., Splunk, Microsoft Sentinel, or Elastic Stack) for log aggregation and alerting
- IDS (e.g., Snort, Suricata) for network traffic analysis
- Firewall logs from devices like Cisco ASA or Palo Alto
- Endpoint detection and response (EDR) tools like CrowdStrike or Microsoft Defender for Endpoint to monitor individual computers and servers
- Vulnerability scanners like Nessus or Qualys to find weak points before attackers do

The entire process—from detecting the alert to investigating, containing, and reporting—takes about 45 minutes for a straightforward attack. The key is that you had the monitoring infrastructure in place to see the attack in real time, rather than discovering it months later during a data breach notification.

## Exam focus

The SSCP exam tests you on the concepts behind monitoring and security controls, not on the specifics of any one vendor's product. You need to know what each tool does, how they fit together, and why they are important.

Here are the exact types of questions you will face:
- 'Which of the following is a detective control?' Answer: an intrusion detection system.
- 'What is the primary purpose of a SIEM?' Answer: to collect, normalise, and analyse logs from multiple sources for security events.
- 'What should you establish before you can detect anomalies?' Answer: a baseline of normal behaviour.

Common traps the exam writers set:
- They will present a scenario and ask you to choose between a 'preventive' and 'detective' control. Remember: a firewall is preventive, a log review is detective.
- They will try to confuse 'monitoring' with 'auditing'. Monitoring is continuous, while auditing is a periodic review of logs and configurations.
- They will ask about 'false positives' vs. 'false negatives'. A false positive is an alert for something that is not really an attack; a false negative is a real attack that does not trigger an alert. You want to minimise both, but false negatives are more dangerous.
- They will test whether you understand that logging alone is not enough—you must also have a process to review logs. A common question: 'Your company collects logs but never looks at them. What control is missing?' Answer: the review process (a detective control).

Key concepts to memorise:
- Definition of 'situational awareness': the ability to know what is happening in your environment to make timely security decisions.
- The three categories of controls: preventive, detective, responsive.
- The difference between an IDS (intrusion detection system) and an IPS (intrusion prevention system). The IDS only alerts; the IPS actively blocks traffic.
- The importance of baselines: you cannot detect abnormal without knowing what normal looks like.
- The four steps of the monitoring cycle: collect, analyse, alert, respond.

Exam questions often present a small business scenario and ask you to recommend the most appropriate control. For instance: 'A small retail company wants to monitor its network for attacks but has a limited budget. Which tool is most cost-effective?' Answer: a host-based intrusion detection system (HIDS) on critical servers, combined with centralised log collection using free tools like the Elastic Stack.

Finally, look out for questions that mix up logging and monitoring. Logging is the act of recording events. Monitoring is the act of reviewing those events for issues. You cannot monitor without logging, but logging alone is not monitoring.

The exam expects you to understand that monitoring is a continuous process, not a one-time project. You will need to know that tuning is required to reduce noise: if your SIEM generates 500 alerts per day and 490 are false positives, you need to adjust the rules to reduce the noise so the security team does not become desensitised (a concept called 'alert fatigue').

## Step by step

1. **Collect Data** — All devices and applications generate logs. The first step is to configure them to send their logs to a central location. This includes servers, firewalls, routers, switches, databases, and applications. Without collection, there is nothing to monitor.
2. **Normalise and Store Logs** — Different systems produce logs in different formats. A SIEM normalises these logs into a standard schema (mapping fields like 'source IP', 'timestamp', 'event type') so that they can be searched and compared. The normalised data is then stored in a database for real-time and historical analysis.
3. **Establish a Baseline** — Before you can detect anomalies, you need to understand what normal looks like. This step involves observing the system for a period (e.g., one week) to record typical patterns: average number of login attempts per hour, typical network traffic volume, normal system resource usage. This baseline becomes your reference point.
4. **Define Alert Rules and Thresholds** — Based on the baseline and known attack patterns, you create rules that trigger alerts when certain conditions are met. For example: 'If more than 50 failed logins per minute from a single IP, generate a medium-priority alert.' Thresholds are set carefully to avoid too many false positives or missed detections.
5. **Analyse and Respond to Alerts** — When an alert fires, a security analyst investigates. They check the raw logs, correlate with other alerts, and determine whether the alert is a true positive (real attack) or a false positive. For true positives, they follow incident response procedures: contain the threat, eradicate the cause, and recover systems. This step closes the loop and ensures monitoring leads to action.

## Comparisons

### Preventive Control vs Detective Control

**Preventive Control:**
- Stops attacks before they happen
- Examples include firewalls, antivirus, and account lockout policies
- Focuses on blocking threats

**Detective Control:**
- Identifies attacks that are in progress or have occurred
- Examples include intrusion detection systems (IDS) and log monitoring
- Focuses on finding threats

### SIEM vs Log Management System

**SIEM:**
- Collects and normalises logs from multiple sources
- Provides real-time correlation and alerting based on rules
- Includes a dashboard for visual analysis

**Log Management System:**
- Collects and stores logs in their original format
- Primarily for archival and manual search; minimal analysis
- May not have built-in alerting or correlation capabilities

### False Positive vs False Negative

**False Positive:**
- Alert fires when no actual threat exists
- Wastes analyst time and can cause alert fatigue
- Example: legitimate user mistyping password triggers brute-force alert

**False Negative:**
- No alert fires when a real threat exists
- Allows attacks to go undetected
- Example: a newly crafted malware that does not match any known signature

### Baseline vs Threshold

**Baseline:**
- A recorded snapshot of normal behaviour over time
- Used as a reference point to compare current behaviour
- Established by observing a healthy system for a period

**Threshold:**
- A specific numerical value that triggers an alert when exceeded
- Derived from the baseline (e.g., 2x normal traffic)
- Example: alert if login attempts exceed 100 per hour

## Diagram

_This flowchart shows the continuous cycle of monitoring: data collection, centralisation in a SIEM, analysis, alerting, investigation, and response._

```mermaid
flowchart TD
    A[Data Sources] --> B[Logs from Servers, Firewalls, Apps]
    B --> C[SIEM collects and normalises logs]
    C --> D[SIEM analyses using rules and baseline]
    D --> E{Anomaly detected?}
    E -->|Yes| F[Alert generated]
    E -->|No| G[Continue monitoring]
    F --> H[Analyst investigates alert]
    H --> I{True positive?}
    I -->|Yes| J[Incident response: contain, eradicate, recover]
    I -->|No| K[Mark as false positive and tune rules]
    J --> L[Update baseline and rules]
    K --> G
```

## Common misconceptions

- **Misconception:** If you have antivirus software installed, you do not need to monitor anything else. **Reality:** Antivirus is only one preventive control. It cannot detect zero-day exploits, insider threats, or attacks on misconfigured systems. Monitoring provides a safety net for everything antivirus misses. (People assume antivirus is a silver bullet because it is the most visible and familiar security tool. They underestimate how many different ways a system can be attacked.)
- **Misconception:** Monitoring and auditing are the same thing. **Reality:** Monitoring is continuous and automated. Auditing is a periodic, manual or semi-automated review of logs, configurations, and controls. They serve different purposes: monitoring detects issues in real time; auditing checks for compliance and process effectiveness after the fact. (The words are often used interchangeably in casual conversation, so beginners think they are synonyms. The exam distinguishes them clearly.)
- **Misconception:** Centralising logs is optional; you can just check each server individually. **Reality:** Centralising logs is essential for correlating events across different systems. An attack on one server might leave clues in logs on another server, and you cannot spot the pattern without bringing all the logs together. (Beginners imagine they can log into each machine manually. They do not appreciate the volume of data (thousands of log entries per second) or the need for correlation across systems.)
- **Misconception:** A SIEM automatically stops attacks. **Reality:** A SIEM is a detective control, not a preventive or responsive one. It alerts you to suspicious activity, but a human or another automated system must take action to stop the attack. Some SIEMs can trigger automated responses (e.g., block an IP), but that is a separate capability called security orchestration, automation, and response (SOAR), not the SIEM itself. (The word 'security' in SIEM makes beginners think it actively prevents breaches, like a firewall does. They miss the distinction between detection and prevention.)
- **Misconception:** More logs always means better security. **Reality:** More logs are useless without a plan to review them, storage capacity to keep them, and tools to search them. Excessive logging can actually harm security by drowning analysts in noise, causing them to miss real alerts. (Beginners think 'more data = more visibility'. They do not understand the operational cost of storing, processing, and analysing logs. Quality and relevance matter more than quantity.)

## Key takeaways

- Monitoring is a continuous detective control that provides situational awareness by collecting and analysing logs, network traffic, and system events.
- Security controls fall into three categories: preventive (stop attacks), detective (find attacks), and responsive (react to attacks)—all three are needed for a complete security posture.
- A baseline of normal behaviour is required to detect anomalies; without a baseline, you cannot distinguish an attack from routine activity.
- A SIEM centralises logs from multiple sources and uses rules to identify and alert on suspicious patterns, but it requires ongoing tuning to reduce false positives.
- Logging alone is not monitoring; you must have a process to review, analyse, and act on log data for it to be effective.
- The monitoring cycle consists of four steps: collect data, analyse it for signs of issues, generate alerts when suspicious activity is found, and respond to those alerts in a timely manner.

## FAQ

**What is the difference between a SIEM and a log management system?**

A log management system simply collects and stores logs. A SIEM adds analysis, correlation, and alerting on top of log storage. Think of it as a log management system with built-in intelligence.

**Do I need a SIEM if I am a small business?**

Not necessarily. Small businesses can start with centralised log collection using free tools like the Elastic Stack (Elasticsearch, Logstash, Kibana) and add manual or simple automated alerts. The key is to have a process to review logs, not necessarily an expensive SIEM.

**How often should I review logs?**

Ideally, you review logs continuously through automated alerting and a real-time dashboard. Manual review should happen daily for critical systems and weekly for less important ones. The SSCP expects you to know that periodic review is part of the monitoring process.

**What is a false positive in monitoring?**

A false positive is an alert that indicates a security issue when there is none. Example: an alert for a brute-force attack that was actually a legitimate user mistyping their password many times. Too many false positives lead to alert fatigue, where analysts start ignoring alerts.

**Can monitoring help after a breach has already happened?**

Yes. Monitoring is not just about preventing breaches; it is also about detecting them quickly and providing forensic evidence. Logs show exactly what the attacker did, what data was accessed, and when. This helps you contain the damage and learn how to prevent future attacks.

**What is the role of a firewall in monitoring?**

A firewall is primarily a preventive control, but it also generates logs about blocked and allowed connections. Those logs are fed into the SIEM or monitoring system to help detect attacks. So a firewall contributes to both prevention and detection.

## Check your understanding

1. **Which category of control does an intrusion detection system (IDS) belong to?**

   Answer: Detective control, because it identifies attacks that may be occurring but does not stop them.

2. **What is the primary purpose of a Security Information and Event Management (SIEM) system?**

   Answer: To centralise, normalise, and analyse log data from multiple sources to identify and alert on security events.

3. **What must be established before you can effectively detect anomalies in system behaviour?**

   Answer: A baseline of normal behaviour, so that deviations from the norm can be recognised as potential issues.

4. **What is the name of the phenomenon where analysts become desensitised to alerts because there are too many low-quality ones?**

   Answer: Alert fatigue.

5. **What is the key difference between logging and monitoring?**

   Answer: Logging is the act of recording events; monitoring is the process of reviewing and analysing those events for signs of trouble.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/isc2-sscp/monitoring-and-security-controls