Security+ SY0-801 Security Monitoring and Alerting: SIEM, Logs, NetFlow, SNMP and SCAP

Security monitoring is the continuous collection and review of data from systems, applications and infrastructure so that problems are detected and someone is alerted while there is still time to act. Security+ objective 4.4 names the parts of that pipeline: the resources you watch, the activities you perform on the data, the tools that collect and act on it, the protocols that move it, and the ways results are shown to people (automated alerts, dashboards, network management systems).

It helps to picture one pipeline and place every term on it:

Scope matters. Objective 4.4 is about what each monitoring tool and protocol does. Prioritising and remediating the findings of a vulnerability scan belongs to objective 4.3, designing automation and orchestration use cases belongs to objective 4.6, and using logs and other data sources during an investigation belongs to objective 4.8. When a scenario asks which tool, protocol or activity fits a monitoring need, you are in 4.4.

Systems monitoring watches individual hosts, application monitoring watches the software and the transactions it handles, and infrastructure monitoring watches the network and the shared services everything depends on. Each layer has its own signals:

To locate a problem, ask where the symptom is actually measured. A full disk or a stopped service is a host fact (systems). A login form that returns an error while the host and network are healthy is a software fact (application). Latency, loss or saturation on the links and shared services that connect users to servers is a path fact (infrastructure). Ruling out the layers whose signals are normal leaves the one to examine.

All three layers measure health and performance. Scanning, covered below, answers a different question: whether a system has weaknesses an attacker could use.

Log aggregation is the activity of gathering logs from many sources into one place and making them consistent enough to search and correlate together. Collection alone is not enough; three things make aggregated logs useful.

• Parsing and normalisation. Every vendor writes logs in its own format. A parser maps each source's values into the SIEM's common fields (source address, user, action, outcome). Field-based searches, correlation rules and dashboards all work on those normalised fields, so a source without a matching parser is stored as raw text that those features cannot use, even though the data is there.
• Time synchronisation. Each source stamps its own events. If clocks drift, events from different sources line up in an impossible order, for example an effect logged before its cause, and time-window correlation stops matching. All sources should use a common time source (NTP) and consistent time zones.
• Reliable transport and retention. The logs must actually arrive, intact and on time (see the syslog section), and must be kept long enough to be searched.

When aggregated data looks wrong, classify the symptom before guessing at a cause:

A security information and event management (SIEM) system is the central platform that aggregates logs from firewalls, servers, applications and security tools, normalises them and correlates related events from different sources to raise alerts. Many logs in, correlated alerts out.

A correlation rule joins events from several sources on a shared field (an account, a host, an IP address) inside a time window. For example, a password reset for an administrator account recorded by the help-desk system, followed within an hour by that account logging on to a domain controller from a workstation it has never used, recorded by the directory. Each system sees only its own half of the pattern, and an alert configured on one device can only ever see that device's events. Patterns that span sources need correlation in the SIEM.

Alerting is the activity of notifying responders when a rule matches; automated alerts are those notifications generated by the tool without anyone having to look. An alert is about one event or pattern that needs action now; it is not a summary or a status screen.

A detection only helps if it reaches the people who triage. Security tools such as antivirus, EDR and DLP keep their own consoles, and an event that sits only in a console nobody is watching is effectively invisible. The fix is to integrate the tool's events into the SIEM, the single queue the SOC already works from, where they can raise automated alerts and be correlated with everything else (for example, the same detection on many hosts in a short time). Side channels that bypass that queue add another place to watch and stay outside correlation.

Alert tuning is the activity of adjusting detection rules so they stop firing on known, legitimate activity (false positives) while still catching real attacks (avoiding false negatives). Untuned rules cause alert fatigue: analysts start ignoring a rule that is usually wrong, and then miss the time it is right. That is why tuning a noisy rule comes first: the noise itself is the risk.

The principle is to make the change as narrow as possible: describe the known-good activity precisely (which source, going to which destination, doing what) and exclude exactly that, so the rule keeps checking everything else.

"Whole source" and "exact pattern" can be the same thing. What decides it is whether the source's entire sanctioned behaviour is the activity the rule detects. An authorised vulnerability scanner exists to scan, so excluding that one scanner from the port-scan rule only (ideally only during its scheduled scan window) is the narrow, known-good exception: nothing it is supposed to do is hidden, and every other rule still watches it. A general-purpose server does many jobs, so excluding it as a source from, say, a data-exfiltration rule hides everything else it might do if compromised. Ask: does the exception cover one rule and one purpose, or a host that does many things?

Example: a rule flags administrator logons outside business hours, and nearly every hit is one service account running scheduled maintenance from one job server. A narrow exception covers that account from that server; the account logging on from anywhere else at night, or any other administrator doing so, still alerts.

