4、网络安全目标与声明：网络安全目标定义、网络安全声明（CS）编写、安全状态假设

好，咱们进入第四讲。这一章的内容，说白了就是回答三个问题：「我们要保护什么？」「凭什么说它安全？」「在什么前提下它才安全？」

我见过不少团队，一上来就猛写安全需求，结果发现目标都没定清楚。嗯，这就像盖房子没图纸——你都不知道要防几级地震，就开始砌墙了。咱们今天就把这块掰开揉碎了讲。

网络安全目标，英文叫 Cybersecurity Goal，简称 CSG。它不是一个需求，而是一个顶层陈述。说白了，就是告诉所有人：「这个系统在安全方面，底线是什么。」

我个人习惯把 CSG 分成两类：

我在项目中遇到过一件事。有个团队定义了一个目标叫「系统足够安全」。你想想看，这能落地吗？没法验证，没法测试。后来我帮他们改成了「在未授权访问尝试时，系统应记录日志并触发报警」。这才是一个合格的 CSG。

  核心原则：网络安全目标必须满足 SMART 原则——具体的、可衡量的、可实现的、相关的、有时限的。

举个例子，一个 T-Box（车载通信终端）的 CSG 可以这样写：

CSG-001：防止通过外部通信接口（如 4G/5G、Wi-Fi）对车辆进行未授权的远程控制。
验证方式：通过渗透测试，确认无法从外部网络发送伪造的控制指令。

你看，这个目标就清晰多了。它告诉了你：防什么、在哪防、怎么验证。

网络安全声明，英文 Cybersecurity Claim，简称 CS。它和 CSG 有什么区别？

我打个比方：CSG 是「我要减肥到 70 公斤」，CS 是「我通过每天跑步 5 公里、控制饮食，能在 3 个月内达到 70 公斤」。明白了吗？CS 是 CSG 的具体化、可论证的版本。

编写 CS 时，我建议你遵循这个结构：

来看一个实际例子。还是那个 T-Box：

CS-001：T-Box 在接收到来自云端的远程控制指令时，会验证指令的数字签名。
论证依据：签名验证模块通过了单元测试和集成测试，测试覆盖率达到 100%。
假设条件：云端私钥未被泄露，T-Box 的根证书未被篡改。

嗯，这里要注意。很多新手写 CS 时，只写声明，不写论证依据。结果评审的时候，别人问「你怎么证明？」——答不上来。我曾经吃过这个亏，后来每个 CS 后面必须跟一条「证据链」。

小技巧：写 CS 时，可以问自己三个问题——「真的吗？」「怎么证明？」「如果前提不成立呢？」。这三个问题能帮你把 CS 写扎实。

安全状态假设，英文 Security State Assumption，简称 SSA。这玩意儿容易被忽略，但恰恰是最容易翻车的地方。

什么叫安全状态假设？就是「我们假设系统在某个时刻是安全的」。比如：

你想想看，如果这些假设不成立，你后面做的所有安全措施都可能白费。比如你假设出厂时固件是安全的，但供应链被人动了手脚——那你的安全架构再牛也没用。

我建议你把 SSA 分成三个层次：

警告：安全状态假设不是「免责声明」。你不能把所有风险都推到假设上。每个假设都必须有对应的缓解措施或监控机制。否则，这个假设就是一句空话。

我曾经在一个项目中，团队写了一个假设：「假设所有 OTA 包都来自可信源」。结果呢？没有做任何来源验证。后来被审计老师傅一眼看穿，直接打了个「不符合项」。嗯，从那以后，我要求每个假设后面必须跟一条「如果假设不成立，怎么办」的应对策略。

最后，咱们把 CSG、CS、SSA 串起来。它们的关系是这样的：

举个例子，完整的一套输出应该是：

CSG-001：防止未授权的远程控制。
  CS-001：T-Box 验证云端指令的数字签名。
    论证：签名验证模块测试通过，覆盖率 100%。
    SSA-001：云端私钥安全存储，未被泄露。
    SSA-002：T-Box 根证书在生命周期内有效且未被篡改。

你看，这样一层层下来，逻辑就通顺了。评审的时候，别人一看就知道：目标是什么、凭什么说实现了、在什么前提下成立。

我个人习惯在项目初期就把这些文档模板定好。别等到开发快结束了才补，那时候你会发现很多假设已经「默认成立」了——其实根本没人验证过。

  总结一句话：网络安全目标定方向，网络安全声明给证据，安全状态假设划边界。三者缺一不可。

好，这一章就到这里。下一章咱们聊聊「安全需求与安全架构」——怎么把目标变成具体的设计约束。到时候见。