security-comms

安全沟通——向非安全领域受众讲解安全工作

弥合其他所有技能所造成的沟通鸿沟的技能。审计类技能生成发现项；响应类技能生成事件报告；治理类技能生成路线图。但这些产出一旦呈交给董事会、客户、试图回答安全问卷的销售工程师，或询问“这会让我们花钱吗”的 CFO，就经不起检验。

这项技能会把技术安全工作转化为受众真正能用的交付物。这是安全从业者每周会用上两到三次的技能；而没有专职安全团队的创始人，每当某项发现必须脱离安全领域语境时，也会用到它。

交叉引用：整合其他所有技能的产出（审计结果、事件复盘、威胁模型摘要、CSF 评估），并生成针对特定受众的交付物；与 finding-triage（处置说明）和 incident-triage（响应叙述）的配合尤为紧密。

授权

根据用户提供的事实，为其所在组织起草沟通材料。草稿不代表已获准发送：任何对外材料（面向客户、监管机构、媒体或研究人员）都必须由计划中指定的负责人签字批准，违规通知还需要经过法律审核。未经批准，不要在草稿中写入客户名称、PII 或未经确认的细节。

七类受众（以及他们真正需要什么）

安全沟通并非只有一种表达方式。不同受众需要不同的交付物；使用了错误的表达方式，是最常见的失败原因。

1. 董事会／非执行董事

他们需要了解： 我们是否面临重大风险？团队是否正在处理？是否需要增加投入？

他们不需要了解： CVE 编号、文件路径、扫描器名称、技术术语、方法论。

格式： 一页幻灯片或一页文档。分为三部分——用一段话说明当前态势、列出最重要的三项风险（每项用一句话说明）、列出需要作出的投资决定。数字必须体现重大影响（以金额或影响百分比表示），而不是简单计数（“我们有 47 个漏洞”毫无意义；“支付团队的两项服务存在未修补的问题，攻击者可能利用这些问题访问客户的银行卡数据”则能让他们知道该做什么）。

常见错误： 给董事会看评分热力图和包含 30 行内容的 CVE 表格。他们想知道结论。

2. 执行领导层（CEO／CFO／COO／GC）

他们需要了解： 要他们作出什么决定？需要权衡什么？不采取行动会有什么代价？

格式： 一至三页的备忘录。开篇说明需要作出的决定；然后介绍背景、列出选项及其权衡、给出建议，以及说明如果他们拒绝，成本、时间、人力和风险会如何变化。尽可能量化（监管风险对应的金额、客户信任风险对应的客户流失率、工程工时）。

常见错误： 申请预算，却不说明预算被拒后有哪些替代方案。

3. 工程领导层／资深工程师

他们需要了解： 哪些地方出了问题、如何修复、优先级如何，以及这会如何影响他们的路线图。

格式： 按工单或设计文档的形式撰写。指出具体文件／端点／提交记录。提供复现步骤、修复方案、验证步骤和工作量估算。工程领导层看重具体细节；含糊地说“某处有个 XSS”，只会招致反感。

常见错误： 不展示依据就把安全工作说成紧急事项。工程师希望亲自验证发现的问题。

4. 一线工程师（实际负责处理问题的人）

他们需要了解： 具体要在自己的代码中改什么，以及如何自行运行验证。

格式： 包含代码级细节的工单——文件路径、行号、当前代码、修复后的代码，以及能证明修复有效的测试。这是最具体的一种表达方式。

常见错误： 不加说明地粘贴扫描器输出。工程师不知道扫描器列出的 50 个字段中哪些才重要。

5. 客户成功 / 销售工程

他们需要了解： 如何回答客户的问题。常见安全问卷字段该如何作答。有哪些变化需要告知客户。

格式： 内部 FAQ——问题应采用客户会使用的措辞，答案则应便于销售工程师照读或粘贴到回复中。避免使用安全术语；除非法务确实这么说，否则不要回答“我们无法置评”。

常见错误： 起草面向客户的文案，却未让客户成功团队在发布前检查语气。安全人员写出的语言往往听起来像是在防御或回避。

6. 客户（公开披露后）

他们需要了解： 我的数据是否被访问？你们对此采取了什么措施？我需要做什么？

格式： 一封简短的信。开头先用客户的视角说明发生了什么（而不是你们的说法）。说明可能涉及哪些数据、已采取哪些措施，以及客户应当做什么。提供有效的联系渠道。避免使用企业公关式的缓和措辞；这类措辞听起来像是在回避问题。

