跳转至

Lecture11

LaTeX 源码

\makecscover

来源审计：把个人案件转化为组织工程课

Joe Sullivan 的职业路径横跨联邦网络犯罪检察、科技公司 security leadership、漏洞披露生态与公益项目。课堂因此同时包含职业经验、个人案件叙述、政策判断和领导力建议。高质量讲义不能把这些内容混成一种“事实”：讲者对事件的回忆属于课堂陈述，检方的主张属于指控，陪审团与法院处理的是法律责任，而本文负责提炼可复用的工程和治理机制。

法律与时间边界

本文是 security engineering 与 governance 讲义，不构成法律意见。课堂录制于 2025 年 1 月，当时 Sullivan 的上诉尚未裁决；第九巡回法院于 2025 年 3 月 13 日维持定罪，2025 年 11 月 12 日发布修订意见并拒绝全院复审，美国最高法院于 2026 年 6 月 29 日拒绝受理 certiorari petition。课堂中的上诉预期只能作为历史观点，不能写成当前程序状态。

本讲的三个治理闭环

  1. External-report loop：接收外部报告 \(\rightarrow\) 验证与定级 \(\rightarrow\) 修复 \(\rightarrow\) 协调披露或奖励；
  2. Incident loop：检测 \(\rightarrow\) 控制影响 \(\rightarrow\) 保存证据 \(\rightarrow\) 调查、恢复与复盘；
  3. Disclosure loop：技术事实 \(\rightarrow\) 法务与 materiality 分析 \(\rightarrow\) 高管/董事会决策 \(\rightarrow\) 对监管者、客户或公众沟通。

三个闭环可以由同一条线索触发，却不能由同一个人、同一张 ticket 或同一种激励机制代替。

Security program 不是一个“英雄 CSO”

安全领导者经常以个人能力被评价：能否发现攻击、能否说服 CEO、能否在危机里快速拍板。然而规模化组织真正需要的是 \term{security program}（安全项目）：明确人员能力、重复流程、技术平台和治理权责，使正确行为不依赖某位负责人临场发挥。Sullivan 从检察官转向 eBay、Facebook、Uber 等技术公司的经历，最有价值的共同主题不是公司名，而是安全团队必须随组织复杂度一起升级。

\lecturefigure{01-security-program.png}{可持续的 security program 同时依赖 people、process、platform 与 governance。}{本地字幕 00:00--03:20；概念重绘。}

读图：四层缺一不可

先看左上角的 people：人才、值班、沟通和决策能力决定组织能否理解事件。Process 把 intake、incident command、disclosure 与复盘变成可重复路径。Platform 提供 identity、telemetry、case management 和 evidence storage。Governance 则回答谁有 authority、谁接受 challenge、谁签署外部披露。只建设工具会得到“告警很多、决定很少”；只依赖专家会得到“专家离开、系统失忆”。

\teachervoice{Sullivan 的职业故事把法律、工程和组织放在同一个视野里。课堂提示：security leader 的稀缺价值不是比所有工程师更懂每个漏洞，而是能把技术事实翻译成法律、业务和公共风险，同时确保每种判断由有权负责的人作出。}

术语消化：角色与责任

\term{CSO/CISO} 负责安全能力、风险信息和升级；\term{general counsel}（总法律顾问，GC）负责组织法律分析与律师管理；\term{CEO} 对企业优先级与重大经营决定负责；\term{board/disclosure committee} 提供监督并处理重大披露。角色可以因公司规模不同而合并，但“谁提供事实、谁给法律意见、谁承担经营决定”必须显式区分。

本章小结

本讲不以“谁说得更有道理”为主线，而以 operating system 为主线：外部报告、事件响应与披露治理分别需要 owner、evidence、decision right 和记录。个人案件只用于检验这些机制为何必须存在。

科技、政府与规则：为什么反馈回路总是滞后

科技公司把支付、通信、身份、交通、医疗和 AI 等社会功能转成软件系统，也因此积累了过去由公共机构或受监管基础设施承担的权力。政府必须回应伤害，却常在技术人才、数据可见性和规则迭代速度上落后。企业若把监管视为纯粹外部摩擦，会失去塑造可执行规则的机会；政府若只在事故后执法，也会制造模糊和寒蝉效应。

Public-private feedback loop

理想的政策循环不是“企业先创新、政府最后处罚”，而是技术信号、现实伤害、规则设计、实施能力与行业反馈持续互相校正。这里的关键工程问题是 observability：政府看不到平台内部风险，企业不了解公共政策约束，任何一方都会根据不完整信息设计控制。

\lecturefigure{02-public-private-loop.png}{技术与政府需要连续反馈，而不是事故后的单向问责。}{本地字幕 03:20--06:20；概念重绘。}

读图：反馈必须返回实现层

Technology 产生产品、数据和新风险；observed harms 形成用户、执法与市场信号；policy 把目标写成法律、标准或监管期望；implementation 再落到 controls、reporting 和 feedback。若回路停在政策文本，组织只会得到抽象义务；若停在企业自律，受影响公众没有可靠救济。好的反馈会把规则转成可测试控制，也会把控制失败重新送回政策设计。

