Table 1 — Three Monitoring Domains: Systems, Applications, Infrastructure
| Domain | What Is Monitored | Key Security Indicators |
|---|---|---|
| Systems | Authentication events, server service activity, backup completion status, installed software versions | Logins from unexpected geographic locations; repeated failed logins; services stopping unexpectedly; backups failing (possible ransomware); unpatched software versions |
| Applications | Uptime and availability, response times, inbound and outbound data transfer volumes, developer security notifications | Application downtime (possible DoS or exploitation); sudden spike in data transfer volume (possible exfiltration); security notifications from developers/vendors |
| Infrastructure | Remote access connections (employees, vendors, guests), firewall rule activity, IPS reports and blocked traffic patterns | Unauthorized remote access sessions; unusual access patterns from vendor accounts; spike in blocked attack attempts at the firewall; new attack types appearing in IPS logs |
Table 2 — SIEM Capabilities and Use Cases
| Capability | Description | Security Value |
|---|---|---|
| Log aggregation | Collects logs from servers, firewalls, switches, routers, VPN concentrators, cloud services, SANs into one central database | Eliminates log silos; enables unified analysis across the entire environment |
| Correlation | Connects events across disparate sources to identify patterns invisible in any single log | Detects multi-stage attacks, brute-force campaigns, and exfiltration patterns that span multiple systems |
| Centralized reporting | Generates reports from the unified log database using a single reporting engine | Consistent, comprehensive reporting without manually querying each system individually |
| Authentication and access tracking | Links VPN authentication events to subsequent internal access and application usage | Identifies compromised credentials being used for lateral movement after initial authentication |
| Data transfer measurement | Baselines normal transfer volumes and alerts when thresholds are exceeded | Primary detection mechanism for data exfiltration, which often produces anomalous transfer spikes |
| Alert generation | Fires alerts when correlation rules or threshold conditions are met | Delivers actionable notifications to analysts in real time rather than waiting for report reviews |
Table 3 — Continuous Scanning: Data Collected and Security Purpose
| Data Collected | Security Purpose |
|---|---|
| Operating system types and versions | Identify systems running end-of-life OS versions with no vendor security support; match against newly disclosed OS-level CVEs |
| Installed applications and versions | Detect unauthorized software; identify applications with known CVEs; track patch compliance across the application stack |
| Device driver versions | Drivers are frequently overlooked in patch management; outdated drivers can be exploited for privilege escalation or kernel access |
| Configuration anomalies | Deviations from the security baseline may indicate tampering, misconfiguration, or unauthorized changes by an attacker or insider |
| Network presence | Identify unauthorized devices on the network; detect changes in device inventory that may indicate new endpoints or rogue devices |
Table 4 — Reporting Types and Their Security Purpose
| Report Type | What It Shows | When It Is Used |
|---|---|---|
| Status report | Number of compliant vs. non-compliant systems; patching coverage; devices running outdated OS versions | Routine security reviews; management reporting; compliance audits |
| Vulnerability response report | Which systems in the environment are running the software version affected by a newly disclosed CVE | Immediately after a new CVE is published; drives emergency patching decisions |
| Ad hoc report | Customized query against current or historical data for an unanticipated need; what-if analysis; end-of-life projections | Incident investigations; forward planning; emerging threats that require immediate custom analysis |
| Trend report | Changes over time: alert volume trends, patching velocity, new device additions | Identifying gradual degradation of security posture; measuring improvement from security investments |
Table 5 — Archiving: Retention Requirements and Evidence Use
| Factor | Detail |
|---|---|
| Average breach discovery time | ~9 months (IBM Security 2022) — logs must span at least this window for historical forensic evidence to be available |
| Forensic investigation | Archived logs allow investigators to reconstruct attacker activity from initial access through lateral movement and exfiltration |
| Compliance and legal | HIPAA, PCI-DSS, SOX, and state breach notification laws mandate specific retention periods; failure to retain logs may result in regulatory penalties |
| Slow attack detection | Low-volume, persistent attacker activity may generate anomalies only visible when analyzed over months — short retention windows make this analysis impossible |
| Recommended minimum retention | At least 12 months for most environments; longer for regulated industries; stored in a tamper-evident format to preserve evidentiary value |
Table 6 — Alerting Methods and Alert Response Actions
| Category | Item | Description |
|---|---|---|
| Alert delivery methods | SMS / text | Immediate notification to on-call personnel; works outside business hours; highest urgency delivery |
| More detail than SMS; creates documented record of alert time and content; suitable for lower-urgency or supplementary notification | ||
| SOC console | Centralized dashboard for security operations teams actively monitoring; enables systematic triage, escalation, and tracking | |
| Alert response actions | Quarantine | Isolate the affected system from network communication; stop lateral spread; preserve system for forensics |
| Alert tuning | Adjust thresholds and rules to reduce false positives and false negatives; ongoing process that improves accuracy over time | |
| Alert calibration problem | False positive | Alert fires on harmless activity — wastes analyst time; causes alert fatigue; risks real alerts being ignored |
| False negative | Real threat does not trigger an alert — organization is unaware of active incident; more dangerous than false positive |