CompTIA CySA+ CS0-003 Study Guide: Incident Response and Management

Coverage: CySA+ domain 3.0 Incident Response and Management

This guide is the remediation map for the original local question bank. It follows the supplied CS0-003 objectives and courseware without reproducing exam or commercial practice questions.

Analyst Method

Establish what the artifact proves and what remains unknown.
Correlate host, network, identity, application, and time context.
Choose the action that best reduces risk while preserving evidence and process.
Prefer durable controls and measurable validation over point fixes.
Communicate confirmed facts, impact, ownership, and next decisions for the audience.

Objective Coverage

3.1: 13 questions
3.2: 24 questions
3.3: 12 questions

Domain Operational Playbook

Declaration, Authority, and Case Control

An incident begins operationally when defined declaration criteria and an authorized role activate the response process. Full scope is rarely known at declaration. The case should state the triggering evidence, current classification, incident commander or owner, affected business service, known safety or legal constraints, and the next decision deadline. Keep alert status separate from incident status: a validated malware event can justify declaration even when lateral movement has not been found. Conversely, one noisy detection should not trigger enterprise-wide breach language. Record who can isolate systems, revoke identities, contact providers, approve downtime, preserve privileged material, and communicate externally. That authority map prevents urgent actions from waiting on improvised approval and prevents analysts from making disclosures outside their role.

Use one case identifier across SIEM, EDR, identity, cloud, ticketing, and evidence systems. Each derived conclusion should link to the underlying artifact and analyst. Establish an update cadence at the start, because silence during uncertainty creates parallel investigations and inconsistent status. A good initial record says what is confirmed, what remains suspected, which criteria will resolve it, what containment is active, and when the next update will occur.

Alert Validation and Scope Expansion

Validation asks whether the event occurred, whether it violates the expected baseline, and whether malicious activity is the best supported explanation. Start with source health and raw fields, then inspect process lineage, identity session, device, request, destination, and action. Dual-use tools require context: encoded PowerShell becomes more significant with an unusual parent, sensitive user, persistence, and callback. Promote an entity to confirmed scope only when it meets written criteria. Maintain a scope matrix with rows for hosts, identities, applications, cloud resources, data sets, and indicators; columns can include evidence, confidence, first and last observed times, containment, and owner.

Expand through shared identifiers before broad similarity. A request ID, session ID, token, stable device ID, process hash, and exact destination are stronger joins than a common severity label or same-day timestamp. Search both directions: identify what the compromised entity accessed and which other entities touched the same infrastructure or credential. Record cleared entities and the evidence that cleared them so later shifts do not repeat work. When a pivot returns no data, distinguish no observed match from absent or expired telemetry.

Timeline Construction and Causal Sequence

Preserve source timestamps, time zones, collector receipt times, and measured offsets. Create a normalized comparison field but never overwrite the original evidence. For a clock known to be slow, add the measured offset; for uncertain drift, show a range or confidence note. SIEM ingestion time is useful for pipeline analysis but can be delayed by buffering, forwarding, or outage recovery. A defensible timeline records source, original time, normalized time, event, entity, evidence ID, and uncertainty.

Use the timeline to separate initial access, execution, persistence, privilege change, discovery, movement, collection, command and control, impact, detection, declaration, containment, and recovery. This sequence supports containment and root-cause work, but avoid forcing every observation into a framework phase. Correlation should preserve contradictory evidence until it is resolved. If two sources disagree, document why one is more authoritative or why the order remains uncertain.

Containment Decision Model

Containment reduces ongoing harm while preserving feasible evidence and business safety. Evaluate attacker access, destructive activity, data exposure, service criticality, patient or industrial safety, redundancy, and reversibility. A noncritical workstation with active command and control generally supports EDR network isolation that retains management access. A patient-care server under ransomware requires the incident commander to coordinate emergency isolation with continuity procedures. A volumetric attack that saturates the circuit needs upstream ISP or scrubbing action; origin firewall rules occur too late in the path.

