[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AFRBB5JAGF4PVM8D9RK6V0":3,"skill-same:01M6AFRBB5JAGF4PVM8D9RK6V0":124},{"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":26,"publishedAt":46,"linkOnly":47,"markdownContent":48,"markdownBody":49,"frontMatter":50,"refName":65,"commitSha":66,"skillDirectory":67,"forksCount":68,"repositoryHtmlUrl":69,"repositoryHomepageUrl":70,"ownerHtmlUrl":71,"ownerBlogUrl":72,"ownerDescription":73,"updatedAt":74,"install":75,"resources":88},"01M6AFRBB5JAGF4PVM8D9RK6V0","performing-dmarc-policy-enforcement-rollout",null,"Execute a phased DMARC rollout by inventorying sending sources, configuring SPF\u002FDKIM alignment, and progressing DNS policy from p=none monitoring through p=quarantine to p=reject enforcement, ensuring all legitimate email sources authenticate before unauthorized senders are blocked. Use when deploying or advancing an organization's DMARC anti-spoofing posture, or when meeting bulk-sender authentication requirements from Google and Yahoo.","mukul975\u002FAnthropic-Cybersecurity-Skills","mukul975","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F42860185?v=4","01M6ADEQR8T5M4EEG6C67BQCWF","Mahipal","01M6ADJPMYWG1E5GM1FWBE3128",35884,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fperforming-dmarc-policy-enforcement-rollout\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000005","邮件与沟通","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45],"performing dmarc policy enforcement rollout","policy","dmarc","dns","email-authentication","anti-spoofing","t1566","defense","email-security","dkim","spf","google","phishing","email","monitoring","authentication","pr","cybersecurity","security","2026-11-10 10:12:30",false,"---\nname: performing-dmarc-policy-enforcement-rollout\ndescription: Execute a phased DMARC rollout by inventorying sending sources, configuring\n  SPF\u002FDKIM alignment, and progressing DNS policy from p=none monitoring through p=quarantine\n  to p=reject enforcement, ensuring all legitimate email sources authenticate before\n  unauthorized senders are blocked. Use when deploying or advancing an organization's\n  DMARC anti-spoofing posture, or when meeting bulk-sender authentication requirements\n  from Google and Yahoo.\ndomain: cybersecurity\nsubdomain: phishing-defense\ntags:\n- dmarc\n- spf\n- dkim\n- email-authentication\n- anti-spoofing\n- phishing\n- dns\n- email-security\nversion: '1.0'\nauthor: mahipal\nlicense: Apache-2.0\nnist_csf:\n- PR.AT-01\n- DE.CM-09\n- RS.CO-02\n- DE.AE-02\nmitre_attack:\n- T1566\n- T1598\n- T1534\n- T1036\n---\n# Performing DMARC Policy Enforcement Rollout\n\n## Overview\nDomain-based Message Authentication, Reporting and Conformance (DMARC) is the cornerstone of email anti-spoofing protection. A DMARC rollout progresses through three phases: monitoring (p=none), quarantine (p=quarantine), and full enforcement (p=reject). When configured at p=reject, any email that fails both SPF and DKIM checks is outright rejected. Google and Yahoo now require DMARC for bulk senders (5,000+ emails), driving a 65% reduction in unauthenticated messages. The rollout typically takes 3-6 months for safe deployment.\n\n\n## When to Use\n\n- When conducting security assessments that involve performing dmarc policy enforcement rollout\n- When following incident response procedures for related security events\n- When performing scheduled security testing or auditing activities\n- When validating security controls through hands-on testing\n\n## Prerequisites\n- Administrative access to DNS management for the domain\n- Understanding of SPF, DKIM, and DMARC protocols (RFC 7208, 6376, 7489)\n- Complete inventory of all legitimate email sending sources\n- DMARC reporting analysis tool (EasyDMARC, DMARCLY, Valimail, or dmarcian)\n- Email gateway with DMARC enforcement capability\n\n## Key Concepts\n\n### DMARC Policy Levels\n| Policy | Behavior | Use Case |\n|---|---|---|\n| p=none | Monitor only, no action on failures | Discovery phase |\n| p=quarantine | Send failing messages to spam\u002Fjunk | Transition phase |\n| p=reject | Block failing messages entirely | Full enforcement |\n\n### DMARC Record Anatomy\n```\nv=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-agg@company.com; ruf=mailto:dmarc-forensic@company.com; adkim=r; aspf=r; fo=1\n```\n- **p**: Policy for organizational domain\n- **sp**: Policy for subdomains\n- **pct**: Percentage of messages subject to policy (for gradual rollout)\n- **rua**: Aggregate report destination (daily XML reports)\n- **ruf**: Forensic report destination (per-failure reports)\n- **adkim**: DKIM alignment mode (r=relaxed, s=strict)\n- **aspf**: SPF alignment mode (r=relaxed, s=strict)\n- **fo**: Failure reporting options (0=both fail, 1=either fails)\n\n### SPF and DKIM Alignment\n- **SPF Alignment**: The domain in the Return-Path (envelope sender) must match the From header domain\n- **DKIM Alignment**: The d= domain in the DKIM signature must match the From header domain\n- **Relaxed**: Organizational domain match (sub.example.com matches example.com)\n- **Strict**: Exact domain match required\n\n## Workflow\n\n### Step 1: Inventory All Sending Sources (Week 1-2)\n- Audit all systems sending email as your domain (marketing, CRM, ticketing, transactional)\n- Document third-party services: Salesforce, Mailchimp, SendGrid, Zendesk, etc.\n- Identify internal mail servers, applications, and relay hosts\n- Check for shadow IT email sending (departments using unauthorized services)\n\n### Step 2: Configure SPF and DKIM (Week 2-4)\n- Consolidate SPF record with all legitimate sending IPs and includes\n- Ensure SPF record stays under 10 DNS lookup limit\n- Generate and publish DKIM keys for each sending source\n- Verify DKIM signing works for all outbound mail paths\n- Test with MX Toolbox or dmarcian SPF\u002FDKIM validators\n\n### Step 3: Deploy DMARC in Monitoring Mode (Week 4-6)\n- Publish initial DMARC record: `v=DMARC1; p=none; rua=mailto:dmarc@company.com; fo=1`\n- Wait 1-2 weeks to collect representative aggregate reports\n- Analyze reports to identify unauthorized senders and alignment failures\n- Fix SPF\u002FDKIM for all legitimate sources showing failures\n- Iterate until all legitimate mail passes DMARC\n\n### Step 4: Move to Quarantine with pct Tag (Week 6-12)\n- Update to quarantine at 10%: `v=DMARC1; p=quarantine; pct=10; rua=...`\n- Monitor for false positives (legitimate mail being quarantined)\n- Increase pct gradually: 10% -> 25% -> 50% -> 75% -> 100%\n- Each increase: wait 1-2 weeks and review reports before advancing\n- Fix any remaining alignment issues discovered at each stage\n\n### Step 5: Advance to Reject Policy (Week 12-20)\n- After stable quarantine at 100%, move to reject at 10%: `v=DMARC1; p=reject; pct=10; rua=...`\n- Gradually increase pct: 10% -> 25% -> 50% -> 100%\n- Monitor closely for legitimate mail being rejected\n- Establish emergency rollback procedure (revert to quarantine)\n- Apply subdomain policy: `sp=reject` for subdomains\n\n### Step 6: Ongoing Monitoring and Maintenance\n- Continuously monitor DMARC aggregate reports\n- Add new sending sources before they start sending\n- Review forensic reports for spoofing attempts\n- Maintain SPF record as sending infrastructure changes\n- Rotate DKIM keys annually\n\n## Tools & Resources\n- **EasyDMARC**: DMARC monitoring dashboard with aggregate\u002Fforensic report analysis\n- **DMARCLY**: SPF, DKIM, DMARC monitoring with auto-DNS updates\n- **dmarcian**: DMARC deployment and management platform\n- **Valimail**: Automated DMARC enforcement with hosted authentication\n- **MX Toolbox**: DNS record lookup and DMARC validator\n- **Google Admin Toolbox**: DMARC check and diagnostic tools\n\n## Validation\n- DMARC record published and resolving correctly at _dmarc.domain.com\n- All legitimate sending sources pass SPF and\u002For DKIM alignment\n- Aggregate reports show >99% legitimate mail passing DMARC\n- Spoofed messages from unauthorized senders are rejected\n- No legitimate mail blocked after full p=reject enforcement\n- Subdomain policy (sp=) also set to reject\n","# Performing DMARC Policy Enforcement Rollout\n\n## Overview\nDomain-based Message Authentication, Reporting and Conformance (DMARC) is the cornerstone of email anti-spoofing protection. A DMARC rollout progresses through three phases: monitoring (p=none), quarantine (p=quarantine), and full enforcement (p=reject). When configured at p=reject, any email that fails both SPF and DKIM checks is outright rejected. Google and Yahoo now require DMARC for bulk senders (5,000+ emails), driving a 65% reduction in unauthenticated messages. The rollout typically takes 3-6 months for safe deployment.\n\n\n## When to Use\n\n- When conducting security assessments that involve performing dmarc policy enforcement rollout\n- When following incident response procedures for related security events\n- When performing scheduled security testing or auditing activities\n- When validating security controls through hands-on testing\n\n## Prerequisites\n- Administrative access to DNS management for the domain\n- Understanding of SPF, DKIM, and DMARC protocols (RFC 7208, 6376, 7489)\n- Complete inventory of all legitimate email sending sources\n- DMARC reporting analysis tool (EasyDMARC, DMARCLY, Valimail, or dmarcian)\n- Email gateway with DMARC enforcement capability\n\n## Key Concepts\n\n### DMARC Policy Levels\n| Policy | Behavior | Use Case |\n|---|---|---|\n| p=none | Monitor only, no action on failures | Discovery phase |\n| p=quarantine | Send failing messages to spam\u002Fjunk | Transition phase |\n| p=reject | Block failing messages entirely | Full enforcement |\n\n### DMARC Record Anatomy\n```\nv=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-agg@company.com; ruf=mailto:dmarc-forensic@company.com; adkim=r; aspf=r; fo=1\n```\n- **p**: Policy for organizational domain\n- **sp**: Policy for subdomains\n- **pct**: Percentage of messages subject to policy (for gradual rollout)\n- **rua**: Aggregate report destination (daily XML reports)\n- **ruf**: Forensic report destination (per-failure reports)\n- **adkim**: DKIM alignment mode (r=relaxed, s=strict)\n- **aspf**: SPF alignment mode (r=relaxed, s=strict)\n- **fo**: Failure reporting options (0=both fail, 1=either fails)\n\n### SPF and DKIM Alignment\n- **SPF Alignment**: The domain in the Return-Path (envelope sender) must match the From header domain\n- **DKIM Alignment**: The d= domain in the DKIM signature must match the From header domain\n- **Relaxed**: Organizational domain match (sub.example.com matches example.com)\n- **Strict**: Exact domain match required\n\n## Workflow\n\n### Step 1: Inventory All Sending Sources (Week 1-2)\n- Audit all systems sending email as your domain (marketing, CRM, ticketing, transactional)\n- Document third-party services: Salesforce, Mailchimp, SendGrid, Zendesk, etc.\n- Identify internal mail servers, applications, and relay hosts\n- Check for shadow IT email sending (departments using unauthorized services)\n\n### Step 2: Configure SPF and DKIM (Week 2-4)\n- Consolidate SPF record with all legitimate sending IPs and includes\n- Ensure SPF record stays under 10 DNS lookup limit\n- Generate and publish DKIM keys for each sending source\n- Verify DKIM signing works for all outbound mail paths\n- Test with MX Toolbox or dmarcian SPF\u002FDKIM validators\n\n### Step 3: Deploy DMARC in Monitoring Mode (Week 4-6)\n- Publish initial DMARC record: `v=DMARC1; p=none; rua=mailto:dmarc@company.com; fo=1`\n- Wait 1-2 weeks to collect representative aggregate reports\n- Analyze reports to identify unauthorized senders and alignment failures\n- Fix SPF\u002FDKIM for all legitimate sources showing failures\n- Iterate until all legitimate mail passes DMARC\n\n### Step 4: Move to Quarantine with pct Tag (Week 6-12)\n- Update to quarantine at 10%: `v=DMARC1; p=quarantine; pct=10; rua=...`\n- Monitor for false positives (legitimate mail being quarantined)\n- Increase pct gradually: 10% -> 25% -> 50% -> 75% -> 100%\n- Each increase: wait 1-2 weeks and review reports before advancing\n- Fix any remaining alignment issues discovered at each stage\n\n### Step 5: Advance to Reject Policy (Week 12-20)\n- After stable quarantine at 100%, move to reject at 10%: `v=DMARC1; p=reject; pct=10; rua=...`\n- Gradually increase pct: 10% -> 25% -> 50% -> 100%\n- Monitor closely for legitimate mail being rejected\n- Establish emergency rollback procedure (revert to quarantine)\n- Apply subdomain policy: `sp=reject` for subdomains\n\n### Step 6: Ongoing Monitoring and Maintenance\n- Continuously monitor DMARC aggregate reports\n- Add new sending sources before they start sending\n- Review forensic reports for spoofing attempts\n- Maintain SPF record as sending infrastructure changes\n- Rotate DKIM keys annually\n\n## Tools & Resources\n- **EasyDMARC**: DMARC monitoring dashboard with aggregate\u002Fforensic report analysis\n- **DMARCLY**: SPF, DKIM, DMARC monitoring with auto-DNS updates\n- **dmarcian**: DMARC deployment and management platform\n- **Valimail**: Automated DMARC enforcement with hosted authentication\n- **MX Toolbox**: DNS record lookup and DMARC validator\n- **Google Admin Toolbox**: DMARC check and diagnostic tools\n\n## Validation\n- DMARC record published and resolving correctly at _dmarc.domain.com\n- All legitimate sending sources pass SPF and\u002For DKIM alignment\n- Aggregate reports show >99% legitimate mail passing DMARC\n- Spoofed messages from unauthorized senders are rejected\n- No legitimate mail blocked after full p=reject enforcement\n- Subdomain policy (sp=) also set to reject\n",{"name":5,"tags":51,"author":52,"domain":44,"license":15,"version":53,"nist_csf":54,"subdomain":59,"description":7,"mitre_attack":60},[29,37,36,31,32,39,30,35],"mahipal","1.0",[55,56,57,58],"PR.AT-01","DE.CM-09","RS.CO-02","DE.AE-02","phishing-defense",[61,62,63,64],"T1566","T1598","T1534","T1036","main","54a798831d2266a3ca61ce68a7acb80b81160d57","skills\u002Fperforming-dmarc-policy-enforcement-rollout",4379,"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":76,"prompt":86,"zipAvailable":87},[77,80,83],{"tool":78,"command":79},"npx","npx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill performing-dmarc-policy-enforcement-rollout",{"tool":81,"command":82},"bunx","bunx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill performing-dmarc-policy-enforcement-rollout",{"tool":84,"command":85},"pnpm","pnpm dlx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill performing-dmarc-policy-enforcement-rollout","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fperforming-dmarc-policy-enforcement-rollout\u002FSKILL.md",true,[89,95,100,106,110,114,120],{"path":90,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":93,"sourceHtmlUrl":94},"assets\u002Ftemplate.md","ASSET","资产文件",1577,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fperforming-dmarc-policy-enforcement-rollout\u002Fassets\u002Ftemplate.md",{"path":96,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":98,"sourceHtmlUrl":99},"LICENSE","许可证",11255,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fperforming-dmarc-policy-enforcement-rollout\u002FLICENSE",{"path":101,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":104,"sourceHtmlUrl":105},"references\u002Fapi-reference.md","REFERENCE","参考文档",907,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fperforming-dmarc-policy-enforcement-rollout\u002Freferences\u002Fapi-reference.md",{"path":107,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":108,"sourceHtmlUrl":109},"references\u002Fstandards.md",1708,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fperforming-dmarc-policy-enforcement-rollout\u002Freferences\u002Fstandards.md",{"path":111,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":112,"sourceHtmlUrl":113},"references\u002Fworkflows.md",2772,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fperforming-dmarc-policy-enforcement-rollout\u002Freferences\u002Fworkflows.md",{"path":115,"resourceType":116,"resourceTypeDesc":117,"sizeBytes":118,"sourceHtmlUrl":119},"scripts\u002Fagent.py","SCRIPT","脚本",5543,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fperforming-dmarc-policy-enforcement-rollout\u002Fscripts\u002Fagent.py",{"path":121,"resourceType":116,"resourceTypeDesc":117,"sizeBytes":122,"sourceHtmlUrl":123},"scripts\u002Fprocess.py",12014,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fperforming-dmarc-policy-enforcement-rollout\u002Fscripts\u002Fprocess.py",[125,150,173,201,227,254],{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":132,"publishedAt":46},"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",[131],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[133,134,135,136,45,44,137,138,43,139,140,141,142,143,144,145,146,147,148,149],"sigstore","provenance","slsa","verifying build provenance with slsa sigstore","incident response","identity","code","artifacts","ci","supply-chain","pipeline","supply-chain-security","t1195","attestation","code-signing","cosign","keyless",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":157,"publishedAt":46},"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",[156],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[158,146,159,160,45,28,44,43,161,162,163,164,165,166,167,168,169,170,171,172],"boot","TPM","validating tpm measured boot attestation","verification","ZeRO","firmware","Tools","measured-boot","PCR","integrity","secrets","remote-attestation","tpm2-tools","integrity-verification","trusted-computing",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":177,"categories":178,"keywords":183,"publishedAt":46},"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",[179,182],{"categoryNo":180,"categoryName":181,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[167,184,185,186,187,44,188,189,161,190,191,192,193,194,195,196,197,198,199,200],"backup","recovery","validating backup integrity for recovery","testing","infrastructure","validation","compliance","hash-verification","incident-response","ransomware","cryptocurrency","detection","t1078","t1490","immutable","disaster-recovery","restore-testing",{"skillNo":202,"name":203,"nameZh":6,"description":204,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":205,"categories":206,"keywords":208,"publishedAt":46},"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",[207],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[209,210,211,44,212,213,214,215,216,217,218,219,220,221,222,223,164,224,225,226],"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":228,"name":229,"nameZh":6,"description":230,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":231,"categories":232,"keywords":234,"publishedAt":46},"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",[233],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[235,236,237,44,238,239,240,241,242,243,244,245,246,247,248,249,250,251,252,253],"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":255,"name":256,"nameZh":6,"description":257,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":258,"categories":259,"keywords":261,"publishedAt":46},"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",[260],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[45,262,44,263,264,265,266,267,268,269,270,196,271,197,272,273,274,275,276,277],"triaging security incident","siem","file","ioc","soc","NIST-800-61","NIST","severity","edr","execution","analysis","classification","severity-classification","incident-triage","SANS-PICERL","SOC-operations"]