[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AF66A66XGM9PST0BJ9W41H":3,"skill-same:01M6AF66A66XGM9PST0BJ9W41H":117},{"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":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":66,"commitSha":67,"skillDirectory":68,"forksCount":69,"repositoryHtmlUrl":70,"repositoryHomepageUrl":71,"ownerHtmlUrl":72,"ownerBlogUrl":73,"ownerDescription":74,"updatedAt":75,"install":76,"resources":89},"01M6AF66A66XGM9PST0BJ9W41H","implementing-hipaa-security-rule-safeguards",null,"Implement the HIPAA Security Rule (45 CFR Part 164 Subpart C) to protect electronic protected health information (ePHI): conduct the required risk analysis, deploy the administrative, physical, and technical safeguards, handle required vs addressable implementation specifications, execute Business Associate Agreements, and stand up breach-notification readiness. Use when an organization is a HIPAA covered entity or business associate, when protecting ePHI, when preparing for an OCR audit or responding to a breach, when performing a HIPAA Security Risk Analysis, when drafting or reviewing a BAA, or when mapping security controls to the §164.308\u002F310\u002F312\u002F314\u002F316 safeguards. Notes the 2025 NPRM proposed changes (not yet final). Keywords: HIPAA, HIPAA Security Rule, ePHI, PHI, 45 CFR 164, risk analysis, administrative safeguards, physical safeguards, technical safeguards, addressable, required, Business Associate Agreement, BAA, OCR, breach notification, HITECH, covered entity, business associate.","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\u002Fimplementing-hipaa-security-rule-safeguards\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"hipaa","implementing hipaa security rule safeguards","hipaa security rule","security","governance","notes","risk analysis","pr","audit","compliance","deploy","implement","ocr","t1078","risk","t1566","hipaa-security-rule","ephi","phi","cybersecurity","2026-11-10 10:12:30",false,"---\nname: implementing-hipaa-security-rule-safeguards\ndescription: >-\n  Implement the HIPAA Security Rule (45 CFR Part 164 Subpart C) to protect electronic\n  protected health information (ePHI): conduct the required risk analysis, deploy the\n  administrative, physical, and technical safeguards, handle required vs addressable\n  implementation specifications, execute Business Associate Agreements, and stand up\n  breach-notification readiness. Use when an organization is a HIPAA covered entity or\n  business associate, when protecting ePHI, when preparing for an OCR audit or responding\n  to a breach, when performing a HIPAA Security Risk Analysis, when drafting or reviewing a\n  BAA, or when mapping security controls to the §164.308\u002F310\u002F312\u002F314\u002F316 safeguards. Notes\n  the 2025 NPRM proposed changes (not yet final). Keywords: HIPAA, HIPAA Security Rule,\n  ePHI, PHI, 45 CFR 164, risk analysis, administrative safeguards, physical safeguards,\n  technical safeguards, addressable, required, Business Associate Agreement, BAA, OCR,\n  breach notification, HITECH, covered entity, business associate.\ndomain: cybersecurity\nsubdomain: compliance-governance\ntags:\n- hipaa\n- hipaa-security-rule\n- ephi\n- phi\n- 45-cfr-164\n- risk-analysis\n- baa\n- breach-notification\n- ocr\n- compliance\n- governance\nversion: \"1.0\"\nauthor: andrewibrah\nlicense: Apache-2.0\nnist_csf:\n- GV.OC-03\n- GV.RM-01\n- ID.RA-01\n- ID.RA-05\n- PR.DS-01\n- PR.AA-01\n- DE.CM-01\nmitre_attack:\n- T1078\n- T1566\n- T1486\n- T1530\n- T1048\n---\n\n# Implementing HIPAA Security Rule Safeguards\n\n## When to Use\n\n- When an organization is a **covered entity** (health plan, clearinghouse, or provider transmitting electronic transactions) or a **business associate** handling **ePHI** on their behalf.\n- When standing up or maturing controls to protect **electronic protected health information**.\n- When performing the mandatory **HIPAA Security Risk Analysis** (§164.308(a)(1)(ii)(A)) — the single most-cited gap in OCR enforcement.\n- When preparing for an **OCR audit\u002Finvestigation** or responding to a suspected **breach**.\n- When drafting, reviewing, or remediating a **Business Associate Agreement (BAA)**.\n- When mapping existing security controls to the HIPAA safeguard standards and implementation specifications.\n\n> Scope note: this skill covers the **Security Rule** (ePHI). The **Privacy Rule** (uses\u002Fdisclosures of all PHI) and the **Breach Notification Rule** are related but distinct; this skill touches breach readiness and BAAs where they intersect security.\n\n## Prerequisites\n\n- A clear determination of the organization's **role** (covered entity vs business associate) and where ePHI lives, flows, and is stored (an ePHI data map).\n- An **asset inventory** of systems that create, receive, maintain, or transmit ePHI.\n- Knowledge of the current rule's structure (45 CFR §§164.302–318) and the **required vs addressable** distinction.\n- Awareness that a **2025 NPRM** proposes significant changes (see Workflow step 7 and `references\u002Fstandards.md`) — track but do not assume them as in force.\n\n## Workflow\n\n### 1. Conduct the Security Risk Analysis (§164.308(a)(1)(ii)(A))\nThis is **required** and foundational. Inventory ePHI and systems, identify threats and vulnerabilities, assess current controls, determine likelihood and impact, and assign risk levels. (Pair with the NIST 800-30 methodology and HHS's SRA Tool.) Output is a documented, dated risk analysis — the artifact OCR asks for first.\n\n### 2. Implement Administrative Safeguards (§164.308)\nThe largest section. Includes the **Security Management Process** (risk analysis, risk management, sanction policy, information-system activity review), assigned **security responsibility** (a named Security Official), **workforce security**, **information access management**, **security awareness and training**, **security incident procedures**, **contingency planning** (data backup, disaster recovery, emergency-mode operation), **evaluation**, and **BAAs** with business associates.\n\n### 3. Implement Physical Safeguards (§164.310)\n**Facility access controls**, **workstation use** and **workstation security**, and **device and media controls** (disposal, media re-use, accountability, data backup and storage).\n\n### 4. Implement Technical Safeguards (§164.312)\n**Access control** (unique user ID, emergency access, automatic logoff, encryption\u002Fdecryption), **audit controls**, **integrity** (mechanisms to authenticate ePHI), **person\u002Fentity authentication**, and **transmission security** (integrity controls + encryption).\n\n### 5. Resolve \"Required\" vs \"Addressable\" specifications\nUnder the current rule, each implementation specification is **Required** (must implement) or **Addressable** (assess whether reasonable and appropriate; if so implement, if not document why and implement an equivalent alternative). **Addressable does not mean optional** — it means make and document a risk-based decision.\n\n### 6. Execute Business Associate Agreements (§164.314 \u002F §164.308(b))\nEvery business associate that touches ePHI needs a BAA binding it to safeguard ePHI, report incidents, and flow requirements to subcontractors. Maintain the BAA inventory.\n\n### 7. Track the 2025 NPRM proposed changes (NOT yet final)\nHHS OCR published an NPRM (Jan 6, 2025) proposing to **remove the required\u002Faddressable distinction** (make nearly all specifications required), and to mandate **MFA**, **encryption of ePHI at rest and in transit**, **asset inventory and network maps**, **vulnerability scans every 6 months**, **annual penetration testing**, **72-hour restoration of certain systems\u002Fdata**, and **annual risk-analysis updates**. **These are proposals** — the current rule remains in force until a final rule is published and effective. Plan toward them, but comply with what is current.\n\n### 8. Stand up breach-notification readiness (45 CFR §§164.400–414)\nDefine how you detect, assess (the four-factor risk assessment), and report breaches of unsecured PHI: to **individuals** and **HHS** (and **media** for breaches affecting 500+ in a state\u002Fjurisdiction), within the required timelines. Encryption to NIST standards renders PHI \"secured\" and is a safe harbor from breach notification.\n\n### 9. Document everything (§164.316)\nMaintain policies, procedures, and records of actions\u002Fdecisions in writing, **retain for six years**, review periodically, and update in response to environmental or operational change.\n\n## Key Concepts\n\n| Concept | Definition |\n|---|---|\n| ePHI | Electronic protected health information — the Security Rule's scope. |\n| Covered entity | Health plan, clearinghouse, or provider doing electronic transactions. |\n| Business associate | A vendor that handles ePHI for a covered entity; bound by a BAA. |\n| Risk analysis | Required, documented assessment of risks to ePHI (§164.308(a)(1)(ii)(A)). |\n| Required vs addressable | Must-implement vs risk-based-decision implementation specifications. |\n| Administrative \u002F Physical \u002F Technical safeguards | §164.308 \u002F §164.310 \u002F §164.312. |\n| BAA | Business Associate Agreement — contractually binds vendors to safeguard ePHI. |\n| Breach (unsecured PHI) | Triggers notification under §§164.400–414; encryption is a safe harbor. |\n| OCR | HHS Office for Civil Rights — enforces HIPAA. |\n| Six-year retention | Documentation retention requirement (§164.316). |\n\n## Tools & Systems\n\n- **45 CFR Part 164 Subpart C** — the Security Rule text (and Subpart D, Breach Notification).\n- **HHS Security Risk Assessment (SRA) Tool** — free guided risk analysis.\n- **NIST SP 800-66 Rev 2** — implementing the HIPAA Security Rule (NIST guidance, maps to 800-53).\n- **NIST SP 800-30** — risk-assessment methodology to ground the SRA.\n- **GRC \u002F compliance platforms** — to manage policies, the BAA inventory, and evidence.\n- **Encryption \u002F MFA \u002F SIEM \u002F audit-logging tooling** — to satisfy technical safeguards and the proposed mandates.\n\n## Common Scenarios\n\n- **OCR investigation after a breach.** First request is almost always the current, dated **risk analysis** and the **risk-management plan** — have them ready.\n- **New SaaS handling ePHI.** Sign a **BAA** before any ePHI flows; confirm the vendor's safeguards.\n- **Addressable spec you won't implement as written.** Document the risk-based rationale and the **equivalent alternative** you implemented instead.\n- **Preparing for the proposed rule.** Pre-position MFA, at-rest\u002Fin-transit encryption, asset inventory, scanning, and pen-testing so a final rule is a small step, not a scramble.\n- **Lost\u002Fstolen device.** If ePHI was encrypted to NIST standards, the safe harbor applies; if not, run the four-factor breach assessment and notify as required.\n\n## Output Format\n\nProduce a **HIPAA Security Rule Gap Assessment** using `assets\u002Ftemplate.md`, containing:\n\n1. **Role & ePHI scope** — covered entity vs BA; ePHI data map and systems.\n2. **Risk analysis summary** — top risks to ePHI with likelihood\u002Fimpact (feeds risk management).\n3. **Safeguard status** — Administrative \u002F Physical \u002F Technical, each specification marked **Implemented \u002F Partial \u002F Gap** with required-vs-addressable noted.\n4. **BAA inventory** — business associates and BAA status.\n5. **Breach-notification readiness** — detection, four-factor assessment, notification workflow.\n6. **2025 NPRM gap view** — readiness against the proposed mandates (clearly labeled proposed).\n7. **Remediation plan** — prioritized, with owners and dates; required specs and risk-analysis gaps first.\n\nUse `scripts\u002Fprocess.py` to score a safeguard-status JSON across the §164.308\u002F310\u002F312 standards, weight required gaps above addressable ones, and emit the gap table plus a remediation-priority list.\n","# Implementing HIPAA Security Rule Safeguards\n\n## When to Use\n\n- When an organization is a **covered entity** (health plan, clearinghouse, or provider transmitting electronic transactions) or a **business associate** handling **ePHI** on their behalf.\n- When standing up or maturing controls to protect **electronic protected health information**.\n- When performing the mandatory **HIPAA Security Risk Analysis** (§164.308(a)(1)(ii)(A)) — the single most-cited gap in OCR enforcement.\n- When preparing for an **OCR audit\u002Finvestigation** or responding to a suspected **breach**.\n- When drafting, reviewing, or remediating a **Business Associate Agreement (BAA)**.\n- When mapping existing security controls to the HIPAA safeguard standards and implementation specifications.\n\n> Scope note: this skill covers the **Security Rule** (ePHI). The **Privacy Rule** (uses\u002Fdisclosures of all PHI) and the **Breach Notification Rule** are related but distinct; this skill touches breach readiness and BAAs where they intersect security.\n\n## Prerequisites\n\n- A clear determination of the organization's **role** (covered entity vs business associate) and where ePHI lives, flows, and is stored (an ePHI data map).\n- An **asset inventory** of systems that create, receive, maintain, or transmit ePHI.\n- Knowledge of the current rule's structure (45 CFR §§164.302–318) and the **required vs addressable** distinction.\n- Awareness that a **2025 NPRM** proposes significant changes (see Workflow step 7 and `references\u002Fstandards.md`) — track but do not assume them as in force.\n\n## Workflow\n\n### 1. Conduct the Security Risk Analysis (§164.308(a)(1)(ii)(A))\nThis is **required** and foundational. Inventory ePHI and systems, identify threats and vulnerabilities, assess current controls, determine likelihood and impact, and assign risk levels. (Pair with the NIST 800-30 methodology and HHS's SRA Tool.) Output is a documented, dated risk analysis — the artifact OCR asks for first.\n\n### 2. Implement Administrative Safeguards (§164.308)\nThe largest section. Includes the **Security Management Process** (risk analysis, risk management, sanction policy, information-system activity review), assigned **security responsibility** (a named Security Official), **workforce security**, **information access management**, **security awareness and training**, **security incident procedures**, **contingency planning** (data backup, disaster recovery, emergency-mode operation), **evaluation**, and **BAAs** with business associates.\n\n### 3. Implement Physical Safeguards (§164.310)\n**Facility access controls**, **workstation use** and **workstation security**, and **device and media controls** (disposal, media re-use, accountability, data backup and storage).\n\n### 4. Implement Technical Safeguards (§164.312)\n**Access control** (unique user ID, emergency access, automatic logoff, encryption\u002Fdecryption), **audit controls**, **integrity** (mechanisms to authenticate ePHI), **person\u002Fentity authentication**, and **transmission security** (integrity controls + encryption).\n\n### 5. Resolve \"Required\" vs \"Addressable\" specifications\nUnder the current rule, each implementation specification is **Required** (must implement) or **Addressable** (assess whether reasonable and appropriate; if so implement, if not document why and implement an equivalent alternative). **Addressable does not mean optional** — it means make and document a risk-based decision.\n\n### 6. Execute Business Associate Agreements (§164.314 \u002F §164.308(b))\nEvery business associate that touches ePHI needs a BAA binding it to safeguard ePHI, report incidents, and flow requirements to subcontractors. Maintain the BAA inventory.\n\n### 7. Track the 2025 NPRM proposed changes (NOT yet final)\nHHS OCR published an NPRM (Jan 6, 2025) proposing to **remove the required\u002Faddressable distinction** (make nearly all specifications required), and to mandate **MFA**, **encryption of ePHI at rest and in transit**, **asset inventory and network maps**, **vulnerability scans every 6 months**, **annual penetration testing**, **72-hour restoration of certain systems\u002Fdata**, and **annual risk-analysis updates**. **These are proposals** — the current rule remains in force until a final rule is published and effective. Plan toward them, but comply with what is current.\n\n### 8. Stand up breach-notification readiness (45 CFR §§164.400–414)\nDefine how you detect, assess (the four-factor risk assessment), and report breaches of unsecured PHI: to **individuals** and **HHS** (and **media** for breaches affecting 500+ in a state\u002Fjurisdiction), within the required timelines. Encryption to NIST standards renders PHI \"secured\" and is a safe harbor from breach notification.\n\n### 9. Document everything (§164.316)\nMaintain policies, procedures, and records of actions\u002Fdecisions in writing, **retain for six years**, review periodically, and update in response to environmental or operational change.\n\n## Key Concepts\n\n| Concept | Definition |\n|---|---|\n| ePHI | Electronic protected health information — the Security Rule's scope. |\n| Covered entity | Health plan, clearinghouse, or provider doing electronic transactions. |\n| Business associate | A vendor that handles ePHI for a covered entity; bound by a BAA. |\n| Risk analysis | Required, documented assessment of risks to ePHI (§164.308(a)(1)(ii)(A)). |\n| Required vs addressable | Must-implement vs risk-based-decision implementation specifications. |\n| Administrative \u002F Physical \u002F Technical safeguards | §164.308 \u002F §164.310 \u002F §164.312. |\n| BAA | Business Associate Agreement — contractually binds vendors to safeguard ePHI. |\n| Breach (unsecured PHI) | Triggers notification under §§164.400–414; encryption is a safe harbor. |\n| OCR | HHS Office for Civil Rights — enforces HIPAA. |\n| Six-year retention | Documentation retention requirement (§164.316). |\n\n## Tools & Systems\n\n- **45 CFR Part 164 Subpart C** — the Security Rule text (and Subpart D, Breach Notification).\n- **HHS Security Risk Assessment (SRA) Tool** — free guided risk analysis.\n- **NIST SP 800-66 Rev 2** — implementing the HIPAA Security Rule (NIST guidance, maps to 800-53).\n- **NIST SP 800-30** — risk-assessment methodology to ground the SRA.\n- **GRC \u002F compliance platforms** — to manage policies, the BAA inventory, and evidence.\n- **Encryption \u002F MFA \u002F SIEM \u002F audit-logging tooling** — to satisfy technical safeguards and the proposed mandates.\n\n## Common Scenarios\n\n- **OCR investigation after a breach.** First request is almost always the current, dated **risk analysis** and the **risk-management plan** — have them ready.\n- **New SaaS handling ePHI.** Sign a **BAA** before any ePHI flows; confirm the vendor's safeguards.\n- **Addressable spec you won't implement as written.** Document the risk-based rationale and the **equivalent alternative** you implemented instead.\n- **Preparing for the proposed rule.** Pre-position MFA, at-rest\u002Fin-transit encryption, asset inventory, scanning, and pen-testing so a final rule is a small step, not a scramble.\n- **Lost\u002Fstolen device.** If ePHI was encrypted to NIST standards, the safe harbor applies; if not, run the four-factor breach assessment and notify as required.\n\n## Output Format\n\nProduce a **HIPAA Security Rule Gap Assessment** using `assets\u002Ftemplate.md`, containing:\n\n1. **Role & ePHI scope** — covered entity vs BA; ePHI data map and systems.\n2. **Risk analysis summary** — top risks to ePHI with likelihood\u002Fimpact (feeds risk management).\n3. **Safeguard status** — Administrative \u002F Physical \u002F Technical, each specification marked **Implemented \u002F Partial \u002F Gap** with required-vs-addressable noted.\n4. **BAA inventory** — business associates and BAA status.\n5. **Breach-notification readiness** — detection, four-factor assessment, notification workflow.\n6. **2025 NPRM gap view** — readiness against the proposed mandates (clearly labeled proposed).\n7. **Remediation plan** — prioritized, with owners and dates; required specs and risk-analysis gaps first.\n\nUse `scripts\u002Fprocess.py` to score a safeguard-status JSON across the §164.308\u002F310\u002F312 standards, weight required gaps above addressable ones, and emit the gap table plus a remediation-priority list.\n",{"name":5,"tags":44,"author":49,"domain":38,"license":15,"version":50,"nist_csf":51,"subdomain":59,"description":7,"mitre_attack":60},[19,35,36,37,45,46,47,48,31,28,23],"45-cfr-164","risk-analysis","baa","breach-notification","andrewibrah","1.0",[52,53,54,55,56,57,58],"GV.OC-03","GV.RM-01","ID.RA-01","ID.RA-05","PR.DS-01","PR.AA-01","DE.CM-01","compliance-governance",[61,62,63,64,65],"T1078","T1566","T1486","T1530","T1048","main","54a798831d2266a3ca61ce68a7acb80b81160d57","skills\u002Fimplementing-hipaa-security-rule-safeguards",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":77,"prompt":87,"zipAvailable":88},[78,81,84],{"tool":79,"command":80},"npx","npx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill implementing-hipaa-security-rule-safeguards",{"tool":82,"command":83},"bunx","bunx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill implementing-hipaa-security-rule-safeguards",{"tool":85,"command":86},"pnpm","pnpm dlx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill implementing-hipaa-security-rule-safeguards","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fimplementing-hipaa-security-rule-safeguards\u002FSKILL.md",true,[90,96,102,107,111],{"path":91,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":94,"sourceHtmlUrl":95},"agents\u002Fopenai.yaml","REFERENCE","参考文档",108,"https:\u002F\u002Fgithub.com\u002Ffderuiter\u002FQRCraftly-web\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fscaffold-exercises\u002Fagents\u002Fopenai.yaml",{"path":97,"resourceType":98,"resourceTypeDesc":99,"sizeBytes":100,"sourceHtmlUrl":101},"assets\u002Ftemplate.md","ASSET","资产文件",4105,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fimplementing-hipaa-security-rule-safeguards\u002Fassets\u002Ftemplate.md",{"path":103,"resourceType":103,"resourceTypeDesc":104,"sizeBytes":105,"sourceHtmlUrl":106},"LICENSE","许可证",11255,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fimplementing-hipaa-security-rule-safeguards\u002FLICENSE",{"path":108,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":109,"sourceHtmlUrl":110},"references\u002Fstandards.md",5612,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fimplementing-hipaa-security-rule-safeguards\u002Freferences\u002Fstandards.md",{"path":112,"resourceType":113,"resourceTypeDesc":114,"sizeBytes":115,"sourceHtmlUrl":116},"scripts\u002Fprocess.py","SCRIPT","脚本",7836,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fimplementing-hipaa-security-rule-safeguards\u002Fscripts\u002Fprocess.py",[118,147,171,197,223,249],{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":129,"publishedAt":39},"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",[124],{"categoryNo":125,"categoryName":126,"taxonomyType":127,"taxonomyTypeDesc":128},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[130,131,132,133,22,38,134,135,26,136,137,138,139,140,141,142,143,144,145,146],"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":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":154,"publishedAt":39},"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",[153],{"categoryNo":125,"categoryName":126,"taxonomyType":127,"taxonomyTypeDesc":128},[155,143,156,157,22,158,38,26,159,160,161,162,163,164,165,166,167,168,169,170],"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":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":175,"categories":176,"keywords":181,"publishedAt":39},"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",[177,180],{"categoryNo":178,"categoryName":179,"taxonomyType":127,"taxonomyTypeDesc":128},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":125,"categoryName":126,"taxonomyType":127,"taxonomyTypeDesc":128},[165,182,183,184,185,38,186,187,159,28,188,189,190,191,192,32,193,194,195,196],"backup","recovery","validating backup integrity for recovery","testing","infrastructure","validation","hash-verification","incident-response","ransomware","cryptocurrency","detection","t1490","immutable","disaster-recovery","restore-testing",{"skillNo":198,"name":199,"nameZh":6,"description":200,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":201,"categories":202,"keywords":204,"publishedAt":39},"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",[203],{"categoryNo":125,"categoryName":126,"taxonomyType":127,"taxonomyTypeDesc":128},[205,206,207,38,208,209,210,211,212,213,214,215,216,217,218,219,162,220,221,222],"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":224,"name":225,"nameZh":6,"description":226,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":227,"categories":228,"keywords":230,"publishedAt":39},"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",[229],{"categoryNo":125,"categoryName":126,"taxonomyType":127,"taxonomyTypeDesc":128},[231,232,233,38,234,235,236,237,238,239,240,241,242,243,33,244,245,246,247,248],"vulnerabilities","framework","triaging vulnerabilities with ssvc framework","status","planning","CISA","vulnerability-management","risk-management","nessus","qualys","openvas","cvss","remediation","vulnerability","api","prioritization","ssvc","decision-tree",{"skillNo":250,"name":251,"nameZh":6,"description":252,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":253,"categories":254,"keywords":256,"publishedAt":39},"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",[255],{"categoryNo":125,"categoryName":126,"taxonomyType":127,"taxonomyTypeDesc":128},[22,257,38,258,259,260,261,262,263,264,265,32,266,193,267,268,269,270,271,272],"triaging security incident","siem","file","ioc","soc","NIST-800-61","NIST","severity","edr","execution","analysis","classification","severity-classification","incident-triage","SANS-PICERL","SOC-operations"]