Lesson 5: Security Incident Practical

Security support is where a careless fix can make the incident worse.

Your job is to protect people, data, and evidence while applying the smallest approved response.

The practical uses one rule throughout:

A security incident is not finished when the scary symptom disappears. It is finished when the affected boundary is contained or corrected, required service is restored, recovery is protected, and the remaining risk is documented.

Incident A: suspicious browser and unexpected MFA prompt

Evidence:

browser redirects began after unknown extension install
redirects occur only in one browser profile
endpoint protection: current
user separately received unexpected MFA prompt
user did not approve prompt

Do not combine these observations into one story yet.

They may be related.

They may not.

Build two parallel investigations:

Browser path

• preserve extension/profile evidence;
• remove the unapproved extension through the approved procedure;
• update and scan with the approved defensive tooling;
• verify browser behavior;
• widen the scope only if additional system evidence appears.

Identity path

• report and review the unexpected authentication prompt;
• verify account activity through the approved identity process;
• revoke or reset sessions/credentials only when evidence or policy requires it;
• verify legitimate sign-in afterward.

A good incident record does not invent a causal link because two suspicious things happened on the same day.

Incident B: end-of-life BYOD endpoint

Evidence:

device ownership: personal
organization email: accessible
OS: end-of-life
security updates: unavailable
required management profile: missing

The device still works.

That does not make it compliant or supportable.

This is a vulnerability and policy problem, not evidence of malware.

A defensible response may require:

• removing or restricting organizational access;
• bringing the device into an approved managed state if supported;
• requiring a supported replacement;
• documenting the compliance decision.

Do not pretend the endpoint is acceptable because email still opens.

Incident C: SOHO edge exposed

Evidence:

router admin credential: default
firmware: outdated
remote management: publicly reachable
guest wireless: can reach trusted devices
unnecessary port forward: active

This is not one problem.

It is several independent exposure boundaries.

Prioritize:

1. secure administrator access;
2. supported firmware;
3. remove unnecessary public management;
4. restore guest separation;
5. remove the unnecessary forwarding rule;
6. verify required user services still work.

Do not change every setting at once if the lab asks you to prove which correction affected which exposure.

Incident D: malware-removal workflow

Evidence:

supplied symptoms: consistent with possible malware
quarantine: authorized
approved anti-malware tool: available
required data backup: verified

Put the response into the correct A+ SOHO sequence:

investigate and verify symptoms
        ↓
quarantine affected system
        ↓
System Restore handling where required by approved workflow
        ↓
remediate infected system
        ↓
update anti-malware
        ↓
scan and remove in normal/safe/recovery environment as appropriate
        ↓
reimage or reinstall if trustworthy remediation cannot be established
        ↓
schedule scans and run updates
        ↓
re-enable System Restore / create clean restore point where applicable
        ↓
educate user and document

The sequence matters because containment, trust, recovery, and verification are different jobs.

Incident E: familiar login page with certificate warning

Evidence:

page: visually familiar
link source: QR code in unexpected message
certificate: trust/name warning
user: has not entered credentials

Do not bypass the warning.

Do not enter test credentials.

Use the known legitimate service path independently and report the suspicious artifact.

The user has not yet crossed the credential boundary. Keep it that way.

Incident F: failed drive retirement

Evidence:

media: failed magnetic HDD
sensitive records: present
software wiping: unreliable
approved destruction vendor: available

Choose an approved high-assurance destruction path appropriate to magnetic media.

Your record should include:

• asset identity;
• chain of custody;
• authorized vendor;
• destruction method;
• certificate of destruction or required recycling record.

The drive being physically broken is not the only evidence the organization may need.

Incident G: possible insider data movement

Evidence:

user: valid authenticated employee
folder access: authorized
data movement: large confidential export to unapproved destination
DLP alert: supplied

Authentication succeeded.

Authorization to read the source may also be valid.

The suspicious boundary is data movement and policy.

Do not respond by changing the user's password as if the identity were necessarily stolen.

Preserve the DLP and access evidence and escalate according to the approved process.

Incident H: browser download matches vendor hash but source is unapproved

Evidence:

downloaded file: hash matches value published on same unapproved mirror
official vendor source: not used

What did the hash prove?

Only that the file matches the expected value you compared it against.

It did not prove the mirror or expected value is trustworthy.

Integrity without trusted provenance is incomplete.

Use the approved vendor or repository path.

Incident I: ransomware-like symptoms on one endpoint

Evidence:

files: inaccessible
ransom note: present
shared resources: potentially reachable
backup status: known through supplied evidence

Your immediate job is not to identify the exact ransomware family.

It is to protect the environment:

• contain according to policy;
• protect shared resources;
• preserve evidence and backup state;
• escalate;
• avoid curiosity-driven interaction.

Precise malware naming comes later, if it matters to the incident owner.

Incident J: public service unavailable during traffic spike

Evidence:

service: unavailable
traffic: extremely high
provider/network evidence: supplied
malware evidence: none

A DoS or DDoS condition may be plausible.

It is not proven simply because traffic is high and the site is down.

A legitimate usage spike, application failure, or upstream problem may create overlapping symptoms.

Record scope and escalate to the service/network/security owner rather than claiming an attack from one graph.

Build four complete incident records

Choose four incidents from different families and document:

asset
observed indicators
threat / vulnerability category
non-malicious alternative where plausible
what is NOT proven
scope currently supported by evidence
immediate containment / control
remediation / hardening / destruction action
data and evidence preservation
recovery dependency
verification of required function or secure state
user guidance
escalation / documentation
remaining risk

Security-domain checkpoint

Weeks 13 and 14 now connect:

physical + logical controls
→ Windows permissions / identity / encryption
→ wireless + workstation / mobile hardening
→ social engineering + threat recognition
→ malware types + defensive tooling + removal
→ SOHO + browser security
→ data destruction
→ containment + recovery + verification

The common skill is not paranoia.

It is disciplined trust.

Ask what the evidence proves, protect the boundary that matters, and avoid making the incident larger while trying to fix it.

Next we close the troubleshooting domain with Windows, mobile, and security symptoms that deliberately overlap.