Monitoring Data — Flashcards

FIM monitors critical system and application files for unauthorized changes. It distinguishes between: (1) Files that change constantly — logs, caches, user data (not FIM targets). (2) Files that should never change — OS binaries, application executables, libraries, key config files (FIM targets). FIM establishes a cryptographic baseline (hash values) of monitored files and alerts when any deviation occurs — modified content, changed permissions, new file, deleted file. Changes to “never change” files are strong indicators of compromise.

SFC (System File Checker) is a built-in Windows utility for file integrity monitoring. Run with sfc /scannow. It scans all protected OS files and verifies them against a trusted catalog stored in the Windows Component Store. If it finds a modified or corrupted file, it automatically restores the known-good version — no manual intervention required. SFC is on-demand, not continuous real-time monitoring. It is the exam’s expected answer for “Windows FIM tool.”

Tripwire is a Linux FIM tool (also available commercially for other platforms). It creates a cryptographic hash baseline of all monitored files and compares current state against that baseline at each scan. Two capabilities distinguish it from SFC: (1) Real-time monitoring — Tripwire can alert instantly when a monitored file is touched, not just at scheduled scan time. (2) Configurable scope — administrators define exactly which files and directories to monitor. Tripwire is the exam’s expected answer for “Linux FIM tool.”

Data in use: information actively being processed on an endpoint — in memory, being copied, printed, or transferred to removable media. Monitored by endpoint/agent DLP. Data in motion: information traversing a network — in transit between systems, being uploaded or downloaded. Monitored by inline network DLP or cloud DLP. Data at rest: information stored on persistent media — file servers, databases, cloud storage, backup. Monitored by storage scanning DLP. Each state requires a different type of DLP deployment to provide coverage.

Endpoint DLP (agent-based DLP) runs as software directly on the individual device — laptop, desktop, workstation. It monitors user activity at the OS level: USB transfers, clipboard operations, printing, screen capture, and file access. Key advantage: enforces policy offline. Network DLP and cloud DLP can only inspect traffic that passes through their inspection point. A device not connected to the corporate network generates no traffic for them to inspect. Endpoint DLP operates locally and enforces policy whether the device is on the office network, home Wi-Fi, or completely offline.

In November 2008, an infected USB drive was plugged into a DoD computer at a military base. The agent.btz worm spread automatically across classified and unclassified networks by replicating through USB storage devices. Response: the DoD banned all removable flash media department-wide and deployed endpoint DLP agents with USB blocking policies on every device. The ban was lifted in February 2010 and replaced with strict controlled-use guidelines. The incident is the canonical example of why USB blocking is a critical DLP control for preventing both malware introduction and data exfiltration.

Cloud-based DLP is deployed as a proxy service between users and the internet, monitoring all cloud service traffic. No on-premises hardware or software installation required. It can block: custom data strings unique to the organization; unauthorized file uploads to consumer cloud storage (personal Dropbox, Google Drive); access to unapproved cloud services; and malware traversing cloud paths. What it covers that on-premises DLP misses: remote workers and branch offices whose traffic does not route through the corporate perimeter appliance — cloud DLP inspects their traffic at the cloud layer regardless of network location.

Inbound email DLP protects against: 1. Malicious attachments — executables, macros, or exploits disguised as documents. 2. Phishing/impostor emails — emails spoofing executives, banks, or vendors to steal credentials. 3. Keyword-based social engineering — filters messages containing patterns associated with phishing or fraud. 4. Quarantine before delivery — suspicious messages are held for review before reaching the user’s inbox, preventing the user from ever seeing and acting on them. Inbound DLP complements SPF/DKIM/DMARC by also scanning content and attachments, not just sender authentication.

Outbound email DLP prevents sensitive data from leaving the organization via email: 1. SSN/credit card/medical record transmission — scans email bodies and attachments for regulated data patterns. 2. Fake wire transfer fraud — blocks outbound BEC-style requests if they contain financial instruction patterns. 3. W-2 and tax document leakage — prevents employee financial records from being emailed externally. 4. Attachment content scanning — inspects Excel/Word files including hidden fields and columns for sensitive data. The 2016 Boeing incident (36,000 employees’ SSNs in hidden spreadsheet columns) is the exam’s canonical outbound email DLP failure case.

In November 2016, a Boeing employee emailed a spreadsheet template to their spouse for personal use. The spreadsheet appeared blank but contained hidden columns with the PII of approximately 36,000 Boeing employees — Social Security numbers, dates of birth, and other personal information. Prevention: outbound email DLP scanning attachments for SSN patterns would have detected the hidden data and blocked the email before transmission. Notably, Boeing sold its own DLP software to government customers for classified work but did not deploy it for internal employee data. The incident illustrates that data leakage is often accidental, not malicious — making automated outbound controls critical.