系统工程手册（Systems Engineering Handbook）是国际系统工程协会（INCOSE）编著的一本权威性指导书籍，旨在为系统工程的全生命周期过程和活动提供详细的指南，其内容基本涵盖ISO/IEC/IEEE 15288（系统生命周期过程）和ISO/IEC/IEEE 26771（系统工程管理计划）。这些标准为系统工程的全生命周期提供了清晰的指导，涵盖了需求分析、设计、开发、测试和维护等环节，帮助工程师高效管理复杂项目，确保系统从概念到退役的全过程都能科学运作。
为了方便感兴趣的人士参考，reddish(@srs.pub)基于系统工程手册第四版（2015），借助通义完成翻译，并做校稿，个别地方有做必要的修正和裁剪。
本文是的中文译本的第十章专业工程活动(Specialty Enginerring Activities)的第十一小节：系统安防 1工程(System Security Engineering)。
又注：本文一般翻译是系统安全工程，但这里是security，同时其他章节中还有safety，因此这里的security统一翻译为安防。 security 和safety的区分，参见reddish(@srs.pub)的文章https://srs.pub/thinking/safety-security.htm
1 系统安防工程
系统安防工程专注于确保系统能够在与滥用和恶意行为相关的破坏性条件下正常运行。系统安防工程学涉及在分析系统威胁和漏洞以及评估和减轻系统生命周期中信息资产风险时，有纪律地应用SE原则。它结合了技术、管理原则和实践以及操作规则，以确保系统在任何时候都有足够的保护措施。
系统安防工程考虑并解释了系统及其相关环境。潜在破坏性条件（威胁）的来源多种多样。它们可能是自然的（例如，天气）或人为的。它们可能来自外部来源（例如，政治或电力中断），也可能由内部力量引起（例如，用户或支持系统）。破坏可能是无意的或有意的（恶意的）。从用户的角度来看，无论是通过设计、政策还是实践实现的安全功能都必须是可用的。
为了有效，系统安防工程在整个系统生命周期中应用。系统安防工程活动可以应用于每个生命周期阶段：
- 概念：系统安防工程研究技术趋势和进展，以识别潜在技术和有前途的安全策略，以应对当前和未来的威胁，并支持提供安全性的架构和操作概念，以支持和保护操作需求。
- 开发：系统安防工程确保安全概念转化为可验证的功能需求，并在此阶段定义安全级别的有效性。
- 生产：系统安防工程在制造、构建和装配过程中提供支持，以确保安全设置得到正确初始化并随最终系统一起交付，并在此阶段建立安全级别的有效性。
- 利用：系统安防工程通过考虑操作、用户和威胁环境的变化，保持使用过程中的安全有效性。
- 支持：系统安防工程确保安全功能在维护后得到更新并保持有效，并监控安全事件以维持安全有效性。
- 退役：系统安防工程确保在系统及其相关信息退役期间采用有效的安全措施。
2 系统工程师和系统安防工程师的角色与职责
系统安防工程将关注安全的学科、技术和问题纳入到SE过程中，以确保在有关系统的决策中给予保护考虑适当的权重（Dove等人，2013年）。系统工程师必须及时聘请安全主题专家和安全工程师进行系统安防分析并提供有效的安全建议。
系统安防工程包括防篡改、供应链风险管理 2、硬件保障、信息保障、软件保障、系统保障等子专业，系统安防工程师需要权衡这些方面以提供平衡的系统安防工程观点。SE和系统安防工程与安全专家领域的关系的一个例子是共同贡献于定义和部署一个满足用户需求的工程解决方案。其中一些联合工作产品包括：
- 系统安防计划
- 漏洞评估计划
- 安全风险管理计划
- 系统安防架构视图
- 安全测试计划
- 部署计划
- 灾难恢复和连续性计划
3 需求的系统安防工程活动
利益相关者 3的安全利益包括知识产权、信息保障、安全法律、供应链合规和安全标准。标准的例子包括ISO/IEC 27002信息安全标准（2013年）；《国防采购指南》第13章（DAU，2010年）；以及《系统保障工程指南》（NDIA，2008年）。系统工程师在进行过程中需要考虑利益相关者的安全利益。
利益相关者的需求和要求定义过程应记录在利益相关者的要求中。在系统需求定义期间，确定了最需要保护的关键功能和数据。基于风险的分析模式包括关键性分析、威胁评估、脆弱性评估以及潜在保护控制和缓解措施的识别，这些作为成本效益分析（CBA）的输入。CBA考虑了对系统性能、可负担性和使用兼容性的影响。为正常安全处理和误用/滥用情况开发了安全场景，以协助系统需求定义。这些场景在验证和确认过程中也非常重要。
系统需求定义需要考虑系统安防保护。系统安防保护可以分为三类：预防、检测和响应。预防包括访问控制和关键功能的隔离与分离。检测包括监控和记录与安全相关行为的功能。响应包括在主要功能或数据受到损害时切换到降级模式的缓解措施。
这些活动的结果是一套系统安防要求（包括流程要求）、安全操作概念和支持概念，以及一套用于验证和确认的场景。
4 用于架构定义和设计定义的系统安防工程
系统安防工程在架构定义和设计定义过程中的参与非常重要，因为系统架构可以促进或阻碍系统安防。对手会学习系统的保护措施并迅速改变他们的方法。架构应该能够快速改变保护措施，从而促进操作时间的工程干预。这是通过修改架构结构和安全功能细节来实现的，并且由系统OpsCon中阐述的敏捷架构策略所支持。不断演变的威胁可以通过由松散耦合的封装安全功能系统元素组成的网络安全架构来对抗，这些元素可以被替换、增加额外的功能，并重新配置为不同的互连（Dove等人，2013年）。
长系统寿命预期特别容易受到不适应、刚性安全架构的影响。架构侧重于SOI不同系统元素之间的高级责任分配，并定义这些系统元素之间的交互和连接。在需求过程中建立的安全要求的责任，在架构设计过程中被适当分配给功能系统元素和安全专业系统元素。
弹性工程与系统安防工程紧密合作。系统的弹性允许系统在遭受攻击时继续运行，并在攻击后恢复，可能性能会有所下降，但关键功能仍能持续提供。弹性是一种架构特性，很难在开发周期后期提供，并且在部署后非常昂贵。
长寿命系统在其整个生命周期中将进行功能升级和系统元素替换。内部威胁和供应链威胁可能表现为具有嵌入式恶意功能的系统元素，这些功能可能会在需要时激活之前处于休眠状态。这表明，系统元素应该自我保护，不信任互联系统的通信和行为，而不是依赖于系统边界保护或可信环境期望。
5 验证和确认的系统安防工程活动
验证和确认过程制定策略以验证和确认SOI。系统安防工程的参与对于验证与安全相关的要求以及对支持系统的安全影响是必要的。为每个安全要求确定了验证方法，具有客观的通过/失败标准，用于检查、分析、演示和测试。里程碑审查被用来确认措施已被计划，威胁和脆弱性评估是最新的，并且正在测试的系统安防要求映射到全面的关键性分析。使用关注操作环境中不断演变的威胁的评估场景对系统进行验证；根据当前的威胁和脆弱性更新风险评估和关键性评估；并更新端到端场景以应对新的脆弱性和威胁。
6 维护和处置的系统安防工程活动
系统安防工程的责任并不会在系统交付后结束。作为维护的一部分，工作指示需要明确授权的维护活动，以防止漏洞插入。作为持续运营的一部分，威胁和安全特性需要重新评估，以确定现有系统中是否存在新的漏洞。作为任何能力升级或技术更新的一部分，必须在新威胁的背景下重复进行关键性分析，重新评估端到端场景以确认有效保护，并评估供应链漏洞以更新设备。在系统处置之前，硬件和软件必须被带到无法逆向工程的状态。
7 风险管理的系统安防工程活动
任务关键性分析、威胁评估和脆弱性评估可以作为风险管理过程的安全输入，以提高风险识别和风险级别确定的客观性。在整体系统性能、成本和进度的背景下平衡安全风险减少需要一个客观的成本效益分析。越早进行安全风险识别和分析，就越能有效地将安全性融入设计、开发过程和供应链中。由于威胁的动态创新性质以及持续发现的脆弱性，需要在整个系统生命周期中经常重复进行风险识别和分析。
8 配置和信息管理的系统安防工程活动
配置和信息管理确保只有那些被授权了解系统配置和能力的人才能完全知道系统的状态。配置和信息管理应允许设计团队成员与他们被授权查看的系统部分进行交互，以保持对系统从概念到交付过程中的一致和准确的看法。对配置的更改必须受到控制，以限制更改系统的访问权限，并且必须记录下来以提供洞察力。在发生攻击或发现漏洞时进行法医分析。
9 采购和供应的系统安防工程活动
系统安防考虑超越了SOI。必须保护启用系统和供应链，并且必须了解组装解决方案的所有方面。系统安防分析、评估、保护实施和更新应成为提案请求的一部分，以确保所获取的系统或系统元素在可接受的风险下交付。
必须在整个生命周期中进行并更新漏洞评估。商用现货（COTS）的硬件和软件产品，虽然通常被认为具有成本效益，但可能无法确保没有恶意插入。COTS产品也可能在SOI之外使用，这使得可以发现可能被用来攻击SOI的漏洞。
系统安防工程师评估失去业务/任务能力的后果和可能性，以便选择具有安全供应链的系统元素。在某些情况下，如果无法通过对策将供应链风险降低到可接受的水平，则可能不会选择性能最佳的商用现货（COTS）系统元素。