Security, Compliance, and Troubleshooting
What this section covers
Security content centers on the CIA triad (confidentiality, integrity, availability) and on separating authentication (who you are) from authorization (what you may do). Know least privilege, role-based access, MFA, segregation of duties, encryption in transit and at rest, and key management - the key is the asset, so protecting ciphertext without protecting the key is meaningless. Compliance adds data classification, retention, audit trails, and evidence collection: controls must be demonstrable, not merely intended. Troubleshooting follows a disciplined loop: identify and scope the problem, isolate it to a layer or component, form a hypothesis, test it with the least intrusive change, verify the fix, and document. Tools include the OSI-style bottom-up/top-down walk, recent-change review, log correlation, and 5 Whys for root cause versus symptom.
Traps
- "Disable the security control to test" - almost never the right answer.
- Fixing the symptom while the question asks for root cause (or vice versa).
- Confusing authentication with authorization failure codes and messages.
- Making an unapproved change in production during an incident; escalate and communicate first.
- Assuming encryption at rest protects data in use or that hashing is reversible (it is not).
Worked example
Users report intermittent failures; a change was deployed an hour ago. Order: confirm scope (all users or one region?), check recent changes, inspect metrics/logs for the failing component, verify connectivity and credentials at the failing boundary, then act. Rule of thumb: scope → correlate with change → isolate layer → smallest test → verify → document.