At 2:40 a.m. a file server's CPU climbs to 100 percent, about 4,000 files are renamed in ten minutes, and someone clears the server's Security log. Every one of those events was recorded somewhere. Whether anyone finds out before the morning shift depends on what the organization was monitoring and where those records went.
Security monitoring is the practice of collecting signals like these continuously and acting on them. On the CompTIA Security+ SY0-801 exam it sits under objective 4.4, which expects you to explain how organizations watch their computing resources, raise alerts and use the tools that make both possible. This lesson covers what to monitor on systems, applications and infrastructure, where network management systems fit, and the activities that turn raw records into action: log aggregation, alerting, scanning, archiving and reporting.
Monitoring covers three layers and a short list of repeatable activities
The exam divides computing resources into three layers, and each one produces different evidence:
- Systems are individual hosts: servers, workstations, virtual machines and the operating systems on them.
- Applications are the software services those hosts run, such as web applications, databases, email and SaaS platforms.
- Infrastructure is what connects and carries everything else: routers, switches, firewalls, wireless controllers, hypervisors, cloud control planes, and power and cooling.
A single attack usually leaves traces in more than one layer. In the opening example, the server's own logs show the CPU spike and the cleared log, the file-sharing service records thousands of renames, and the firewall shows an RDP session on port 3389 to the server from a workstation that has never connected to it before. Watching one layer gives you a fragment; watching all three shows you the incident.
What you do with the data follows a short list of activities:
| Activity | What it does | Example |
|---|---|---|
| Log aggregation | Collects logs from many sources into one place | Domain controllers, firewalls and web servers forward to a central collector |
| Alerting | Notifies a person or system when a condition is met | Page the on-call analyst when a domain admin logs on at 3 a.m. |
| Scanning | Checks systems on a schedule for weaknesses and drift | A weekly credentialed vulnerability scan of the server VLAN |
| Archiving | Keeps older logs safely and cheaply for a set period | Logs older than 90 days move to immutable storage for a year |
| Reporting | Summarizes results for people who don't read raw logs | A monthly report on patch compliance and incident counts |
| Alert tuning | Adjusts rules so alerts stay accurate | Excluding the backup server from a mass-file-access rule |
All of these depend on a baseline, a record of what normal looks like for each system. Full CPU on a build server during the nightly compile is normal; full CPU on an idle file server at 2:40 a.m. is not. Alert tuning is covered with SIEM in the next lesson.
System monitoring watches the health and activity of individual hosts
System monitoring has two halves. Health monitoring tracks CPU, memory, disk space, uptime and whether key services are running. These have security meaning: a full disk can stop a host from writing logs, an endpoint agent service that stops unexpectedly may have been killed by an attacker, and sustained CPU load on a quiet server is a common sign of cryptomining or bulk encryption.
Activity monitoring tracks who logged on, which accounts and groups changed, which processes started and what privileges were used. On Windows, the Security event log carries the events you'll see most often:
| Event ID | Meaning | Why you might alert on it |
|---|---|---|
| 4624 | Successful logon | Admin logon at an odd hour or from an odd host |
| 4625 | Failed logon | Many failures against one account or from one source |
| 4720 | User account created | Accounts created outside the provisioning process |
| 4732 | Member added to a security-enabled local group | Someone added to the local Administrators group |
| 4740 | Account locked out | Many lockouts in minutes suggest password spraying |
| 1102 | Audit log cleared | Attackers clear logs to hide their tracks |
Linux systems record authentication in /var/log/auth.log on Debian and Ubuntu or /var/log/secure on Red Hat-family distributions, and the auditd service can record file access and system calls in more detail. A typical line looks like this:
Oct 21 02:41:07 fs01 sshd[4127]: Failed password for invalid user admin from 203.0.113.45 port 51122 ssh2
File integrity monitoring (FIM) completes the picture. A FIM tool records hashes of critical files, such as system binaries, /etc/passwd, configuration files and a web server's document root, and alerts when any of them change. On the exam, a scenario about detecting unauthorized changes to system files or a website's pages is pointing at FIM.