“不要监管”与“任何监管都好”都过于简单

规则可能过时、重叠或奖励形式合规，但没有清晰规则同样会把成本转移给用户、研究人员和一线安全团队。课程真正要求的是参与设计：明确想保护的对象、需要观察的证据、允许的实验空间、升级阈值和申诉机制，而不是只表达支持或反对。

\teachervoice{讲者强调，早期科技行业常把“regulation 会扼杀创新”当作 mantra。课堂中更成熟的转折是：缺少规则也会产生摩擦，因为企业不知道边界、用户缺少信任、政府只能借事故和执法反向定义标准。}

规则通过哪些渠道抵达组织

安全义务很少来自单一法条。Congress 或州立法机构可以创建义务，行政机构可以 rulemaking 或监督，NIST 等标准组织提供可操作框架，执法与法院则把一般规则应用到具体事实。跨国公司还面对不同司法辖区、行业规则、合同和客户承诺。治理系统必须维护 obligation inventory，而不能让每个 incident 临时搜索“可能适用什么”。

\lecturefigure{11-regulation-paths.png}{网络安全规则通过立法、标准、监督、执法与法院等多条路径形成。}{本地字幕 06:00--09:10；政府资料；概念重绘。}

读图：区分规则来源与证据类型

Legislation/rules 定义普遍义务；standards 把目标翻译为 controls 和 practices；supervision 通过检查、报告和持续互动观察执行；enforcement/courts 对具体记录作出判断。工程团队不能把标准等同法律，也不能把一宗执法案件当成完整规范。正确做法是让 counsel 建立适用性判断，让安全团队把义务映射到资产、流程、日志和演练证据。

Obligation-to-control mapping

对每项义务维护五列：source（来源）、scope（哪些实体/数据/系统）、trigger（何时生效）、control/evidence（如何证明执行）、owner/reviewer（谁负责、谁挑战）。这样 incident commander 才能快速定位相关要求，而不是在高压时刻把法律研究塞给 on-call engineer。

本章小结

科技与政府之间的张力本质上是反馈、能力和证据问题。组织应主动把法规、标准和执法经验映射为可执行控制，同时让技术人员参与政策讨论，使规则知道系统真正如何失败。

Security Team Maturity：从救火队到嵌入式治理

团队成熟度不是 headcount 曲线。一个 5 人团队可能拥有清晰 authority 和高质量自动化；一个 100 人团队也可能只是接收告警、转发 ticket。成熟的 security organization 会逐步把 threat signal、incident workflow、risk acceptance 和 product decision 嵌入业务系统，使安全不再是发布前的临时审批。

四个阶段与错误捷径

Reactive 阶段依赖少数专家救火；program 阶段建立 intake、on-call、policy 和 repeatable controls；platform 阶段把 identity、telemetry、automation 和 guardrails 做成共享能力；embedded 阶段让 product、finance、legal、HR 和 communications 在日常决策中承担自己的安全责任。阶段不会自动前进，尤其不能用购买产品假装完成组织变革。

\lecturefigure{13-security-maturity.png}{安全团队从 reactive response 走向 embedded governance。}{本地字幕 00:00--03:20；31:20--33:40；概念重绘。}

读图：成熟度的输出不是更多控制，而是更短反馈

Reactive 只能在事件后响应；program 建立角色和运行节奏；platform 让控制可复用、可观察；embedded 把产品 ownership、risk acceptance 与持续改进送回业务。判断成熟度时先看 handoff 是否明确、决策是否留痕、例外是否过期、postmortem 是否改变系统，而不是看 policy 数量或采购金额。

“Security owns risk” 是危险表述

安全团队通常负责识别、分析、建议和监控，但业务负责人拥有产品收益与残余风险，法务负责法律判断，高管和董事会承担重大企业决策。把所有风险都交给 CSO，会让其他负责人在平时缺席、在事故后寻找单点责任人。

成熟团队的最小接口

至少定义：统一 intake、severity taxonomy、incident commander、legal/comms escalation、evidence repository、materiality workstream、exception register、executive exercise 和 post-incident owner。每个接口都应有响应时间、替补角色与可审计输出。

本章小结

团队成长的目标是把个人经验编码为组织接口。越接近 embedded 阶段，越少出现“安全团队知道但高管不知道”“法务判断了但没有技术事实”或“事件结束却无人修改系统”的断裂。

Vulnerability Disclosure Policy：把外部研究变成修复输入

外部研究人员可能比内部团队更早发现问题，但如果没有清晰报告渠道，他们不知道哪些系统可以测试、什么行为被允许、何时会收到回应。\term{Vulnerability Disclosure Policy}（VDP，漏洞披露政策）是一份公开规则与接收机制：定义 scope、授权边界、提交方式、组织承诺和协调沟通。它首先解决“如何安全报告”，并不保证支付奖励。

