mcpField
B
breach-risk-assessment

breach-risk-assessment

github.com/mukul975安全32338 次安装32 周前更新
代码仓库

关于 breach-risk-assessment

该 Skill 提供基于 GDPR 和 EDPB 指南的数据泄露风险评估方法,适用于判断是否需要通知监管机构或数据主体的团队。它结合泄露类型分类、因素评分、阈值判断和文档记录。

主要功能

  1. 01按机密性、完整性和可用性分类
  2. 02评估数据敏感度与受影响人数
  3. 03依据六项因素进行风险评分
  4. 04按阈值判断通知义务
  5. 05记录评估依据与决策

适用场景

  1. 01评估个人数据泄露的通知义务
  2. 02比较不同泄露情境的风险
  3. 03记录 DPO 建议和管理层决定
  4. 04在新信息出现时重新评估风险

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/mukul975/privacy-data-protection-skills --skill breach-risk-assessment

安装后在 Claude Code 中输入/breach-risk-assessment确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

assets/
template.md
references/
standards.md
workflows.md
scripts/
process.py

详细介绍

开展泄露风险评估

概述

发生个人数据泄露时,控制者必须评估该泄露是否“可能对自然人的权利和自由构成风险”(第 33(1) 条),以确定是否需要通知监管机构;还必须评估其是否“可能构成高风险”(第 34(1) 条),以确定是否需要通知数据主体。本技能基于 EDPB Guidelines 9/2022 和 Guidelines 01/2021,提供了一套结构化、可重复执行的方法。

泄露类型分类(CIA 三元组)

必须首先根据安全受损的类型对每起泄露进行分类:

机密性泄露

未经授权或意外披露个人数据,或未经授权或意外访问个人数据。

场景严重程度指标
包含 50 条客户记录的电子邮件被发送到错误的内部部门低——暴露范围有限,且仅限同一组织内部
包含 200,000 条记录的数据库导出文件被发布到公开的文件共享服务严重——大规模暴露,且可公开访问
员工未经授权访问同事的医疗记录中——范围有限,但涉及敏感数据
包含未加密工资数据的备份磁带在运输途中丢失高——涉及财务数据,且访问者未知
完整性泄露

未经授权或意外更改个人数据。

场景严重程度指标
恶意软件修改临床数据库中的患者用药剂量严重——可能造成身体伤害
软件缺陷覆盖了 5,000 条客户记录中的邮政编码低——字段不敏感,可从备份恢复
未经授权修改员工绩效评估分数中——可能产生就业方面的后果
SQL 注入篡改财务交易记录高——财务数据完整性受损
可用性泄露

意外或未经授权地丧失对个人数据的访问,或销毁个人数据。

场景严重程度指标
勒索软件将人力资源系统加密 48 小时;之后从干净的备份恢复中——暂时无法使用,数据已恢复
火灾烧毁了患者档案的唯一副本严重——永久丢失,影响医疗服务
DDoS 攻击导致客户门户无法访问 6 小时低——暂时中断,未发生数据丢失或受损
加密密钥被销毁,导致加密数据集永久无法读取严重——数据不可逆地丢失

风险评估方法

因素 1:数据敏感性(权重:高)
分数标准示例
1 — 低已公开或容易获取的非敏感数据商务联系信息、公开列出的地址
2 — 中泄露后可能造成轻微不便的个人数据电子邮件地址、电话号码、购买历史记录
3 — 高敏感个人数据,或可能造成重大影响的数据金融账户详情、政府身份证号码、就业记录
4 — 严重特殊类别数据(第 9 条)、刑事定罪数据(第 10 条)或可能造成重大伤害的数据健康记录、生物识别数据、遗传数据、性取向、政治观点
因素 2:受影响的数据主体数量
分数数据主体数量理由
1少于 100 人规模有限——可逐一评估
2100 至 1,000 人规模中等——需要有序应对
31,000 至 100,000 人规模较大——对组织有重大影响
4超过 100,000 人大规模——可能对社会造成广泛影响
因素 3:易于识别程度
分数标准
1数据经过假名化或加密;重新识别需要使用单独安全保存的其他数据
2数据仅包含间接标识符;通过适度努力即可重新识别
3数据包含直接标识符(姓名 + 另一项信息);个人很容易被识别
4数据包含多个直接标识符、照片或生物识别数据;可立即识别个人
因素 4:后果严重程度
分数潜在后果
1轻微不便——例如收到未经请求的营销信息、需要更改密码
2中等影响——例如遭受定向网络钓鱼的风险、轻微财务损失、声誉受损带来的不便
3重大影响——例如身份盗窃风险、重大财务损失、就业方面的后果、歧视风险
4严重影响——例如人身安全威胁、重大金融欺诈、无法获得基本服务、生命受到威胁
因素 5:个人特征
分数标准
1没有较高脆弱性的普通成年人群体
2群体中包括处于依附关系中的部分个人(员工、租户)
3群体中包括老年人、经济脆弱人群或处于权力不平等关系中的个人
4群体中包括未成年人、患者、寻求庇护者,或安全依赖于数据保密性的个人
因素 6:控制者特定因素
分数标准
1控制者将个人数据处理作为辅助活动(例如办公室管理)
2控制者将个人数据处理作为提供服务的核心活动
3控制者处于受信赖地位(金融机构、医疗服务提供者、教育机构)
4控制者将大规模数据处理作为核心业务(数据经纪商、支付处理商、社交媒体平台)

评分矩阵与阈值