常见错误： 明明想表达“我们尚不清楚，但必须告知你”，却说“出于格外谨慎的考虑”。客户看得出来。

向客户披露信息涉及法律和监管层面的问题——此技能会生成草稿；发布前应由法务审阅，必要时还应由外部法律顾问审阅。

7. 采购 / 法务 / 合规相关方（内部或供应商方）

他们需要了解： 我们是否合规、有哪些文档、合同立场是什么、是否有证据？

格式： 结构化材料——问卷答复、BAA / DPA 修订意见、审计证据汇总。使用相关方采用的框架术语（CSF 子类别 ID、ISO 控制项、PCI 要求编号、HIPAA 保障措施名称）。不要转换成你自己的框架；他们希望收到的是他们自己的术语。

常见错误： 只回答“是”或“否”，却不附上证据出处。采购方审核人员需要在答复中直接看到证据，而不是另行索取。

工作流

此技能支持两种模式——根据技术输入起草，或审阅他人撰写的草稿。

模式 1：根据技术输入起草

1. 确定受众。 属于上述七类中的哪一类？如果不止一类，请分别准备材料，不要合并。
2. 明确对方需要作出的决策。 董事会：“批准预算。”工程团队：“在某日期前修复。”客户：“相信我们已妥善处理此事。”如果无法用一句话说明所需决策，那么受众就没有明确的决策要作出，你的材料只是提供信息，而非推动行动。
3. 删去与该受众无关的技术材料。 CVE 编号是给工程师看的。金额是给高管看的。客户影响是给客户看的。同一项发现，需要写成三份不同的草稿。
4. 先写开头。 如果对方只读第一段，他们会记住什么？先写下这一点，再补充支撑细节。
5. 尽可能量化，即使只是大致估算。 “大约影响 8% 的付费客户”胜过“影响一些客户”。如果不知道，就明确说明；不要用含糊其辞的说法搪塞。
6. 请一位能从受众视角出发的第二审核人审阅。 面向工程团队的材料：找另一位工程师。面向客户的披露：找客户成功团队。董事会更新：找一位真正参加董事会会议的人。

模式 2：审阅草稿

1. 检查受众。 措辞和语气是否适合指定受众？
2. 检查决策。 对方需要作出的决策是否一目了然？
3. 检查术语。 标出受众在日常工作中不会使用的词语。
4. 检查含糊措辞。 “出于格外谨慎的考虑”“尽最大努力”“符合行业标准”——这些听起来像是在回避问题。尽可能改成具体陈述。
5. 检查具体程度。 草稿是否说明了发现的问题、已采取的措施、后续计划，并注明相关负责人？

模板

模板：安全事件董事会更新

# Security Update — [Date]
## To: Board
## From: [CISO / equivalent]

### Bottom line
[One sentence — material exposure yes / no, contained yes / no, action needed yes / no]