从 report 到 coordinated disclosure

\term{coordinated vulnerability disclosure}（协调漏洞披露，CVD）是研究人员、受影响组织和可能的供应商在修复与公开之间协调时间、影响范围和信息内容的过程。VDP 的工程价值在于把模糊邮件变成可追踪 workflow：acknowledge、triage、validate、scope、remediate、verify、communicate。这里的 service-level objective 不是为了漂亮 dashboard，而是降低研究人员重复测试、公开升级或失去信任的概率。

\lecturefigure{03-vdp-intake.png}{VDP 将外部研究报告转化为验证、修复与协调披露流程。}{CISA VDP template；本地字幕 12:30--15:20；概念重绘。}

读图：每个 handoff 都要返回状态

Reporter 提交资产、影响和复现证据；triage 确认 scope、severity 与 duplicate；remediation 指定 owner、修复、验证和 timeline；close/disclose 向研究人员更新状态，并在需要时协调供应链或公众。最容易失败的是中间静默：组织已收到却不确认、已修复却不验证、需要延期却不给理由。透明不等于公开所有内部信息，而是建立可预测承诺。

VDP intake 的最小字段

  • 受影响 asset、endpoint 或 product version；
  • 观察到的 security impact 与最小复现证据；
  • 测试时间、researcher contact 和是否可能涉及第三方；
  • 自动生成 case ID、acknowledgement 与状态更新窗口；
  • severity、owner、containment、fix、verification 和 disclosure decision。

不要要求研究人员提交与验证无关的个人资料，也不要让 bounty payment 成为修复排期的唯一优先级。

\teachervoice{Sullivan 把 responsible disclosure 描述为一项基础设施创新：它向善意研究者说明“如果你按这些边界报告，我们希望听到，并会通过既定渠道处理”。课堂提示是关系设计，而不只是 security.txt 地址。}

VDP 不能自动把事件降级为普通漏洞

外部报告可能同时表明 unauthorized access、credential compromise、数据获取或持续威胁。此时 VDP case 仍负责 researcher communication，但事件必须进入独立 incident command、evidence preservation 与 disclosure analysis。把所有事实留在 bounty platform 会遮蔽严重性。

本章小结

VDP 是安全报告渠道和信任合同。它通过 scope、响应承诺与协调修复降低双方不确定性，但一旦事实显示真实 compromise，就必须触发更强的事件治理。

Bug Bounty 与 Safe Harbor：奖励不能替代授权边界

VDP 与 bug bounty 经常一起出现，却解决不同问题。\term{bug bounty program}（漏洞赏金计划）是在既定规则下对符合条件的有效报告提供金钱、积分或认可的可选计划；VDP 即使没有奖金也应存在。Bounty 帮助竞争研究注意力、设定 severity rewards 和运营 triage，但不能通过事后付款重写已经发生的有害行为。

VDP 与 bounty 的边界

一个组织可以有 VDP 而没有 bounty，也可以通过第三方平台管理 bounty。两者共享资产范围、报告渠道与协调机制，但 bounty 还需要 reward table、duplicate rule、eligibility、tax/payment 与 appeal。安全领导者必须防止团队因为“这是 bounty 报告”而忽略 data access、extortion signal 或其他 incident indicators。

\lecturefigure{04-vdp-vs-bounty.png}{VDP 提供安全报告渠道，bug bounty 在此基础上增加可选奖励机制。}{CISA/DOJ VDP guidance；本地字幕 12:30--15:20；概念重绘。}

读图：先问授权，再问奖励

VDP 的核心是 safe channel、scope、response promise 和 coordinated disclosure；bounty 的额外层是 optional payment、severity table、eligibility 与 duplicate。二者都不覆盖 extortion、破坏、超出必要范围的数据访问或拒绝停止测试。评估报告时先判断行为是否符合预先公布的边界和 good faith，再判断漏洞价值和奖励，不要让支付流程决定法律或事件分类。

Payment 不是 post-hoc authorization

组织支付奖金、签署 NDA 或继续沟通，可能是为了控制风险和促成修复；这些动作不会自动证明此前行为获得授权，也不能消除保存证据、通知受影响方或咨询 counsel 的需要。任何“付钱就把 incident 变成 bounty”的捷径都会制造治理盲点。

Safe harbor、scope 与 good faith

\term{safe harbor}（安全港）在 VDP 语境中是组织对符合政策、善意研究行为的承诺，例如不主张某些民事权利、支持研究者说明其善意，或在适用范围内不建议起诉。它不是普遍法律豁免，也不能约束所有第三方。\term{scope}（范围）明确可测试的域名、应用、API、版本与排除资产；\term{good faith}（善意）通常要求只做验证所需的最小访问、避免隐私和服务影响、停止并及时报告。

\lecturefigure{05-safe-harbor.png}{Safe harbor 只有与清晰 scope、善意要求、禁止行为和升级路径结合才有效。}{CISA VDP template；DOJ VDP framework；概念重绘。}