Contain the identity and the device when both are active paths. Revoke sessions and refresh tokens rather than relying on a password reset. For exposed credentials, stop attacker access before rotating replacements that the attacker could read. Record the containment objective, approver, action, time, expected side effects, evidence preserved, and rollback or continuity state. Temporary blocks should have owners and expiry or conversion criteria so they do not become undocumented permanent architecture.

Eradication and Recovery Gates

Eradication removes the full foothold: payloads, web shells, tasks, services, extensions, accounts, tokens, keys, vulnerable entry points, and unsafe configuration. Deleting the first detected file or blocking one domain is not enough. Build an artifact checklist from the timeline and ATT&CK mapping, then validate each item across affected and similarly exposed systems. If trust cannot be re-established efficiently, rebuild from a controlled image after addressing credentials and dependencies.

Recovery is a gate, not simply a restore operation. Verify that the selected backup predates compromise and scans clean in a controlled environment. Confirm that the entry weakness and persistence are addressed, security controls and logging are operational, business owners accept restored function, and focused monitoring is ready. Reconnect in stages where possible. Watch for prior process chains, callbacks, privilege changes, anomalous authentication, and service errors. If a restored system resumes the same behavior, re-isolate and investigate the backup, build pipeline, credentials, and connected dependencies rather than restoring the same state again.

Digital Evidence and Forensic Triage

Collection priorities depend on volatility, legal scope, and time. Memory, live processes, connections, logged-in users, mounted resources, and temporary cloud state can disappear at shutdown or termination. Centralized logs and provider audit history may remain durable and can follow. Document why the selected order was appropriate. Use trusted acquisition tools, record versions and commands, hash digital evidence, assign identifiers, and preserve an untouched master with verified working copies. A hardware write blocker protects removable source media from writes, but source and image hashes are still needed to demonstrate integrity.

Chain of custody records identity, description, source, collector, UTC time, hash, storage, each transfer, purpose, and signatures or equivalent acknowledgment. Hashes prove content consistency, not who possessed the evidence. Legal holds suspend normal deletion for defined custodians, dates, systems, and search terms; they do not authorize indefinite collection of unrelated company data. Coordinate privileged material and disclosure obligations through counsel-approved channels while preserving factual observations required for response.

Cloud and SaaS investigations often rely on provider control-plane evidence rather than physical disk acquisition. Request scoped authentication, token, consent, mailbox action, message trace, storage access, administrative change, and API audit records. Preserve tenant, account, region, resource ID, query, export time, retention window, and provider integrity information. An endpoint mailbox export can preserve content but will miss provider-side rule creation, OAuth consent, token use, and historical actions.

Preparation, Exercises, and Improvement

Preparation should make the hard decisions visible before an emergency. Maintain declaration criteria, roles, alternate contacts, evidence procedures, provider escalation paths, communication templates, continuity dependencies, tool access, and known-good baselines. Tabletop exercises test decision-making and communication; technical simulations test telemetry, tooling, containment, and recovery. Record inject time, decision, authority, expected action, actual action, gap, owner, and due date. A successful meeting with no tested decisions is not sufficient evidence of readiness.

After an incident, distinguish the attack vector, artifacts, contributing conditions, detection gaps, and root cause. Five-whys or causal-tree analysis should reach an actionable enabling control such as missing ownership, unsafe provisioning, weak approval, or unsupported architecture. Convert findings into detections, configuration changes, training, playbook updates, and governance actions. Every improvement needs priority, owner, target date, dependency, escalation condition, and validation method. Close the loop by testing the control against the original behavior and monitoring recurrence, time to detect, affected scope, and response quality.

Response Quality Review Worksheet

Before closure, walk the case as if another team must defend every decision. Verify that the declaration trigger is preserved, roles and approvals are recorded, source health was checked, timestamps can be reconciled, and scope criteria explain every confirmed or suspected entity. Confirm that containment addressed each active path and that any business or safety tradeoff has an owner. Trace eradication from the initial-access weakness through credentials, persistence, tools, and related assets. Recovery evidence should show trusted backup or build state, functional and security validation, staged reconnection, and focused monitoring.

