AD6.1 Why You Need Response Procedures

The cost of improvisation

Research on incident response consistently shows that organizations with pre-written response procedures contain incidents 50-70% faster than those without. The reason isn't that the procedure is technically superior to what an experienced responder would do ad-hoc — it's that the procedure eliminates decision paralysis, ensures nothing is missed, and provides a consistent sequence regardless of who executes it, when it happens, or how stressful the situation is.

Consider the practical difference. Without a procedure, your internal dialogue during a confirmed compromise sounds like: "OK, I need to... should I reset the password first? Wait, if I reset the password, the attacker loses access but so does the user — should I warn them first? Actually, I should revoke the sessions first because the attacker might have an active session. But what if revoking sessions doesn't work because they have a refresh token? And I should check whether they've added MFA methods before I reset the password, otherwise the attacker just re-registers MFA after the reset..."

With a procedure, your internal dialogue is: "Step 1: Revoke all sessions. Step 2: Reset password. Step 3: Review and remove attacker-registered MFA methods. Step 4: Check inbox rules. Step 5: Document." You execute the steps in sequence. Each step takes 1-2 minutes. The entire procedure takes 10-15 minutes. No paralysis, no missed steps, no wondering what comes next.

The sequence matters

The order of steps in a response procedure is deliberate. Consider the compromised account procedure:

Why revoke sessions BEFORE resetting the password: The attacker's active session uses a token that's valid even after a password change. Resetting the password prevents NEW sign-ins but doesn't terminate EXISTING sessions. Revoking sessions first terminates the attacker's current access. Then the password reset prevents them from signing back in.

Why check MFA methods AFTER revoking sessions and resetting the password: If you check MFA methods first, the attacker is still active in the mailbox. If you reset the password before checking MFA, the attacker might see the password reset notification and quickly register a new MFA method on their device. By revoking sessions first (kicking them out) and resetting the password second (preventing re-entry), you have a window to safely review MFA methods without the attacker interfering.

Why check inbox rules AFTER securing the account: Inbox rules are persistence — they continue operating even after the attacker loses access. A forwarding rule created yesterday continues forwarding emails today, tomorrow, and every day until someone removes it. Securing the account (steps 1-3) stops the attacker from creating new persistence. Checking inbox rules (step 4) removes existing persistence.

This sequence wasn't invented theoretically — it was developed through hundreds of real incident responses and refined based on what goes wrong when steps are out of order.

What this module covers

AD6.2 provides the complete compromised account procedure — the 5-step response you execute when the sign-in log confirms a credential compromise. AD6.3 provides the phishing click response — what to do when a user reports clicking a suspicious link or Safe Links shows a click on a confirmed phishing URL. AD6.4 provides the BEC response — the specific additional steps needed when the attacker is using the compromised mailbox for financial fraud.

AD6.5 covers evidence preservation — what to capture before you take containment actions, so the evidence isn't destroyed by the response. AD6.6 covers managed SOC coordination — how to work with an external security team during an active incident. AD6.7 addresses the after-hours decision — what to do when an incident happens outside business hours. AD6.8 covers Microsoft's automatic attack disruption — the system that may contain the attacker before you even know there's an incident. AD6.9 covers documentation — what to record during and after the incident for management reporting and compliance. AD6.10 covers the post-incident review — learning from each incident to improve your procedures and controls.

Each procedure is designed for an IT administrator, not a SOC analyst. The tools are the same ones you've used throughout the course: Entra ID, Exchange Online PowerShell, and the Defender portal. No forensic tools, no KQL, no SIEM — just the Microsoft admin portals with step-by-step instructions.

Pre-incident preparation — do this TODAY

Don't wait for an incident to prepare your response capability. Complete these items now:

1. Test PowerShell connectivity. Run each of these commands and verify they connect without errors:

Connect-MgGraph -Scopes "User.ReadWrite.All","AuditLog.Read.All"
Connect-ExchangeOnline
Connect-IPPSSession

If any command fails, resolve the authentication or module installation issue now. During a real incident, you need these to work first time.

2. Create the scripts directory. Create C:\SecurityScripts\ and save these scripts (you'll build them throughout this module): Preserve-Evidence.ps1, Respond-CompromisedAccount.ps1, Respond-PhishingClick.ps1, BEC-Response-Checklist.md, IncidentReportTemplate.md.

3. Test on a test account. Create a test user (testuser@yourdomain.com). Execute the compromised account procedure against it: revoke sessions, reset password, check MFA methods, check inbox rules. Verify each command works. Delete the test user after testing.

4. Print the procedures. After completing this module, print the three response procedures (AD6.2, AD6.3, AD6.4) and the escalation contact sheet (AD5.10). Pin them next to your monitor. During an incident, you follow the printed checklist — you don't search for a document.

5. Communicate with your manager. "I've built incident response procedures for credential compromise, phishing, and BEC. If I execute these procedures during an incident, it may involve resetting user passwords and temporarily disabling accounts — I'll notify you immediately after containment." This pre-communication prevents surprise when you take containment actions that affect users.

Realistic incident frequency

How often will you actually use these procedures? Based on industry data and the typical M365 E3 environment:

Compromised accounts: 2-5 per year for a 200-user organization. Most are commodity AiTM phishing — automated campaigns that target thousands of organizations simultaneously. Your controls (MFA, CA policies) block most attempts. The ones that get through are what these procedures handle.

Phishing clicks: 5-15 per year that reach your attention (user reports + Safe Links alerts). The majority are blocked by Safe Links — the user clicked but didn't reach the phishing page. 1-3 per year may result in a user actually reaching the phishing page, which triggers the credential compromise assessment.

BEC incidents: 1-3 per year if credential compromises are detected early. BEC is a CONSEQUENCE of credential compromise — the attacker gets in, reads financial emails, and prepares fraud. If you contain compromised accounts quickly (same day via the Monday review), BEC has less opportunity to develop. If compromises go undetected for days, BEC risk increases significantly.

These numbers mean you'll use the AD6.2 procedure 2-5 times per year, the AD6.3 procedure 5-15 times per year (mostly the "blocked" path), and the AD6.4 BEC extension 1-3 times per year. Infrequent enough that you need printed procedures (you won't remember the steps from memory), but frequent enough that the investment in building and practising the procedures is justified.

Response time targets

Set realistic response time expectations:

These targets are achievable for a solo IT administrator: the Monday review catches most incidents within 7 days. Alert notifications catch high-severity events within hours. The response procedures execute in 15-20 minutes once initiated. Document these targets for your manager — they set expectations and provide accountability.