5.6.1. Security Incident Symptoms and Causes
💡 First Principle: Security problems present as access failures (legitimate users can't get in or can't get to resources), behavioral anomalies (processes running that shouldn't be), or performance changes (excessive CPU/network from malware). Distinguishing security problems from configuration problems requires checking whether changes were authorized.
Common Security Problems
| Symptom | Most Likely Security Cause | Investigation |
|---|---|---|
| File integrity failure | Unauthorized modification, malware | File integrity monitoring alerts, hash comparison |
| Improper privilege escalation | Excessive permissions, sudo abuse | Audit logs, group membership review |
| Applications will not load | SELinux/AppArmor denying access, AV quarantine | Security logs, SELinux audit log (/var/log/audit) |
| Cannot access network fileshares | Permission change, share access revoked | Check permissions, share configuration |
| Unable to open files | File encrypted by ransomware, permissions changed | Check file encryption state, permission audit |
| Unusual outbound traffic | Malware command-and-control, data exfiltration | Network monitoring, netstat, DLP alerts |
| New user accounts created | Compromised admin account, insider threat | AD audit logs, account creation events |
| Services running unexpectedly | Malware, backdoor | Running process list vs. known-good baseline |
Root Causes
| Cause | How It Manifests | Mitigation |
|---|---|---|
| Open ports | Services accessible that shouldn't be | Port scan and firewall audit |
| Active/orphan/zombie services | Processes consuming resources, potential backdoors | Process audit vs. baseline |
| Misconfigured IDS | False positives blocking legitimate traffic | Tune IDS rules |
| Misconfigured anti-malware | Legitimate tools quarantined | Whitelist known-good tools |
| Misconfigured firewall rules | Over-permissive or conflicting rules | Firewall rule audit |
| Misconfigured permissions | Users accessing unauthorized resources | ACL audit, apply least privilege |
| Virus/malware infection | Performance impact, unusual behavior | Full system scan, process audit |
| Rogue processes/services | Unauthorized code running | Process list audit, netstat |
| DLP triggered | Legitimate transfer blocked | Review DLP policy, confirm data classification |
The Orphan/Zombie Process Problem
When a service is removed but its process persists, you are left with an orphan — and orphans and zombies are not the same thing:
| Orphan process | Zombie (defunct) process | |
|---|---|---|
| State | Still running | Already terminated |
| Parent | Died; the process is re-parented to init/systemd (PID 1) | Still alive but has not read the exit status ("reaped") |
| Resources | Holds real CPU, RAM, files, and sockets | Holds only a PID and a process-table entry — no CPU, no RAM |
| Security risk | Yes — it executes code and can hold open ports | Minimal; the risk is PID-table exhaustion if they pile up |
| Fix | Kill it | Kill or fix the parent; a zombie cannot be killed — it is already dead |
The security concern in this section is the orphan. An orphaned service process:
- Consumes resources while performing no legitimate work
- May represent a malware persistence mechanism
- Creates open ports and attack surfaces that aren't documented
Baseline comparison is critical — regularly compare running processes and listening ports against a known-good baseline to identify unauthorized additions.
⚠️ Exam Trap: SELinux/AppArmor denials can look like application failures — the application reports a permissions error, but standard file permissions appear correct. The real issue is the mandatory access control layer. Check /var/log/audit/audit.log for avc: denied messages. Running setenforce 0 (SELinux permissive mode) as a diagnostic test confirms SELinux is the cause if behavior changes.
Reflection Question: A Linux web server is returning "Permission denied" errors for a newly deployed application, despite the application files being owned by the web server user with correct permissions. What additional security mechanism might be causing this, and how would you diagnose it?
