5.4.1. Monitoring Computing Resources
💡 First Principle: Every computing resource generates data that reveals its security status. Monitoring transforms that data into visibility. Different resources produce different signals — network infrastructure shows traffic patterns, systems show configurations and performance, and applications show user behavior.
Systems monitoring — tracking server health, resource utilization, service status, and configuration compliance. Abnormal CPU usage might indicate cryptomining; unexpected disk activity might indicate data exfiltration or ransomware encryption. Key metrics include CPU, memory, disk I/O, process lists, and service states. Tools like Windows Performance Monitor, Linux top/htop, and agent-based monitoring platforms (Nagios, Zabbix) provide visibility.
Infrastructure monitoring — network device health, bandwidth utilization, interface errors, routing changes, and configuration compliance. An unexpected routing change could indicate BGP hijacking; bandwidth spikes could indicate DDoS or exfiltration. SNMP polling, NetFlow analysis, and syslog collection are primary data sources. Baseline traffic patterns first — you can't detect anomalies without knowing what normal looks like. Watch for beaconing: a host contacting the same external address at a fixed, regular interval with small, near-identical payloads is the classic command-and-control check-in pattern, and DNS beaconing is the same behavior at the DNS layer (regular lookups of a rarely seen or newly registered domain). One large sustained transfer points instead to exfiltration, and legitimate update checks go to well-known vendor infrastructure. Outbound connections from a server that has no reason to initiate them (a database server, for example) are a red flag for command-and-control or exfiltration. For SNMP polling, agents listen on UDP 161 and send traps to the manager on UDP 162.
Applications monitoring — tracking application performance, error rates, access patterns, and user behavior. Unusual query patterns might indicate SQL injection attempts; repeated authentication failures indicate brute-force attacks. Application logs capture business-level events (orders processed, records accessed) that infrastructure monitoring can't see. Application Performance Monitoring (APM) tools correlate user experience with backend behavior.
The monitoring stack works in layers: infrastructure tells you a port is open, systems tell you a process is running, and application logs tell you what that process is doing. A comprehensive view requires all three. If your firewall shows allowed connections to a web server, but you're not monitoring the web application logs, you won't detect SQL injection or authentication attacks against the application itself.
⚠️ Exam Trap: Monitoring should cover all three layers: systems, infrastructure, and applications. A question describing a missed attack often points to a monitoring gap at one specific layer. If the scenario describes detecting a network anomaly but missing the actual compromise, application-level monitoring is likely the gap.