读图：政策必须同时保护研究者与用户

In-scope 列出允许测试的资产和方法；good faith 要求最小化访问、报告和保护敏感数据；prohibited 明确 disruption、persistence、data use 或 extortion 等边界；escalation 提供 safety contact、legal contact 与争议路径。只有鼓励语没有具体 scope，会让研究者承担不可预测风险；只有禁止清单没有响应承诺，则不会形成信任。

政策设计检查表

资产清单必须可维护，第三方服务必须标出所有权边界，测试速率与自动化限制应解释原因，敏感数据处理应规定停止、最小保留和删除，争议应有人工 escalation。政策更新还应保留版本与生效时间，避免组织事后用新规则评价旧行为。

本章小结

VDP 管渠道，bounty 管激励，safe harbor 管符合边界的组织承诺。三者都不能替代 incident classification，也不能把支付、NDA 或善意假设当成技术事实。

Incident Command：一条外部报告何时升级为企业事件

当报告显示 credential 被使用、敏感系统被访问、数据可能离开控制边界或攻击仍在持续，组织面对的已经不只是 vulnerability remediation。\term{incident commander}（事件指挥官，IC）是负责协调目标、优先级、节奏、角色与升级的单一运行负责人；IC 不必亲自完成取证或作出法律结论，但要确保每个 workstream 有 owner，冲突被升级，决策被记录。

跨职能指挥结构

事件响应至少包含 command、technical、legal/comms 和 business 四个 workstream。Technical 团队确认事实、控制影响、修复并恢复；legal/comms 识别义务、privilege 和外部受众；business 处理用户、运营、财务和产品取舍；command 维护共同 timeline、objectives、cadence 与 dependency。让 security on-call 同时担任所有角色，会在压力下把假设误写成事实。

\lecturefigure{06-incident-command.png}{重大安全事件需要 command、technical、legal/comms 与 business 的跨职能结构。}{NIST SP 800-61 Rev. 3；本地字幕 15:10--25:40；概念重绘。}

读图：IC 负责同步，不垄断专业判断

Command 维护 severity、owners 和 decision log；technical 处理 contain、forensics、recovery；legal/comms 分析 privilege、regulators、customers 与 messaging；business 决定 customer impact、continuity 和资源。箭头的含义是双向：技术发现会改变 materiality，法律 deadline 会改变调查优先级，业务恢复动作可能破坏证据，因此任何工作流都不能独立运行。

术语消化：severity、containment 与 recovery

\term{Severity} 是组织对当前影响和紧迫度的运行分类，不等同最终法律 materiality。\term{Containment} 是限制攻击或数据影响的短期动作，例如隔离 credential 或服务。\term{Eradication} 消除根因与 persistence；\term{recovery} 恢复可信服务并监控复发。先恢复业务并不意味着调查结束，先保全证据也不意味着必须延迟所有保护用户的动作。

\teachervoice{课堂叙述中最值得保留的不是具体入侵步骤，而是分类冲突：一条线索可以最初由 disclosure channel 接收，却逐步显示为更严重事件。实践经验是预先定义升级条件，让员工不必靠“这看起来像不像 bounty”作个人判断。}

VDP-to-incident escalation triggers

发现真实账户或 credential 使用、非最小化数据访问、敏感数据离开边界、持续访问、第三方受影响、研究者要求与停止损害无关的付款、事实与报告明显不一致，或任何监管/合同 trigger 时，立即启动 incident review。触发不等于指控研究者犯罪，而是提高组织调查和治理等级。

本章小结

事件指挥把多个专业判断组织成共同运行节奏。IC 的价值是让事实、保护动作、法律义务和经营决定互相可见，而不是由 CSO 一人扮演工程师、律师、发言人和 CEO。

Evidence Preservation：让事实可以被复核

重大事件中，团队的记忆会被高压、并行聊天和事后结果改变。证据保存不是为了“为诉讼准备故事”，而是为了让技术调查、用户保护、保险、监管回应和复盘拥有同一组可验证输入。保存动作必须尽早开始，同时避免妨碍 containment。

Chain of custody、legal hold 与 timeline

\term{chain of custody}（保管链）记录证据由谁、在何时、以什么方式收集、传输、访问和保存，使后来审查者能够判断完整性。Hash 可以帮助检测文件变化，但 hash 本身不证明采集方法正确。\term{legal hold}（法律保全通知）是 counsel 要求暂停常规删除并保存可能相关信息的程序；工程师不应自行宣布 privilege 或决定保全范围。

\lecturefigure{07-evidence-chain.png}{证据质量依赖 preserve、integrity、custody 与 timeline 的连续链路。}{NIST incident response guidance；本地字幕 21:00--25:40；概念重绘。}

读图：完整性来自过程，不只来自工具

