Security engineering and incident response

Prerequisites: Threat modeling, sessions, and software delivery.

Learning objectives

• Prioritize vulnerabilities using exposure and impact.
• Design useful security telemetry.
• Separate containment, eradication, and recovery.

Security work continues after release

A secure development process translates threats into requirements, reviews sensitive changes, tests failure paths, manages dependencies, and prepares for incidents. A scanner finding is evidence to investigate, not a complete risk model. Severity depends on exploitability, exposure, affected authority, and the consequences in the deployed context.

Track dependencies and build inputs so an advisory can be connected to the actual artifact in use. A package listed somewhere in a repository may not be reachable in production; a transitive dependency omitted from an informal inventory may be. Reproducible build records and deployment provenance reduce this uncertainty.

Work a stolen-session incident

Suppose logs show a valid session downloading many private notes from an unusual client. The immediate question is not whether the password is correct. The session may have been stolen. Containment can revoke the affected session or account sessions, limit further exports, and preserve relevant evidence. Do not destroy the only logs while trying to clean up.

Investigation determines how the credential was obtained, what authority it had, which records were accessed, and whether other accounts are affected. Eradication removes the root cause, such as an exposed token or an injection vulnerability. Recovery restores normal service with replacement credentials and monitoring for recurrence. These phases can overlap, but they answer different questions.

Telemetry must serve a decision

Record events such as session creation, revocation, permission changes, administrative actions, and unusual export activity. Include stable event identifiers, timestamps, outcomes, and enough context to correlate events. Avoid storing passwords, raw session tokens, or unnecessary private content in logs. A log that leaks credentials creates another attack surface.

Define retention, access, integrity protection, and time synchronization. A timestamp from one machine is not perfect proof of global event order. Where ordering matters, include request or transaction identifiers and understand clock uncertainty.

Recovery is something to rehearse

Backups are useful only if restoration is tested. Specify recovery point and recovery time objectives, then perform a drill that demonstrates what data can be restored and how long it takes. A backup encrypted with a lost key is not recoverable; a backup reachable with compromised production credentials may be destroyed alongside the primary data.

After an incident, document the timeline, contributing conditions, effective defenses, and changes with owners. Avoid reducing a complex failure to one person's mistake. The purpose is to improve the system's ability to prevent, detect, limit, and recover from the next failure. Exercises should use isolated environments and synthetic data so learning does not create new victims.

Practice problem

Create a short response plan for an accidentally published API credential. Include immediate containment, investigation evidence, recovery, and one preventive change. Explain why deleting the public file alone is insufficient.

Worked solution

Revoke or disable the exposed credential immediately and issue a replacement through the approved secret-distribution path. Preserve the publication timeline and relevant access logs, determine the credential’s permissions, inspect its use, and assess affected data or operations. Restore dependent services with the new credential and verify that the old one fails. Remove the public copy, but assume it may already have been copied or cached. Add a preventive control such as scoped short-lived credentials and a secret check in the delivery process. Review whether the original credential had more authority than needed.

Check your understanding

Why is deleting a leaked secret insufficient?

• Deleted text is always restored automatically.
• An attacker may already possess a copy that remains valid.
• It prevents key rotation.
• Logs cannot record credential use.

Explanation

Revocation or expiration must remove the leaked credential’s authority.

What demonstrates that backups support recovery?

• A successful backup job alone.
• A large storage bill.
• A documented and tested restoration meeting the required objectives.
• Keeping backups in the same writable directory.

Explanation

Recovery requires usable data, keys, procedures, and demonstrated restoration.

Primary reading

• Computer Security textbook: UC Berkeley CS 161

Open the study and save your work →