来源： 巴西计算机学会期刊
罗伯托·加洛 (Roberto Gallo) 的文章
系统的安全始终取决于其组件的安全。这句话虽然看似简单，也得到了常识的支持，但却隐藏着一系列因素，即使是最有能力的计算机系统设计、开发、部署和维护团队也难以保证其在整个生命周期内的安全。
通过检查文献、已知漏洞存储库（由 MITRE 维护的 CVE 视频）甚至有关该主题的媒体，我们可以发现一些重要案例，其中系统组件化的某些方面引发了安全问题，而如果向计算机系统设计团队更多地传播安全知识，这些问题可能就可以避免。
一些值得注意的例子包括：
- 针对 SolarWinds Orion 的供应链攻击以及 XZ 爆发 (CVE-2024-3094)，这些组件在其他解决方案中被破坏，
危害使用它们的系统；
- 针对英特尔 CPU 的 Downfall 侧信道攻击（CVE-2023-12301）、针对 AMD CPU 的 Inception 攻击（CVE-2023-12302）以及最近的 GoFetch 攻击
在 CPU Apple Mx（2024）下，允许系统进程（组件）之间泄漏信息（加密密钥）；
- 架构不充分加上 Amazon S3 存储桶配置错误的情况导致了著名的数据泄露事件，例如 1 年 Attunity 的 2019TB 泄露事件和 100 年 2019 亿 Capital One 客户数据泄露事件。
在本文中，我们将探讨几起安全故障案例的共同点，这些案例看似截然不同，但其根本原因以及应对措施都在于负责开发、采购、集成和测试系统及其相关组件的各个团队的组织和协调行动。
组件化的一些问题
以组件形式对系统进行模块化具有许多好处，这些好处在学术界和工业界都广为人知，特别是便于维护和测试、可重用性、降低成本和风险，以及系统和开发过程的可扩展性[1]。
然而，这些好处并没有脱离计算的内在理论基础，也没有脱离构成威胁的常见具体现象，而且令人惊讶的是，这些并没有融入许多计算机高等教育毕业生的思维模式中。 接下来，以摘要形式代表 限于篇幅，我列出一些主要内容：
1. 赖斯定理是计算的基础，该定理指出程序的任何非平凡属性都是不可判定的。这意味着没有通用算法可以决定任何程序及其任何可能的输入是否具有某种行为属性，例如不允许执行某些不安全的操作。在实践中，这意味着程序安全测试具有有限的自信度，基于案例，并且必然得到启发式方法的支持。
此外，尽管这些技术经典且广为人知，但许多开发人员仍然抱有一定的幻想，认为某些技术是“灵丹妙药”，例如虚拟化平台。
- 制定安全策略非常困难：将组件的各个安全策略组合成一个系统的最终策略是一个 NP 甚至指数问题，即使使用带有限制的形式模型，例如扩展 Petri 网 [2]。
结果是，即使存在对组件安全性的可靠、正式描述（罕见），将这样的描述组合成最终系统的安全策略也并非易事。
也许是由于难度，也许是由于安全要求通常具有定性特征，我们观察到，平均而言，很少有进入市场的专业人士接受过该主题的培训。
大多数软件许可证都声明“本软件不提供任何担保，也不保证适合任何特定用途”，这也是一种症状；
- 乐观或浅显的建模：计算研究人员和从业人员通常不会在他们的模型（理论和/或精神）中考虑到算法及其以程序形式的实现不是具体的对象，而仅仅是一个或多个处理元件（CPU、MCU、GPU、NPU、FPGA）在一个或多个设备中组织的指令。这种建模简化通常意味着对软件组件之间的隔离和敏感数据的乐观和不切实际的假设。例如，当一个系统的所有组件都在同一台机器上、由同一个用户运行时，声称系统实现了“分层保护”，这通常是错误的，因为它有几种常见的故障模式（即，如果某个项目受到攻击，则会破坏多个组件的安全性，例如处理器、磁盘和内核）。
另一个经常被证明是致命的错误是将虚拟机（或容器）视为真正孤立的，即使近年来有无数“逃离”主要技术的案例。
- 过度抽象和软件依赖：API 和框架中计算资源的过度抽象以及软件依赖项数量的急剧增加同时促进了漏洞的故意插入和 它们还使得负责实施、维护和安全的团队难以甚至不可能正确维护最新的威胁模型和系统架构。
人们对这个问题知之甚少，但 Apache Maven [3] 的数据表明，2022 年的 Java 应用程序平均依赖于大约 40 个第三方库。在此背景下， 每个单独组件供应链攻击仅 1,7% 的污染就会导致应用程序被入侵的复合概率达到 50%。
另一方面，在软件工程学科中众所周知，架构腐蚀[4]是一个导致安全问题难以识别和纠正的因素，从而使得缓解周期变得缓慢。
- 过去 25 年来，许多开发人员高估了攻击的难度。我观察到一种模式——大多数开发人员，即使是那些在我们最好的学校接受培训的开发人员，也从未见过在他们所了解或开发的系统上执行真正的、实际的攻击。结果，他们中的许多人低估了，甚至忽略了典型的威胁。
另一方面，在我的职业生涯中，当我与一支优秀的安全研究团队一起处理多个客户案例时，我能够观察到，在大约 9% 的案例中，我们能够“获胜”并控制系统，有时是通过攻击单个模块，但通常是通过滥用架构——这种类型的经验通常不会在计算机专业人员的基础培训课程中提供。
这种曲目缺乏的矛盾，往往会产生“新人犯经典错误”的效果。
保护复合系统的最佳实践
复合系统及其组件的最佳安全实践根据您的安全和保证目标而有所不同，因为不同的方法和工程选择会影响成本、额外工作、技术选择和交货时间。它并不打算详尽无遗地介绍实践， 但仅列出一些在本科课程中显然很少受到关注的课程。
在继续之前，有必要确定本节中使用的一些术语。安全目标（也称为安全声明）是对软件、子系统或系统本身所提供内容的描述。例如：“声明 1：该消息保证保密性，安全级别为 2256，可抵御非量子对手的攻击。”已经 保证是指某一特定声明为真实的确定程度。例如，主张 1 以“高度概率”或“有形式证明”的方式为真。
实践经验表明，设计、实施和维护具有高安全级别的组件和系统往往比获得高级别的保证相对省力，这主要归功于赖斯定理和安全策略组合的影响。总的来说，实现高水平保证所需的大量努力与许多使用场景不相容，与更宽松的保证相比，例如 ISO/IEC 3.83 标准——“通用标准”中的 EAL 5 级与 EAL 1 级，高出 7 倍 [15408]。
简而言之，从所涉及团队的能力以及可用资源的角度来协调用例的关键性与安全目标和保证级别至关重要。在实践方面，我们观察到最有效的方法是：
- 词汇和方法基线：所有团队成员都必须接受培训，使用通用术语来表达安全目标、威胁、漏洞、安全检查、事件响应等，并使用文档化的框架来管理系统的安全生命周期，例如 Microsoft SDL 或 SAMM 模型；
- 解决方案架构师应该负责中小型项目的安全性：在中小型项目中，解决方案架构师或类似角色必须了解所有模块和系统组件（包括源代码和架构），并且熟悉主要的攻击类型。这是一个要求很高的职位，但它大大减少了软件开发和维护流程正规化的需要。一般来说，培养这类人才涉及安全生命周期（例如 MS-SDL、SAMM）、应用程序中使用的特定技术以及攻击性安全（例如 CEH、CompTIA PenTest+、ECSA/LPT）的培训轨道；
- 任何规模的关键项目都需要形式主义，并且必须采用保证方法，例如北约 AEP-67 系统保证工程北约计划，该方法提出了一种记录和证明安全声明以及解决方案生命周期内相应保证级别的方法，同时考虑到其所有组成部分。由于其协调能力和可调节的努力程度，北约 AEP-67 已成功应用于多个成功项目，并作为团队训练的基础 [6]，这个主题将在后面讨论；
- 从源头上将一次性软件与生产软件分开：有必要避免在生产中使用一次性软件思维，这是原型设计阶段的典型特征，其中组件的“夜间构建”版本的使用通常由始终在寻找“最新功能”的热心开发人员团队完成。 冻结“长期支持 - LTS”版本中的组件在提供安全系统方面发挥着重要作用，这不仅是因为它们保证了复合系统的长期可维护性，而且从根本上因为它们“冻结”了攻击面并减少了安全缺陷的插入，从而使团队对他们想要保护的内容有更好的形式和/或心理模型。
保证案例作为团队建设工具
以 NATO AEP-67 形式呈现的保证案例以分层方式组织安全声明，如图 1 所示。每个“声明”可以由一个或多个中间声明（“子声明”）以递归方式支持。
在给出的例子中，“权利要求 A”同时要求子权利要求 1 和 2（以及可能的其他权利要求）为真，它才为真。在某些时候，必须以一定的确定性来证明或假定子声明是真实的。对于子权利要求 1，通过论证证明其为真，并且 预先定义的评估标准。
如图。 01 |摘自保险案例，来源 [6]。
正如我们在 [6] 中所报告的，正是这种在保证案例组成中表达和细节的能力（或需求），对于处理系统设计、开发和维护的团队的培训和改进起到了重要作用。在该项目中，坎普大学的研究生和本科生被组织成多个团队，旨在实施安全的群组安全消息服务，记录他们的安全保障，然后攻击另一个团队的系统。因此，团队在解决方案的整个生命周期中都得到了指导，并在信息安全领域所需的整体视野下提供了强大的见解。
在教育实验中，保证案例至少在三个教育方面被证明是至关重要的：（i）它们迫使每个学生挑战他们对系统组件安全性的假设，（ii）它们向团队证明了定义和记录简单而精确的系统组件安全策略/声明的必要性，以及（iii）它们充当了轴心 团队成员之间的客观沟通，优化努力并缩小差距。
这不仅仅是理论上的收获和学术练习，在 [6] 中报告的实验之后，我能够亲眼看到保证案例对于持续改进和专业人员的“在职培训”至关重要。更重要的是，这样的案例为开发系统的利益相关者提供了服务，因为他们现在对他们可以从系统中得到什么有了准确的描述。
结论
设计、实施、获取和维护安全的复合系统是一项严峻的挑战，首先需要参与团队具备态势感知能力。也就是说，尽管软件模块化具有商业优势，但组件化的组织却抽象出了对手用来实施成功攻击的几种实际路径。
为了最大限度地减少漏洞数量，开发、运营和安全团队必须具有相同的威胁模型、词汇和开发实践，以及对系统及其组件的整体视图。为此，Microsoft SDL、SAMM 和 NATO AEP-67 等方法和框架已被证明是有效的。
此外，致力于设计和开发的团队必须与安全团队反复联系，以便不断了解攻击技术，最重要的是，了解成功攻击所需的努力通常很少。在作者看来，没有什么可以阻止所有这些知识和实践纳入计算机本科和研究生课程。
参考文献
1.
Len Bass、Paul Clements 和 Rick Kazman，《实践中的软件架构》，第 4 版，2021 年 XNUMX 月。
2.
颜旭俊。 “论Petri网语言的规律性。”第十三届IEEE国际凤凰年会论文集
计算机与通信会议（1994）：329。
3.
- M. Mir、M. Keshani 和 S. Proksch，“传递性和粒度对漏洞传播的影响
Maven 生态系统”，2023 年 IEEE 软件分析、演化和再工程国际会议（SANER），澳门
澳门，2023 年，第 201-211 页，doi：10.1109/SANER56733.2023.00028。
4.
- Ullah Khan、M. Munib、U. Manzoor 和 S. Nefti，“分析架构层面的风险”，国际会议
信息社会 (i-Society 2011)，英国伦敦，2011 年，第 231-236 页，doi：10.1109/i-Society18435.2011.5978442。
5.
Kou, K.、Jeong, J. 和 Lee, G. (2008 年)。评估保证水平的定义和评估工作的估计
基于 ISO/IEC 19791 的操作系统。2008 年国际安全技术会议，176-183。 https://doi.
org/10.1109/SECTECH.2008.41
6.
Gallo，R.，Dahab，R.（2015）。保证案例作为信息安全的教学工具。见：Bishop, M.、Miloslavskaya, N.、
Theocharidou，M.（编辑）跨课程的信息安全教育。 WISE 2015. IFIP 信息进步
和通信技术，第 453 卷。Springer，Cham。 https://doi.org/10.1007/978-3-319-18500-2_2
罗伯托·加洛
他是政府、电信、军事、（反）情报和企业应用领域的国防和网络安全方面的资深人士。 在学术、专业和机构领域的表现。他拥有 UNICAMP 计算机科学博士和硕士学位，专注于网络安全。他还拥有同一所大学的计算机工程学位。
