[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6ADYPJ2YR6ZSJ5NDK9Y3F3F":3,"skill-same:01M6ADYPJ2YR6ZSJ5NDK9Y3F3F":104},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":36,"linkOnly":37,"markdownContent":38,"markdownBody":39,"frontMatter":40,"refName":55,"commitSha":56,"skillDirectory":57,"forksCount":58,"repositoryHtmlUrl":59,"repositoryHomepageUrl":60,"ownerHtmlUrl":61,"ownerBlogUrl":62,"ownerDescription":63,"updatedAt":64,"install":65,"resources":78},"01M6ADYPJ2YR6ZSJ5NDK9Y3F3F","building-incident-response-playbook",null,"Designs and documents structured incident response playbooks with step-by-step procedures per incident type, decision trees, escalation criteria, RACI matrices, and SOAR platform integration, aligned to NIST SP 800-61r3 and SANS PICERL. Use when creating or maturing an IR program, documenting response runbooks for a new incident type, or designing SOAR playbooks.","mukul975\u002FAnthropic-Cybersecurity-Skills","mukul975","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F42860185?v=4","01M6ADEQR8T5M4EEG6C67BQCWF","Mahipal","01M6ADJPMYWG1E5GM1FWBE3128",36078,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fbuilding-incident-response-playbook\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35],"incident response","building incident response playbook","cybersecurity","soar","documents","integration","incident-response","IR-playbook","runbook","NIST-800-61","SOAR-integration","response-procedures","2026-11-10 10:12:30",false,"---\nname: building-incident-response-playbook\ndescription: Designs and documents structured incident response playbooks with step-by-step\n  procedures per incident type, decision trees, escalation criteria, RACI matrices,\n  and SOAR platform integration, aligned to NIST SP 800-61r3 and SANS PICERL. Use\n  when creating or maturing an IR program, documenting response runbooks for a new\n  incident type, or designing SOAR playbooks.\ndomain: cybersecurity\nsubdomain: incident-response\ntags:\n- IR-playbook\n- runbook\n- NIST-800-61\n- SOAR-integration\n- response-procedures\nmitre_attack:\n- T1486\n- T1566\n- T1190\n- T1041\n- T1078\nversion: 1.0.0\nauthor: mahipal\nlicense: Apache-2.0\nnist_csf:\n- RS.MA-01\n- RS.MA-02\n- RS.AN-03\n- RC.RP-01\n---\n\n# Building Incident Response Playbooks\n\n## When to Use\n\n- Establishing or maturing an incident response program from scratch\n- Documenting procedures for a new incident type after a novel attack\n- Automating response workflows in a SOAR platform (Cortex XSOAR, Splunk SOAR)\n- Preparing for compliance audits requiring documented IR procedures (SOC 2, PCI-DSS, HIPAA)\n- Conducting a gap analysis of existing IR capabilities against specific threat scenarios\n\n**Do not use** for one-time ad hoc investigations; playbooks are reusable procedure documents, not case-specific reports.\n\n## Prerequisites\n\n- Organizational risk assessment identifying top incident scenarios by likelihood and impact\n- NIST SP 800-61r3 or SANS PICERL framework adopted as the organizational IR standard\n- Asset inventory with business criticality ratings and data classification\n- RACI chart defining roles: Incident Commander, SOC analysts, system administrators, legal, communications\n- Existing detection capabilities inventory (SIEM rules, EDR detections, IDS signatures)\n- SOAR platform access if building automated playbooks\n\n## Workflow\n\n### Step 1: Select and Scope the Incident Type\n\nDefine the specific scenario the playbook will address:\n\n- Identify the top incident types based on organizational risk assessment and historical data\n- Scope each playbook to a single incident type for clarity (do not combine unrelated scenarios)\n- Define trigger conditions that activate the playbook\n\nCommon playbook types:\n```\nPriority Playbooks (build first):\n1. Ransomware incident response\n2. Phishing\u002Fcredential compromise\n3. Business email compromise\n4. Malware infection\n5. Data breach\u002Fexfiltration\n6. DDoS attack\n7. Insider threat\n8. Account takeover\n9. Web application compromise\n10. Cloud infrastructure compromise\n```\n\n### Step 2: Define the Playbook Structure\n\nEvery playbook should follow a consistent structure:\n\n```\nPLAYBOOK TEMPLATE\n━━━━━━━━━━━━━━━━\n1. Playbook Metadata\n   - Name, version, owner, last review date\n   - Trigger conditions\n   - Severity criteria\n\n2. RACI Matrix\n   - Who is Responsible, Accountable, Consulted, Informed for each step\n\n3. Detection & Triage\n   - How the incident is detected\n   - Initial triage checklist\n   - Severity classification criteria\n\n4. Containment\n   - Short-term containment actions\n   - Long-term containment actions\n   - Evidence preservation requirements\n\n5. Eradication\n   - Root cause identification\n   - Malware\u002Fthreat removal steps\n   - Verification procedures\n\n6. Recovery\n   - System restoration steps\n   - Validation criteria\n   - Monitoring requirements post-recovery\n\n7. Post-Incident\n   - Lessons learned meeting trigger\n   - Report template\n   - Detection improvement actions\n\n8. Communication\n   - Internal notification matrix\n   - External notification requirements (regulators, customers, law enforcement)\n   - Status update cadence\n\n9. Appendices\n   - Tool-specific procedures\n   - Contact lists\n   - Evidence collection checklists\n```\n\n### Step 3: Write Decision Trees and Escalation Criteria\n\nDefine clear decision points with binary outcomes:\n\n```\nDetection Alert Received\n├── Is the alert a true positive?\n│   ├── YES → Classify severity\n│   │   ├── P1 (Critical) → Page incident commander, begin containment immediately\n│   │   ├── P2 (High) → Notify IR lead, begin investigation within 30 min\n│   │   ├── P3 (Medium) → Queue for investigation within 4 hours\n│   │   └── P4 (Low) → Document and investigate within 24 hours\n│   └── NO → Document as false positive, tune detection rule\n└── Cannot determine → Escalate to Tier 2 for deeper analysis\n```\n\nEscalation triggers:\n- Any P1 incident: Immediate escalation to IR lead and CISO\n- Data exfiltration confirmed: Legal counsel and privacy officer notified\n- Customer data involved: Customer notification process activated\n- Third-party involvement: Vendor security contact engaged\n- Law enforcement needed: General counsel authorizes before contact\n\n### Step 4: Define Specific Technical Procedures\n\nWrite tool-specific instructions for each step (not generic guidance):\n\n```\nCONTAINMENT - Endpoint Isolation via CrowdStrike:\n1. Open Falcon Console > Hosts > Search for affected hostname\n2. Click on the host > Host Details\n3. Click \"Contain Host\" button in upper right\n4. Confirm isolation (host will only communicate with CrowdStrike cloud)\n5. Document containment action in incident ticket with timestamp\n6. Verify containment: Host should show \"Contained\" status badge\n\nCONTAINMENT - Block C2 Domain at DNS:\n1. SSH to DNS server: ssh admin@dns-primary.corp.local\n2. Add to block zone: echo \"zone evil.com { type master; file \u002Fetc\u002Fbind\u002Fdb.sinkhole; };\" >> \u002Fetc\u002Fbind\u002Fnamed.conf.local\n3. Reload DNS: rndc reload\n4. Verify: dig @dns-primary evil.com (should resolve to sinkhole IP 10.0.0.99)\n5. Document blocked domain in incident ticket\n```\n\n### Step 5: Integrate with SOAR Platform\n\nConvert manual playbook steps into automated workflows:\n\n- Map each playbook step to a SOAR action (API call, script, human decision point)\n- Define automation boundaries (what runs automatically vs. what requires analyst approval)\n- Build enrichment automations for the triage phase\n- Create containment automations with approval gates for high-impact actions\n- Configure notification automations for stakeholder communication\n\n### Step 6: Test and Maintain the Playbook\n\nValidate the playbook through exercises and maintain currency:\n\n- Conduct tabletop exercises with the IR team walking through the playbook\n- Perform live-fire exercises simulating the incident type in a test environment\n- Review and update after every real incident that uses the playbook\n- Schedule quarterly reviews for accuracy of contact lists, tool procedures, and escalation paths\n- Track playbook metrics: mean time to contain, mean time to resolve, false positive rate\n\n## Key Concepts\n\n| Term | Definition |\n|------|------------|\n| **Playbook** | Documented, repeatable set of procedures for responding to a specific incident type |\n| **Runbook** | More granular than a playbook; step-by-step technical instructions for a specific task within a playbook |\n| **RACI Matrix** | Responsibility assignment chart defining who is Responsible, Accountable, Consulted, and Informed for each activity |\n| **Decision Tree** | Flowchart-based logic defining the response path based on binary conditions at each decision point |\n| **Escalation Criteria** | Predefined conditions that trigger notification of higher-level personnel or external parties |\n| **SOAR Playbook** | Automated workflow in a Security Orchestration, Automation, and Response platform executing playbook steps |\n\n## Tools & Systems\n\n- **Cortex XSOAR**: SOAR platform with visual playbook editor, 700+ integrations, and collaborative War Room\n- **Splunk SOAR**: SOAR platform integrated with Splunk ES, drag-and-drop playbook builder with 2,800+ automated actions\n- **TheHive**: Open-source incident response platform with case templates that function as playbook frameworks\n- **Confluence \u002F GitLab Wiki**: Documentation platforms for maintaining human-readable playbook documents with version control\n- **Tines**: No-code security automation platform for building playbook workflows without programming\n\n## Common Scenarios\n\n### Scenario: Building a Phishing Response Playbook from Scratch\n\n**Context**: An organization with a 5-person SOC has no documented phishing response procedure. Analysts handle phishing reports inconsistently.\n\n**Approach**:\n1. Interview SOC analysts to document their current ad hoc process\n2. Define the trigger: user reports phishing email via abuse@ mailbox or phishing button\n3. Write triage steps: extract email headers, check sender reputation, analyze URLs\u002Fattachments in sandbox\n4. Define containment: quarantine email from all mailboxes, block sender domain, reset passwords if credentials entered\n5. Build SOAR automation: auto-extract IOCs from reported email, enrich via VirusTotal, create case in TheHive\n6. Test with simulated phishing email and measure response time improvement\n\n**Pitfalls**:\n- Writing overly generic procedures that don't reference specific tool interfaces or commands\n- Not including the communication plan for notifying users who received the phishing email\n- Forgetting to define the criteria for when a phishing report becomes a full incident investigation\n- Not versioning the playbook or scheduling regular review cycles\n\n## Output Format\n\n```\nINCIDENT RESPONSE PLAYBOOK\n============================\nPlaybook Name:    Phishing Incident Response\nVersion:          2.1\nOwner:            SOC Manager\nLast Reviewed:    2025-11-01\nNext Review:      2026-02-01\nTrigger:          Phishing email reported via abuse@corp.com or phish button\n\nRACI MATRIX\nActivity                    | SOC L1 | SOC L2 | IR Lead | Legal | Comms\nInitial Triage              |   R    |   C    |   I     |       |\nEmail Analysis              |   R    |   A    |   I     |       |\nContainment                 |        |   R    |   A     |   I   |\nCredential Reset            |        |   R    |   A     |       |\nUser Notification           |        |   C    |   A     |       |   R\nRegulatory Notification     |        |        |   C     |   R   |   A\nLessons Learned             |   C    |   C    |   R     |   I   |   I\n\nPROCEDURE STEPS\n[Detailed steps with tool-specific instructions]\n\nDECISION TREE\n[Flowchart logic]\n\nESCALATION MATRIX\n[Conditions and contacts]\n\nMETRICS\nTarget MTTA: 15 minutes\nTarget MTTC: 1 hour\nTarget MTTR: 4 hours\n```\n","# Building Incident Response Playbooks\n\n## When to Use\n\n- Establishing or maturing an incident response program from scratch\n- Documenting procedures for a new incident type after a novel attack\n- Automating response workflows in a SOAR platform (Cortex XSOAR, Splunk SOAR)\n- Preparing for compliance audits requiring documented IR procedures (SOC 2, PCI-DSS, HIPAA)\n- Conducting a gap analysis of existing IR capabilities against specific threat scenarios\n\n**Do not use** for one-time ad hoc investigations; playbooks are reusable procedure documents, not case-specific reports.\n\n## Prerequisites\n\n- Organizational risk assessment identifying top incident scenarios by likelihood and impact\n- NIST SP 800-61r3 or SANS PICERL framework adopted as the organizational IR standard\n- Asset inventory with business criticality ratings and data classification\n- RACI chart defining roles: Incident Commander, SOC analysts, system administrators, legal, communications\n- Existing detection capabilities inventory (SIEM rules, EDR detections, IDS signatures)\n- SOAR platform access if building automated playbooks\n\n## Workflow\n\n### Step 1: Select and Scope the Incident Type\n\nDefine the specific scenario the playbook will address:\n\n- Identify the top incident types based on organizational risk assessment and historical data\n- Scope each playbook to a single incident type for clarity (do not combine unrelated scenarios)\n- Define trigger conditions that activate the playbook\n\nCommon playbook types:\n```\nPriority Playbooks (build first):\n1. Ransomware incident response\n2. Phishing\u002Fcredential compromise\n3. Business email compromise\n4. Malware infection\n5. Data breach\u002Fexfiltration\n6. DDoS attack\n7. Insider threat\n8. Account takeover\n9. Web application compromise\n10. Cloud infrastructure compromise\n```\n\n### Step 2: Define the Playbook Structure\n\nEvery playbook should follow a consistent structure:\n\n```\nPLAYBOOK TEMPLATE\n━━━━━━━━━━━━━━━━\n1. Playbook Metadata\n   - Name, version, owner, last review date\n   - Trigger conditions\n   - Severity criteria\n\n2. RACI Matrix\n   - Who is Responsible, Accountable, Consulted, Informed for each step\n\n3. Detection & Triage\n   - How the incident is detected\n   - Initial triage checklist\n   - Severity classification criteria\n\n4. Containment\n   - Short-term containment actions\n   - Long-term containment actions\n   - Evidence preservation requirements\n\n5. Eradication\n   - Root cause identification\n   - Malware\u002Fthreat removal steps\n   - Verification procedures\n\n6. Recovery\n   - System restoration steps\n   - Validation criteria\n   - Monitoring requirements post-recovery\n\n7. Post-Incident\n   - Lessons learned meeting trigger\n   - Report template\n   - Detection improvement actions\n\n8. Communication\n   - Internal notification matrix\n   - External notification requirements (regulators, customers, law enforcement)\n   - Status update cadence\n\n9. Appendices\n   - Tool-specific procedures\n   - Contact lists\n   - Evidence collection checklists\n```\n\n### Step 3: Write Decision Trees and Escalation Criteria\n\nDefine clear decision points with binary outcomes:\n\n```\nDetection Alert Received\n├── Is the alert a true positive?\n│   ├── YES → Classify severity\n│   │   ├── P1 (Critical) → Page incident commander, begin containment immediately\n│   │   ├── P2 (High) → Notify IR lead, begin investigation within 30 min\n│   │   ├── P3 (Medium) → Queue for investigation within 4 hours\n│   │   └── P4 (Low) → Document and investigate within 24 hours\n│   └── NO → Document as false positive, tune detection rule\n└── Cannot determine → Escalate to Tier 2 for deeper analysis\n```\n\nEscalation triggers:\n- Any P1 incident: Immediate escalation to IR lead and CISO\n- Data exfiltration confirmed: Legal counsel and privacy officer notified\n- Customer data involved: Customer notification process activated\n- Third-party involvement: Vendor security contact engaged\n- Law enforcement needed: General counsel authorizes before contact\n\n### Step 4: Define Specific Technical Procedures\n\nWrite tool-specific instructions for each step (not generic guidance):\n\n```\nCONTAINMENT - Endpoint Isolation via CrowdStrike:\n1. Open Falcon Console > Hosts > Search for affected hostname\n2. Click on the host > Host Details\n3. Click \"Contain Host\" button in upper right\n4. Confirm isolation (host will only communicate with CrowdStrike cloud)\n5. Document containment action in incident ticket with timestamp\n6. Verify containment: Host should show \"Contained\" status badge\n\nCONTAINMENT - Block C2 Domain at DNS:\n1. SSH to DNS server: ssh admin@dns-primary.corp.local\n2. Add to block zone: echo \"zone evil.com { type master; file \u002Fetc\u002Fbind\u002Fdb.sinkhole; };\" >> \u002Fetc\u002Fbind\u002Fnamed.conf.local\n3. Reload DNS: rndc reload\n4. Verify: dig @dns-primary evil.com (should resolve to sinkhole IP 10.0.0.99)\n5. Document blocked domain in incident ticket\n```\n\n### Step 5: Integrate with SOAR Platform\n\nConvert manual playbook steps into automated workflows:\n\n- Map each playbook step to a SOAR action (API call, script, human decision point)\n- Define automation boundaries (what runs automatically vs. what requires analyst approval)\n- Build enrichment automations for the triage phase\n- Create containment automations with approval gates for high-impact actions\n- Configure notification automations for stakeholder communication\n\n### Step 6: Test and Maintain the Playbook\n\nValidate the playbook through exercises and maintain currency:\n\n- Conduct tabletop exercises with the IR team walking through the playbook\n- Perform live-fire exercises simulating the incident type in a test environment\n- Review and update after every real incident that uses the playbook\n- Schedule quarterly reviews for accuracy of contact lists, tool procedures, and escalation paths\n- Track playbook metrics: mean time to contain, mean time to resolve, false positive rate\n\n## Key Concepts\n\n| Term | Definition |\n|------|------------|\n| **Playbook** | Documented, repeatable set of procedures for responding to a specific incident type |\n| **Runbook** | More granular than a playbook; step-by-step technical instructions for a specific task within a playbook |\n| **RACI Matrix** | Responsibility assignment chart defining who is Responsible, Accountable, Consulted, and Informed for each activity |\n| **Decision Tree** | Flowchart-based logic defining the response path based on binary conditions at each decision point |\n| **Escalation Criteria** | Predefined conditions that trigger notification of higher-level personnel or external parties |\n| **SOAR Playbook** | Automated workflow in a Security Orchestration, Automation, and Response platform executing playbook steps |\n\n## Tools & Systems\n\n- **Cortex XSOAR**: SOAR platform with visual playbook editor, 700+ integrations, and collaborative War Room\n- **Splunk SOAR**: SOAR platform integrated with Splunk ES, drag-and-drop playbook builder with 2,800+ automated actions\n- **TheHive**: Open-source incident response platform with case templates that function as playbook frameworks\n- **Confluence \u002F GitLab Wiki**: Documentation platforms for maintaining human-readable playbook documents with version control\n- **Tines**: No-code security automation platform for building playbook workflows without programming\n\n## Common Scenarios\n\n### Scenario: Building a Phishing Response Playbook from Scratch\n\n**Context**: An organization with a 5-person SOC has no documented phishing response procedure. Analysts handle phishing reports inconsistently.\n\n**Approach**:\n1. Interview SOC analysts to document their current ad hoc process\n2. Define the trigger: user reports phishing email via abuse@ mailbox or phishing button\n3. Write triage steps: extract email headers, check sender reputation, analyze URLs\u002Fattachments in sandbox\n4. Define containment: quarantine email from all mailboxes, block sender domain, reset passwords if credentials entered\n5. Build SOAR automation: auto-extract IOCs from reported email, enrich via VirusTotal, create case in TheHive\n6. Test with simulated phishing email and measure response time improvement\n\n**Pitfalls**:\n- Writing overly generic procedures that don't reference specific tool interfaces or commands\n- Not including the communication plan for notifying users who received the phishing email\n- Forgetting to define the criteria for when a phishing report becomes a full incident investigation\n- Not versioning the playbook or scheduling regular review cycles\n\n## Output Format\n\n```\nINCIDENT RESPONSE PLAYBOOK\n============================\nPlaybook Name:    Phishing Incident Response\nVersion:          2.1\nOwner:            SOC Manager\nLast Reviewed:    2025-11-01\nNext Review:      2026-02-01\nTrigger:          Phishing email reported via abuse@corp.com or phish button\n\nRACI MATRIX\nActivity                    | SOC L1 | SOC L2 | IR Lead | Legal | Comms\nInitial Triage              |   R    |   C    |   I     |       |\nEmail Analysis              |   R    |   A    |   I     |       |\nContainment                 |        |   R    |   A     |   I   |\nCredential Reset            |        |   R    |   A     |       |\nUser Notification           |        |   C    |   A     |       |   R\nRegulatory Notification     |        |        |   C     |   R   |   A\nLessons Learned             |   C    |   C    |   R     |   I   |   I\n\nPROCEDURE STEPS\n[Detailed steps with tool-specific instructions]\n\nDECISION TREE\n[Flowchart logic]\n\nESCALATION MATRIX\n[Conditions and contacts]\n\nMETRICS\nTarget MTTA: 15 minutes\nTarget MTTC: 1 hour\nTarget MTTR: 4 hours\n```\n",{"name":5,"tags":41,"author":42,"domain":26,"license":15,"version":43,"nist_csf":44,"subdomain":30,"description":7,"mitre_attack":49},[31,32,33,34,35],"mahipal","1.0.0",[45,46,47,48],"RS.MA-01","RS.MA-02","RS.AN-03","RC.RP-01",[50,51,52,53,54],"T1486","T1566","T1190","T1041","T1078","main","54a798831d2266a3ca61ce68a7acb80b81160d57","skills\u002Fbuilding-incident-response-playbook",4414,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills","https:\u002F\u002Fmahipal.engineer\u002FAnthropic-Cybersecurity-Skills\u002F","https:\u002F\u002Fgithub.com\u002Fmukul975","Mahipal.engineer","🔐 Cybersecurity | 💻 Dev | 📷 Street Photographer\r\n🎓 MSc | 📚 Research & AI Security","2026-08-31 12:32:44",{"source":8,"skillName":5,"commands":66,"prompt":76,"zipAvailable":77},[67,70,73],{"tool":68,"command":69},"npx","npx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill building-incident-response-playbook",{"tool":71,"command":72},"bunx","bunx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill building-incident-response-playbook",{"tool":74,"command":75},"pnpm","pnpm dlx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill building-incident-response-playbook","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fbuilding-incident-response-playbook\u002FSKILL.md",true,[79,84,90,94,100],{"path":80,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":82,"sourceHtmlUrl":83},"LICENSE","许可证",11255,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fbuilding-incident-response-playbook\u002FLICENSE",{"path":85,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":88,"sourceHtmlUrl":89},"references\u002Fapi-reference.md","REFERENCE","参考文档",2366,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fbuilding-incident-response-playbook\u002Freferences\u002Fapi-reference.md",{"path":91,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":92,"sourceHtmlUrl":93},"references\u002Feffects.md",8761,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fhyperframes-gsap\u002Freferences\u002Feffects.md",{"path":95,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":98,"sourceHtmlUrl":99},"scripts\u002Fagent.py","SCRIPT","脚本",9695,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fbuilding-incident-response-playbook\u002Fscripts\u002Fagent.py",{"path":101,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":102,"sourceHtmlUrl":103},"scripts\u002Fextract-audio-data.py",6463,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fhyperframes-gsap\u002Fscripts\u002Fextract-audio-data.py",[105,131,155,182,208,235],{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":112,"publishedAt":36},"01M6AGDM3HJXTKXX15ZZ0ZVCJ3","verifying-build-provenance-with-slsa-sigstore","Verifies artifact signatures and SLSA provenance using Sigstore's cosign (verify, verify-attestation, verify-blob-attestation) and slsa-verifier (verify-artifact), enforcing keyless OIDC builder identity and source repo against SLSA Build levels. Use in CI\u002FCD before deploying artifacts, when consuming third-party attestations, establishing a SLSA Build L3 pipeline, or confirming provenance during incident response or admission control.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fverifying-build-provenance-with-slsa-sigstore\u002FSKILL.md",[111],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[113,114,115,116,117,26,24,118,119,120,121,122,123,124,125,126,127,128,129,130],"sigstore","provenance","slsa","verifying build provenance with slsa sigstore","security","identity","pr","code","artifacts","ci","supply-chain","pipeline","supply-chain-security","t1195","attestation","code-signing","cosign","keyless",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":138,"publishedAt":36},"01M6AGDGBPWYVZ2F11GFKJ4HZ9","validating-tpm-measured-boot-attestation","Verifies TPM 2.0 measured-boot integrity and remote attestation with tpm2-tools -- reading PCRs (tpm2_pcrread), replaying the boot event log, generating and checking signed quotes (tpm2_quote\u002Ftpm2_checkquote), and sealing secrets to a PCR policy. Use to confirm a system booted trusted firmware\u002Fkernel for Zero Trust device posture, detect boot-chain tampering via PCR drift, or build a golden-value baseline for fleet attestation.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-tpm-measured-boot-attestation\u002FSKILL.md",[137],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[139,127,140,141,117,142,26,119,143,144,145,146,147,148,149,150,151,152,153,154],"boot","TPM","validating tpm measured boot attestation","policy","verification","ZeRO","firmware","Tools","measured-boot","PCR","integrity","secrets","remote-attestation","tpm2-tools","integrity-verification","trusted-computing",{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":159,"categories":160,"keywords":165,"publishedAt":36},"01M6AGDCW0Y4FXZ3362GT1941M","validating-backup-integrity-for-recovery","Validates backup integrity through cryptographic hash verification, automated restore testing, corruption detection, and recoverability checks to confirm backups are reliable for disaster recovery and ransomware response. Use before relying on backups for recovery, when building post-backup validation pipelines, auditing backup infrastructure for compliance, or checking immutable\u002Fair-gapped backups for silent corruption or tampering.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-backup-integrity-for-recovery\u002FSKILL.md",[161,164],{"categoryNo":162,"categoryName":163,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[149,166,167,168,169,26,170,171,143,172,173,30,174,175,176,177,178,179,180,181],"backup","recovery","validating backup integrity for recovery","testing","infrastructure","validation","compliance","hash-verification","ransomware","cryptocurrency","detection","t1078","t1490","immutable","disaster-recovery","restore-testing",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":189,"publishedAt":36},"01M6AGD9GBG2KZ336AE763J3WH","triaging-windows-with-kape","Runs KAPE (Kroll Artifact Parser and Extractor) to collect targeted forensic artifacts (registry hives, $MFT, event logs, prefetch, browser data) via Targets and parse them with Modules wrapping Eric Zimmerman's EZ Tools (PECmd, MFTECmd, RECmd). Use during early incident containment\u002Ftriage when full disk imaging is impractical but a defensible, parseable Windows artifact set is needed quickly, including at-scale remote collection.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-windows-with-kape\u002FSKILL.md",[188],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[190,191,192,26,193,194,195,196,197,198,199,200,201,202,203,204,146,205,206,207],"windows","kape","triaging windows with kape","registry","browser","logs","windows-forensics","dfir","mft","mftecmd","data","prefetch","eric-zimmerman","digital-forensics","SET","collection","pecmd","artifact-collection",{"skillNo":209,"name":210,"nameZh":6,"description":211,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":212,"categories":213,"keywords":215,"publishedAt":36},"01M6AGD5PW5J4EVZM958WD74ZQ","triaging-vulnerabilities-with-ssvc-framework","Triages and prioritizes vulnerabilities with CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) decision tree, weighing exploitation status (via the CISA KEV catalog and FIRST EPSS API), technical impact, automatability, and mission prevalence to output Track\u002FTrack*\u002FAttend\u002FAct decisions. Use when prioritizing vulnerability scan results (OpenVAS, Nessus, Qualys) for remediation planning beyond raw CVSS scores.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-vulnerabilities-with-ssvc-framework\u002FSKILL.md",[214],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[216,217,218,26,219,220,221,222,223,224,225,226,227,228,229,230,231,232,233,234],"vulnerabilities","framework","triaging vulnerabilities with ssvc framework","status","planning","CISA","vulnerability-management","risk-management","nessus","qualys","openvas","cvss","remediation","risk","vulnerability","api","prioritization","ssvc","decision-tree",{"skillNo":236,"name":237,"nameZh":6,"description":238,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":239,"categories":240,"keywords":242,"publishedAt":36},"01M6AGD24TTQQM4CXG69E3B9TJ","triaging-security-incident","Performs initial triage of security incidents using the NIST SP 800-61r3 and SANS PICERL frameworks, classifying incident type, assigning priority by business impact, and routing to the appropriate response team. Use when a SIEM\u002FEDR alert needs human classification, concurrent alerts must be prioritized, or a user report or threat-intel IOC match requires initial incident categorization.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-security-incident\u002FSKILL.md",[241],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[117,243,26,244,245,246,247,33,248,249,250,177,251,178,252,253,254,255,256,257],"triaging security incident","siem","file","ioc","soc","NIST","severity","edr","execution","analysis","classification","severity-classification","incident-triage","SANS-PICERL","SOC-operations"]