Marico's space
安全不只是技术活，更是一道资源分配的数学题。
一个AI平台，架构设计图画得再漂亮，如果缺了下面这些东西，照样千疮百孔：
所以安全这件事，必须认真做预算和规划。
目标不是：
在安全上花越多越好。
目标应该是：
把有限的资源投入到真正能降低最重要风险的安全控制上。
成熟的安全投资策略要把这几件事串起来：
风险 → 所需控制 → 资源 → 成本 → 预期风险降低 → 残余风险
安全经济学研究的是：资源有限、威胁不确定、控制有成本、事件影响可能很大、安全投入主要产生预防价值——在这种情况下组织怎么做决策。
做安全决策要同时考虑两件事：
和
一个简化的概念公式是：
预期安全损失 = 事件概率 × 事件影响
当一项安全投入的预期风险降低相对于其成本有吸引力时，这笔投入就是值得的。
但这不意味着每个安全决策都要简化为数学计算。有些要求是强制性的，因为合同、法律、法规、安全或组织政策有规定。
一个完整的AI平台安全预算可以分为以下几个大类。
一份扎实的的安全预算应该遵循几个原则。
资金要跟着实际风险走。
先保护高价值系统，低影响系统往后排。
光靠预防控制是不够的。
假设某些控制最终会失效。
自动化应该提升安全能力，而不是简单地增加复杂性。
安全投入要用可衡量的改进来评估。
资源规划要回答的问题是：
要有效运行安全架构，需要哪些能力？
一个平台可能需要在以下领域具备能力：
身份管理
应用安全
云安全
基础设施安全
数据安全
AI安全
安全运营
事件响应
治理
隐私
业务连续性
每项能力都应该有：
技术替代不了有经验的安全人员。
举例来说：
一份只买工具、不投人员来运营的的安全预算，只会制造虚假的安全感。
一个正在成长的AI平台可以把安全职责分成几个功能块。
构建和维护安全控制。
与开发人员协作，确保软件安全。
保护基础设施和部署环境。
评估模型、Agent、提示词、工具、检索系统以及AI特有的威胁。
监控事件，调查可疑活动。
处理确认的安全事件。
维护政策、风险记录、控制措施和证据。
小公司可能需要让少数人承担多个职责。
一个实用的规划模型：
预算规划应该资助下一个可实现的成熟阶段，而不是试图一次性实现所有高级能力。
每项安全能力都可能通过三种方式实现：
优势：
劣势：
优势：
劣势：
优势：
劣势：
最便宜的采购成本不一定是最低的总体成本。
评估安全技术要用总拥有成本（TCO，Total Cost of Ownership）。
要考虑的要素：
许可成本
+ 实施成本
+ 集成成本
+ 工程成本
+ 维护成本
+ 监控成本
+ 培训成本
+ 存储成本
+ 支持成本
+ 迁移成本
一个许可费很低的工具，如果需要大量工程投入，成本可能很高。
AI平台可能产生大量云安全成本，包括：
所以安全架构在设计阶段就要考虑成本。
比如，无限期保留所有原始事件可能并不会增加多少安全价值，反而会产生大量存储和处理成本。
AI平台会带来额外开支。
可能的类别包括：
AI安全应该被视为平台核心安全预算的一部分，而不是可选的附加项。
一个成熟的平台应该在多种测试类型上做预算。
常见的预算错误：买了漏洞扫描器，却没钱做修复。
实际的漏洞生命周期是：
发现 ↓
验证 ↓
优先级排序 ↓
分配 ↓
修复 ↓
验证
每个环节都需要容量。
如果一个平台每月能发现10000个问题，但只能修复100个，安全项目需要：
自动化可以减少重复性的安全工作。
例子：
目标应该是：
减少人工工作，但不降低控制质量。
评估自动化投入可以用：
举例：
自动化前：
每周花5小时人工审核安全例外情况。
自动化后：
每周只用30分钟审核真正需要人工判断的例外。
节省下来的容量可以重新投入到更高价值的安全工作上。
资源有限时，用这些因素来确定投资优先级：
一个实用的概念公式是：
投资优先级 = 风险降低 × 战略重要性 ÷ 实施成本
这是一个规划启发式方法，不是精确的财务公式。
有些安全投入能快速产生高价值。
例子：
快速见效项目可以在大型架构项目规划期间，先降低眼前的暴露风险。
长期安全投入可能包括：
这些项目可能需要较大的前期投入，但能降低长期风险和运维复杂性。
组织应该明确为安全债务做预算。
例子：
如果没有专门容量，团队往往会把所有资源花在新的功能上，安全债务越积越多。
安全不是一次性的购买。
每项安全控制都需要维护。
例子：
所以：
安全实施成本 ≠ 安全生命周期成本
预算规划必须包含持续运营。
培训应该按角色定制。
用户和员工仍然是安全边界的一部分。
意识教育可以解决：
意识教育应该用行为和报告结果来衡量，而不是简单地数完成了多少培训模块。
AI平台经常依赖外部提供商。
例子包括：
供应商风险应该纳入规划。
预算可能需要用于：
平台应该搞清楚，如果一个关键供应商：
安全预算应该包括关键依赖的应急规划。
弹性投入包括：
这些控制可能看起来很贵，因为很少用到。
但在大规模故障时，它们的价值就显现出来了。
真正的问题不是简单地：
我们有备份吗？
而是：
我们能否在要求的恢复目标内可靠地恢复关键数据？
预算应该覆盖：
未经测试的备份不应该被视为有保障的恢复能力。
事件响应需要：
平台应该提前决定：
等到事件发生了才建立响应能力，会增加风险。
组织可以根据业务情况考虑网络安全保险。
保险可以转移部分财务风险，但不能替代安全控制。
投保要求可能包括：
所以保险应该被视为风险转移的一部分，而不是风险消除。
有些安全支出是外部要求驱动的。
可能的成本包括：
但合规应该补充安全，而不是成为安全的唯一目标。
一个系统可以完全合规但仍然不安全。
第95章确定了安全指标应该驱动决策。
现在可以扩展这个关系：
安全指标 ↓
风险指标 ↓
风险优先级 ↓
安全投入 ↓
控制实施 ↓
风险降低 ↓
新指标
这形成了一个基于证据的投资循环。
资助一个项目之后，衡量它的效果。
举例：
自动化密钥扫描。
密钥偶尔在代码进入共享仓库后才被发现。
密钥在开发阶段就被检测到，并在合并前被阻止。
降低了凭证暴露风险。
这比简单报告：
购买了密钥扫描工具。
要有说服力得多。
安全预算应该定期审查。
问题包括：
安全支出应该随着威胁环境和平台架构演进。
买太多安全产品可能造成：
购买新工具之前，先确定：
整合可以降低：
但整合不应该为了简化架构而移除关键独立控制。
目标是高效防御，而不是工具数量最少化。
每个重大架构决策都有安全成本影响。
举例：
需要：
可能减少外部数据暴露，但会增加：
可能提高弹性，但会增加：
所以架构和预算必须一起设计。
AI推理成本可能影响安全架构。
高成本模型可能促使：
这些控制可以同时改善：
所以FinOps（云财务管理）和安全有时候可以互相加强。
安全控制也可以减少财务滥用。
例子：
这些可以减少：
所以安全和成本控制应该协调。
容量规划应该考虑增长。
重要变量包括：
安全基础设施必须随平台扩展。
一个每天处理1000次请求的监控系统，在每天1000万次请求时可能经济上或运维上都撑不住。
组织应该准备多个场景。
保护关键资产，满足强制要求。
资助正常安全运营和计划中的改进。
支持用户、基础设施和AI模型的大幅扩展。
处理重大事件、紧急修复或重大威胁变化。
场景规划提高财务韧性。
组织应该为意外事件保持一些安全容量。
可能的用途：
没有储备容量，每个意外安全问题都要跟计划中的工程工作直接竞争。
一份多年路线图可以这样组织：
确切时间线应该反映组织规模和风险。
安全投入可以分为：
降低攻击概率。
改进发现能力。
缩短事件持续时间。
降低影响。
改进问责。
均衡的投资组合比全部投入某一类要强。
预防有吸引力，因为它可以在事件发生前阻止。
例子：
但预防不能保证零事件。
所以预防必须配合检测和恢复。
检测投入不能直接预防攻击。
但能降低：
所以即使预防失败，强检测能力也能提供显著的风险降低。
恢复投入在预防和检测都不够用时保护组织。
例子：
它们的价值往往在低频高影响事件中显现。
实施安全控制后，总会留下一些风险。
决策流程变成：
初始风险 ↓
安全投入 ↓
控制 ↓
降低后的风险 ↓
残余风险
管理层必须决定残余风险是：
有时候组织无法立即消除某个风险。
这种情况下：
预算限制不应该悄悄地变成永久的风险接受。
管理层应该能问出：
这些问题促进严谨的投入决策。
成熟的安全预算流程应该连接：
业务战略 ↓
威胁模型 ↓
风险评估 ↓
安全目标 ↓
安全路线图 ↓
预算 ↓
实施 ↓
衡量 ↓
管理层审查
这防止安全支出与业务优先级脱节。
不要规定固定百分比，组织应该按风险分配资源。
一个简单的规划矩阵：
| 风险 | 影响 | 投入优先级 |
|---|---|---|
| 严重 | 严重 | 立即处理 |
| 严重 | 中等 | 高优先级 |
| 高 | 严重 | 高优先级 |
| 高 | 中等 | 计划中 |
| 中等 | 中等 | 计划中 |
| 低 | 低 | 视机会 |
矩阵应该根据组织的风险偏好调整。