Why Security Monitoring Must Be Continuous
Attackers do not observe business hours. They probe systems at 2 AM on holidays, automate credential-stuffing attacks around the clock, and conduct reconnaissance over weeks or months before taking visible action. Monitoring that runs only during business hours or reviews logs once a day gives attackers a guaranteed window of unobserved access. Effective security monitoring is a 24/7/365 operation — the only question is whether the organization is watching in real time or reviewing events after the fact.
The entry points that require constant monitoring include: authentication systems (login events, failed attempts, unusual times and locations); publicly accessible services (web servers, APIs, email gateways); remote access infrastructure (VPN concentrators, remote desktop gateways); and data storage locations (file servers, databases, cloud storage buckets) where exfiltration would appear as unusual outbound transfer volume. When a security event occurs on any of these surfaces, monitoring enables the team to see it in time to react.
Status dashboards consolidate monitoring output into an at-a-glance view of the current security posture. Rather than requiring analysts to check individual systems, a well-designed dashboard surfaces the most security-relevant indicators — authentication failures, service status, recent alerts, patching compliance — in one view so that abnormalities stand out immediately against the established baseline.
Systems Monitoring — Servers and Authentication
System-level monitoring covers the operating environment that all services run on. Two areas receive the most security attention:
Authentication monitoring watches for login events that deviate from established patterns. Logins from geographic locations where the organization has no employees, authentication attempts outside of normal business hours, repeated failed logins followed by a successful one (potential credential stuffing or brute force), or sudden account access after months of inactivity all represent anomalies worth investigating. An authentication spike from a foreign country with no organizational presence is a textbook alert trigger.
Server monitoring tracks service activity (processes running, services starting and stopping), backup completion status (a backup that suddenly stops completing could indicate ransomware encrypting data), and installed software versions. Software version data is particularly valuable for vulnerability management: if a new vulnerability is published for a specific version of a service, server monitoring data can immediately identify how many servers are running that version.
Application and Infrastructure Monitoring
Application monitoring tracks both availability and security indicators. Availability monitoring ensures that business-critical applications remain accessible — unexpected downtime may indicate a denial-of-service condition or a service crash caused by exploitation. Data transfer monitoring is a particularly sensitive security indicator: an application that normally transfers 5 GB per day suddenly transferring 500 GB is a red flag for data exfiltration, even if no other indicators are present. Organizations should also maintain communication channels with application developers and vendors to receive security notifications when vulnerabilities are discovered in the software they run.
Infrastructure monitoring focuses on the connectivity layer: remote access systems, firewalls, and intrusion prevention systems. Remote access monitoring should track who is connecting — distinguishing between employees, vendors, and guests — and flag sessions with unusual duration, volume, or access patterns. Firewall and IPS reports surface attack trends: a sudden spike in blocked inbound connections on specific ports can indicate active reconnaissance or the beginning of a larger attack campaign targeting the organization.
SIEM — Security Information and Event Management
An organization monitoring dozens of systems generates log data from firewalls, servers, switches, routers, VPN concentrators, cloud services, SAN storage systems, and endpoints — each in a different format, each covering a different slice of the environment. Reviewing these logs individually is impractical; detecting cross-system attack patterns by reading them separately is nearly impossible. A SIEM (Security Information and Event Management) system — also referred to as a SEM (Security Event Manager) — solves this by aggregating all of these logs into a single central database.
Once logs are centralized, the SIEM's defining capability is correlation: comparing and connecting events across disparate sources that would be invisible in isolation. A single failed login on one server is noise. The SIEM connecting 200 failed logins from the same IP across 30 servers in 60 seconds is an actionable brute-force alert. A VPN authentication from an unusual location connected to an unusual volume of file access is an exfiltration indicator that no single log would reveal on its own.
SIEM use cases that the exam specifically tests: authentication and access correlation — linking VPN authentication events to subsequent internal access; application access tracking — which users are accessing which applications through which access paths; and data transfer measurement — baselining normal transfer volumes and alerting when they are exceeded. The SIEM is the operational center of gravity for a security operations team: everything flows in, correlation happens in one place, and alerts and reports flow out.
Continuous Scanning — Active Inventory of the Threat Surface
The threat landscape changes continuously: new vulnerabilities are disclosed daily, employees add and remove software on their devices, mobile devices and laptops move between networks, and the organization's own infrastructure evolves. A static inventory taken once a quarter is immediately out of date. Continuous scanning actively queries devices across the network to maintain a current picture of the threat surface.
Scans collect: operating system types and versions (identifying systems running end-of-life or unpatched OS versions); device driver versions (drivers are frequently overlooked patching targets that can be exploited); installed applications (particularly useful for identifying unauthorized software or applications with known CVEs); and configuration anomalies (deviations from the security baseline that may indicate tampering or misconfiguration).
The output is a database that is continuously updated with the current state of every device on the network. This database becomes the foundation for all vulnerability management reporting and enables the team to answer "how many systems are affected by this new CVE" in minutes rather than days.
Reporting — Turning Data into Actionable Decisions
Collected data has no security value until it is analyzed and transformed into actionable information. Security reports should answer the question: what do we need to do next? Not just what the current state is, but what specific actions follow from that state.
Status reports show the current posture: number of devices fully patched and in compliance, number of devices running outdated operating systems, compliance percentage against a security policy baseline. These answer "where are we?"
Vulnerability response reports answer the question: when a new CVE is published today, how many systems in this environment are running the affected software version? The continuously-updated scan database makes this query answerable immediately rather than requiring a new scan to run.
Ad hoc reports support what-if analysis and emerging situations. If an operating system is approaching end-of-life in six months, an ad hoc report can project how many systems will become vulnerable when vendor security support ends. If an incident is under investigation, an ad hoc report can pull historical data on a specific user's access patterns for the past 90 days. Ad hoc reporting capability is essential because security incidents are unpredictable and investigation needs cannot always be anticipated in advance.
Archiving — Why Historical Data Is a Security Requirement
According to an IBM Security report published in 2022, organizations take an average of approximately nine months to identify and contain a data breach. This statistic has direct implications for log retention: if an attacker gains initial access in January and is not discovered until October, and the organization only retains 90 days of logs, the evidence of the initial compromise, the lateral movement, and the persistence mechanisms is gone. Investigation cannot proceed, and the full scope of the breach may never be understood.
Log archiving is not just best practice — it is frequently a legal obligation. State laws (like some U.S. state breach notification laws), federal regulations (HIPAA, PCI-DSS, SOX, and others), and industry frameworks mandate specific retention periods for security records. Organizations that fail to retain required logs may face regulatory penalties in addition to losing forensic evidence.
Archived data serves multiple purposes: forensic investigation of incidents that were not detected in real time; compliance audit support; legal proceedings where log records become evidence; and long-term trend analysis that can identify slow-moving attacker campaigns that generate low-volume anomalies below short-term alerting thresholds. The nine-month average discovery time is a compelling argument for retaining at least 12 months of security logs — ideally more for high-risk environments.
Alerting — Real-Time Notification of Security Events
Monitoring and reporting provide a picture of what has happened; alerting provides immediate notification when something that requires action is happening right now. The goal of alerting is to surface actionable information to the right people fast enough that they can respond before an incident escalates.
Common alert triggers include: increases in authentication failures (brute-force or credential stuffing attempts); large or anomalous data transfers (potential exfiltration); malware detections by endpoint protection; firewall rule changes; and service outages. Each trigger represents a condition that warrants immediate human attention and cannot wait for a morning report review.
Alert delivery methods are selected based on urgency and the availability of the recipient. SMS/text messages reach on-call personnel immediately, even outside business hours. Email notifications provide more detail and create a documented record of the alert and the time it was sent. Security console or SOC dashboards surface alerts to analysts who are actively watching screens in a Security Operations Center, enabling immediate triage and dispatch. Most mature security programs use multiple delivery methods in parallel: text for immediate awareness, email for detail, and SOC console for systematic tracking and escalation.
Alert Response — Quarantine and Alert Tuning
When an alert fires, the initial response is investigation: determine whether the alert represents a genuine threat or a false positive. For alerts that represent confirmed or likely threats, quarantine is the foundational initial containment action. Quarantining a system removes it from normal network communication — isolating it from other systems so that an attacker who has compromised it cannot use it as a pivot point to reach additional systems, and so that it cannot receive further instructions from a command-and-control server. Quarantine preserves the system for forensic examination while stopping the spread.
Alert tuning is the ongoing process of calibrating the alerting system to minimize false positives and false negatives while maintaining accurate detection of real threats. This is a balance: alert thresholds set too aggressively generate excessive false positives, overwhelming analysts with noise and causing real alerts to be missed in the volume. Thresholds set too loosely miss real threats — false negatives that leave the organization unaware of active incidents.
Alert tuning is never complete. As the network changes, as new attack techniques emerge, and as the organization's understanding of its own baseline behavior deepens, alert thresholds require adjustment. New users, new applications, seasonal traffic patterns, and infrastructure changes all affect what "normal" looks like and therefore what should be flagged as anomalous. A well-tuned alert system is the product of months of iterative refinement — not a one-time configuration task.