Preserve 阶段确定 logs、systems、snapshots 和 communications；integrity 记录 hash、timestamp 与 acquisition method；custody 限制并审计访问、transfer 和 purpose；timeline 把事实、假设、决策与后续修正排成时间。不能只截一张聊天截图，也不能让所有人直接修改同一证据目录。每个导出都应有 owner、来源系统、时区和保留策略。

“清理现场”可能同时破坏证据和恢复

删除账户、重装系统或轮换所有凭证可能是必要 containment，但若没有记录和采集，会失去 root-cause evidence。反过来，为了取证而延迟保护用户也可能扩大伤害。IC 应让 technical lead 与 forensics/counsel 明确哪些动作可立即执行、哪些需要 snapshot、哪些无法保存但必须记录理由。

Decision log：把事实、分析与授权分开

高质量记录不是把每条 Slack 消息永久保存，而是维护结构化 decision log：当前技术事实、未知项、法务分析、经营选项、decision owner、时间、依据和复审条件。\term{privilege}（律师保密特权）在美国语境中通常保护为获得或提供法律意见而进行的特定保密沟通；让律师加入频道、把文档标为 privileged，并不会自动让所有业务事实消失或受保护。

\lecturefigure{09-decision-log.png}{技术事实、法务分析、高管决定与记录必须在同一链路中保持边界。}{本地字幕 21:00--25:40；NIST/SEC guidance；概念重绘。}

读图：记录“谁决定什么”，不要记录虚假的一致

Technical facts 应包含 evidence 与 confidence；counsel analysis 写适用义务、假设和保密范围；executive decision 列出 options、risk acceptance 与 approver；record/audit 保存 owner、rationale、next review 和 superseded decision。后续事实变化时应追加修正，而不是覆盖旧条目。这样既能避免 CSO 被误认为独自作出法律判断，也能防止领导者事后声称从未收到风险信息。

最小 decision record 模板

Time/owner；known facts and evidence links；unknowns；options；technical recommendation；legal/materiality analysis owner；business decision and approver；external communication；next checkpoint。不要在事实字段写推测，也不要在 recommendation 字段伪装成已批准决定。

本章小结

证据链回答“我们如何知道”，decision log 回答“谁基于哪些已知和未知作了什么决定”。两者共同保护调查质量、用户利益与组织责任，绝不是为了给个人制造免责备忘录。

Materiality 与 Disclosure：四工作日从哪里开始算

安全团队可以判断技术影响，却不能独自决定全部披露义务。\term{materiality}（重大性）在美国证券法语境中关注一个合理投资者是否很可能认为该信息对投资决定重要；它不是由记录数量、CVSS、停机分钟或攻击者标签单独决定。不同司法辖区、行业、合同和用户通知规则还有各自 trigger，因此组织需要 parallel analysis，而不是寻找一个“万能阈值”。

Facts、materiality、audience 与 timing

披露工作流先建立可靠事实，再由适当人员分析对运营、财务、声誉、法律和战略的影响，然后识别受众与时间。受众可能包括受影响用户、业务伙伴、保险人、执法机构、隐私或行业监管者，以及公开市场。不同通知可以有不同目的和信息粒度，但不能互相矛盾。读这一流程时要特别注意：technical severity 只回答防御资源应多快投入，materiality 则回答该事件对特定法律和决策受众是否重要；前者可以触发后者，却不能自动替代后者。

\lecturefigure{08-disclosure-decision.png}{披露决策从技术事实开始，经 materiality 分析进入受众、内容与时间选择。}{SEC 2023 cybersecurity disclosure final rule；NIST guidance；概念重绘。}

读图：先判断，再启动相应时钟

Facts 列出 scope、data、systems、operational impact 与 confidence；materiality 分析 investor/customer/user harm、financial/operational effect 和 cumulative impact；audience 列出 users、regulators、law enforcement、partners；timing 再映射 contract、statute、Form 8-K 或 approved delay。关键顺序是“发现后不无理拖延地作重大性判断；一旦确定重大，再计算相应申报窗口”，不是所有事件发现后统一四天。

SEC 四工作日规则的准确口径

对适用的美国上市公司，SEC 规则要求在发现 incident 后不无理拖延地判断重大性；如果公司确定事件具有重大性，通常在该重大性确定之后四个工作日内提交 Form 8-K Item 1.05。\term{Form 8-K} 是上市公司报告特定重大事件的当前报告表格。规则包含由美国司法部长认定即时披露会对国家安全或公共安全造成重大风险时的延迟机制。具体适用必须由合格 counsel 判断。

不要等待“所有事实百分之百确定”

调查可能持续数周，但通知时钟可能更短。治理目标不是用不确定性拖延，而是明确已知、未知、置信度和预计更新。过早给出不准确数字会伤害信任，过晚启动 materiality workstream 也会制造违规风险。应从事件早期就让 disclosure owner 参与，并设置重复评估 checkpoint。

RACI 如何防止责任扩散

\term{RACI} 是 Responsible、Accountable、Consulted、Informed 的责任矩阵。对 technical scoping，forensics lead 可能 Responsible、IC Accountable；对法律义务，counsel Responsible、GC Accountable；对重大经营披露，CEO 或 disclosure committee Accountable。RACI 不是让四类角色平均承担责任，而是明确每个 deliverable 的唯一最终责任人。

