14.4 Logging, Monitoring, and Security Events for Data

Visibility Turns Policy into Evidence

Data controls are incomplete without visibility. An access rule may say only payroll staff view salary data, but logs prove whether the rule is followed. Encryption may protect a database, but key-access logs show who requested decryption. A label may mark a file Restricted, but monitoring reveals whether it was copied somewhere unapproved. Logging and monitoring convert policy into evidence, and Domain 5 expects you to recognize when they are the right answer.

What to Log

Useful data-security logs capture enough context to answer who, what, when, where, and how without drowning analysts or violating privacy.

Not every system can log everything, and excessive logging adds cost and privacy exposure. The goal is enough reliable context, not maximum volume.

Correlation Beats Single Events

Individual log lines are weak; correlation is strong. Suppose a cloud-storage log shows Jordan sharing a folder externally at 9:14 p.m. from a new device. An identity log shows Jordan passed multi-factor authentication (MFA) from a foreign country five minutes earlier. A DLP alert shows the folder held tax documents. Any one event is ambiguous; together they paint a clear, high-risk picture. This is the logic behind a Security Information and Event Management (SIEM) system, which aggregates and correlates logs centrally.

Monitoring Patterns That Matter

Monitoring hunts for risk-relevant patterns rather than noise:

• Repeated failed logins, then a sudden success (possible password guessing).
• A service account exporting thousands of records off its normal schedule.
• A help-desk agent opening executive files with no related ticket.
• A maintenance query run at midnight from an unfamiliar network rather than during an approved change window.

Alerts should be tied to data sensitivity: reading Public data rarely deserves the priority of a bulk export of Restricted data. Effective monitoring blends sensitivity, identity, role, device, location, time, volume, and recent changes.

Protecting the Logs Themselves

Logs are evidence, and attackers routinely try to delete or alter them after a breach. Protect them by sending records to a central, access-controlled system, keeping clocks time-synchronized (so events line up across systems), and retaining logs per policy. A crucial principle: an administrator who manages a system should not be able to erase the independent audit trail of his own actions — that preserves accountability and supports investigations. Retention is itself a data decision: too short and slow-moving incidents go uninvestigable; too long and you add cost, privacy, and e-discovery risk.

Events, Incidents, and Triage

A security event is any observable occurrence that may matter to security — a failed login, a blocked export, a permission change. An incident is a confirmed or strongly suspected violation requiring response. The first alert is not automatically an incident; analysts triage by weighing evidence, context, and impact.

Suppose monitoring reports a manager downloaded 800 customer records. Before declaring a breach, the analyst checks:

1. Does the manager own a customer-migration project?
2. Is there an approved change ticket?
3. Was the destination an approved system?
4. Were the records encrypted in transit and at rest?
5. Is 800 records a normal volume for this role?

If the download came from a personal device with no business justification, escalation to incident response is appropriate; if it matches an approved project, it is benign.

Mapping Scenarios to Answers

• "How do we detect inappropriate access?" choose logging and monitoring.
• "How do we prove who changed access rights?" choose audit logs plus unique (non-shared) accounts.
• "How do we prevent tampering with evidence?" choose centralized, tamper-protected logging with appropriate retention and time sync.

Why Time Synchronization Matters

A detail the exam likes to test is clock synchronization using the Network Time Protocol (NTP). When a firewall, an identity provider, and a database each keep their own slightly wrong clock, an investigator cannot reliably order events, and a defense attorney can challenge the timeline. Synchronizing every system to a common time source means logs from different systems line up to the second, so the share, the foreign login, and the DLP hit in the earlier example can be proven to occur in sequence. Without it, correlation falls apart.

Baselines and Anomalies

Monitoring is only meaningful against a baseline of normal behavior. If a billing service normally exports about fifty records each morning, an export of five thousand records at 2 a.m. is a clear anomaly worth an alert; without the baseline, the same number is just a row in a log. Establishing baselines for volume, timing, location, and typical roles lets monitoring surface the few events that matter out of millions that do not. This is also why brand-new accounts and dormant accounts that suddenly activate draw scrutiny — there is no established normal, or the normal was "inactive."

Connecting the Whole Domain

Notice how the four sections interlock. Cryptography (14.1) protects confidentiality and integrity; key handling (14.2) keeps that cryptography trustworthy; classification and retention (14.3) decide which data deserves which controls and how it is destroyed; and logging and monitoring (14.4) prove the controls are working and catch the cases where they are not. On the CC exam, a single Domain 5 scenario can touch several of these at once — for example, a question about an encrypted Restricted file shared externally and caught by DLP draws on classification, handling rules, and monitoring together.

Reason across the lifecycle rather than treating each term in isolation, and the answer that respects who, what, where, how long, and who can see it is almost always the credited one.