### What happened
[Two to four sentences in the board's terms. No file paths or CVE numbers.]

### What's been done
- [Action 1, by date]
- [Action 2, by date]

### What we're asking of the board
[If anything — funding, vendor change, communications approval. If nothing, say so.]

### What we'll know by [next-meeting date]
[Open questions, planned investigations]

模板：请求作出决策的高管备忘录

# Memo: [Decision name]
## From: [author]
## To: [decision-maker]
## Date: [date]
## Decision needed by: [date]

### The decision
[One sentence — what you're asking them to approve.]

### Why now
[Two sentences — what changed, what the regulatory / customer / risk pressure is.]

### Options
1. [Option A — cost, time, residual risk]
2. [Option B — cost, time, residual risk]
3. [Do nothing — what happens]

### Recommendation
[Which option and why.]

### Cost of inaction
[Specific — regulatory fines, customer-trust impact, engineering hours saved elsewhere, etc.]

模板：面向客户的泄露事件披露（草稿——需法律审核）

# Security Notice
## Date: [date]

Dear [customer],

On [date], we identified [what happened — in the customer's terms]. Information that may have been involved includes [specific data fields]. Information not involved includes [specific data fields].

We have taken the following steps:
- [Action 1]
- [Action 2]

We recommend you:
- [Action 1 they should take, e.g., reset password]
- [Action 2]

If you have questions, contact [working contact path — not a generic security@].

We are sorry this happened.

[Name and title — not a corporate signature]

模板：事后复盘叙述（内部）

# Post-mortem: [Incident name]
## Severity: [SEV1 / SEV2 / SEV3]
## Date detected: [date]
## Date resolved: [date]
## Duration: [hh:mm]
## Authors: [names]

### Summary
[One paragraph that someone outside the response can read and understand the incident.]

### Timeline
[Bulleted, with timestamps in one timezone. Detection → triage → containment → eradication → recovery → all-clear.]

### Impact
- [Who was affected — customers, internal users, third parties]
- [What was affected — service availability, data confidentiality, data integrity]
- [Quantify where possible — affected user count, downtime minutes, data records involved]

### Root cause
[The actual root cause — not the proximate trigger. Why did the trigger lead to user impact?]

### What went well
[Two to four items. Be specific.]

### What did not go well
[Two to four items. Be specific. No blame language.]

### Action items
| Item | Owner | Deadline | Status |
|------|-------|----------|--------|

### Lessons for the rest of the org
[What other teams should change based on this incident.]

模板：审计发现事项转述（供工程团队使用）

# Security Findings — [Project / sprint]
## Audit source: [owasp-audit / api-audit / etc.]
## Date: [date]

### Summary
[One sentence — N findings, severity breakdown, target resolution window.]

### Findings (prioritized)
| ID | Severity | File / endpoint | Effort estimate | Sprint candidate |
|----|----------|-----------------|-----------------|------------------|

### Per-finding detail
[Per-finding entries with file:line, reproduction, fix proposal, verification step, effort estimate.]

### Not findings (FYI)
[Items the scanner / audit flagged that we've determined are not real — with one line each on why. This builds engineering trust that we're not crying wolf.]

模板：销售工程常见问题解答

# Customer Q&A — [Topic, e.g., recent vulnerability disclosure]
## Internal — for SE use; not customer-facing

**Q: Were we affected by [CVE / event]?**
A: [Straight answer. Yes / no / partially with which part.]

**Q: What did you do about it?**
A: [Specific actions with dates.]

**Q: Should I be doing anything on my end?**
A: [Customer-facing recommendation, or "no action required, here's why."]

**Q: When can I expect a written notice?**
A: [Date / not applicable / "you're reading the only one, you can quote it."]

**Q: [Other anticipated question]**
A: [...]

**If asked something not on this list:** [Escalation path — to whom, with what info, how fast.]

审核 AI 生成的安全沟通内容

特别说明：这项技能本身也会供 AI Agent 使用。

AI 生成安全沟通内容时，未经熟悉相关受众的人工审核者审阅，不要将其发送出去。具体来说：

• 面向客户的披露内容必须经过法律审核后才能发送
• 面向董事会的更新内容应由 CEO / CISO 审阅后才能放入演示文稿
• 高管备忘录应由了解该高管决策风格的人审阅
• 工程工单可以采用较宽松的审核，但不得跳过验证步骤

AI 起草的安全沟通内容最适合作为初稿，而非终稿。这项技能可将起草初稿的时间从 90 分钟缩短至 10 分钟，但不能免去审核流程。

边界

• 这项技能用于生成沟通材料；它不授权披露信息
• 面向客户的泄露事件披露涉及法律、监管（GDPR 第 33 条、HIPAA 泄露通知规则、各州泄露通知法，以及上市公司重大事件的 SEC 8-K 披露要求）和合同层面的考量——草稿不等于已发送的消息
• 拒绝起草旨在误导的沟通内容，包括淡化重大影响、错误归咎，或将已接受风险的发现事项描述为已解决
• 未经授权，不得起草披露个别客户姓名或其个人身份信息（PII）的内容
• 对于涉及执法部门介入的事件（勒索软件付款、国家级行为体归因），应与法律顾问共同制定沟通策略——这项技能为指定受众起草材料，不负责执法部门方面的内容

参考资料

• 《Crafting the InfoSec Playbook》——Bollinger / Enright / Valites（沟通章节）
• SANS——《Communicating with Executives》报告（年度报告）
• 《The Manager's Path》——Camille Fournier（关于面向非技术受众写作）
• SEC《网络安全风险管理、战略、治理和事件披露最终规则》（2023）——重大事件披露时限
• GDPR 第 33 条（泄露通知时限——72 小时内通知监管机构）
• HIPAA 泄露通知规则（60 天内通知受影响个人）
• ENISA——《危机沟通指南》
• 《Cybersecurity Incident Response: How to Contain, Eradicate, and Recover from Incidents》——Eric C. Thompson