本章小结

Disclosure 是证据驱动、跨职能且多时钟的决策。安全团队提供及时可靠事实，counsel 解释义务，高管或委员会承担经营与公开披露决定；“四天”从重大性确定开始，而不是从第一个告警开始机械倒计时。

Sullivan 案时间线：课堂预期与最终程序状态

课堂用 Uber 2016 年事件讨论 bug bounty、披露和 regulation by enforcement。为了保持教学准确性，必须分四层阅读：Sullivan 在课堂中的个人叙述；政府在起诉与审判中的理论；陪审团和法院已经作出的裁判；本文从中提取的工程控制。任何一层都不能替代另一层。

2016–2026 的程序节点

DOJ 于 2022 年宣布陪审团就妨碍 FTC 程序和 misprision of felony 作出有罪裁决；2023 年法院判处三年 probation。课堂录制时，Sullivan 讨论 \term{nexus}：在 obstruction 语境中，被指行为与官方程序之间需要满足的关联要求，并预期 2024 年最高法院 Fischer 判决可能帮助上诉。第九巡回法院后来维持定罪并发布修订意见；最高法院拒绝 \term{certiorari}（调卷复审请求），即拒绝审理该上诉请求，并不表示最高法院对每个实体争点另行背书。

\lecturefigure{10-current-legal-timeline.png}{课堂中的 pending appeal 已被 2025--2026 年法院程序结果取代。}{DOJ；Ninth Circuit No. 23-927；Supreme Court docket 25-1082；概念重绘。}

读图：把事件、观点与裁判分开

2016 是底层事件；2022 jury conviction 与 2023 sentencing 是审判结果；2025 Ninth Circuit opinion 是上诉裁判；2026 cert denial 结束本轮最高法院复审请求。课堂关于 nexus、harmless error 或行业影响的陈述属于 2025 年 1 月的诉讼观点。当前讲义可以解释其治理含义，但不能继续写“上诉待决”或把讲者预测当成法院结论。

案件不是通用 VDP 法律测试

该案涉及特定公司、FTC 调查、事件事实、沟通和记录。不能从一宗刑事案件推出“支付 bounty 都违法”或“签 NDA 都是掩盖”，也不能推出“只要有 VDP 就不会承担责任”。工程上可复用的是分流、升级、证据、披露和共同决策机制；具体法律结论必须回到司法辖区和事实。

\teachervoice{Sullivan 在课堂上把 Fischer 与 nexus 看作上诉的重要机会。保留 teacher voice 的正确方式，是记录“他当时为何这样判断”，同时明确后来法院结果已取代 pending 状态；忠实不是把历史时点冻结成今天的事实。}

四种陈述标签

写 case study 时显式区分：speaker account（讲者称）、government allegation（政府主张）、adjudicated fact/outcome（陪审团或法院处理）、engineering judgment（本文建议）。这能减少对人物动机的臆测，也能让读者知道哪一部分可以被系统设计直接采用。

本章小结

这条时间线的教学价值在于纠正旧稿：截至 2026 年 8 月 11 日，上诉不再 pending。更重要的是，组织不能把法律结局当作事件后才需要关注的外部变量；事实记录、权责和披露路径必须在事件发生前设计。

Executive Accountability：责任共享，但不能稀释

重大安全事件往往暴露组织结构：谁收到事实、谁能要求更多调查、谁批准付款、谁决定不通知、谁向董事会报告。把责任全部压给 CSO 会诱发防御性文化；把责任平均分散给十几个委员会，又会让任何人都不真正 accountable。成熟治理需要 shared responsibility 与 named decision owner 同时存在。

CSO、GC、CEO 与 board 的 decision rights

CSO 应确保风险被准确升级，GC 应确保法律问题由有资质团队处理，CEO 应为资源和重大经营选择负责，board 或 disclosure committee 应提供监督与 challenge。CSO 不能以“legal approved”替代自己的技术真实性义务，GC 也不能在缺少 evidence 时单独判断影响，CEO 更不能只在公开披露前才第一次听说安全架构。

\lecturefigure{12-executive-accountability.png}{网络安全责任由 CSO、GC、CEO 与 board 共同承担，但每项决定仍需明确 owner。}{本地字幕 25:20--35:20；治理概念重绘。}

读图：共享信息，不共享模糊责任

CSO 提供 technical scope、security recommendation 与 escalation facts；GC 提供 legal duties、regulator strategy 与 privilege advice；CEO 作 enterprise risk 和 disclosure decision；board/committee 监督、挑战并要求复盘。图中边界不是 silo：每个角色都能 challenge 其他 workstream，但不能把自己的 deliverable 推给别人。最终记录应能回答谁负责事实、谁负责分析、谁批准行动。

