Lesson 2: Logging Foundations: Ingestion, Time Sync, Retention

Why logging foundations matter

Every alert, hunt and incident timeline in this course depends on logs. If events never reach the Security Information and Event Management (SIEM) system, if someone changes them, or if their timestamps are wrong, you will reach the wrong conclusion and feel sure of it. CompTIA covers logging under Domain 1 (Security Operations), objective 1.1, system and network architecture concepts. The topics are log ingestion, logging levels, time synchronisation, log integrity and retention. The official objectives belong to CompTIA. They are not reproduced here, and you can download them free from CompTIA's website.

Before you trust any log, check that it passes three tests:

• Complete: every expected source is sending, and nothing is being dropped.
• Unaltered: nobody has edited or deleted entries.
• Correctly timed: timestamps from different hosts can be lined up against each other.

Task 1: Trace the log pipeline and find gaps

Log ingestion means collecting events from their sources (servers, firewalls, endpoints, cloud services), parsing them into fields and storing them where they can be searched. A gap can appear at any stage.

To trace the pipeline:

1. Inventory the sources. List every asset that should be logging, then compare that list with the sources the SIEM actually reports. Any asset missing from the SIEM is a blind spot.
2. Check volume baselines. A firewall that normally sends 40,000 events an hour and now sends zero has a broken agent, a full disk or a network problem, or an attacker has stopped its logging.
3. Check transport. Classic syslog over User Datagram Protocol (UDP) port 514 has no delivery guarantee, so messages can be lost without anyone noticing. Prefer syslog over TCP with Transport Layer Security (TLS) for important sources.
4. Check parsing. If a vendor update changes the log format, events still arrive but land in the wrong fields or none at all. Searches for src_ip then return nothing, even though the raw data is there.
5. Watch for tampering signals. On Windows, Event ID 1102 ("The audit log was cleared") records that the Security log was wiped. Clearing the log is rarely a legitimate admin task, so treat the event as suspicious until you have an explanation.

What to DO: for any question about a gap, ask where the event stopped: at the source, in transit, at parsing or in storage.

Task 2: Choose logging levels

Logging levels control how much detail a source records. The syslog standard (RFC 5424) defines eight severities, and a lower number means more urgent:

Setting a device to a level records that severity and everything more urgent. For example, level 4 records codes 0 to 4.

How to choose:

• Too low a level (for example, Error only): you miss successful logins, configuration changes and denied connections. These are the routine events an investigation needs.
• Too high a level (Debug in production): you flood storage and SIEM licensing, slow searches and may write sensitive data such as session tokens into the logs.
• Usual choice: Informational or Notice for security-relevant devices. Use Debug only for a short troubleshooting window, then turn it off.

What to DO: match the level to the question you need answered. If the requirement is "prove who logged in and when", you need Informational-level authentication events.

Task 3: Protect log integrity and security

An attacker who gets in will try to remove the evidence. Protect your logs like this:

1. Forward events off the host quickly to a central collector, so deleting the local log does not destroy the only copy.
2. Restrict access. Administrators of a server should not also be able to delete that server's records in the SIEM. Keeping those roles separate is called separation of duties.
3. Use immutable storage, such as write once, read many (WORM) storage, for archives.
4. Hash log files (for example with SHA-256) when you archive them. If the hash no longer matches later, the file has changed.
5. Encrypt logs in transit with TLS so they cannot be read or altered on the network.

Task 4: Synchronise time with NTP

Network Time Protocol (NTP) keeps clocks in step over UDP port 123. It uses a hierarchy of levels called strata. Stratum 0 is the reference clock, such as an atomic or GPS clock. A stratum 1 server is attached directly to that clock, and each server further down adds one to the stratum number.

Correlation means joining events from different hosts in time order. If one host's clock is wrong, the SIEM puts its events in the wrong place. Example:

fw01   2026-10-18T09:14:02Z  ALLOW 203.0.113.7 -> 10.0.5.20:443
web01  2026-10-18T09:11:47Z  POST /upload.php from 203.0.113.7  (200)
web01  2026-10-18T09:11:49Z  new process: cmd.exe (parent w3wp.exe)

In these logs the web server seems to accept the upload before the firewall let the connection through, which is impossible. web01 is running about 2 minutes 15 seconds slow. A correlation rule that looks for "firewall allow followed by web upload within 60 seconds" will never fire.

How to spot drift:

1. Compare the same connection as recorded on two devices, for example the firewall and the server.
2. Look for effects that appear before their causes, or for a steady offset across many events.
3. Check the host's NTP status, for example w32tm /query /status on Windows or chronyc tracking on Linux.
4. Make sure all hosts use the same internal NTP source and log in Coordinated Universal Time (UTC), so that time zones and daylight saving do not add further confusion.

Task 5: Set retention

Retention is how long you keep logs, and where. Base it on three things:

• Compliance: the Payment Card Industry Data Security Standard (PCI DSS) v4.0, requirement 10.5.1, requires at least 12 months of audit log history, with at least the most recent three months immediately available for analysis.
• Investigation needs: attackers can sit in a network unnoticed for months, so 30 days of logs often ends before you reach the first intrusion.
• Cost: keep recent data in fast, searchable ("hot") SIEM storage and move older data to cheaper archive ("cold") storage.

What to DO: when a question names a regulation or a contract, its minimum sets the floor. Keeping the logs longer is allowed, but keeping them for less time is a violation.

What the exam asks about this

• Scenarios with mismatched timestamps across hosts. The answer is usually NTP or time synchronisation.
• A source that has "gone quiet", or a Security log that was cleared. Recognise these as an ingestion failure or tampering.
• Choosing a logging level or retention period that meets a stated requirement without excessive volume.
• Performance-based questions where you put log lines from several devices in order. Normalise them to one time base first.

Key takeaways

• Logs are only useful if they are complete, unaltered and correctly timed.
• Find a gap by locating where the event stopped: at the source, in transit, at parsing or in storage.
• Syslog severities run from 0 (Emergency) to 7 (Debug). A setting records its own level and every level more urgent.
• Forward, restrict, hash and use immutable storage to protect log integrity. Event ID 1102 means the Security log was cleared.
• NTP (UDP 123) and UTC timestamps make correlation possible. Effects that appear before their causes point to clock drift.
• PCI DSS 10.5.1: keep at least 12 months of logs, with the most recent 3 months immediately available.