Archiving moves logs that have left the SIEM's active, searchable window to lower-cost long-term storage, where they are retained for legal, regulatory or investigative needs and can be restored if required. Retention requirements are often measured in years while fast SIEM storage holds weeks or months and is costly to grow, so archiving is how organisations meet long retention cheaply. A requirement to retain logs is met only by keeping the log records themselves; summaries or statistics derived from them do not count.

Archives must also keep their integrity, especially when logs may be used as evidence. Proving integrity needs two things: something that prevents change, and a reference value recorded at the time of archiving that proves nothing changed. Two controls supply them:

• Write-once (WORM) or immutable storage stops anyone, including administrators with write access, from changing or deleting a stored file during the retention period.
• Hashes recorded at archiving time (kept separately) let anyone later recompute and compare, proving that each file is unchanged.

Controls built for other goals do not supply this. Encryption is chiefly a confidentiality control: it does not stop someone with legitimate write access from replacing or deleting files. Copies made for availability reproduce whatever state a file was in when copied, altered or not.

Reporting produces periodic, point-in-time summaries of a defined period, such as a monthly summary of mean time to respond and phishing-simulation click rates for the security steering committee. Reports are for review, trends, accountability and compliance records; dashboards are for watching what is happening now.

Three ways of presenting monitoring data are easy to confuse, so tell them apart by timing and purpose:

The underlying detections and data are the same; what differs is the presentation. A continuously refreshing visual of current state is a dashboard, however its numbers were produced.

A network management system (NMS) is the operations console for the network: it finds the devices on the network, maps how they connect, and tracks their health and load over time, largely through SNMP polling and the traps devices send it. An NMS is the operational counterpart of a SIEM: the SIEM correlates security events, the NMS manages device health and performance. Utilisation graphs in an NMS come from SNMP interface counters, which tell you how much traffic crossed a link, not who sent it.

Benchmarks are published, consensus-developed secure-configuration recommendations for a specific platform; the CIS Benchmarks are the best-known example. Monitoring and scanning tools measure systems against them, and auditors recognise them. What makes a benchmark a yardstick is that it is external and about configuration:

• Anything you built yourself (an internal build standard, a template you maintain) can only show drift from itself; if it has drifted too, comparing against it hides the gap.
• Out-of-the-box settings are chosen for easy deployment, not hardening.
• Policies and standards you wrote state requirements and intent (for example, that remote administration must be encrypted) rather than the exact value each setting should hold, so there is nothing for a configuration scan to compare setting by setting, and they are internal rather than independently maintained.
• Material written for other jobs, such as vulnerability identifiers, response procedures, detection content or risk records, does not say how a system should be configured.

Agents vs agentless. An agent is software installed on the monitored host; it collects locally and reports to its console over any internet connection, so it keeps working on devices that are off the corporate network for long periods. Agentless monitoring installs nothing and reaches in from the network using existing protocols and credentials, so it suits devices where installing software is not allowed, but it can only see devices it can reach. Scans have a second dimension: a credentialed scan logs in to the target and can read installed packages, patch levels and local settings, while a non-credentialed scan sees only what is exposed from outside, such as open ports and service banners. The two choices are independent: an agentless scan can be credentialed or not.

Antivirus matches malicious code in files and processes. Data loss prevention (DLP) inspects content in motion and at rest for sensitive data patterns, such as national ID numbers in a file being uploaded to a personal cloud drive, and can block the action and alert. Both are alert sources: detecting something is only half the job, because an event nobody sees in time is no better than no detection. Their events belong in the SIEM, forwarded as they happen, for two reasons. First, the SIEM queue is the one place the SOC actually triages, so any side channel outside that queue is another place someone has to remember to watch. Second, events that arrive in real time can drive rules, such as an alert when the same detection appears on many hosts in a short window or when a DLP block follows a suspicious sign-in. Anything that summarises events after the fact, wherever it is produced, suits trend reporting, not alerting.

Vulnerability scanners (the scanning activity) probe hosts for missing patches and weak configurations. In monitoring, their results also enrich alerts: an attack aimed at a specific flaw can only succeed against a host that has that flaw, so the target's latest scan results are what tell an analyst whether an attempted exploit matters. Network records answer a different question, whether traffic reached the host.

Orchestration, delivered by SOAR (security orchestration, automation and response) platforms, connects separate security and IT tools through their APIs and runs playbooks that carry out a sequence of actions across them. For a suspected account compromise a playbook might disable the account in the directory, isolate the user's laptop through EDR, add the attacker's IP address to a firewall block list and record each step in the ticket. The SIEM detects and raises the alert; orchestration acts on it. What defines orchestration is coordinating many separate products; one product that combines several functions or automates its own response is not orchestration.