总分风险等级Art. 33 SA 通知Art. 34 DS 通知必要行动
6-8不太可能导致风险无需通知无需通知仅在 Art. 33(5) 违规事件登记簿中记录
9-12存在风险,但未达到高风险阈值须在 72 小时内通知无需通知通知监管机构;完整记录
13-18可能导致风险,接近高风险须在 72 小时内通知建议通知通知 SA;强烈建议考虑通知 DS
19-24可能导致高风险须在 72 小时内通知须在不无故拖延的情况下通知通知 SA 和数据主体

EDPB 违规场景分析(Guidelines 01/2021)

场景 1:有备份可用的勒索软件攻击
  • 事实:医院遭受勒索软件攻击。患者数据被加密。已在 24 小时内从干净备份恢复。没有证据表明数据遭到外泄。
  • 分类:可用性违规。
  • 风险评估:数据敏感度 = 4(健康数据),数据量 = 3(2,500 名患者),可识别性 = 4,后果 = 3(治疗延迟),脆弱性 = 4(患者),控制者 = 3(医疗机构)。总分 = 21。
  • EDPB 结论:通知 SA 和数据主体。尽管有备份可用,但在 24 小时恢复期间健康数据暂时无法使用,对患者安全构成了高风险。
场景 2:没有备份的勒索软件攻击
  • 事实:一家小型制造公司遭遇勒索软件攻击。员工薪资数据永久丢失。没有备份。
  • 分类:可用性泄露(永久性)。
  • 风险评估:数据敏感度 = 3,数据量 = 1(45 名员工),可识别性 = 4,后果 = 3,脆弱性 = 2,控制者 = 2。总分 = 15。
  • EDPB 结论:通知 SA 和数据主体。薪资数据永久丢失会直接影响员工的财务利益。
场景 3:网站数据外泄
  • 事实:SQL 注入攻击从电商平台窃取了 120 万名注册用户的用户名、哈希密码和电子邮件地址。
  • 分类:保密性泄露。
  • 风险评估:数据敏感度 = 2,数据量 = 4,可识别性 = 3,后果 = 2,脆弱性 = 1,控制者 = 3。总分 = 15。
  • EDPB 结论:通知 SA 和数据主体。电子邮件地址与哈希密码相结合,可能导致攻击者利用凭据填充攻击其他服务。
场景 4:电子邮件误发(单个收件人)
  • 事实:人力资源部门通过电子邮件将一名员工的工资单发送给了错误的内部同事。错误在 10 分钟内被发现。收件人确认已删除。
  • 分类:保密性泄露。
  • 风险评估:数据敏感度 = 3,数据量 = 1,可识别性 = 4,后果 = 1,脆弱性 = 2,控制者 = 1。总分 = 12。
  • EDPB 结论:通知 SA(临界情况)。无需通知数据主体。泄露已得到控制,收件人身份明确且配合,财务数据暴露范围有限。
场景 5:未加密的 USB 驱动器丢失
  • 事实:一名员工丢失了一个未加密的 USB 驱动器,其中包含 3,500 名养老金计划成员的姓名、地址和国家保险号码。
  • 分类:保密性泄露。
  • 风险评估:数据敏感度 = 3,数据量 = 3,可识别性 = 4,后果 = 3,脆弱性 = 3(老年人/退休人员),控制者 = 3。总分 = 19。
  • EDPB 结论:通知 SA 和数据主体。政府身份标识信息与脆弱群体(退休人员)的结合会带来较高的身份盗窃风险。
场景 6:意外公开学生成绩
  • 事实:一所大学意外在可公开访问的网页上发布了带有学生姓名的考试成绩,36 小时后才将其删除。
  • 分类:保密性泄露。
  • 风险评估:数据敏感度 = 2,数据量 = 2(800 名学生),可识别性 = 4,后果 = 2,脆弱性 = 2,控制者 = 3(教育)。总分 = 15。
  • EDPB 结论:通知 SA 和数据主体。学业表现数据与姓名相关联,公开暴露了 36 小时,可能影响学生的学业和职业前景。

评估文档要求

每项泄露风险评估都必须记录以下要素:

  1. 评估元数据:日期、评估人姓名、泄露事件参考编号、版本
  2. 泄露事件描述:对所发生事件的事实摘要
  3. CIA 分类:泄露的类型
  4. 逐项因素评分:为每个因素评分并提供书面理由
  5. 总分和阈值判定:适用哪些通知义务
  6. DPO 建议:DPO 是否同意评估结果
  7. 管理层决定:最终通知决定及签字确认
  8. 重新评估触发条件:需要重新评分的情况(例如,后来确认发生了数据外泄)

常见评估错误

  1. 因“未确认”数据外泄而低估后果:没有数据外泄的证据,并不代表没有发生数据外泄。评估后果时,应考虑数据落入未经授权者手中可能造成的影响。
  2. 将加密数据一概视为低风险:只有在加密密钥也未遭泄露,且加密标准稳健(AES-256 或同等标准)的情况下,加密才能起到缓解作用。
  3. 将多起小规模泄露分开评估:反复发生的类似泄露(例如,多次误发电子邮件)可能表明存在系统性问题,使总体风险高于单起事件所显示的风险。
  4. 忽视可用性泄露:即使保密性未受影响,暂时无法访问健康记录、财务数据或安全关键信息也可能造成损害。
  5. 将 250 名员工豁免适用于通知义务:第 30(5) 条为小型组织提供了有限的 RoPA 豁免,但第 33/34 条规定的数据泄露通知义务并无此类豁免。

评论

支持 Markdown