Detection and Response
Turn host, identity, network, and application events into alerts a team can act on.
More logs do not automatically create better detection. Collect events that answer a question, keep enough context to investigate them, and route each alert to someone with authority to act.
Build useful telemetry
| Source | Events worth keeping | Questions it answers |
|---|---|---|
| Identity | Sign-ins, failures, MFA changes, privilege grants | Who accessed what, from where, and with which privilege? |
| Linux host | SSH, sudo, service, package, process, file-integrity events | What changed on the host? |
| Network | Flow logs, firewall decisions, DNS, load-balancer and proxy logs | Which systems communicated and what was blocked? |
| Application | Authentication, authorization, admin actions, errors | Which user or service initiated the action? |
| Cloud control plane | API calls, policy changes, key use, snapshot actions | Who changed infrastructure or security controls? |
Send security-relevant logs off the server quickly. Synchronize time, restrict log deletion, document retention, and avoid recording secrets, session tokens, full credentials, or unnecessary personal data.
Inspect one Linux host
These commands support triage, not a verdict. Compare results with deployment records, configuration management, expected operators, and the service baseline.
Write alerts as decisions
An actionable alert states:
- what changed and which detection produced the signal;
- affected account, host, service, and environment;
- first and last observed time, count, and relevant baseline;
- evidence links that do not expose secrets;
- likely impact and confidence;
- the first safe check, escalation owner, and containment option.
Examples of useful signals include a new public listener, interactive login by a service account, security logging disabled, a burst of failed logins followed by success, unexpected privilege escalation, or outbound traffic to a destination never used by the service.
Respond in a controlled order
Declare and assign
Name the incident lead, communications owner, operations lead, and evidence owner. Record decisions and times in one shared timeline.
Confirm scope
Identify affected identities, hosts, data, regions, and dependencies. Separate confirmed facts from working hypotheses.
Contain safely
Use the cloud or network control plane to isolate affected systems. Avoid powering off a host when volatile evidence may matter unless safety or ongoing damage requires it.
Remove access
From a known-clean system, revoke sessions, rotate exposed credentials, remove persistence, and close the initial access path.
Recover trust
Rebuild from approved artifacts, restore clean data, validate controls, and monitor the recovered service for recurrence.
Preserve evidence
Record who collected each artifact, when, from where, how its integrity was checked, and every transfer. Follow company policy and legal guidance for packet captures, disk snapshots, memory images, personal data, and communications. Do not run unreviewed cleanup commands that destroy timestamps or logs.
Improve after the incident
A useful review explains impact, timeline, contributing conditions, why safeguards did not prevent or detect the event sooner, and what will change. Give every action an owner, priority, due date, and verification method. Focus on system conditions and decision context rather than blame.