\teachervoice{讲者建议安全领导者在危机前就与 CEO、GC 建立关系，而不是第一次重大通话就要求他们理解复杂 incident。课堂提醒：executive readiness 是一种预先训练的 interface，需要定期 brief、tabletop 和明确的“何时叫醒我”阈值。}

“我已经告诉过他们”不是治理完成

单次邮件或口头提醒不能证明接收者理解风险、拥有 decision right 或完成后续行动。高风险升级应包含 severity、evidence、unknowns、recommended actions、deadline、明确 ask 与确认；若决策被延迟或拒绝，应记录 owner、理由和下一次复审。

保护安全领导者的正确方式

保护不等于制造自利 memo。组织应提供清晰 job authority、written escalation、independent legal advice、董事会 access、D&O/indemnification 与适当 employment support；领导者则应保持事实诚实、避免越权作法律结论、拒绝删除不利记录，并在重大分歧时使用正式升级渠道。

本章小结

Accountability 的目标是让有能力、有信息且有权的人作决定。CSO 不应成为所有安全风险的单点承担者，也不能因“集体决策”而放弃准确升级和专业判断。

Resilience 与 Public Service：事件之后如何继续工作

安全事故和法律程序会影响员工、研究人员、用户与领导者的健康、身份和职业。\term{resilience}（韧性）不是假装没有伤害，而是通过支持、恢复、反思和重新参与，逐步重建可持续服务能力。课程谈到 Sullivan 在乌克兰公益项目中的工作；这部分不能作为案件证据，却提供了一个重要的人类系统视角。

Human recovery 也是 incident lifecycle

传统 postmortem 关注 root cause、control gap 和 owner，却可能忽略长期值班、公开压力、道德伤害和家庭负担。组织如果只要求“恢复服务”，会让关键人员在下一次事件前耗尽。Recovery plan 应包括轮换、心理支持、法律与 HR 协助、休假、角色调整以及重新进入工作的路径。

\lecturefigure{14-resilience-loop.png}{韧性来自支持、恢复、意义重建与重新服务的循环。}{本地字幕 27:00--29:20；概念重绘。}

读图：恢复不是回到事故前的状态

Incident/case 造成业务与个人冲击；support 提供 family、peer、professional 和 legal care；recovery 需要 rest、perspective 与 new routines；service/learning 把经验转化为 community work、mentoring 和 better systems。箭头不是保证每个人都会线性恢复，而是提醒组织为不同速度保留空间。将 resilience 解释为“个人要更坚强”会掩盖制度责任。

不要把公益或个人成长当成法律洗白

一个人在事件后的善行可以解释其价值选择和恢复过程，却不能自动改变已经裁判的事实；同样，法律责任也不应让组织忽视健康与人性。课程讲义应允许两种判断同时存在，而不是用励志叙事取代证据分析。

Government technical talent

公共部门需要理解 cloud、identity、AI、supply chain 和 incident operations 的技术人才，否则规则可能只描述目标而无法评估实现。技术领导者参与 government 不只意味着全职任职，也包括 standards work、advisory groups、公开评论、incident coordination 和短期服务。参与者必须处理利益冲突，并把公共责任置于公司 lobbying 之外。

\lecturefigure{15-government-talent.png}{技术人才只有留在政策、实施与行业反馈闭环中，才能提高公共治理质量。}{本地字幕 36:20--39:17；概念重绘。}

读图：人才流动要形成制度记忆

Technical expertise 帮助描述 systems、threats 和 operational cost；policy design 把目标写成 rules、incentives 与 oversight；implementation 建立 agency capability、metrics 和 enforcement；industry feedback 返回 evidence、failure modes 与 burden。若专家只短期“空降”而没有文档、career path 和 permanent staff，知识会随个人离开；若行业只提供立场，不提供可验证数据，也无法形成高质量规则。

\teachervoice{讲者最后呼吁技术人员不要把 government 当成别人的问题。课堂提示：当软件系统承载公共生活时，懂系统的人需要帮助设计公共约束；否则规则仍会出现，只是更可能在信息不足和危机压力下出现。}

本章小结

Resilience 把个人恢复纳入长期安全能力，public service 把技术经验送回制度反馈。两者都要求从英雄叙事转向支持系统和组织记忆。

综合演练：从 VDP Report 到披露与学习

最后用 tabletop 把本讲机制连成一条可演练路径。设想研究人员通过 VDP 提交一个高影响报告，初步看来只是漏洞，但验证时发现真实 credential 使用和可能的数据访问。演练目标不是猜测攻击者动机，而是观察团队能否及时升级、保存证据、保护用户、完成 materiality 分析并保持一致沟通。

五阶段 tabletop

每个阶段只向参与者释放部分事实，并要求记录假设、owner 和下一步。Facilitator 应故意加入不确定性：日志缺失、第三方依赖、研究者要求快速回应、业务希望继续服务、媒体开始询问。优秀答案不是“立即全部关闭”或“等调查完成”，而是能说明不同动作的收益、代价、证据需求与批准者。

