security-incident-response
When to use: active or suspected Salesforce org compromise, unauthorized access investigation, attacker containment, forensic evidence collection from EventLogFile/LoginHistory, session revocation, OAuth token cleanup, eradication of attacker persistence, and post-incident recovery verification. Trigger keywords: org compromised, suspicious login, attacker access, session revocation, forensic investigation, breach response, event log forensics, login anomaly investigation, incident response runbook. Does NOT cover general security setup, permission set design, field-level security configuration, or proactive security hardening — those are separate skills. NOT for general security setup.
Best use case
security-incident-response is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
When to use: active or suspected Salesforce org compromise, unauthorized access investigation, attacker containment, forensic evidence collection from EventLogFile/LoginHistory, session revocation, OAuth token cleanup, eradication of attacker persistence, and post-incident recovery verification. Trigger keywords: org compromised, suspicious login, attacker access, session revocation, forensic investigation, breach response, event log forensics, login anomaly investigation, incident response runbook. Does NOT cover general security setup, permission set design, field-level security configuration, or proactive security hardening — those are separate skills. NOT for general security setup.
Teams using security-incident-response should expect a more consistent output, faster repeated execution, less prompt rewriting, better workflow continuity with your supporting tools.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
- You already have the supporting tools or dependencies needed by this skill.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/security-incident-response/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How security-incident-response Compares
| Feature / Agent | security-incident-response | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
When to use: active or suspected Salesforce org compromise, unauthorized access investigation, attacker containment, forensic evidence collection from EventLogFile/LoginHistory, session revocation, OAuth token cleanup, eradication of attacker persistence, and post-incident recovery verification. Trigger keywords: org compromised, suspicious login, attacker access, session revocation, forensic investigation, breach response, event log forensics, login anomaly investigation, incident response runbook. Does NOT cover general security setup, permission set design, field-level security configuration, or proactive security hardening — those are separate skills. NOT for general security setup.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Security Incident Response — Salesforce
## Overview
This skill covers the complete lifecycle of responding to a suspected or confirmed Salesforce security incident: preserving forensic evidence, containing the attacker, eradicating persistence mechanisms, recovering to a known-good state, and verifying the attacker has been fully removed.
Salesforce incident response differs from traditional IR because evidence lives in platform objects (EventLogFile, LoginHistory, SetupAuditTrail, AuthSession), containment requires both UI and API actions, and evidence retention windows are critically short in free-tier orgs (1-day EventLogFile retention vs. 30-day with Event Monitoring add-on / Shield).
The cardinal rule: **preserve evidence before containment**. In free-tier orgs, beginning containment first risks permanently destroying EventLogFile records before they can be downloaded.
## Key Platform Concepts
### Forensic Evidence Sources
| Source | Retention | License | What It Shows |
|---|---|---|---|
| EventLogFile | 1 day (free) / 30 days (add-on/Shield) | Free tier: 5 event types only | API usage, report exports, logins, data exports, SOQL queries (ApiTotalUsage) |
| LoginHistory | 6 months | Free | Login IP, geolocation, MFA used, login type, browser/client |
| SetupAuditTrail | 180 days | Free | Setup-UI config changes (not Metadata API deploys) |
| AuthSession | Live only | Free | Active sessions — query and DELETE to revoke |
| LoginAnomaly (RTEM) | Real-time | Shield required | ML-scored suspicious login events |
### Event Monitoring Tiers
- **Free tier**: 5 event types (Login, Logout, URI, API, LightningPageView), **1-day retention** — nearly useless for incidents discovered >24 hours after the attack.
- **Event Monitoring add-on**: 70+ event types, **30-day retention** — includes ReportExport, DataExport, ApiTotalUsage, MetadataApiOperation.
- **Shield**: Includes Event Monitoring add-on plus Real-Time Event Monitoring (RTEM) with LoginAnomaly, PermissionSetAssignment, ApiAnomalyEventStore.
### Transaction Security Policy Enforcement Actions
Policies can enforce one of four actions when a matching platform event fires:
| Action | Effect |
|---|---|
| Block | Prevents the operation from completing |
| Two-Factor Authentication (MFA challenge) | Requires step-up auth |
| Notification | Emails the org admin; no blocking |
| End Session | Terminates the user's current session |
Policy configuration: Enhanced Condition Builder (no-code, available Spring '21+) or legacy Apex `PolicyCondition` class. Policies only apply to events fired **after** activation — they are not retroactive.
### Session Revocation
Freezing a user in Setup does not revoke active sessions or OAuth tokens. Full containment requires:
1. Freeze user (blocks new logins) — Setup > Users > Freeze
2. Delete active `AuthSession` records via REST API or Setup > Session Management
3. Revoke OAuth tokens — Setup > Connected Apps > OAuth Usage > Revoke All (per user), or DELETE `AuthToken` records via API
### LoginAnomaly vs. LoginHistory
- **LoginHistory**: free, 6-month retention, shows every login with IP/country/MFA/login type — requires manual analysis to detect anomalies.
- **LoginAnomaly** (Real-Time Event Monitoring): Shield-only, ML-scored events with risk `Score` field — automated detection, but requires a Transaction Security Policy with Notification/Block action to generate admin alerts. The two are **not interchangeable**.
## Recommended Workflow
1. **Scope and license check** — Identify the org's Event Monitoring tier (free / add-on / Shield). Query `EventLogFile` to determine which event types are available and how far back logs exist. If the org is free-tier and the incident window is >24 hours old, assess whether EventLogFile evidence has already expired.
2. **Preserve forensic evidence (before any containment)** — Download all EventLogFile CSVs covering the attack window via REST API. Query and export LoginHistory, SetupAuditTrail, and AuthSession for the affected users. If Shield is active, query LoginAnomaly and ApiAnomalyEventStore. Save all exports externally before proceeding.
3. **Assess blast radius** — Analyze EventLogFile (ReportExport, DataExport, ApiTotalUsage event types) to determine what records were accessed or exported. Check SetupAuditTrail for configuration changes (permission set assignments, connected app creation, profile edits). Cross-reference MetadataApiOperation events for API-based deploys.
4. **Contain the attacker** — Execute in sequence: (a) freeze compromised user accounts; (b) delete active AuthSession records via REST API or Setup > Session Management; (c) revoke OAuth tokens for connected apps used by the attacker; (d) activate or tighten Transaction Security Policies to block ongoing attack vectors (e.g., Block on ReportExport or API usage above threshold).
5. **Eradicate persistence** — Audit and remove: unauthorized connected apps, suspicious Apex classes/triggers installed during the window, anomalous named credentials, newly created admin/privileged users, and any permission set or profile changes that were not authorized. Restore modified Flow metadata to pre-incident versions.
6. **Recover and verify** — Reset credentials for all affected accounts, rotate Named Credential secrets and OAuth client secrets for any compromised integrations, and verify data integrity for records that may have been modified. Confirm the attacker no longer has any access path by re-querying AuthSession and LoginHistory.
7. **Harden for the future** — Configure a Transaction Security Policy for LoginAnomaly (if Shield is licensed) with a Notification action. Implement automated daily EventLogFile export to an external store for ongoing retention beyond the platform default. Document the incident timeline, blast radius, and remediation steps for post-incident review.
## SOQL Reference Queries
### LoginHistory — suspicious logins for a user in a time window
```soql
SELECT Id, UserId, LoginTime, SourceIp, LoginGeo.Country, LoginType,
AuthenticationServiceId, Status, Browser, Platform, IsMFAEnabled
FROM LoginHistory
WHERE UserId = '005XXXXXXXXXXXXXXX'
AND LoginTime >= 2026-01-01T00:00:00Z
AND LoginTime <= 2026-01-10T23:59:59Z
ORDER BY LoginTime DESC
```
### SetupAuditTrail — config changes in attack window
```soql
SELECT Id, Action, Section, Display, CreatedDate, CreatedBy.Username
FROM SetupAuditTrail
WHERE CreatedDate >= 2026-01-01T00:00:00Z
ORDER BY CreatedDate DESC
LIMIT 200
```
### Active sessions for a user
```soql
SELECT Id, UsersId, LoginTime, LastActivityDate, SessionType, SourceIp
FROM AuthSession
WHERE UsersId = '005XXXXXXXXXXXXXXX'
```
### EventLogFile — available event types and dates
```soql
SELECT Id, EventType, LogDate, LogFileLength, LogFileContentType
FROM EventLogFile
WHERE LogDate >= 2026-01-01T00:00:00Z
ORDER BY LogDate DESC
```
### Recently modified Apex classes (detect metadata changes)
```soql
SELECT Id, Name, LastModifiedDate, LastModifiedBy.Username
FROM ApexClass
WHERE LastModifiedDate >= 2026-01-01T00:00:00Z
ORDER BY LastModifiedDate DESC
```
## Official Sources Used
- Salesforce Security Guide — https://help.salesforce.com/s/articleView?id=sf.security_overview.htm&type=5
- Salesforce Help: Event Monitoring — https://help.salesforce.com/s/articleView?id=sf.bi_setup_enable_event_monitoring.htm&type=5
- Salesforce Help: Transaction Security Policies — https://help.salesforce.com/s/articleView?id=sf.transaction_security_overview.htm&type=5
- Salesforce Help: Real-Time Event Monitoring — https://help.salesforce.com/s/articleView?id=sf.real_time_em_overview.htm&type=5
- Salesforce Help: Login Anomaly Detection — https://help.salesforce.com/s/articleView?id=sf.real_time_em_threat_detection_login_anomaly.htm&type=5
- Salesforce Object Reference: AuthSession — https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_authsession.htm
- Salesforce Object Reference: SetupAuditTrail — https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_setupaudittrail.htm
- Salesforce Architects: A Primer on Forensic Investigation of Salesforce Security Incidents — https://www.salesforce.com/blog/forensic-investigation-salesforce-security-incidents/
- Salesforce Well-Architected Overview — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.htmlRelated Skills
visualforce-security-and-modernization
Use when hardening or modernizing legacy Visualforce pages — covers the platform CSRF token model and when disabling it is a security regression, view state encryption guarantees and the 170 KB ceiling, FLS/CRUD enforcement gaps on `<apex:outputField>` and on getters that return sObjects, `<apex:includeScript>` interaction with the org Content Security Policy, hosting LWC inside a VF page via `lightning:container` / `lightning-out`, and the retire-vs-harden-vs-leave-alone decision for an inventory of legacy pages. Triggers: 'should I rewrite this Visualforce page in LWC', 'CSRF protection disabled on Visualforce page is that safe', 'community user sees a field they should not on a Visualforce page', 'view state encryption is that enough for sensitive data', 'how do I host an LWC inside a Visualforce page', 'apex:dynamicComponent and apex:actionFunction safe to keep'. NOT for greenfield Visualforce architecture (use apex/visualforce-fundamentals — controller types, view state pattern selection, PDF rendering); NOT for Visualforce email template authoring (use apex/visualforce-email-templates if/when that skill is authored); NOT for general Apex security review across triggers and async (use apex/soql-security and security/secure-coding-review-checklist).
transaction-security-policies
Transaction Security policy creation and configuration: condition builder, enhanced policies, enforcement actions (block, MFA, notification, end session), real-time monitoring mode, and policy troubleshooting. NOT for Event Monitoring log analysis or Shield Event Monitoring setup (use event-monitoring). NOT for Apex testing or debug-log analysis.
security-health-check
Use when running, interpreting, or acting on Salesforce Security Health Check results — reading the score, understanding risk categories, evaluating specific settings, creating or importing a custom baseline, querying the Tooling API programmatically, or planning remediation from findings. Triggers: 'security health check score', 'health check failing settings', 'custom baseline', 'remediate health check findings', 'fix risk'. NOT for org hardening implementation, permission model design, or broad baseline config beyond what Health Check directly measures.
network-security-and-trusted-ips
Configure and audit Salesforce network security controls — trusted IP ranges (org-wide Network Access), login IP ranges on profiles, CSP Trusted Sites for Lightning components, CORS allowlists for external JavaScript, and TLS requirements — and troubleshoot login-blocked-by-IP or CSP violation errors. NOT for org-wide session settings, MFA configuration, or real-time Transaction Security Policies.
guest-user-security
Use when hardening the Experience Cloud guest user profile, controlling unauthenticated access to records and Apex, or investigating data exposure through guest SOQL. Covers object permissions, sharing model enforcement for unauthenticated users, and Apex execution context. NOT for Experience Cloud site creation (use Experience Cloud skills) or for authenticated external user security (use security/experience-cloud-security).
guest-user-security-audit
Auditing the security posture of an Experience Cloud (Community) site's Guest User. Covers the post-Spring '21 secure-by-default lockdown (object permissions removed, sharing rule grants required for any access), the Guest User profile permissions to remove (View All Data, Modify All Data, Manage Users, etc.), guest sharing rules, the Run-As-Guest test, OWASP A01 (Broken Access Control) mapping, and the standard set of leakage vectors (Apex with `without sharing`, Aura / LWC `@AuraEnabled` methods, public-site Visualforce, REST endpoints under `/services/apexrest`). NOT for Experience Cloud authenticated user setup (see experience/experience-cloud-user-management), NOT for general Salesforce profile design (see admin/profile-permset-design).
experience-cloud-security
Use when configuring access controls, sharing, or site security for authenticated or guest Experience Cloud (community) users: external OWD, Sharing Sets, Share Groups, CSP, clickjack protection, guest user record access. NOT for internal sharing model configuration (use sharing-and-visibility).
connected-app-security-policies
Managing OAuth policies, IP relaxation, session security, PKCE, and credential rotation for Salesforce Connected Apps. Use when hardening Connected App security, rotating client secrets, configuring IP restrictions, or requiring high-assurance sessions. NOT for basic Connected App setup or creation. NOT for OAuth flow implementation (use oauth-flows-and-connected-apps).
api-security-and-rate-limiting
Use when configuring, auditing, or troubleshooting API rate limits, Connected App OAuth scope restriction, Connected App IP restrictions, API session policies, or API usage monitoring in a Salesforce org. Trigger keywords: 'API rate limit', '429 error', 'OAuth scope restriction', 'Connected App IP restriction', 'API usage monitoring', 'concurrent API limits', 'Bulk API limits'. NOT for OAuth flow implementation, token exchange mechanics, or general Connected App setup — use security/oauth-flows-and-connected-apps for those.
omnistudio-security
Use when designing or reviewing OmniStudio security across OmniScripts, Integration Procedures, DataRaptors, custom LWCs, Apex actions, guest-user exposure, and outbound HTTP actions. Triggers: 'OmniStudio security', 'guest user omniscript', 'DataRaptor CRUD FLS', 'OmniStudio Apex security', 'HTTP action data exposure'. NOT for general portal identity architecture or generic Apex security reviews when OmniStudio is not the main surface.
lwc-security
Use when designing or reviewing Lightning Web Components for DOM safety, Lightning Web Security boundaries, third-party library handling, and secure server-side data access from LWC. Triggers: 'innerHTML in lwc', 'Lightning Web Security', 'document.querySelector', 'light DOM security', 'secure apex class for lwc'. NOT for org-wide sharing architecture or Apex-only security reviews when no LWC surface is involved.
crm-analytics-security-predicates
Row-level security in CRM Analytics datasets via security predicates — SAQL filter expressions stored on the dataset that apply at query time per running user. Covers the syntax (`'DatasetColumn' operator value`), the `$User.*` context variables, multi-level predicates (role hierarchy + team + region), the performance cost of complex predicates, and the testing discipline (admins bypass predicates by default). NOT for Salesforce Core sharing rules (different runtime), NOT for App / Dashboard / Lens-level access (that's CRM Analytics App sharing, not predicates), NOT for field-level masking inside a dataset (use Encryption + dataset transformations).