🔬 Detecting Attacks on Data
Logging, honeypots, and hashing — the analyst's toolkit for finding what happened⏱ ~3 min
Was the data accessed? (Logging answers this.) Was it accessed by someone who shouldn't have been there? (Honeypots answer this — if a honeypot was touched, an unauthorized person was definitely there.) Was the data changed? (Hashing answers this — compare the current hash to the known-good hash.) These three questions map exactly to three detection mechanisms. No single mechanism answers all three — you need all of them.
Three Core Data Detection Mechanisms
| Mechanism | Question It Answers | How It Works | What It CANNOT Tell You |
|---|---|---|---|
| Logging / Accounting | Was data accessed, by whom, when, and from where? | Systems record every read, write, delete, login, and command with timestamp and user identity | Whether the access was authorized (needs human analysis of logs); whether data was changed |
| Honeypot | Was data accessed by someone who shouldn't be there? | Decoy file/system that real users have no reason to open; any access is an automatic red flag requiring no analysis | Who the attacker is (just that unauthorized access occurred); what they did beyond accessing the honeypot |
| Hashing (Integrity Check) | Was the data modified? | Hash the file when known-good; periodically re-hash and compare; any change produces a different hash | Who changed it or when (only that a change occurred); cannot detect data theft if nothing is modified |
Choosing the Right Detection Control
- •Cost — logging is nearly free (built into most systems); DLP (data loss prevention) monitoring all traffic is expensive; match cost to data sensitivity
- •Data sensitivity / criticality — medical records and financial data require monitoring by law (HIPAA, PCI-DSS); cafeteria lunch preferences do not
- •Data classification — some compliance frameworks mandate what controls apply; the decision is made for you
- •Speed — honeypot triggers instant alert; automated log analysis is fast (seconds/minutes); manual log review is slow (hours/days)
- •Timing — real-time (catches attack in progress) vs. retrospective (discovers it happened days later)
- •Coverage gaps — hashing misses data theft without modification; honeypots miss attackers who avoid the decoy; no single tool is complete
Log Analysis — Reading Indicators of Attack
Three patterns in logs consistently indicate attacks:
- •Repeated failed logins — 10 failed SSH attempts from one IP in 30 seconds = automated brute-force attack
- •Unusual file access — intern account accessing /secure/payroll.csv at 2 AM from a Romanian IP on an unknown device = likely account compromise and data theft
- •Suspicious input in requests — web server log showing 'user=admin%27%20OR%20%271%27%3D%271' (URL-encoded SQL injection) = active SQL injection attempt
- •Bulk data actions — 847 files downloaded from /sensitive/PII/ in 4 minutes = data exfiltration
Practice: Analyze These Log Entries
| Log Entry | Normal or Suspicious? | Why |
|---|---|---|
| jsmith | Mon 09:14 | budget_Q3.xlsx | Chicago office | Company laptop | Normal | Work hours, known location, expected device, plausible file for this user |
| jsmith | Sat 02:47 | HR_medical_records_all.xlsx | Romania IP | Unknown device | SUSPICIOUS | Weekend 3 AM, foreign IP, unknown device, sensitive file unrelated to jsmith's role — multiple red flags |
| agarcia | Tue 14:22 | project_proposal.docx | Office network | Work laptop | Normal | Business hours, internal network, work device, plausible work document |
| agarcia | Tue 14:38 | 847 files from /sensitive/PII/ | Office network | SUSPICIOUS | Same user, 16 minutes later, bulk download of sensitive PII directory — possible exfiltration |
| guest | 02:14:33 | /secure/payroll.csv | SUCCESS | SUSPICIOUS | Guest account should have no access to payroll; 2 AM; successful access = either privilege escalation or misconfigured permissions |
As a junior security analyst, you receive this SIEM alert at 3 AM: • 02:14:33 — guest account accessed /secure/payroll.csv: SUCCESS • 02:14:45 — guest account accessed /secure/employee_SSNs.csv: SUCCESS • 02:15:01 — 2,400 records exported from HR database by guest account • 02:15:14 — honeypot file '/secure/passwords_do_not_open.txt' accessed by guest account Which detection mechanisms triggered, what does the honeypot access specifically confirm, and what is your recommended immediate action?