Your 200-201 exam domain on Security Monitoring directly relies on your ability to understand how logs are handled. Without a system to collect and connect logs, you are trying to solve a jigsaw puzzle with pieces from a thousand different boxes. This chapter explains the entire pipeline — how logs are generated, stored, and, most crucially, linked together to reveal hidden attacks that no single log would show.
Jump to a section
A simple way to picture Log Management and Correlation
A detective's whiteboard is the central tool for solving a complex crime. It starts as a blank canvas, but as evidence arrives, the detective pins up every piece: a witness statement, a torn receipt, a phone record, a text message timestamp. Each piece of evidence is a single log entry. At first, the whiteboard is chaotic, full of unrelated facts. The detective then starts linking things: the receipt's time matches a phone call's duration, the witness saw someone wearing a blue jacket matching the suspect's description. This linking is correlation. The detective doesn't just collect evidence; they connect it to tell a single coherent story of what happened. They might use different coloured string to show different types of connections: financial, temporal, or geographical. Similarly, a security team uses a Security Information and Event Management (SIEM) system as their digital whiteboard. A single firewall log saying "blocked connection from IP 5.5.5.5" is useless. But when correlated with a server log saying "failed login attempt from IP 5.5.5.5 at the same time" and an authentication log showing "new admin account created 5 minutes later", the string is pulled. The detective then writes a summary report of the attack timeline. The log management system does the same: it archives the raw evidence, but the correlation is what actually solves the case.
The whiteboard itself, with its organisation, timestamped notes, and interconnected strings, directly maps to a modern log management platform. Without the whiteboard, the detective has a pile of paper. Without log management and correlation, an IT team has a pile of isolated, meaningless events.
Log management and correlation is the process of collecting, storing, analysing, and connecting log data from many different sources to detect security incidents that would otherwise remain invisible. Think of a single log entry as a single security camera frame. Alone, it shows a person walking past a door. A thousand frames from a thousand cameras, however, can show that same person walking through every door they should not have entered, at a time they should not have been there, and then plugging a USB drive into a server. Correlation is the technique of stitching those frames together into a coherent video of an attack.
First, you need to understand what a log actually is. A log is a record of an event. Every device on a network — a firewall, a server, a router, a printer, a laptop — generates logs. Each log contains: a timestamp (the exact time the event happened), a source (what device or software created it), an action (what happened, like "login failed" or "file deleted"), and often a result (did it succeed or fail?). Common log types you will see in 200-201 include:
Syslog: A standard protocol for sending log messages over a network. Most network devices use it. A syslog message has a severity level (0 for emergency to 7 for debug) and a facility code (what type of process generated it).
Authentication logs: Records of login attempts, both successful and failed, from systems like Microsoft Entra ID or a Linux server's /var/log/auth.log.
Security logs: Generated by firewalls, intrusion detection systems (IDS), and antivirus software, showing blocked connections, detected malware, or policy violations.
Application logs: Generated by specific software, like a web server showing every HTTP request it received.
The collection phase is where all these logs are sent to a central location. Most organisations use a SIEM (Security Information and Event Management) system. The SIEM acts like a giant funnel. Devices are configured to forward their logs to the SIEM over the network. This is critical because if logs stay on individual devices, an attacker who compromises a device can simply delete its logs to hide their tracks. Centralisation also means you can search across millions of events from one interface.
The management phase involves storage, retention, and indexing. Logs take up enormous amounts of space. A busy organisation might generate terabytes of logs every day. Management means deciding:
How long to keep logs (retention): Compliance regulations often require keeping authentication logs for 90 days, 1 year, or longer.
How to store them efficiently: Compressing old logs and moving them to cheaper storage like Amazon S3 or Azure Blob Storage while keeping recent logs on fast storage for searching.
How to index them: Creating a searchable catalogue so you can find "all failed logins from IP 10.0.0.5 between 2 PM and 3 PM" in seconds rather than hours.
The correlation phase is where the real detective work happens. Correlation is the process of examining multiple logs from different sources and finding relationships between them. A SIEM uses rules or algorithms to do this automatically. A simple rule might be: "If there are more than 10 failed login attempts from the same IP address within 5 minutes, and then a successful login from that same IP, generate an alert for a brute-force attack." This uses logs from the authentication system (failed attempts) and the firewall (allowing the connection).
Why is correlation so important? Because a single log is almost never evidence of an attack by itself. A failed login is normal. A single port scan from an external IP is common. But when you see a failed login, followed by a successful login from a country you do not do business with, followed by the creation of a new admin account, followed by a data export to an external server — that sequence of correlated logs tells a story of a breach. Without the correlation, each event individually would have been ignored as noise.
Correlation techniques include:
Rule-based correlation: Defining explicit conditions like "Event A happens, then Event B within X seconds". This is the most common method and very reliable for known attack patterns.
Statistical correlation: Looking for anomalies based on historical baselines. For example, if a server usually sends 50 logs per hour and suddenly sends 5000, something is wrong.
Behavioural correlation: Building profiles of normal user behaviour and flagging deviations. If an employee who never logs in at night suddenly authenticates at 3 AM, that is suspicious.
Threat intelligence feed correlation: Matching IP addresses and domain names in logs against known malicious lists provided by external threat intelligence services.
The entire process replaces the old method where an administrator would manually log into each device and check its logs individually — a process that would take days and would miss almost everything. Modern log management and correlation turns a flood of noise into a small set of actionable alerts, allowing a single security analyst to monitor thousands of devices effectively.
Log Generation
Every device and application on the network generates log entries when events occur. For example, a firewall logs each allowed or blocked connection, a web server logs each HTTP request, and an authentication server logs every login attempt. These logs are generated in real time as events happen.
Log Forwarding
Logs are sent from the generating device to a central collection point, typically a SIEM. This is done using protocols like syslog for network devices, or direct API integrations for cloud services. Forwarding is configured on each device by specifying the SIEM's IP address and port. This step ensures logs survive even if the originating device is compromised.
Log Normalisation and Indexing
The SIEM receives logs in diverse formats. Normalisation translates each log into a standardised schema with consistent field names like 'timestamp', 'source_ip', 'action', and 'user_name'. Indexing then creates a searchable database so analysts can quickly find logs based on any field. Without normalisation, correlation rules cannot compare a firewall log to an application log because the fields would not match.
Correlation Rule Execution
The SIEM continuously evaluates incoming normalised logs against a set of predefined correlation rules. Each rule specifies a pattern of events to look for. For instance, a rule might say: 'If three or more failed logins from one IP within 60 seconds AND then a successful login from that IP, generate a brute-force alert.' The SIEM tracks the state of events over time to detect these patterns.
Alert Generation and Escalation
When a correlation rule is triggered, the SIEM creates an alert with a severity level (low, medium, high, or critical). This alert includes the correlated log entries and a summary of the finding. The alert is then presented to a security analyst in a dashboard or sent via email, SMS, or ticketing system. High-severity alerts may automatically trigger faster response actions, like isolating a device from the network.
Incident Response and Tuning
The analyst investigates the alert, determines if it is a true positive (actual attack) or false positive (benign behaviour that triggered the rule), and takes appropriate action. If it is a false positive, the analyst may modify the correlation rule to exclude that scenario in the future. This tuning step is continuous: rules must be refined as network behaviour changes to maintain a low false-positive rate.
An IT security analyst at a mid-sized e-commerce company, "CyberShop Ltd", starts her shift by opening her SIEM dashboard. The company has 500 servers, 20 firewalls, 5 intrusion detection sensors, and 2000 employee laptops. Every single device sends logs to a central SIEM platform that stores them for 90 days. Her job is not to read every log; that is impossible. Her job is to prioritise the alerts generated by the correlation rules.
At 10:00 AM, she sees an alert titled "Possible Data Exfiltration — High Severity". She clicks on it. The SIEM shows her the correlated timeline:
09:45: Authentication log shows user "jsmith" (a database administrator) logged into the main database server from his usual workstation IP.
09:47: Database audit log shows a query: SELECT * FROM customers WHERE card_number IS NOT NULL. This is unusual because jsmith does not normally query customer credit card data.
09:49: Firewall log shows an outbound connection from the database server to an external IP address 203.0.113.55 on port 22 (SSH). This IP is not in the company's approved vendor list.
09:51: Application log on the database server shows a new file "export.csv" was created.
The SIEM correlated these four events across four different log sources. It compared the external IP against a threat intelligence feed and found it was flagged as a known command-and-control server used by a ransomware group. The analyst now has a clear picture: an insider threat or a compromised account is stealing customer data. She immediately follows the incident response plan: she disables user jsmith's account, blocks the external IP at the firewall, and isolates the database server from the network. She then creates a ticket to investigate how jsmith's credentials were compromised.
In another scenario, the SIEM might have missed this if logs were not collected at all. A typical mistake new companies make is only collecting firewall logs and ignoring application or database audit logs. The attacker's query would never have been seen. The analyst also understands that correlation is only as good as the logs fed into it. If the database server's clock was 5 minutes slow, the timestamps would not align correctly, and the correlation rule might fail. That is why many SIEMs automatically synchronise time across all devices using Network Time Protocol (NTP).
The analyst also uses correlation for more mundane tasks:
Compliance reporting: The SIEM automatically generates a weekly report showing all failed login attempts to the finance server, which is required by auditors.
Threat hunting: She runs a custom search correlating VPN login logs with antivirus alert logs to see if any remote user who logged in from a hotel Wi-Fi later had malware detected on their laptop.
Tuning: She notices that the SIEM is generating too many false positives for a rule that alerts on "multiple failed logins from the same IP". The marketing department's IP address is triggering it because they use a shared tool that constantly tries different accounts. She adds an exclusion for that specific IP to reduce noise.
The final step in her workflow is reviewing the daily summary report. It lists all correlated alerts from the last 24 hours, their severity, and whether they were investigated. This report goes to the IT manager. Without correlation, this report would be a meaningless list of thousands of individual log entries. With correlation, it tells a story of what actually needs attention.
The 200-201 exam focuses on your conceptual understanding of log management and correlation rather than vendor-specific SIEM product knowledge like Splunk or ArcSight. Cisco wants you to know the principles. You will see questions that test your ability to identify what correlation is, why it is necessary, and how logs are structured.
Key exam topics to memorise:
Definition of a SIEM: Know that a Security Information and Event Management system collects, aggregates, and correlates logs. It is both a log management and a correlation tool. Do not confuse it with a simple log aggregator — the correlation function is the key differentiator.
Syslog severity levels: Level 0 (Emergency) through Level 7 (Debug). You may be asked which level indicates a system is unusable (Level 0). Or which level an informational message uses (Level 6). These are direct recall questions.
Log types: syslog, authentication logs, security logs, application logs. Be able to identify which type of log would contain a specific event. For example, a firewall dropping a packet would be in the security log.
Correlation vs collection: Collection is just gathering logs; correlation is analysing them for relationships. A common exam trap question asks: "Which of the following is a benefit of log correlation?" and lists advantages of log collection as distractors. Learn the difference.
Log retention and compliance: You need to know that organisations keep logs for a set period to meet legal or regulatory requirements (like GDPR, HIPAA, PCI DSS). A question might ask: "Why do organisations implement log retention policies?" Answer: To ensure compliance and support forensic investigations.
Normalisation: This is the process of converting logs from different formats (JSON, syslog, Windows Event Log) into a common, standardised format so the SIEM can compare them. This is a concept Cisco loves to test. Expect a question like: "What is the purpose of log normalisation?"
Time synchronisation: Logs must have consistent timestamps. If a firewall and a server have different times, correlation fails. NTP is the standard protocol used. You may be asked what protocol ensures logs are timestamped correctly.
Common traps Cisco sets in the exam:
Trap: They ask "What is the primary purpose of a SIEM?" and offer answers like "To block malicious traffic" (that is a firewall) or "To encrypt log data" (that is encryption). The correct answer is always "To collect and correlate events from multiple sources".
Trap: They ask "Which log type would record a failed user authentication?" and some options are "syslog" and "security log". The correct answer is authentication log (often stored in /var/log/secure or /var/log/auth.log on Linux). Syslog is the transport protocol, not the specific type.
Trap: They list several events and ask which sequence would indicate a successful brute-force attack. You must select the order: many failed logins followed by one successful login from the same source. The trap is including an extra event like "firewall rule change" that is unrelated.
Trap: They say "A security analyst sees a single log showing a port scan from an external IP. Why is this not a concern?" Answer: Because a single port scan is normal internet noise. It only becomes a concern when correlated with other logs, like a successful scan followed by exploitation.
Specific concepts to memorise for the exam:
The difference between centralised logging (all logs in one place) vs decentralised (logs stay on devices).
The concept of a "correlation rule" — a predefined condition that, when matched, triggers an alert. Example: "If Event A and Event B occur within 60 seconds".
The role of threat intelligence feeds in correlation: they add context (e.g., "this IP is known malicious") to log data.
The importance of log integrity: logs must not be altered after creation (write-once, read-many storage). This is often tested in the context of legal admissibility.
Finally, expect at least 2-3 questions that present a scenario with multiple logs and ask you to identify the correct sequence of events or what type of attack is being described. Practise reading log snippets and extracting the key data: timestamp, source IP, action, and result.
Log management is the process of collecting, storing, and protecting logs from all devices; correlation is the separate process of analysing those logs for relationships that reveal attacks.
A SIEM (Security Information and Event Management) system combines both log management and correlation into a single platform, but the two functions are distinct and require separate configuration.
Log normalisation is essential because logs from different vendors use different formats; a SIEM must convert them to a common schema before correlation rules can compare them.
Correlation rules define specific conditions (like Event A then Event B within a time window) that, when matched across multiple log sources, trigger an alert for further investigation.
Time synchronisation using NTP (Network Time Protocol) is critical because correlated events must have accurate timestamps; a 5-minute clock skew can break correlation rules.
A single log entry rarely indicates an attack; correlation connects seemingly innocent events from different sources to reveal the full story of a security incident.
Log retention policies are driven by compliance regulations and forensic needs; organisations must decide how long to keep logs and where to store them cost-effectively.
Threat intelligence feeds enrich correlation by adding external context, such as marking an IP address as a known command-and-control server, turning a simple connection log into an actionable alert.
These come up on the exam all the time. Here's how to tell them apart.
Log Management
Focuses on collection, storage, and retention of logs
Does not analyse relationships between events
Answers 'what logs do we have and where are they?'
Requires normalisation and indexing
Log Correlation
Focuses on finding patterns across multiple logs
Uses rules to connect events from different sources
Answers 'what is the story these logs tell?'
Requires a time window and defined criteria
Syslog
A protocol for transporting log messages over UDP or TCP
Does not store or analyse logs on its own
Uses facility and severity codes (0-7)
Requires a separate log server to receive messages
SIEM
A platform that receives, stores, and correlates logs
Includes analysis engine, dashboard, and alerting
Supports many input protocols beyond syslog
Provides a single interface for security monitoring
Centralised Logging
All logs sent to one central server or SIEM
Easier to search and correlate across devices
Single point of failure if central server goes down
Requires network bandwidth for log transport
Decentralised Logging
Logs stored on each device individually
Harder to search and almost impossible to correlate manually
No single point of failure for log storage
Logs may be lost if device is compromised
Mistake
All logs are the same and one tool can parse them all without any configuration.
Correct
Logs come in hundreds of different formats (JSON, XML, key-value pairs, plain text). SIEMs require normalisation rules to translate each format into a common schema before correlation can work.
New learners assume logs are universal because they have only seen simplified examples. In reality, a Cisco ASA firewall log looks completely different from a Windows Event Log, and both need custom parsing.
Mistake
If I collect all logs in one place, I automatically get correlation for free.
Correct
Collection is just the first step. Correlation requires active rules or algorithms to find relationships between logs. A centralised log repository without correlation rules is just a pile of unsorted data.
The terms 'log management' and 'correlation' are often used together, leading people to believe they are the same thing. They are separate functions that must both be configured.
Mistake
A SIEM can replace all other security tools like firewalls and antivirus.
Correct
A SIEM is a monitoring and analysis tool, not a prevention tool. It cannot block traffic or remove malware. It only alerts on suspicious patterns that other tools create logs about.
Marketing materials sometimes overstate SIEM capabilities. Beginners see the central dashboard and think it does everything, when it is actually passive — it reads logs, it does not stop attacks.
Mistake
Logs are always accurate and can be fully trusted as evidence.
Correct
Logs can be spoofed, deleted, or altered by attackers. Some devices have buggy log generation. Logs must be protected with integrity controls (like hashing or write-once storage) and should be corroborated with other data sources.
People trust computers to be precise. They do not realise that an attacker who gains admin access can modify log files just like any other file. This is why log centralisation and integrity are emphasised in security.
Mistake
Correlation only works for known attack patterns (signature-based).
Correct
Correlation can also use behavioural analysis and statistical baselines to detect unknown threats (anomaly-based). For example, a user suddenly logging in from a new country is a behavioural anomaly even if no signature matches.
Many introductory materials only teach rule-based correlation because it is simpler to explain. Learners then assume that is the only method, missing the broader world of anomaly detection.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Syslog is a protocol used to send log messages from a device to a log server. A SIEM is a full platform that receives syslog messages (and other logs), stores them, and runs correlation rules on them. Syslog is just the transport; the SIEM does the analysis.
No. The exam tests concepts, not specific products. You need to understand what a SIEM does, how correlation works, and common log types. Many free or open-source tools like Wazuh or ELK stack (Elasticsearch, Logstash, Kibana) can demonstrate the same principles.
It depends on the regulation. Many frameworks like PCI DSS require at least one year of logs with three months readily available. HIPAA often requires six years. Your organisation's legal and compliance team will set the retention period. The exam expects you to know that retention is driven by compliance needs.
Yes, but it is extremely manual. You could export logs to a spreadsheet and look for patterns by hand, but this does not scale to any real-world environment. SIEMs automate correlation at scale. For the exam, the assumption is that correlation is done by a SIEM.
Correlation will fail or produce inaccurate results. For example, if a firewall log shows a blocked connection at 10:00:00 but the server's authentication log for that connection shows 10:05:00, a correlation rule looking for events within 60 seconds will not match. This is why all devices must synchronise their clocks using NTP.
Because many attacks avoid the firewall entirely. An attacker who uses a legitimate credential to log in never triggers a firewall rule. Only the authentication log will show that login. If you ignore those logs, you miss the breach entirely. Comprehensive log collection from all sources is necessary.
You've finished Log Management and Correlation. Continue through the 200-201 study guide to build a complete picture of the exam.
Done with this chapter?