\lecturefigure{16-tabletop.png}{Tabletop 把 VDP、incident、materiality、notification 与 learning 串成端到端演练。}{本讲综合设计；概念重绘。}

读图：每一关都要交付可审计输出

VDP report 交付 case ID、scope 和 acknowledgement；incident 交付 severity、IC、containment 与 evidence plan；governance 交付 materiality owner、RACI 和 decision log；notify/learn 交付一致消息、deadline、recovery 与 remediation owners。演练成功不以“没有争论”为标准，而以争论是否围绕同一事实、是否在 deadline 前升级、是否由正确角色拍板为标准。

Tabletop injects

  1. 报告来自 out-of-country researcher，描述 in-scope 漏洞但附带真实用户记录；
  2. internal logs 显示 credential 曾被使用，时间早于报告；
  3. 第三方 SaaS 也可能受影响，合同通知窗口不同；
  4. 修复需要短暂停机，业务负责人要求延后；
  5. counsel 要求重大性分析，communications 收到记者询问；
  6. 新证据推翻最初记录数量，团队必须修正而不是覆盖旧决定。

演练不应寻找“标准答案”

真实义务依赖事实和司法辖区。Tabletop 应检验接口：能否识别升级 trigger、能否在 containment 前后保存关键 evidence、能否让 GC/CEO/committee 在需要时加入、能否解释对用户和公众的选择。若演练只考政策记忆，就无法暴露组织断点。

本章小结

端到端演练把政策从文档变成组织肌肉。只有当 VDP、incident command、evidence、materiality、executive decision 和 learning 在同一场景中协作，团队才能发现现实中的责任缝隙。

总结与延伸

本讲把 security leadership 从“CSO 是否足够勇敢”重写为一套可验证的组织设计：

  1. 安全是 operating system：people、process、platform 和 governance 共同决定结果；
  2. 公共规则需要反馈：企业应把真实系统 evidence 带入政策，同时接受公共 accountability；
  3. VDP 管报告渠道：scope、acknowledgement、修复和协调披露构成信任合同；
  4. Bounty 管可选激励：奖励、NDA 或 payment 不能事后授权有害行为；
  5. Incident command 管跨职能执行：IC 同步工作流，但不垄断技术、法律和经营判断；
  6. Evidence 与 decision log 管可复核性：事实、分析、决定和修正必须分层记录；
  7. Materiality 不等于 severity：对适用上市公司，Form 8-K 的四工作日通常从重大性确定后计算；
  8. 案件状态必须更新：课堂的 pending appeal 已被 2025 年第九巡回法院裁判和 2026 年 cert denial 取代；
  9. Accountability 共享但不稀释：CSO、GC、CEO 和 board 各有明确 deliverable 与 decision right；
  10. Resilience 与 public service 是长期能力：恢复人员、保留制度记忆并改善公共技术治理。

Security Governance 作业

为一个虚构 SaaS 公司设计端到端 playbook：公开 VDP 与 safe-harbor 边界；定义 VDP-to-incident triggers；画出 IC、technical、legal/comms、business RACI；提供 evidence chain 与 decision-log 模板；列出 customer、regulator、law-enforcement 和 public-market disclosure workstream；最后设计六个 tabletop inject。每个关键决定必须标明 owner、evidence、deadline 和 review condition。

最终自检：五个不能混淆

不要把 vulnerability 与 incident 混淆，不要把 severity 与 legal materiality 混淆，不要把 payment 与 authorization 混淆，不要把 speaker account 与 adjudicated outcome 混淆，也不要把 shared responsibility 与 diffuse accountability 混淆。只要这五组边界清楚，组织就更可能在高压中保持事实和责任完整。

拓展阅读

下面的材料不是同一层级：CISA、DOJ 与 NIST 主要帮助设计 VDP 和 incident-response process；SEC 资料解释特定公开市场披露框架；法院意见和 docket 记录案件程序结果。阅读时应先确定自己要回答的是“如何建设控制”“适用什么义务”还是“法院对既有记录作了什么判断”，避免用工程指南代替法律分析，也避免用单一案件代替普遍工程原则。

{

}

建议阅读顺序：从可执行控制到裁判边界

先用 CISA template 检查公开 policy 是否给出 scope、承诺和联系渠道；再用 DOJ framework 审视 good-faith 与授权边界；随后用 NIST SP 800-61 Rev. 3 把报告升级到组织级 incident response；若组织是适用的美国上市公司，再阅读 SEC fact sheet 与 final rule 原文；最后对照 Ninth Circuit opinion 和 Supreme Court docket，确认课堂案件的程序状态。每一步都记录来源日期和适用范围，因为政策、标准与案件状态会继续变化。

Source triangulation 练习

选择一个假想 incident，分别写出：技术团队从 NIST 得到的运行建议、counsel 需要核验的通知与披露义务、管理层需要作出的经营决定，以及法院材料不能替你回答的问题。若四栏出现同一句结论，通常说明证据层级仍被混在一起。