Review evidence handling separately: acquisition reason, collection order, tool and command, source, hash, custody, storage, legal scope, and provider limitations. Re-run decisive searches with recorded time ranges and fields so results are reproducible. Then compare the final causal chain with the actions. If the root cause is missing provisioning ownership, an action that blocks one hash does not address it. If the lesson is slow identity containment, the validation should exercise session and token revocation, not merely confirm password reset. Document residual unknowns and accepted risks at closure; closing the incident does not make unresolved uncertainty disappear.

Rehearse the hardest branch before calling the process mature. Give the team a destructive event on a safety-sensitive service, an identity token that reaches several cloud applications, a provider with short retention, and an executive request for a definitive impact statement before scope is complete. Observe whether responders declare under criteria, preserve volatile evidence, activate continuity, revoke the right credentials, request provider records, and communicate uncertainty through the approved matrix. Measure elapsed time between inject, recognition, decision, approval, and effective action. The exercise report should distinguish a knowledge gap from an authority, tooling, telemetry, staffing, or dependency gap, because each requires a different corrective action and validation test.

Build the closure packet before dispersing the response team. Include the final scope matrix, normalized timeline with original timestamps, decisive evidence index, containment and recovery approvals, credential and token actions, provider exports, custody records, customer or regulatory messages, unresolved risks, and links to corrective actions. Reconcile every affected entity across those records. The timeline should not show a host as recovered while the scope matrix still marks its persistence review pending, and the status report should not claim complete containment while an exposed token remains valid.

Assign retention and access according to legal, privacy, regulatory, and operational requirements. Preserve query definitions and exported results needed to reproduce conclusions after normal log retention expires. Record which evidence remains with a provider and any integrity or availability limitation. Finally, conduct a formal handoff from incident command to the owners of remediation, monitoring, legal follow-up, and risk acceptance. Incident closure ends emergency coordination; it does not transfer unfinished work into an ownerless archive.

Courseware objective context. Frameworks organize different analytic views. The Cyber Kill Chain describes broad progression, ATT&CK catalogs goals and behaviors, the Diamond Model relates adversary, infrastructure, capability, and victim, and testing methodologies structure authorized assessment. Map observations after preserving the underlying evidence. Framework labels help compare cases and coverage, but technique overlap alone does not prove sequence or actor attribution.

Attack methodology frameworks

Definition and purpose. Kill chain, Diamond Model, MITRE ATT&CK, OSSTMM, and the OWASP Testing Guide organize different aspects of adversary behavior and testing; none is a substitute for evidence.

Analyst workflow. Preserve observations, then map the analytic view needed: phase progression, detailed behavior, intrusion relationships, or test methodology. Record confidence and unmapped evidence.

Worked artifact or example. certutil decoding plus a Run-key change can map to ATT&CK techniques without replacing process, command, registry, user, and time evidence in the case.

Commands, filters, or calculations. Use ATT&CK Navigator for behavior coverage, a Diamond Model record for adversary-infrastructure-capability-victim relationships, and the selected testing guide for authorized procedures.

Common traps. ATT&CK is not a strict one-pass lifecycle. Technique overlap does not prove a named group, and a framework label cannot replace timeline or scope analysis.

Question-bank coverage: 13 items.

3.2 Given a scenario, perform incident response activities.

Courseware objective context. Incident response moves from alert validation to scope, containment, eradication, recovery, and evidence preservation, with business coordination throughout. The correct order depends on active harm, volatility, safety, and service impact. Keep confirmed, suspected, and cleared entities separate; preserve identifiers and normalized time; and validate that the cause and persistence are addressed before reconnecting systems or closing identities.

Detection and analysis

