A switch's power supply fails at 1:15 a.m., a Linux server rejects 200 SSH passwords in a minute, a workstation uploads 8 GB to an address nobody recognizes, and a web server quietly drifts away from its hardened configuration. Each of those facts exists on some device. Monitoring protocols are how they reach the people and tools that can act on them.
On the CompTIA Security+ SY0-801 exam these protocols sit under objective 4.4, which expects you to explain the concepts and tools organizations rely on for security monitoring and alerting. This lesson covers syslog, SNMP, NetFlow and SCAP: what each carries, the ports and versions to know, how to secure them, and how to pick the right one from a scenario's wording.
Each monitoring protocol answers a different question
The four are easy to blur together, so start with what each one is for:
| Protocol | Question it answers | Ports | Main weakness |
|---|---|---|---|
| Syslog | What happened on this device? | UDP 514; TLS on TCP 6514 | Plain UDP is unencrypted and unacknowledged |
| SNMP | What state is this device in? | UDP 161 for polling, UDP 162 for traps | v1 and v2c send community strings in cleartext |
| NetFlow / IPFIX | Who talked to whom, when, and how much? | UDP to a collector, often 2055 or 4739 | No payload content |
| SCAP | Does this system meet the required configuration? | Not a network protocol | Only as good as the checklist content |
They complement each other. During one incident you might use syslog to see the failed logons, SNMP to learn that a switch port went down, NetFlow to measure what left the network, and SCAP to show which servers lacked the setting that would have prevented it. Despite the P in its name, SCAP isn't a network protocol at all; it is a set of standard formats, explained later in this lesson.
Syslog sends event messages to a collector with a facility and a severity
Syslog is the standard way Linux and Unix systems, network devices, firewalls and most appliances send log messages to a central collector. Windows doesn't speak syslog natively; its event logs need an agent or forwarder to convert and send them.
Every syslog message carries a priority built from two values. The facility identifies the kind of program that produced it, such as kern (0), user (1), mail (2), daemon (3), auth (4), cron (9) and authpriv (10), with local0 through local7 (16 to 23) reserved for custom use, which is where many network devices log. The severity is a number from 0 to 7, and lower means more urgent:
| Level | Name | Meaning |
|---|---|---|
| 0 | Emergency | System is unusable |
| 1 | Alert | Action needed immediately |
| 2 | Critical | Critical condition, such as a hardware failure |
| 3 | Error | Error condition |
| 4 | Warning | Warning condition |
| 5 | Notice | Normal but significant event |
| 6 | Informational | Routine operational message |
| 7 | Debug | Detailed debugging output |
A device set to log at a level sends that level and everything more severe. A Cisco router configured with logging trap warnings, for example, sends levels 0 through 4 to its syslog server.
Here is one message as it travels on the network in the current format, defined in RFC 5424:
<38>1 2026-10-21T02:41:07.004Z web01 sshd 4127 - - Failed password for invalid user admin from 203.0.113.45 port 51122 ssh2
The priority value equals the facility times 8 plus the severity, so 38 decodes as facility 4 (auth) and severity 6 (informational). Then come the format version, a timestamp with a time zone, the host, the application, the process ID, two dashes for an empty message ID and structured data, and the message. The older BSD format (RFC 3164), still used by many devices, carries a timestamp like "Oct 21 02:41:07" with no year and no time zone.
That example carries a practical lesson. Severity is set by the program, not by how much the event matters to security. To sshd, a failed password is routine and informational, so a collector that keeps only warnings and above would discard every brute-force attempt.
Traditional syslog runs over UDP 514, which has three weaknesses: messages can be lost without anyone knowing, anyone on the path can read them, and nothing proves who sent them, so they can be spoofed. Plain TCP makes delivery more reliable. Syslog over TLS, on TCP 6514, keeps that reliability and adds encryption and certificate-based authentication. A Linux host running rsyslog can forward its authentication messages that way:
# /etc/rsyslog.d/60-forward.conf: send auth messages over TLS
global(DefaultNetstreamDriverCAFile="/etc/pki/rsyslog/ca.pem")
auth,authpriv.* action(type="omfwd" target="logs.corp.example" port="6514"
protocol="tcp" StreamDriver="gtls" StreamDriverMode="1"
StreamDriverAuthMode="x509/name")
On the exam, "secure syslog" or "encrypt log messages in transit" means syslog over TLS on port 6514.