A packet analyzer captures and decodes individual packets, headers and payloads. It is the only monitoring source that shows what was sent: application data such as file contents, commands typed in a cleartext session, or the names a host asks for in its DNS lookups. Flow records, SNMP counters and firewall connection logs are all metadata, and changing how often or how finely they are collected never adds payload to them.

On a switched network a capture port sees mostly broadcasts, multicast, flooded frames and its own traffic, because a switch forwards unicast frames only to the destination port. What a port receives is decided by the switch, not by settings on the capturing machine's NIC. To see another host's traffic, the switch has to be told to copy it: port mirroring (SPAN) copies the traffic of a chosen port or VLAN to the analyzer's port. (A hardware network TAP does the same job on a cable.)

Port mirroring is also how you feed a passive sensor such as an IDS. The deciding difference is where the sensor sits:

• Out of band (mirror or TAP): the sensor receives a full copy of the packets, payload included. If it crashes or falls behind, production traffic is unaffected, but it can only detect and alert, not block.
• Inline: traffic passes through the device, so it can block (an IPS), but a crash or overload can disrupt production. Choose inline only when blocking is required.

NetFlow (and its standards-based relative IPFIX) exports one record per flow: source and destination addresses, ports, protocol, packet and byte counts, and timestamps. It carries no payload. A router or switch exports the records to a collector, which stores and analyses them.

Think of three levels of detail and pick the lightest one that answers the question:

Investigations often climb this ladder: counters show that something unusual is happening, flows show which hosts and services are involved, and a capture shows what they exchanged. Each level comes from a different source, so moving up the ladder means changing source.

The Simple Network Management Protocol (SNMP) lets a manager (usually the NMS) read values from, and receive notifications from, agents on network devices. It works in two directions on two ports:

Polling only discovers a change at the next poll, however short the interval, and every extra poll adds load on the devices and the network. Traps are event-driven, so they give immediate notice at no polling cost. Because the two mechanisms use different ports and opposite directions, treat them as two separate paths when troubleshooting: a firewall can allow one and block the other, and which one still works tells you which path is broken.

Versions. SNMPv1 and v2c protect access with a community string sent in cleartext, and the management data is unencrypted too. SNMPv3 adds per-user authentication and integrity, and at the authPriv security level, encryption (the levels are noAuthNoPriv, authNoPriv and authPriv). Protection in transit is a property of the protocol version: of the SNMP versions, only SNMPv3 at authPriv encrypts credentials and data on the wire.

syslog is the standard protocol for forwarding event messages from Unix-like systems, network devices and many applications to a central collector or SIEM. Every message carries a facility (the type of source, such as kernel, auth or a local facility) and a severity from 0 to 7. The scale is inverted: the lower the number, the more severe.

A threshold written as "level X or more severe" therefore matches X and every lower number. "Warning or worse" means 0 to 4; Notice, Informational and Debug fall outside it.

Transport. Classic syslog runs over UDP 514: no encryption and no delivery guarantee, so a dropped message is silently lost. Syslog over plain TCP gives connection-oriented, reliable transport (the sender knows when the connection fails) but is still cleartext, and messages buffered when a connection drops can still be lost because syslog itself has no application-level acknowledgement (RELP adds that). Syslog over TLS on TCP 6514 adds encryption and integrity on top of TCP's reliable delivery.

Confidentiality and delivery are separate properties, so check each requirement on its own: encryption comes from TLS (or a tunnel), while knowing about lost messages comes from a connection-oriented transport. Adding encryption never changes how reliable the underlying transport is, so check what each layer contributes.

The Security Content Automation Protocol (SCAP), maintained by NIST, is a suite of specifications that lets security tools from different vendors read the same machine-readable assessment content and report results in the same format. Its main components:

• XCCDF: the checklist format, the rules a benchmark wants checked.
• OVAL: the language for the technical checks that test a system's state.
• CVE, CCE and CPE: standard names for vulnerabilities, configuration items and platforms.
• CVSS: the standard way to score vulnerability severity.

The payoff is interoperability. Benchmark publishers ship their checklists as SCAP data streams (XCCDF rules plus OVAL checks in one package). Any SCAP-validated scanner, whoever makes it, imports the same data stream and evaluates exactly the same rules, then returns results in a standard format. Results from different tools are therefore comparable because every tool evaluated the same content.

Keep the four protocols apart: syslog moves event messages, SNMP manages and monitors devices, NetFlow summarises traffic flows, and SCAP standardises security checklists and assessment results.