Definition and purpose. Validate the alert, establish a timeline, identify affected assets and accounts, determine scope, and preserve volatile evidence before drawing conclusions.

Analyst workflow. Validate the alert and source health, normalize time, identify process, identity, device, request, and session pivots, then maintain confirmed, suspected, and cleared scope with evidence criteria.

Worked artifact or example. Proxy request_id=9f2, EDR source 10.20.8.44, and IdP session_id=s-771 become one supported sequence through shared user, device, request, and session identifiers.

Commands, filters, or calculations. Build a timeline table containing original and normalized time, source, entity, action, evidence ID, and confidence. Query adjacent accounts, hosts, destinations, tokens, and application actions.

Common traps. Same-day events and common severity labels are weak joins. Containment is not scope completion, and suspicious identity alerts should not be promoted to confirmed compromise from timing alone.

Question-bank coverage: 5 items.

Containment, eradication, and recovery

Definition and purpose. Contain according to business impact, remove cause and persistence, restore from trusted state, monitor closely, and document validation before normal operations resume.

Analyst workflow. Choose containment proportional to active harm and business safety, preserve feasible evidence, remove access and persistence, fix the entry weakness, restore trusted state, and monitor prior TTPs.

Worked artifact or example. For an abused administrator session from one endpoint, revoke the account's sessions and isolate the endpoint. A password reset alone can leave tokens active.

Commands, filters, or calculations. Use EDR isolation, IdP token revocation, upstream DDoS controls, network segmentation, credential dependency maps, trusted backups, rescans, and focused recovery-window detections.

Common traps. Blocking one domain, deleting one file, or restoring the newest backup is incomplete. Emergency actions must account for patient care, industrial safety, and approved continuity procedures.

Question-bank coverage: 12 items.

Forensics and evidence handling

Definition and purpose. Collect in order of volatility when appropriate, hash and label evidence, maintain chain of custody, coordinate legal process, and analyze copies rather than originals.

Analyst workflow. Set legal and case scope, collect according to volatility and provider constraints, hash and label evidence, record every transfer, preserve a master, and analyze verified working copies.

Worked artifact or example. A complete custody entry includes evidence ID, description, collector, UTC time, source location, hash, transfer parties, purpose, storage, and signatures.

Commands, filters, or calculations. Capture memory and live connections before shutdown when authorized; use a hardware write blocker for removable media; calculate SHA-256 hashes; request provider audit, token, mailbox, and trace records for SaaS.

Common traps. A write blocker does not guarantee completeness, and a hash does not replace custody. Endpoint mailbox exports miss provider-side rules and tokens; durable cloud logs can be collected after more volatile instance state.

Question-bank coverage: 7 items.

3.3 Explain the preparation and post-incident activity phases of the incident management life cycle.

Courseware objective context. Preparation establishes plans, authorities, communication paths, evidence capability, exercises, and known-good baselines before an incident. Post-incident work converts evidence into durable change through root-cause analysis, new detections, updated playbooks, assigned actions, and validation. A lessons-learned meeting is incomplete until owners and due dates are tracked and the resulting control change is tested.

Preparation and post-incident improvement

Definition and purpose. Plans, roles, communications, tools, exercises, and baselines enable response. Lessons learned, root-cause work, IoC creation, and control updates reduce recurrence.

Analyst workflow. Define roles, declaration criteria, authority, contacts, tools, evidence access, exercises, and baselines before incidents; afterward, run causal analysis and track validated improvements to closure.

Worked artifact or example. A five-whys chain from public service to missing inventory ownership identifies a systemic root cause. The exploit remains the attack mechanism, not the process cause.

Commands, filters, or calculations. Use tabletop injects with decisions and timestamps, after-action records, root-cause trees, ATT&CK coverage, detection tests, action owners, due dates, dependencies, and validation evidence.

Common traps. A meeting or longer report is not improvement. Do not name malware, a scheduled task, or a missed alert as root cause when an upstream ownership or provisioning control enabled entry.