├── the_impact_of_open_source_software_and_hardware ├── images │ ├── image-007.jpg │ ├── image-008.png │ ├── image-009.jpg │ └── image-010.jpg ├── chapter_01.md ├── chapter_03.md └── front_matter.md ├── nist_sp_800-125a ├── chapter_8.md ├── chapter_5.md ├── chapter_7.md ├── chapter_3.md ├── chapter_4.md ├── front_matter.md ├── chapter_6.md ├── chapter_1.md ├── chapter_2.md └── appendix.md ├── nist_sp_800-147b ├── chapter_5.md ├── chapter_1.md ├── chapter_3.md ├── chapter_4.md ├── front_matter.md └── chapter_2.md ├── peripheral-based_attack_memory ├── acknowledgement.md ├── abstract.md ├── chapter_7.md └── chapter_1.md ├── platform_firmware_security_defense ├── front_matter.md ├── chapter_4-6.md ├── chapter_2.md ├── appendix_b-d.md └── chapter_3.md ├── nist_sp_800-193 ├── chapter_1.md ├── front_matter.md ├── chapter_2.md ├── appendix.md └── chapter_3.md ├── nist_sp_800-147 ├── chapter_1.md ├── front_matter.md ├── chapter_3.md ├── chapter_2.md └── appendix.md ├── nist_ir_8151 ├── front_matter.md ├── chapter_1.md ├── chapter_4.md └── chapter_3.md ├── nist_ir_8176 ├── chapter_4.md ├── chapter_3.md ├── chapter_2.md ├── front_matter.md ├── chapter_6-10.md ├── chapter_1.md ├── appendix.md └── chapter_5.md └── nist_sp_800-155 ├── chapter_1.md ├── front_matter.md └── chapter_2.md /the_impact_of_open_source_software_and_hardware/images/image-007.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hardenedlinux/hardenedlinux_translations/HEAD/the_impact_of_open_source_software_and_hardware/images/image-007.jpg -------------------------------------------------------------------------------- /the_impact_of_open_source_software_and_hardware/images/image-008.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hardenedlinux/hardenedlinux_translations/HEAD/the_impact_of_open_source_software_and_hardware/images/image-008.png -------------------------------------------------------------------------------- /the_impact_of_open_source_software_and_hardware/images/image-009.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hardenedlinux/hardenedlinux_translations/HEAD/the_impact_of_open_source_software_and_hardware/images/image-009.jpg -------------------------------------------------------------------------------- /the_impact_of_open_source_software_and_hardware/images/image-010.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hardenedlinux/hardenedlinux_translations/HEAD/the_impact_of_open_source_software_and_hardware/images/image-010.jpg -------------------------------------------------------------------------------- /nist_sp_800-125a/chapter_8.md: -------------------------------------------------------------------------------- 1 | # 第 8 章 安全性建议总结 2 | 3 | 虚拟机监视器是一种复杂的服务器级别的软件，它通过虚拟化硬件资源以允许执行多个具有各异 OS 的计算栈（VM）以及托管于其中的多个应用程序。对于虚拟机监视器及其物理宿主（即虚拟机监视器宿主或者虚拟化的宿主）的安全配置被总体性地称为虚拟机监视器平台，并且对于为关键任务应用程序的执行提供安全平台是必需的。 4 | 5 | 由于存在多种方式对虚拟机监视器架构进行分类，此文档中所采用的方式是识别虚拟机监视器所执行的 5 项基线功能、每一项基线功能所涉及的任务、该任务的安全执行的潜在威胁，以及对以安全性建议的形式给出的，能够提供担保以对抗利用这些威胁的反制措施进行表述。 6 | 7 | 从总体上看，为虚拟机监视器的安全部署提供了 20 项安全性建议。除了两项（HY-SR-1 和 HY-SR-2）以外，都与虚拟机监视器平台中的软件模块的配置参数相关。这些参数包括软件模块（例如设备驱动程序和 VM 镜像）的完整性度量，访问控制（例如设备访问、VM 镜像访问和 VM 管理）的设置，以及安全协议（例如 VM 镜像服务器的访问和 VM 迁移）的配置。这些安全性建议同虚拟机监视器的基线功能之间的对应关系于附录 B 提供。 8 | 9 | 此文档中概述的信任模型（参见 1.2 节）假设虚拟机监视器宿主的硬件可信。然而必须指出的是，已有被报导的攻击案例（例如与某些被隐式共享的硬件资源，诸如 CPU 缓存和转译后备缓冲器（TLB），相关的旁路攻击）。更近时期公开的与 CPU 层级的性能优化相关的攻击（例如 Spectre 和 Meltdown）同样限制了对于当前用于虚拟机监视器部署的硬件平台的信任的担保。 10 | 11 | -------------------------------------------------------------------------------- /nist_sp_800-147b/chapter_5.md: -------------------------------------------------------------------------------- 1 | # 第 5 章 关于服务处理器的指导意见 2 | 3 | 服务器和客户端的关键区别之一在于系统中是否包含服务处理器。服务处理器在管理和监视服务器的过程中具有重要作用，并且可能在更新系统 BIOS 过程中也有作用。本章描述服务处理器并且为包含服务处理器的系统提供更加详细的安全性要求。 4 | 5 | ## 5.1 作为可信根的服务处理器 6 | 7 | 受管理的服务器和刀片服务器中的服务处理器可能拥有直接更新 BIOS 闪存存储器、BIOS 执行内存或者它们自己的闪存或者其他存储介质的能力。在这些情况下，某些或者全部服务处理器环境可以被用作系统 BIOS 的 RTU。这适用于在那些使用 BIOS 闪存保护机制以防止对 BIOS 代码的非授权修改的系统（例如使用第 4 章所述的更新机制 1 或 2 的系统）上能够更新 BIOS 闪存的服务处理器。这也适用于在那些在执行前验证 BIOS 代码的系统（例如使用更新机制 3 的系统）上能够修改用于验证 BIOS 代码的 RTU 的服务处理器。 8 | 9 | 在这些情况下，服务处理器（SP）的执行环境必须被保护以防止那些能够更新 BIOS 或者 SP 闪存的恶意代码。为了满足第 3 章所述的 BIOS 安全性原则，用作可信根以保护 BIOS 的服务处理器应该满足以下指导意见： 10 | 11 | 1. 针对 SP 代码、密码学密钥以及存储于 SP 闪存中的静态数据的更新应该经过认证更新机制 12 | 2. SP 环境应该被控制，使得只有合法代码可以在 SP 上执行 13 | 3. 用户同服务处理器的交互应该要求授权。 14 | 15 | ## 5.2 由服务处理器实现的 BIOS 保护的不可绕过性 16 | 17 | 某些带有服务处理器的服务器可能不将服务处理器用作 BIOS 更新的 RTU。为了保证 SP 环境不能绕过 BIOS 保护，这些系统中的服务处理器不应该拥有对于 BIOS 代码在其中验证或者执行的 BIOS 闪存存储器的直接写入访问权限。更进一步地，服务处理器应该受到限制，使得它不能干涉 BIOS 更新过程，也不能干涉 BIOS 或者 RTU 代码在其中执行的内存。 18 | 19 | 未被实施这些限制的服务处理器可能能够绕过此文档所概述的 BIOS 保护。因此，它们必须被信任以保护 BIOS，即使它们在其正常操作中并未被用于 BIOS 更新。这样的服务处理器应该被视为可信根，并且满足 5.1 节的要求。 20 | 21 | -------------------------------------------------------------------------------- /peripheral-based_attack_memory/acknowledgement.md: -------------------------------------------------------------------------------- 1 | # 致谢 2 | 3 | 首先，我特别想要感谢我的导师 Jean-Pierre Seifert。我不仅感谢众多有益的讨论以及卓越的研究环境，同时也感谢允许我自由地选择我自己的论文题目。他的感召、鼓舞、激励和启发使我感激终生。感谢我的导师，他使我总是对我的研究和论文充满信心。其次，我想要对来自柏林科大电信安全委员会（SecT）的同事和朋友们致以最诚挚的谢意。特别感谢 Nico Golde 和 Dmitry Nedospasov（博士团队），以及 Iurii Bystrov，Kévin Redon，Ravi Borgaonkar，和 Collin Mulliner。如果没有博士团队，我可能现在还在写作我的论文。特别地，我感谢 Collin 在所有领域提出的建议。如果没有 Iruii，与 Intel AMT/ME 相关的工作不可能取得如此巨大的成功。 4 | 5 | 我同样想要感谢柏林科大通讯和操作系统（KBS）研究小组以及计算机安全工作组（AGRS），由于众多有益的评论，以及他们对于对于准备学术会议演讲的有益建议。此外，我想要感谢来自云和安全实验室（惠普 Bristol 实验室）的 Dirk Kuhlmann 和 Chris Dalton，由于他们那些非常有益和激励性的讨论帮助我开发了 BARM 所基于的理念。 6 | 7 | 我同样感谢我所得到的来自软件校园计划的帮助。德国电信 AG（DTAG）和电信创新实验室（T-Labs）在此计划的上下文环境中对我的工作进行了支持。我的软件校园计划由德意志联邦教育和科研部资助（批准号 O1IS12056）。此项目的成果是我的论文的重要组成部分。因此，我想要感谢软件校园团队的组织支持、DTAG/T-Labs 的业界指导、柏林科大/SecT 的学术指导，以及德意志联邦教育和科研部的经济支持。 8 | 9 | 在我作为博士生期间，有许多其他人以不同方式帮助过我。我没法在此列出他们的全部，但是我想要特别感谢下列支持者的帮助（不完全统计，排名不分先后）：Yacine Gasmi，Martin Unger，Kei Ishii，和 Marcel Selhorst。此外，博士学位委员会，即 Hans-Ulrich Heiß，Jean-Pierre Seifert，以及外部审稿人 Konrad Rieck 和 Volker Roth 为我的论文最终版本给予了无价的反馈，我对此深表谢意。 10 | 11 | 此外，我特别想要感谢我的家庭，特别是我的家长和姐妹的鼓励和爱。最后，我深深地感谢我的未婚妻 Gesche，你总是尽你所能极大地帮助了我。感谢你的光辉灿烂的支持，鼓舞和爱！ 12 | 13 | -------------------------------------------------------------------------------- /nist_sp_800-125a/chapter_5.md: -------------------------------------------------------------------------------- 1 | # 第 5 章 HY-BF2 安全性建议 2 | 3 | 关于 2.2.2 节所讨论的所有 3 种形式的设备虚拟化以及自虚拟化的设备的讨论于本节提供。 4 | 5 | _安全性建议 HY-SR-6A（模拟）_：由于通过软件模拟硬件的复杂性，模拟方式除了受到性能损失以外，还会增加 TCB 的大小，特别是在客户 OS 拥有原生设备驱动程序并且设备模拟代码作为内核模块运行在和虚拟机监视器相同的权限层级的情况下。因此，模拟应该仅被应用于这种复杂性可控时（例如 USB 主机控制器） 6 | 7 | _安全性建议 HY-SR-6B（准虚拟化）_：在准虚拟化的设备驱动程序被用于 VM 中的情况下，对物理设备的访问的调度应该通过在专用 VM 而非在虚拟机监视器中运行后端设备驱动程序（它们控制着连接到虚拟机监视器宿主的物理设备）来启用。这有助于使得后端设备驱动程序代码运行在低于虚拟机监视器的权限层级上。此外，虚拟机监视器平台应该包括输入/输出内存管理单元（IOMMU）形式的硬件支持以便验证并且翻译从驱动程序域的底层硬件设备到宿主内存的访问。强制性的具体 IOMMU 特性包括 DMA 重映射，在此，从设备到客户物理地址（GPA）的 DMA 调用必须被翻译到宿主物理地址（HPA），并且随后被检查该 HPA 地址是否落在指认给该设备的保护域内。结合这些机制可以减少 TCB 的大小，并且降低错误的设备或者设备驱动程序的行为的影响（限制在设备驱动程序 VM 范围内，而非虚拟机监视器） 8 | 9 | _安全性建议 HY-SR-6C（透传或者自虚拟化的硬件设备）_：对于 VM 需要被赋予对具有 DMA 能力的设备的专用访问权限的情况，虚拟机监视器平台应该包括输入/输出内存管理单元（IOMMU）形式的硬件支持以便验证并且翻译所有设备对宿主内存的访问。此建议也适用于自虚拟化的硬件设备的使用（基于 SR-IOV 规范）。强制性的具体 IOMMU 特性包括 DMA 重映射，在此，从设备到客户物理地址（GPA）的 DMA 调用必须被翻译到宿主物理地址（HPA），并且随后被检查此 HPA 是否落在指认给该设备的保护域内 10 | 11 | 下列安全性建议的适用性与设备虚拟化的类型无对应关系： 12 | 13 | _安全性建议 HY-SR-7（设备访问）_：应该可能设置访问控制列表（ACL）以便将每一个 VM 进程的访问权限限制为仅对指认给该 VM 的设备。为了实现这一点，虚拟机监视器配置应该支持某种特性以标记 VM（从语义上讲，一组任务），并且/或者拥有某种特性以便为每一个 VM 指定一组白名单，或者被允许的设备的列表 14 | 15 | _安全性建议 HY-SR-8（设备使用）_：应该可能为每一个 VM 的网络带宽和 I/O 带宽（例如硬盘读/写速度）设置资源限制以防止拒绝服务（DOS）攻击。此外，对资源限制的适当使用可以使得 DOS 攻击对定义了资源限制的 VM 或者集群的影响定域化 16 | 17 | -------------------------------------------------------------------------------- /platform_firmware_security_defense/front_matter.md: -------------------------------------------------------------------------------- 1 | # 用于企业系统管理员和蓝队的平台固件安全防御 2 | 3 | Paul English 和 Lee Fisher 著 4 | 5 | PreOS Security 6 | 7 | [https://preossec.com](https://preossec.com) 8 | 9 | 著作权所有（C）2018 Paul English 和 Lee Fisher 10 | 11 | 知识共享：署名—非商业—相同方式共享 4.0 许可证（CC BY-NC-SA 4.0） 12 | 13 | # 著作权声明 14 | 15 | ## 封面 16 | 17 | 封面艺术修改自 Wikipedia 的 IIVQ 的原创作品，其许可证为 GNU 自由文档许可证（GFDL）（[https://www.gnu.org/copyleft/fdl.html](https://www.gnu.org/copyleft/fdl.html)）或者知识共享：署名—相同方式共享 3.0（CC BY-SA 3.0）。 18 | 19 | [https://commons.wikimedia.org/wiki/File:Dartboard_unlabeled.svg](https://commons.wikimedia.org/wiki/File:Dartboard_unlabeled.svg) 20 | 21 | ## 内容 22 | 23 | 所有其他内容：著作权所有（C）2018 Paul English 和 Lee Fisher，知识共享：署名—非商业—相同方式共享 4.0（CC BY-NC-SA 4.0） 24 | 25 | # 免责声明 26 | 27 | 固件属于软件，但是与存储在您的（固态）硬盘上的操作系统和应用软件不同的是，您不一定能够将其擦除并且重新安装。由于平台固件使得系统能够运作，您在处理固件的时候有可能使得您的系统完全不能运作。在本书中，我们将会试图强调那些比较危险的操作，特别是自动化的模糊测试，或者写入/重写。对于大多数技术建议或者软件——小心操作并且自行承担风险。 28 | 29 | # 注记 30 | 31 | 在企业环境中，理论上会部署众多（几乎）完全相同的系统。因此在部署到大量系统之前先在一台样机上测试某些比较危险的操作是合理的。PreOS Security 强烈建议采用这种方式。在企业环境中，您可能还会拥有来自制造商或者 OEM 的保修以及延伸支持。在操作之前，请毫不犹豫地咨询制造商——事实上，这会通过向制造商强调消费者关注这些问题并且想要得到可靠、安全的系统这一点进而帮助每一个人乃至整个生态系统。 32 | 33 | # 关于本书 34 | 35 | ## 脚注 36 | 37 | 与此书的第一版的脚注不同的是，我们将最新版本的 Awesome Firmware Security 的在线文档 _Github Awesome list_ 作为附录包含进来。每一处应该作为脚注的参考文献都被包含到此文档中。 38 | 39 | 我们欢迎您的反馈！我们希望这本书成为顶尖的，而此书的两位作者都不是作家。 40 | 41 | 邮件：editor@preossec.com 42 | 43 | -------------------------------------------------------------------------------- /the_impact_of_open_source_software_and_hardware/chapter_01.md: -------------------------------------------------------------------------------- 1 | # 1. 简介 2 | 3 | 开源（OS）在最近二十年内日益增长的相关性要求我们更新对其当前作用、地位，及其对于欧洲经济的潜力的深度分析。特别地，在最近几年发生了若干起与基于开源的公司相关的重大投资和收购。 4 | 5 | 尽管开源软件（OSS）已经在过去的二十年内在软件产业的所有领域成为主流，开源硬件（OSH）仍然处于新兴阶段。然而，关于 OSH 的商业生态系统正在发展。这包括诸如三维打印、电子产品（其典型案例是 Arduino 的成功，这是一种基于欧洲的开源电子微控制器和原型平台，允许用户创造交互式电子产品），以及开源芯片等领域。开源的原则同样被应用于数据中心，通过诸如开源计算计划等促进会。OSH 与 OSS 拥有若干共同特性，但是也有其独特特征。此报告将 OSS 定义为基于某种符合开放源代码促进会的开源定义的许可证发布的软件，而将 OSH 和开放硬件定义为其设计已经公开，并且基于符合由开源硬件协会发布的开源硬件定义的许可证发布硬件（任何实体物品）。由于 OSS 和 OSH 拥有超出授权许可模型以外的涵义，应该时刻记住，开源软硬件（OSSH）这一总称是一个包括了源代码、设计授权、合作管理、提供方法，以及生产过程本身等方面的宽泛的概念。 6 | 7 | 此研究的一般目标是调查 OSSH 对于欧洲经济在宏观经济和公司层面上的影响的不同维度，同时也借助于案例研究，尤其是在 OSH 领域。这些见解构成了识别开源在不同领域的强弱危机的基础。更进一步地，在欧洲和世界范围内所倡导的旨在支持开源的政策必须予以分析。最后，基于不同类型的分析，必须得出政策建议，它们可以使得开源带来的效益最大化，以便支持具有竞争力的欧盟软硬件产业以及欧盟经济整体的生态友好型转变。 8 | 9 | 此最终研究报告的目标是为“关于开源软硬件对欧盟的技术独立性、竞争力和创新的影响的研究（SMART 2019/0011）”这一项目提供关于分析和政策建议最终结果，该项目正在由夫琅禾费 ISI 和开放欧洲论坛实施。 10 | 11 | 此报告涵盖了于下文简述的话题。为了阐述关于尤其是同 OSS 相关联的大量研究的最先进技术，我们指导了对于近二十年来发表的文献的完整综述，包括同该领域中的领先学者进行联系。其结果汇总于第二章。基于对于文献的发现，包括考虑到现存数据的局限性，我们开发了方法论以应对不同任务。我们所提议的方法论因此被详细阐述于第三章。由于存在着多种适用于 OSS 的分类学和商业模型，其中有些也适用于 OSH，而有些则是独特的，来自不同行业领域的包括成功案例在内的案例研究呈现于第四章，其后跟着对于欧洲经济的 SWOT 分析以及对于 OSS 和 OSH 的商业模型的定量调查。第五章首先呈现了对于尤其是 OSS，也包括现存的其他方法所带来的影响的经济分析，并且强调了其局限性。其次，该经济分析由一项既在国家层面也在公司层面的基于成本的影响分析作为补充，以便得出最终的成本效益比例。股东调查的结果呈现于第六章，其后在第七章跟着对于来自不同方法的结果的完整汇总以及浓缩的三方分析。基于某种分析框架，通过对于旨在支持 OSS 和 OSH 的不同政策的分析而得出的见解显示于第八章，随后呈现的是基于通过不同分析而获得的不同见解的政策建议。 12 | 13 | -------------------------------------------------------------------------------- /nist_sp_800-193/chapter_1.md: -------------------------------------------------------------------------------- 1 | # 第 1 章 简介 2 | 3 | ## 1.1 目的 4 | 5 | 现代计算和信息技术系统构建于一系列提供系统运行所必需的功能能力的硬件组件之上。众多此类硬件组件拥有驱动其行为的固件和配置数据，并且它们必须维持在某种具有完整性的状态，以使得系统正常运作。此类固件的一个范例通常被称为基本输入/输出系统（BIOS），它被用于辅助硬件初始化过程并且将控制权移交给操作系统。取决于系统，可能有数十或者数百个具有其他类型的可编程固件的微控制器，其固件支持了整体系统架构。这些硬件和固件的集合通常称为 _平台_。 6 | 7 | 构成了平台的设备对于基于此平台构建的系统的完整性和可用性至关重要。没有这些设备，系统可能不能正确地运行，甚至完全不能运行。针对平台中的某些设备的攻击可以对系统的安全状态造成重大影响，有可能允许低级恶意软件的持久存在。定位于损坏或者移除平台固件的攻击具有使得系统永久损坏的潜力，从而对受其影响的相关方受到实质性的损失。 8 | 9 | 此文档的目的是为在平台层级支持系统弹性提供安全性指导意见。如同系统工程国际委员会（INCOSE）所定义，系统弹性是指“具有某些特定性质的系统在干扰发生之前、之中和之后吸收此干扰、恢复至某种可接受的性能水平，并且维持该水平达到一段可接受的时间的能力” \[10\]。应用于信息系统时，网络弹性是指“预见、抵御、恢复并且适应针对包含网络资源的系统的不利条件、压力、攻击或者破坏的能力”。尽管关于系统层级的网络弹性的指导意见在 NIST 特别出版 800-160 草案第 2 卷中有所描述，此出版物指出这种系统层级的弹性应该由计算机平台中的基础安全性能力所支持。此文档中的指导意见支持网络弹性，通过具体说明保护固件和配置数据不受攻击，以及能够检测并且从成功的攻击中恢复的机制。 10 | 11 | ## 1.2 受众 12 | 13 | 此文档本意中的受众包括计算机系统的系统和平台设备厂商，其中包括客户端、服务器和网络设备的制造商。这些技术指导意见假设读者拥有平台架构方面的技能，并且主要面向负责在系统和设备中实现固件级安全技术的开发者和工程师。 14 | 15 | 这些素材对于开发企业范围内的采购和部署策略可能也会有用。此文档中的素材是面向技术的，并且假设读者对于计算机安全性原理和计算机架构至少拥有基本的理解。此文档提供了背景信息以帮助这些读者理解正在讨论的话题。 16 | 17 | ## 1.3 适用性和范围 18 | 19 | 此文档的目的是提供能够支持主要面对远程攻击的平台弹性的原则和指导意见。这些原则和指导意见直接适用于构成了平台的独立设备（参见 2.1 节以获取一系列范例的列表）。具体地，它们描述了定位于保护每个设备使其固件或者关键数据不被非授权修改以及将平台恢复至某种具有完整性的状态的安全机制。 20 | 21 | ## 1.4 文档结构 22 | 23 | 此文档的剩余部分被组织进下列主要部分中： 24 | 25 | * 第 2 章提供了描述平台组件和架构的信息性素材 26 | * 第 3 章描述了构成此文档中的指导意见的基础的安全性原则，并且描述了将这些原则应用于平台弹性的关键概念 27 | * 第 4 章包含关于保护固件代码和关键数据、检测非授权更改以及恢复至某个具有完整性的状态的安全技术指导意见 28 | * 附录 A 提供了此文档中的首字母缩略词和缩略语 29 | * 附录 B 呈现了此文档中的选定的术语的词汇表 30 | * 附录 C 包含此文档中的参考文献列表 31 | 32 | -------------------------------------------------------------------------------- /nist_sp_800-147b/chapter_1.md: -------------------------------------------------------------------------------- 1 | # 第 1 章 简介 2 | 3 | ## 1.1 目的和范围 4 | 5 | 此文档提供服务器级别的系统中的 BIOS 保护指导意见。它是关于 BIOS 保护的系列出版物中的第二部。于 2011 年四月发布的首部文档，SP800-147，BIOS 保护指南，提供了关于部署于企业环境中的台式机和笔记本系统的指导意见。 6 | 7 | 恶意软件对 BIOS 固件的恶意修改构成了一种重大威胁，由于 BIOS 在现代计算机系统架构中的独特和特权的地位。恶意 BIOS 修改可能是针对组织机构的高级攻击的一部分——可以是永久的拒绝服务（如果 BIOS 损坏）或者是持久的恶意软件存在（如果 BIOS 被植入恶意软件）。 8 | 9 | 列出于 NIST SP800-147 中的用于客户端系统的 BIOS 保护的三大核心原则——认证固件更新、完整性保护和保护机制的不可绕过性——也适用于服务器级别的设备。然而，服务器由于其需要远程管理而带来的架构和操作上的复杂性，其以相同于客户端的方式实施 BIOS 安全保护更加困难；造成这种增加的难度的核心原因是服务器通常拥有多种 BIOS 更新机制。此外，某些服务器拥有一块或者更多的服务处理器（SP）。SP 为其宿主执行多种管理功能，这可能包括 BIOS 更新。这将 SP 作为一种安全关键组件引入进来，此文档因此包含关于作为 BIOS 更新过程的一部分的 SP 的指导意见。 10 | 11 | 启动固件指那些用于辅助硬件初始化过程并且将控制权移交给虚拟机监视器或者操作系统的软件或者固件。此出版物将 BIOS 用作指代服务器中的系统启动固件的通用、认可的词语，包括但不限于基于传统 BIOS、可扩展固件接口（EFI）BIOS 和统一可扩展固件接口（UEFI）BIOS 的启动固件。此文档中的指导意见包括在服务器上避免执行恶意或者损坏的 BIOS 代码的要求。它们适用于存储于 BIOS 闪存存储器中的 BIOS 固件，包括 BIOS 代码、作为更新可信根（RTU）的一部分的密码学密钥，以及静态 BIOS 数据。同系统 BIOS 固件一同存储并且由相同机制更新的设备固件根据此文档的目的被视为 BIOS 的一部分（例如，嵌入于 BIOS 闪存中的 Option ROM）。这些指导意见并不适用于存储于服务器的其他位置，例如一块可选板卡本身的其他设备固件或者 Option ROM。 12 | 13 | 此指南的本意是为服务器平台厂商提供关于安全 BIOS 更新过程的建议和指导意见。系统管理员应该查询 NIST SP800-147 的 3.2 节以获得关于在客户端和服务器系统上管理 BIOS 的建议的最佳实践。 14 | 15 | ## 1.2 受众 16 | 17 | 此文档本意上的受众包括服务器级别的系统的 BIOS 和平台厂商，以及负责管理服务器安全的系统安全专业人士。这些素材对于开发企业范围内的采购策略并且部署可能也会有用。 18 | 19 | 此文档中的素材是面向技术的，并且假设读者对于系统和网络安全至少具有基本理解。此文档提供背景信息以帮助这些读者理解所讨论的话题。我们鼓励读者充分利用其他资源（包括此文档中所列出的那些）以获取更多的细节信息。 20 | 21 | ## 1.3 文档结构 22 | 23 | 此文档的剩余部分被组织进以下的主要章节中： 24 | 25 | * 第 2 章呈现对于 BIOS 的概览，描述服务器架构及其更新机制，识别对于服务器中的 BIOS 的潜在威胁，并且解释更新可信根 26 | * 第 3 章识别为了化解对服务器中的 BIOS 的威胁所要求或者建议的用于 BIOS 实现的安全控制 27 | * 第 4 章为三种更新机制中的每一种提供额外的安全指导意见 28 | * 第 5 章为服务处理器提供额外的安全指导意见 29 | 30 | 此文档还包括带有支持素材的附录： 31 | 32 | * 附录 A 包含用于系统 BIOS 实现的安全指导意见的总结 33 | * 附录 B、C 和 D 描述用于实现服务器中的 BIOS 保护的可能的系统设计范例 34 | * 附录 E 定义此文档中使用的词语 35 | * 附录 F 包含此文档中使用的首字母缩略词和缩略语 36 | * 附录 G 包含此文档开发过程中使用的参考文献的列表 37 | 38 | -------------------------------------------------------------------------------- /nist_sp_800-147/chapter_1.md: -------------------------------------------------------------------------------- 1 | # 第 1 章 简介 2 | 3 | ## 1.1 权力范围 4 | 5 | 美国国家标准技术研究所（NIST）开发此文档以履行其在 2002 年美国联邦信息安全管理法案，公法 107-347 下的法定责任。 6 | 7 | NIST 负有开发标准和指导意见，包括最低要求的责任，以便为所有政府机构的运作和财产提供足够的信息安全；但是，这些标准和指导意见不会适用于国家安全系统。此指导意见与美国行政管理和预算局（OMB）的公告 A-130 第 8b\(3\) 节“防护政府机构信息系统”相一致，如同在 A-130 的附录 IV“关键章节分析”中所分析的那样。补充信息在 A-130 附录 III 中提供。 8 | 9 | 此指导意见为联邦政府机构而准备。它可以在自愿基础上被非政府组织使用，并且不受限于版权，尽管我们要求署名权。 10 | 11 | 此文档中的任何部分都不应该被用于否认由美国商务部秘书在法定权力之下规定为对于联邦政府机构具有强制性和法定约束力的标准和指导意见，这些指导意见也不应该被解读为更改或是取代商务部秘书、OMB 主任或是任何联邦官员的现有职权。 12 | 13 | ## 1.2 目的和范围 14 | 15 | 此文档为防止 PC 客户端系统上的针对基本输入/输出系统（_BIOS_）的非授权修改提供了指导意见。由恶意软件进行的非授权 BIOS 修改构成了显著的威胁，由于 BIOS 在 PC 架构中的独特和特权的地位。对 BIOS 的恶意修改可能是针对某个组织的高级攻击的一部分——可以是永久的拒绝服务（如果 BIOS 损坏），也可以是持久的恶意软件存在（如果 BIOS 被植入恶意软件）。 16 | 17 | 如同在本出版物中所使用的那样，BIOS 这一词语可以指代传统 BIOS、可扩展固件接口（_EFI_）BIOS 以及统一可扩展固件接口（_UEFI_）BIOS。此文档适用于存储于计算机系统中的系统闪存中的系统 BIOS 固件（例如，传统 BIOS 或者 UEFI BIOS），包括可能被格式化为 Option ROM 的部分。然而，它并不适用于存储于计算机系统中的其他位置的 Option ROM、UEFI 驱动程序和固件。 18 | 19 | 此指南的 3.1 节为平台厂商提供了用于安全 BIOS 更新过程的建议和指导意见。此外，3.2 节提供了针对操作环境中的 BIOS 管理的建议。此出版物的未来修订版本还将应对与 BIOS 进行交互的关键系统固件的安全性。 20 | 21 | 尽管此文档的关注焦点是当前和未来的 x86 和 x64 客户端平台，其控制和过程独立于任何特别的系统设计。类似地，尽管此指南面向企业级平台，其必要的技术可以期望随着时间迁移到消费者级别的系统上。未来的努力可能会着眼于企业服务器平台的启动固件安全性。 22 | 23 | ## 1.3 受众 24 | 25 | 此文档本意中的受众包括 BIOS 和平台厂商，以及负责管理终端平台的安全性、安全启动过程和硬件安全性模块的信息系统安全专业人士。这些素材在开发企业范围的采购策略并且部署的时候可能也会有用。 26 | 27 | 此文档中的素材是面向技术的，并且它假设读者至少拥有对于系统和网络安全的基本理解。此文档提供了背景信息，以帮助这些读者理解所讨论的话题。我们鼓励读者利用其他资源（包括列出于此文档中的）以获取更多细节信息。 28 | 29 | ## 1.4 文档结构 30 | 31 | 此文档的剩余部分被组织为以下章节： 32 | 33 | * 第 2 章呈现了对于 BIOS 及其在启动中的作用的总览，并且指认了在操作环境中针对 BIOS 的潜在攻击 34 | * 第 3 章检验了针对 BIOS 的选定威胁可以如何被化解。3.1 节描述了为了化解这些威胁所要求或者推荐的用于 BIOS 实现的安全控制。3.2 节定义了在企业内部作为平台管理生命周期的一部分撬动这些控制以实施一种安全 BIOS 更新过程的过程 35 | 36 | 此文档还包含带有支持材料的附录： 37 | 38 | * 附录 A 包含了关于系统 BIOS 实现的安全指导意见的总结 39 | * 附录 B 定义了此文档中所使用的词语 40 | * 附录 C 包含了此文档中使用的首字母缩略词和缩略语列表 41 | * 附录 D 包含了开发此文档过程中所使用的参考文献列表 42 | 43 | -------------------------------------------------------------------------------- /nist_ir_8151/front_matter.md: -------------------------------------------------------------------------------- 1 | # NIST 跨部门报告 8151 2 | 3 | # 显著减少软件漏洞——致美国白宫科技政策办公室 4 | 5 | Paul E. Black，Lee Badger，Barbara Guttman 和 Elizabeth Fong 著 6 | 7 | 信息科技实验室 8 | 9 | 此出版物可从此处免费获得： 10 | 11 | [https://doi.org/10.6028/NIST.IR.8151](https://doi.org/10.6028/NIST.IR.8151) 12 | 13 | 2016 年十一月 14 | 15 | 美国商务部 秘书 Penny Pritzker 16 | 17 | 美国国家标准技术研究所 标准技术商务次长兼主任 Willie May 18 | 19 | 美国国家标准技术研究所跨部门报告 8151，64 页（2016 年十一月） 20 | 21 | > 此文档中可能会提到某些商业实体、设备或者器材以便充分地描述某种试验程序或者概念。这样的提名的本意并非暗示 NIST 对其的推荐或认可，也非暗示这些实体、器材或者设备一定是可用于该目的之最好的。 22 | 23 | > 此文档中可能会有对于 NIST 的当前正在开发中的其他出版物的引用，以便符合其被赋予的法定责任。此出版物中的信息，包括概念和方法论，可以被联邦政府机构使用，即使是在这些附带的出版物完成之前。因此，直到每部出版物完成之前，当前的要求、指导意见和过程在其所存在之处仍然有效。关于计划和迁移的目的，联邦政府机构可能想要紧密跟踪由 NIST 提供的这些新出版物的进展。 24 | 25 | > 我们鼓励组织机构在公开评论期间审阅所有出版物草案，并且向 NIST 提供反馈。除了上述出版物以外，NIST 的众多计算机安全出版物可以从 [https://csrc.nist.gov/publications](https://csrc.nist.gov/publications) 获取。 26 | 27 | 关于此出版物的评论可以被提交至： 28 | 29 | 美国国家标准技术研究所 30 | 31 | 收件人：计算机安全分部，信息科技实验室，办事处大道 100 号（8930 邮递点），盖瑟斯堡，马里兰州 20899-8930 32 | 33 | 邮件：[paul.black@nist.gov](mailto:paul.black@nist.gov) 34 | 35 | 所有评论必须在美国信息自由法（FOIA）条款下发布。 36 | 37 | # 摘要 38 | 39 | 对于显著减少软件漏洞的诉求发出自众多来源，从最近的 2016 年二月发布的美国联邦网络安全研发战略计划开始。此计划以描述众所周知的危险性开始：当前的系统正在执行着越来越关键的任务，并且其存在漏洞这一点广为人知。这些漏洞通常不易发现并且难于修复。网络安全并未跟上步伐，并且所需的步伐正在快速加速。此报告的目的是呈现一系列特定的技术方式，它们拥有在减少漏洞方面发挥显著作用的潜力——通过在漏洞发生之前阻止它们、在漏洞被利用之前发现它们，或者降低漏洞所造成的影响。 40 | 41 | # 关键字 42 | 43 | 测定；度量；软件担保；软件措施；安全漏洞；减少软件漏洞 44 | 45 | # 致谢 46 | 47 | 非常感谢 Rajeev Joshi（rajeev.joshi@jpl.nasa.gov），由于其对第 2.3 节“附加软件分析技术”的贡献。 48 | 49 | 同样感谢来自麻省理工学院林肯实验室的答辩、研究和工程助理秘书办公室的合同官 W. Konrad Vesey（william.k.vesey.ctr@mail.mil），由于其为第 2.5 节“移动目标防御（MTD）”和“自动软件多样性”提供的素材，大量词句直接来自作者同他的私人通讯。 50 | 51 | 我们感谢 Terry Cohen、Mark Cornwell、John Diamant、Jeremy Epstein、D. Richard Kuhn、Andrew Murren、Kenneth S. Thompson、Jan Vandenbos、David Wheeler 和 Lok Yan，由于他们的大量评论和建议极大地改进了此报告，我们还要感谢众多提出了改进意见、提问了问题并且提交了评论的其他人。 52 | 53 | -------------------------------------------------------------------------------- /nist_sp_800-125a/chapter_7.md: -------------------------------------------------------------------------------- 1 | # 第 7 章 HY-BF5 安全性建议 2 | 3 | 对于任何服务器级别的软件而言，管理功能的安全选项都是至关重要的，虚拟机监视器也不例外。其结果是一种能够提供对抗安全侵犯所必需的保护的安全配置。在虚拟机监视器的案例中，相对于众多服务器软件实例，非安全配置的影响可能更加严重，由于针对虚拟机监视器的攻击可能导致针对其上运行着的众多 VM 的攻击。尽管配置参数的组成取决于虚拟机监视器供应的设计特性，对于每一个独立的参数的值的选择的纬度会产生不同的配置选项。众多配置选项与功能特性和性能相关。然而，有一些选项对于虚拟机监视器的安全执行具有直接影响，并且这些就是此文档中所讨论的配置选项。 4 | 5 | 以下是一些通用于任何服务器级别的软件的安全实践。尽管也适用于虚拟机监视器，这些并未在此文档中解决： 6 | 7 | * (a) 虚拟机监视器宿主本身上的管理帐户控制以及对不同管理员的最小权限指认 8 | * (b) 虚拟机监视器软件和宿主 OS 的补丁管理 9 | * (c) 通过诸如 TLS 或者 Secure Shell（SSH）等安全协议同虚拟机监视器进行通讯 10 | 11 | ## 7.1 中心化管理 12 | 13 | 对虚拟机监视器和虚拟机监视器宿主的管理可以通过两种方式实现： 14 | 15 | * 在每一个虚拟机监视器宿主中设置有管理帐户 16 | * 通过企业虚拟化管理软件对所有虚拟机监视器和虚拟机监视器宿主进行中心化管理 17 | 18 | 通过企业虚拟化管理软件（EVMS）对企业中的所有虚拟机监视器平台进行中心化管理是理想的，由于用于企业中的所有虚拟机监视器的一组黄金标准配置可以通过 EVMS 定义并且简单地强制实施。对于任何想要高效运行的 IT 数据中心，实施负载均衡和容错措施是必要的，这可以通过定义虚拟机监视器集群来实现。对集群的创建、指派应用程序负载以及管理只能依靠中心化的管理软件来实现，使得部署和使用企业虚拟化管理软件成为强制性的。 19 | 20 | 因此，对于虚拟机监视器管理架构的建议如下所述： 21 | 22 | _安全性建议 HY-SR-19_：对于企业中安装的所有虚拟机监视器的管理应该利用企业虚拟化管理系统（EVMS）以中心化的方式实现。用于不同类型的负载和集群的企业黄金标准虚拟机监视器配置必须通过 EVMS 进行管理和强制实施。此黄金标准配置至少应该覆盖 CPU、内存、存储、网络带宽，以及如有必要，宿主 OS 加固 23 | 24 | ## 7.2 保护管理网络 25 | 26 | 为了将多个 VM 彼此连接起来，以及将它们连接到虚拟化的宿主作为其中一个结点的企业网络，虚拟机监视器通过其管理控制台或者命令行界面（CLI）允许一种由软件定义的通讯结构，或者虚拟网络。此能力可以由专用的管理 VM 提供，也可以直接在虚拟机监视器内核中通过内核模块来提供。虚拟网络是一种由软件定义的人造物，它完全驻留于虚拟化的宿主中，并且拥有驻留于其中的 VM 作为其结点。此虚拟网络的组件包括：(a) 为每一个 VM 定义并且提供每一个 VM 到虚拟网络的连接的虚拟网卡（vNIC）；(b) 在 VM 之间提供选择性的连接性，并且其配置决定了虚拟网络拓扑结构的虚拟交换机；以及 (c) 提供 VM 到企业网络的连接性的虚拟化的宿主的物理网卡（pNIC）。 27 | 28 | 在考虑虚拟网络的安全性影响时，下列 3 项主要功能必须被考虑到： 29 | 30 | * 在属于不同逻辑分组（例如，在基础设施即服务（IaaS）的云服务案例中的不同租用者；诸如网络服务器或者数据库服务器中的不同应用层；或者企业中的不同业务线应用程序等）的 VM 组别中提供选择性的连接性或者隔离 31 | * 设置专用的子网用于关键功能，诸如 (a) 出于安全性或者性能的原因，将 VM 从一个虚拟机监视器宿主迁移到另一个，(b) 连接基于网络的存储设备，以及 (c) 容错性日志 32 | * 在管理 VM（虚拟网络的一个结点）中提供对管理接口的访问，此管理 VM 被用于执行 VM 生命周期管理（HY-BF4）和虚拟机监视器平台管理（HY-BF5）的虚拟机监视器关键基线功能 33 | 34 | 在上述 3 种功能之中，VM 组别之间的选择性的连接性和隔离对于为运行在这些 VM 上的应用程序提供安全性是必需的，因此超出了此文档的范围。同样的判据适用于设置专用的子网用于基于网络的存储管理。我们已经在第 6 章讨论了 VM 生命周期管理之下的安全 VM 迁移。因此，我们对于虚拟网络配置的专注限于为用于执行 VM 管理和虚拟机监视器管理功能的网络接口提供保护。一种被普遍采用的方式是分配一块专用的物理网卡（NIC）用于处理管理流量，如果这不可行，则改为专用于此功能的虚拟网段（vLAN ID）。 35 | 36 | _安全性建议 HY-SR-20_：对于虚拟机监视器宿主和软件管理功能的保护应该通过分配一块专用的物理 NIC 来保证，如果这不可行，则改为将虚拟机监视器的管理接口置于专用的虚拟网段中，并且利用防火墙强制实施流量控制（例如，在企业网络中指定子网，从这些子网到管理接口的流入流量被允许） 37 | 38 | -------------------------------------------------------------------------------- /nist_ir_8176/chapter_4.md: -------------------------------------------------------------------------------- 1 | # 第 4 章 对于宿主 OS 保护的担保要求 2 | 3 | ## 4.1 对于通用宿主 OS 保护的要求 4 | 5 | 安装容器专用 OS（相对于通用 OS 发行版而言），保持 OS 版本最新并且安装补丁，利用能够跟踪对 OS 的匿名访问的日志特性，以及任何授权以执行高权限操作，以上这些构成了 _容器安全指南_ 一文中的宿主 OS 反制措施的关键。除了以上这些反制措施以外，在宿主上禁用所有未使用的接口（串行或者私有接口）并且最小化用户和管理员帐户和组也是良好的 OS 安全实践。除此之外，还有诸如 grsecurity \[9\] 和 PaX \[10\] 等 Linux 专用补丁可用于 Linux 发行版。所有措施组合起来应该为宿主 OS 提供下列安全性担保： 6 | 7 | * (a) 防止通过修改内存来操纵程序执行（例如缓冲区溢出攻击） 8 | * (b) 防止对现存的程序代码进行重新路由的企图（例如通用库中的系统调用） 9 | 10 | ## 4.2 针对容器逃逸的宿主 OS 保护的担保要求 11 | 12 | 宿主 OS 应该被保护起来以化解源自容器逃逸或者突破的威胁，并且所有容器都应该被保护起来以防止来自宿主上的其他容器的影响。有众多解决方案可用于 Linux 环境以启用这些保护，但是，此文档中所分析的 3 种解决方案是 SELinux、AppArmor 和 Seccomp，所有这些都利用内核可加载模块（利用首字母缩略词 LKM 或者 Linux 内核模块来引用）。SELinux，或者安全增强式 Linux 可以为进程和对象（例如文件、套接字）指认分类并且基于特定的分类组合指定访问限制。例如，一个具体的 SELinux 标签可以被应用于某个容器以强制实施某种安全策略（例如，托管网络服务器的容器仅可打开 80 或者 443 端口） \[6\]。AppArmor 是另一款 LKM 产品，它通过对进程应用能够限制其在 Linux 能力以及文件访问层级上所拥有的权限的配置文件来帮助实施强制访问控制。因此，这些控制是以数据为中心的，并且与 SELinux 相比，位于较粗的粒度等级。SECure COMPuting（Seccomp）是一个可以定义并且强制实施某种访问控制方法的模块，该方法允许指定容器中的某个应用程序可用于同内核进行交互的系统调用的数量。限制系统调用提供了一种限制执行环境，并且因此减小了内核的攻击面。对于某个进程的系统调用的允许的列表（即白名单）和禁止的列表（即黑名单）通过利用系统调用过滤器进行设置 \[11\]。 13 | 14 | 上述内核可加载模块或者 LKM 的总体目标是在 Linux 中提供的标准文件层级访问控制（自主访问控制或者 DAC）的基础上为进程和用户的访问权限提供一个额外层级的安全检查 \[6\]。这一目标因此得出以下需要被满足的安全性担保要求： 15 | 16 | * (a) 被授权在容器中运行应用程序的用户不应该被允许访问上述内核可加载模块 17 | * (b) 如果使用 SELinux，用于标记文件及其上级文件夹的 `chcon` 工具应该被应用于文件系统层级结构中的正确层级，以使得这将会保证最小化权限 18 | * (c) 如果使用 Seccomp，系统调用白名单（可被允许的调用列表）和系统调用黑名单（被禁止的调用列表）都应该被生成。容器的白名单中的系统调用的选择应该基于容器中托管的应用程序类型、部署状况以及容器大小。黑名单中包括的系统调用被用于高风险、可能易受攻击、未知地危险，以及被显式地禁止的系统调用 \[11\]。此类中的范例包括允许加载内核模块、重启、引发挂载操作以及其他管理调用的系统调用 19 | * (d) seccomp 实现使用 Berkley 包过滤系统（BPF），并且因此其完整安装通常称为 seccomp-bpf。seccomp-bpf 允许为系统调用定义白名单和黑名单，拥有对这些调用进行参数检查的特性，以及用于获取下列任意过滤器返回值（kill、trap、trace、errno）的选项 \[15\]。seccomp 的最小化配置应该涉及定义具有 kill 作为其过滤器返回值的系统调用的白名单。此白名单的初始内容应该包括基本系统调用（信号处理、读取、写入、退出）。处理逻辑应该从验证架构开始（由于系统调用编号依附于架构），并且随后加载该系统调用编号并且将其与白名单进行比对。如果没有发现良好的匹配，则此进程应该被杀死。可以部署可选的 seccomp 过滤器的额外特性，它可以暂时捕获失败的系统调用并且报告它（而非立即退出）。这可以提供这样的担保，即此系统调用列表（白名单）为最终状态并且无需对其进行更改，除非其应用程序或者应用程序库发生更改 20 | * (e) 如果使用 Seccomp，由 seccomp 过滤器创建的沙盒必须不能允许使用 `ptrace` 命令。如果 `ptrace` 被允许，跟踪者可以修改此进程的系统调用以绕过过滤器，并且由此调用被阻止或者限制的系统调用 21 | * (f) 一种应该可用的最小化配置特性允许将宿主的容器分割为不同的安全域 22 | * (g) LKM 应该拥有特性以防止容器的挂载/重新挂载敏感目录以及/或者对于安全性的强制实施至关重要的特定系统目录（Cgroups、procfs、sysfs）的能力 23 | * (h) LKM 应该拥有特性以便利用上述特性的组合为容器运行时的管理员创建安全配置文件 24 | 25 | -------------------------------------------------------------------------------- /nist_sp_800-147/front_matter.md: -------------------------------------------------------------------------------- 1 | # 美国商务部国家标准技术研究所 特别出版 800-147 2 | 3 | # BIOS 保护指南——来自美国国家标准技术研究所的建议 4 | 5 | David Cooper，William Polk，Andrew Regenscheid 和 Murugiah Souppaya 著 6 | 7 | 计算机安全分部，信息科技实验室，美国国家标准技术研究所，盖瑟斯堡，马里兰州 20899-8930 8 | 9 | 2011 年四月 10 | 11 | 美国商务部 秘书 Gary Locke 12 | 13 | 美国国家标准技术研究所 主任 Patrick D. Gallagher 博士 14 | 15 | ## 计算机系统技术报告 16 | 17 | 位于美国国家标准技术研究所（NIST）的信息科技实验室（ITL）通过为美国国家的测量和标准基础设施提供技术领导以提升美国的经济和公众福利。ITL 通过开发测试、测试方法、参考数据、概念实现的证明以及技术分析来推进信息技术的发展和生产性的应用。ITL 的责任包括为美国联邦计算机系统的敏感未分类信息的经济高效的安全性和隐私性开发技术、物理、行政和管理方面的标准和指导意见。此特别出版 800 系列报导了 ITL 的研究、指导意见以及在计算机安全及其与工业、政府和学术组织的合作活动的领域中的延伸努力。 18 | 19 | 美国国家标准技术研究所特别出版 800-147 20 | 21 | Natl. Inst. Stand. Technol. Spec. Publ. 800-147, 27 页（2011 年四月） 22 | 23 | > 此文档中可能会提到某些商业实体、设备或器材，以便完整地描述一种实验过程或概念。这样的提名的本意并非暗示美国国家标准技术研究所对其的推荐或认可，也不是为了暗示该实体、器材或设备一定是可用于其目的之最佳选择。 24 | 25 | ## 致谢 26 | 27 | 来自美国国家标准技术研究所（NIST）的作者 David Cooper，William Polk，Andrew Regenscheid 和 Murugiah Souppaya 想要感谢曾经审阅此文档草案并且为之贡献技术内容的同事。作者感激地致谢并且赞赏来自那些向此出版物的公开草案提交评论的个人或组织的贡献。这些评论和贡献帮助了提升此文档的整体质量。 28 | 29 | 此外，作者还想感谢 Gustavo Duarte，此人创作了早期的启动过程示意图，它被用作此文档中的图 1 和图 2 的基础。 30 | 31 | # 执行摘要 32 | 33 | 现代计算机依赖基础系统固件，通常称为系统的基本输入/输出系统（BIOS），以协助硬件初始化过程并且将控制权移交给操作系统。BIOS 通常由原始设备制造商（OEM）和独立 BIOS 厂商开发，并且由主板或者计算机制造商分发给最终用户。制造商频繁地更新系统固件以修复 bug、为漏洞打补丁，以及支持新硬件。此文档提供了关于在 PC 客户端系统上阻止对 BIOS 固件进行非授权修改的安全指导意见。 34 | 35 | 恶意软件对 BIOS 的非授权更改构成了一种重大威胁，由于 BIOS 在 PC 架构中的独特、特权的地位。恶意 BIOS 修改可能是针对某个组织的高级攻击的一部分——要么是永久的拒绝服务（如果 BIOS 损坏），或者是持久的恶意软件存在（如果 BIOS 被植入了恶意软件）。从传统 BIOS 到基于统一可扩展固件接口（UEFI）的实现的迁移可能使得恶意软件以广泛的方式针对 BIOS 发动攻击变得更加容易了，由于这些 BIOS 实现基于通用的规范。 36 | 37 | 此文档专注于当前和未来的 x86 和 x64 台式机和笔记本系统，尽管其控制和程序也可能潜在地适用于任何系统设计。类似地，尽管此指南面向企业级平台，可以期望必要的技术随着时间迁移到消费者级别的系统上。此安全指导意见并不试图阻止通过供应链、通过物理替换 BIOS，或是通过安全本地更新程序来安装非授权 BIOS。 38 | 39 | 安全指导意见具体针对四种系统 BIOS 特性： 40 | 41 | * 认证 BIOS 更新机制，在此，由数字签名阻止非授权的 BIOS 镜像安装 42 | * 可选的安全本地更新机制，在此，由物理存在认证 BIOS 更新镜像的安装 43 | * 完整性保护特性，以便在认证 BIOS 更新过程外防止无意或者恶意的 BIOS 修改 44 | * 不可绕过性特性，以保证没有任何机制可以允许系统处理器或者任何其他系统组件绕过认证更新机制 45 | 46 | 此外，此文档还呈现了与安全指导意见互补的最佳管理实践，应对五个不同阶段： 47 | 48 | * 供货阶段，在此阶段建立起能够识别出许可的 BIOS 版本和配置设置的配置基线 49 | * 平台部署阶段，在此阶段利用安全本地更新机制建立或者验证配置基线 50 | * 操作和维护阶段，在此阶段，系统被监视其所发生的意外更改，并且利用认证 BIOS 更新机制以执行计划的 BIOS 更新 51 | * 恢复阶段，此阶段支持经过认证的回滚到早期 BIOS 版本的操作，以及从损坏的 BIOS 进行恢复 52 | * 废弃处理阶段，在此阶段，BIOS 和配置数据被恢复到其初始设定以防止意外泄露信息 53 | 54 | 此出版物的未来版本同时也会应对与 BIOS 进行交互的关键系统固件的安全性问题。 55 | 56 | -------------------------------------------------------------------------------- /nist_sp_800-125a/chapter_3.md: -------------------------------------------------------------------------------- 1 | # 第 3 章 针对整体平台完整性的安全性建议 2 | 3 | 配置更改、模块版本变化，以及补丁将会影响虚拟机监视器平台组件的内容，诸如 BIOS、虚拟机监视器内核，以及运行于内核中的后端设备驱动程序。为了保证作为虚拟机监视器栈的组成部分的这些组件中的每一个都可信，有必要通过某种能够提供启动完整性的担保的，植根于硬件的证明机制来检测它们的完整性。完整性检测是通过以密码学的方式来认证所启动的虚拟机监视器组件来实现的。这种认证方式验证只有授权的代码可以在系统上运行。具体地，在虚拟机监视器的上下文环境中，这种完整性证明可以防止破坏以及诸如 rootkit 的低级目标性攻击。如果此完整性证明被推迟到某个具有可信权力的作用的可信第三方，此验证过程被称为 _可信证明_。可信证明提供对于此虚拟机监视器组件的代码未被破坏的证明。在此方式中，对于虚拟机监视器组件的信任是建立在可信硬件的基础之上的。换言之，一条从硬件到虚拟机监视器的信任链是建立在称为 _可信根_ 的首个组件之上的。此服务可以由支持启动完整性测定和证明过程的虚拟机监视器宿主的硬件/固件基础设施来提供。简言之，测定启动环境（MLE）是虚拟机监视器宿主所必需的。 4 | 5 | 某些硬件平台利用用于测定启动序列中的组件的完整性（通常是二进制代码的散列值）的固件例程来提供对于 MLE 的支持。实施了测定启动过程的基于硬件的密码学存储模块的一个范例是基于标准的可信平台模块（TPM），它已经由可信计算小组（TCG）标准化 \[4\]。TPM 的 3 个主要组件包括：(a) 测定可信根（RTM）——进行完整性测定（通常是密码学散列值）并且将其转换为证明，(b) 完整性可信根（RTI）——提供受保护的存储、完整性保护，以及受保护的接口以存储和管理证明，以及 (c) 报告可信根（RTR）——提供受保护的环境和接口以管理身份并且签名证明。RTM 沿着启动序列测定下一段代码。此测定结果被存储在称为平台配置寄存器（PCR）的特定寄存器中。 6 | 7 | 在此，以 TPM 为例简单解释测定启动过程。测定启动过程始于在 BIOS 中执行一段可信的不可变代码，它同样会测定将要执行的下一段代码。在将控制权移交给序列中的下一个程序之前，此测定结果被扩展到 TPM 中的 PCR。由于序列中的每一个组件在移交控制权之前依次测定下一个组件，一条信任链被建立起来。如果测定链持续贯穿整个启动序列，则由此产生的 PCR 值反映了所有组件的测定结果。 8 | 9 | 证明过程始于请求者调用，通过宿主上的代理，TPM 引用命令。它指定一个证明识别密钥（AIK）以执行对于一组 PCR 的内容的数字签名，该组 PCR 包括启动序列中的所有欲引用的组件的测定结果，以及一个密码学临时随机数以保证数字签名的新鲜度。在接收到签名的引用之后，请求者验证签名并且通过比较 TPM 引用中的测定结果和已知良好的测定结果来决定是否信任所启动的组件。 10 | 11 | MLE 可以以如下方式整合到虚拟机监视器宿主中： 12 | 13 | * 托管虚拟机监视器的硬件被建立为可信根，一条始于硬件贯穿 BIOS 直到所有虚拟机监视器组件的信任链被建立起来 14 | * 对于想要被建立为可信根并且构建信任链的由处理器和芯片组构成的硬件，它应该拥有支持 MLE 的基于硬件的模块。在支持 MLE 的硬件中启动虚拟机监视器的结果是固件、BIOS，以及虚拟机监视器（内核）模块的全部或者某个关键子集的测定启动，因此构成了从硬件到虚拟机监视器的信任链 15 | * 虚拟机监视器供应必须能够利用 MLE 特性。换言之，虚拟机监视器应该能够调用安全启动过程，这通常是通过向虚拟机监视器的代码库中整合一个前内核模块来实现的，由于内核是在虚拟机监视器启动过程中首个被安装的模块。这个前内核模块的目的是保证选择硬件中的正确的经过认证的模块，该模块对虚拟机监视器中启动的组件或者该硬件上启动的任何软件执行有序的评估或者测定。Tboot 是这样的机制的一个范例，它允许虚拟机监视器利用硬件的 MLE 特性 16 | * 想要成为可信计算基（TCB）的一部分的所有虚拟机监视器组件必须被包括在启用 MLE 机制的范围内，以使得它们作为其启动过程的一部分而被测定 17 | 18 | 可以撬动虚拟化的宿主的硬件上的带有存储和报告机制的 MLE 特性以提供虚拟机监视器组件的启动完整性担保，通过测定启动序列中的所有实体的身份，从固件开始，然后是 BIOS、虚拟机监视器，以及虚拟机监视器模块，将其与“已知良好值”进行比较；并且报告任何不相符之处。如果该测定启动过程将要被延伸以覆盖 VM 及其内容（客户 OS 和应用程序），在虚拟机监视器内核中的对于基于硬件的 MLE 实现的基于软件的扩展是必需的。现在，对于保证虚拟机监视器平台的所有组件的安全启动过程的安全性建议可以叙述如下： 19 | 20 | _安全性建议 HY-SR-1_：所启动的虚拟机监视器应该成为平台以及整体基础设施的一部分，它包括：(a) 具有基于标准的密码学测定能力和存储设备的支持 MLE 的硬件，以及 (b) 具有提供一条从硬件开始直到所有虚拟机监视器组件的信任链的能力的证明过程。更进一步地，被测定的元素至少应该包括核心内核、内核支持模块、设备驱动程序，以及虚拟机监视器的用于 VM 生命周期管理和虚拟机监视器管理的原生管理应用程序。信任链应该为所有被测定的组件未被破坏并且它们的版本正确（即整体启动完整性）提供担保。如果信任链将要被延伸至客户 VM，虚拟机监视器应该提供一个虚拟接口到基于硬件的 MLE。 21 | 22 | -------------------------------------------------------------------------------- /nist_ir_8176/chapter_3.md: -------------------------------------------------------------------------------- 1 | # 第 3 章 基于硬件的容器安全性解决方案 2 | 3 | _容器安全性指南_ 一文在其 _硬件反制措施_ 标题之下推荐了一种始于测定/安全启动、提供经过验证的系统平台，并且构建一条植根于硬件中的信任链的可信计算模型。此信任链随后被延伸至引导程序、OS 内核，以及 OS 组件以允许对启动机制、系统镜像、容器运行时以及容器镜像进行密码学验证。为容器化的宿主实现可信平台模块（TPM）的技术解决方案在文献 \[7\] 中概述。此文档中将会讨论两种这样的方式，以及每一种解决方案所要求的安全性担保。 4 | 5 | 两种方式都涉及基于硬件的，或者物理的 TPM 和基于软件的 vTPM（虚拟 TPM）的组合。两种方式之间的差别在于 vTPM 在容器栈中所处的位置。3.1 节讨论了将 vTPM 置于 Linux 内核中的安全性解决方案，而 3.2 节讨论了将 vTPM 置于专用容器中的解决方案。 6 | 7 | 构建 TPM 架构并非为容器栈提供植根于硬件的信任的唯一一类方式。另一类已经被提议的方式是撬动某些 CPU 架构中的可信执行支持以保护运行于容器中的进程，防止来自同一容器栈中的来源的攻击。这包括同一栈中的高权限软件，诸如容器运行时和 OS 宿主内核 \[8\]。3.3 节讨论并且分析了一种基于此类方式的机制或者安全性解决方案。 8 | 9 | ## 3.1 宿主 OS 内核中的 vTPM——安全性担保要求 10 | 11 | 在文献 \[7\] 所提议的一种架构方式中，称为 vTPM（虚拟 TPM）的基于软件的模块置于 OS 内核中。为了使得此模块可用于多个容器，它需要被虚拟化。这是利用某个能够提供任意数量的基于软件的 vTPM 的内核模块而实现的，这些 vTPM 通过通常的机制暴露给容器，并且对容器用户空间呈现一个字符设备类型接口。此功能可以被实现为使得容器运行时（或者容器管理器）请求宿主 OS 内核创建一个新的 vTPM 并且将该虚拟设备指认给某个容器。这些 vTPM 被连接到托管容器栈的硬件平台中实现的 TPM（称为“物理 TPM”）。此架构方式的示意图如图 2 所示。 12 | 13 | > 图 2——实现于内核模块中的 vTPM 14 | 15 | 上文讨论的架构方式的安全性担保要求可以在下列场景中检视： 16 | 17 | _宿主 OS 完全可信_：宿主 OS 中的信任可以通过利用基于硬件的，或者物理 TPM 从硬件中延伸可信根来建立。由于宿主 OS 对于防止来自容器和进程的非授权访问而言是可信的，它对于防止对于内核中的 vTPM 的非授权访问也是可信的。更进一步地，存在这样的担保，即容器不能通过加载新的模块或者利用内核中的漏洞来修改宿主内核。因此容器可以被可靠地证明为处于它们自身的状态，通过利用 vTPM 的散列值延伸特性。 18 | 19 | _宿主 OS 不完全可信，并且在 vTPM 上需要独立的信任_：为了在 vTPM 上实现信任，与建立硬件 TPM（物理 TPM）信任使用相同机制的方案在文献 \[7\] 中引用。在物理 TPM 中，硬件平台提供商签名一个签注密钥（EK）以证明 TPM 可信。这在随后被延伸，通过赋予每个 vTPM 实例其自身的签注密钥并且部署利用基于硬件的 TPM 来签名 vTPM 的签注密钥的协议。 20 | 21 | ## 3.2 专用容器中的 vTPM——安全性担保要求 22 | 23 | 拥有与 3.1 节所述的相同功能的基于软件的 vTPM 被构建起来，并且托管于某个专用容器（称为 vTPM 管理容器）中。此架构方式的示意图如图 3 所示。此 vTPM 拥有两大主要特性： 24 | 25 | * (a) 对基于硬件的（物理）TPM 的访问 26 | * (b) 通过某种通讯信道将 vTPM 接口暴露给其他容器，此信道可以是本地 UNIX 域套接字或者其他 IPC 机制。如果 IPC 机制被使用，则使用 vTPM 服务的容器需要额外的软件（在图 3 中称为“适配器”），该软件将 IPC 接口呈现为标准字符设备。在托管 vTPM 的容器中，一个守护进程将会处理来自其他容器的请求，而非上一案例中的内核模块 27 | 28 | > 图 3——位于专用容器中的 vTPM 29 | 30 | 由此架构方式提供的安全性担保与容器栈中的宿主 OS 所提供的相同。宿主 OS，诸如 Linux，通过名称空间特性为属于不同容器的进程提供隔离。如果此功能工作正确，没有属于不同容器的进程可以访问部署于专用容器中的 vTPM 的状态。换言之，这种实现的安全性只会在发生容器逃逸攻击时受到破坏。并且，此方式提供的保护少于 3.1 节所述的方式（宿主内核中的 vTPM），由于内核可以更加可靠地限制其暴露给用户空间的访问。 31 | 32 | ## 3.3 撬动硬件的可信执行支持 33 | 34 | Intel 于 2015 年为其 CPU 发布了 Software Guard eXtensions（SGX）\[8\]，它提供了硬件机制，利用安全 enclave 的概念以保护用户层级的软件以防止高权限的系统软件的影响。enclave 页缓存（EPC）是一块受保护的物理内存区域，驻留于其中的应用程序代码和数据受到 CPU 访问控制的保护。如果 EPC 页中的代码和数据被移至 DRAM，它们立即被芯片上的内存加密引擎（MEE）加密，并且在它们被从 DRAM 中传输至 EPC 页时被解密。enclave 内存本身的完整性也是受到能够检测内存修改和回滚的机制保护的。因此，enclave 是由 SGX 为驻留于容器中的应用程序提供的可信执行环境。此技术可能于 2018 年中期可用。 35 | 36 | -------------------------------------------------------------------------------- /nist_ir_8176/chapter_2.md: -------------------------------------------------------------------------------- 1 | # 第 2 章 用于 Linux 应用容器栈的安全性解决方案 2 | 3 | 在 1.1 节中，宿主 OS（在此上下文环境中为 Linux）的接口被列出为用于为容器栈实现安全性解决方案的机制。有两种类型的接口：Linux 内核接口和内核可加载模块（又称为 Linux 安全模块或者 LSM）接口。与前一类接口相关联的 Linux 内核特性包括：名称空间、Cgroups 和能力。其中，名称空间和 Cgroups 的内核特性为运行在宿主 OS 上的进程提供隔离，并且可以成为开发容器概念的驱动特性。Linux 内核特性和内核可加载模块特性中的重要功能将会在后续章节中简要描述，以便为后续章节中所分析的安全性配置和解决方案提供上下文环境。 4 | 5 | ## 2.1 Linux 内核特性——名称空间 6 | 7 | 名称空间将与内核全局资源相关联的标识符表和其他结构分割到独立的例程之中。因此，它们将文件系统、进程、用户、网络栈、进程间通信（IPC）对象、主机名以及其他组件分割为独立的片断。例如，每一个文件系统名称空间都拥有其自身的 root 目录以及挂载表 \[2\]。这些不同的名称空间可以在随后以任何频率或者组合方式捆绑起来，以便对每一个容器的资源以及随后对它们的可访问性提供统一的视图。对于容器中的某个进程的资源的限制性的视图可以被延伸到某个子进程。诸如重映射的 root 文件系统和虚拟网络设备等的配置能力属于可以利用名称空间特性而启用的安全性解决方案的一部分。对于基于名称空间的安全性解决方案的担保依赖强制实施名称空间隔离的方法，而这进一步依赖与实施了适当的访问控制的每一个名称空间相关联的那一类元数据。 8 | 9 | 名称空间概念已经扩展到通用架构以用于隔离一系列内核全局资源，而这些资源之前的范围是面向整个系统的。因此，与之相关联的 API 也已经扩展到包括若干系统调用。然而，仍然有一些资源对于名称空间并不敏感（例如设备）。 10 | 11 | ## 2.2 Linux 内核特性——Cgroups 12 | 13 | 控制组（Cgroups）是一种内核机制，用于为某一个或者某一组进程指定并且强制实施硬件资源限制和访问控制，其目标是防止某一个进程消耗所有可用资源并且使得宿主上的其他进程和容器没有资源可用。因此，Cgroups 在一组进程之中进行隔离并且限制一定的资源以实现对于性能或者安全性的控制。受到控制的资源包括中央处理器（CPU）份额、随机访问存储器（RAM）、网络带宽以及硬盘 I/O \[5\]。它也可以被用于任务控制。 14 | 15 | 由 Cgroups 提供的安全性保护包括： 16 | 17 | * (a) 防止拒绝服务攻击：它可以提供针对拒绝服务攻击的保护以防止出现诸如失控容器等情况，通过利用下列特性，诸如通过 SIGSTOP 进行任务冻结、利用 PID Cgroup 设置进程 ID 的上限以限制每个用户的最大进程数量，以及指定诸如缓冲限制以及流量优先级级别（由 iptables 强制实施）等网络控制参数 18 | * (b) 设备完整性保护：它可以通过利用基于标签的访问控制或者利用允许指定设备白名单的特性来限制对设备的访问 19 | 20 | 对 Cgroups 的配置通过挂载某个类似于 /proc 或者 /sys 的特殊 Cgroup 虚拟文件系统来启用，该文件系统允许查看名称空间和控制的状态。此机制的漏洞在于，诸如卸载或者重复挂载等攻击可能使得由 Cgroups 配置设置的资源限制失效。Cgroups 可以在容器管理框架外部进行配置和管理，由于它是完全与宿主 OS 的内核相关联的配置特性。 21 | 22 | ## 2.3 Linux 内核特性——能力（Capabilities） 23 | 24 | Linux 内核中的能力特性可以帮助分割可用于 root 的广泛的权限集合，以使得进程（在此文档的上下文环境中指容器）刚好被分配给执行某个特定功能所需的权限。在引入能力特性之前，需要打开网络套接字的进程必须以 root 运行以执行这一个功能。这意味着对应的二进制文件，诸如 /bin/ping 中的一个 bug 即可能允许攻击者获得该系统上的所有 root 权限 \[6\]。通过启用能力 `CAP_NET_RAW`，某个版本的 ping 可以被创建为仅拥有由此能力所启用的权限，而非完整的 root 权限。其安全性结果是，潜在的攻击者通过利用 ping 工具的漏洞所能获得的权限显著减少。 25 | 26 | ## 2.4 内核可加载模块（或者称为 Linux 安全模块或者 LSM） 27 | 28 | 内核可加载模块，如同其名称所提示的那样，是加载至 Linux 内核的模块，它们提供安全功能以增强那些由名称空间、Cgroups 和能力所提供的安全功能。其范例包括 SELinux、AppArmor 和 Seccomp。SELinux 通过对进程和对象应用分类来提供对于对象访问的控制，而 AppArmor 通过对进程应用配置文件来执行相同的功能。Seccomp 允许系统调用限制规范，并且因此减少 Linux 内核的攻击面。 29 | 30 | ## 2.5 应用容器安全性配置过程 31 | 32 | Linux 宿主 OS 内核特性——诸如名称空间、Cgroups 和能力——可以被撬动以便为每一个容器创建一个安全配置。众多容器运行时产品提供 API 以便为宿主内的容器创建安全配置。一种典型的容器运行时，通常是通过客户端访问的，包含直接进行系统调用的库，该库以其客户端的名义执行诸如创建所必需的内核名称空间、Cgroups 和能力管理等任务。其他管理功能可能拥有安全性启示（例如由于不均衡负载而导致缺乏可用性），诸如在宿主之间分布容器以及创建宿主集群等，可以通过一组称为编排器的工具进行管理。 33 | 34 | -------------------------------------------------------------------------------- /peripheral-based_attack_memory/abstract.md: -------------------------------------------------------------------------------- 1 | # 检测针对宿主内存的基于外设的攻击 2 | 3 | Patrick Stewin 4 | 5 | # 摘要 6 | 7 | 对手可以通过在目标平台上部署 rootkit 技术以便以某种隐秘的方式持续攻击计算机系统。行业和政治间谍活动、对用户的监控，以及引导网络犯罪等行为要求对计算机系统进行隐秘攻击。利用某种 rootkit 技术意味着，所实现的攻击代码中的一部分负责隐藏此次攻击。被加载到诸如网卡或者特殊的微控制器等外设的攻击代码目前成为了 rootkit 进化的顶峰。本工作检视了宿主计算机上的此类基于外设的隐秘攻击。外设拥有一块专用处理器以及专用的运行时内存以处理其任务。这意味着这些外设实质上是一个独立的系统。攻击者得益于这种隔离。外设通常通过宿主的主内存同宿主进行通讯。攻击者利用了这一事实。宿主的所有运行时数据存在于主内存中，这包括密码学密钥、口令、已打开的文件以及其他敏感数据。攻击者只需定位这些数据。随后，攻击者可以利用外设的直接内存访问机制暗中读取和修改这些数据。这使得绕过诸如业界最先进的反病毒软件和加固的现代操作系统内核等安全软件成为可能。 8 | 9 | 检测这样的攻击是本工作的目标。基于独立微控制器的隐形恶意软件被实现为引导技术分析。此恶意软件的概念验证称为 DAGGER，它来自于 _Direct memory Access based keystroke code loGGER_（基于直接内存访问的击键码记录器）。对此恶意软件的开发和分析揭示了基于外设的恶意软件的重要属性。其检测程序称为 BARM——_Bus Agent Runtime Monitor_（总线代理运行时监视器）。此检测程序揭示了通过利用某些硬件属性对宿主的主内存进行的基于外设的隐秘攻击。一种永久的并且高效利用资源的测定策略保证了此检测程序同时还能检测瞬时攻击。如果所应用的测定策略只会在特定的时间点进行测定，则此类瞬时攻击将会成为可能。攻击者可以如此利用此种测定策略，通过在两次测定之间对系统进行攻击，并且在系统被测定之前销毁所有进攻痕迹。对于之前提出的预防性保护方式，即输入/输出内存管理单元，此检测程序代表了一种替代解决方案。由于实践方面的原因，之前提出的方法不一定是高效的。这一事实再加上由基于外设的恶意软件所带来的威胁共同要求本工作所呈现的替代检测方案。此检测程序不仅能够揭示攻击，同时能够终止该恶意设备。BARM 立即检测到并且阻止由 DAGGER 引导的攻击。其性能开销可以忽略。更进一步地，BARM 能够向外部平台报告宿主的主内存是否受到了外设的攻击。 10 | 11 | # 与本论文相关的发表 12 | 13 | 本论文呈现的工作带来了下列通过同行评审的发表： 14 | 15 | * _Understanding DMA Malware_, Patrick Stewin and Iurii Bystrov, DIMVA2012 Proceedings of the 9th Conference on Detection of Intrusions and Malware & Vulnerability Assessment, Heraklion, Crete, Greece, July 26-27th, 2012 (\[参见 123\] / 第 4 章) 16 | * Extended Abstract – _Poster: Towards Detecting DMA Malware_, Patrick Stewin, Jean-Pierre Seifert, Collin Mulliner, CCS2011 Proceedings of the 18th ACM Conference on Computer and Communications Security, 2011 (\[参见 126\] / 第 4 章) 17 | * _A Primitive for Revealing Stealthy Peripheral-based Attacks on the Computing Platform’s Main Memory_, Patrick Stewin, RAID2013 Proceedings of the 16th International Symposium on Research in Attacks, Intrusions and Defenses (RAID), St. Lucia, October 23-25, 2013 (\[参见 122\] / 第 5 章) 18 | 19 | 下列通过同行评审的发表根据第 6 章进行了更新，以考虑到基于 DMA 的恶意软件的场景，这也是本论文关注的焦点： 20 | 21 | * _Beyond Secure Channels_, Yacine Gasmi, Ahmad-Reza Sadeghi, Patrick Stewin, Martin Unger, N. Asokan, STC2007 Proceedings of the 2007 ACM Workshop on Scalable Trusted Computing, 2007 (\[参见 52\]) 22 | * _An Efficient Implementation of Trusted Channels based on OpenSSL_, Frederik Armknecht, Yacine Gasmi, Ahmad-Reza Sadeghi, Patrick Stewin, Martin Unger, Gianluca Ramunno, Davide Vernizzi, STC2008 Proceedings of the 3rd ACM Workshop on Scalable Trusted Computing, 2008 (\[参见 10\]) 23 | 24 | -------------------------------------------------------------------------------- /nist_sp_800-155/chapter_1.md: -------------------------------------------------------------------------------- 1 | # 第 1 章 简介 2 | 3 | ## 1.1 权力范围 4 | 5 | 美国国家标准技术研究所（NIST）开发此文档以履行其在 2002 年美国联邦信息安全管理法案，公法 107-347 下的法定责任。 6 | 7 | NIST 负有开发标准和指导意见，包括最低要求的责任，以便为所有政府机构的运作和财产提供足够的信息安全；但是，这些标准和指导意见不会适用于国家安全系统。此指导意见与美国行政管理和预算局（OMB）的公告 A-130 第 8b\(3\) 节“防护政府机构信息系统”相一致，如同在 A-130 的附录 IV“关键章节分析”中所分析的那样。补充信息在 A-130 附录 III 中提供。 8 | 9 | 此指导意见为联邦政府机构而准备。它可以在自愿基础上被非政府组织使用，并且不受限于版权，尽管我们要求署名权。 10 | 11 | 此文档中的任何部分都不应该被用于否认由美国商务部秘书在法定权力之下规定为对于联邦政府机构具有强制性和法定约束力的标准和指导意见，这些指导意见也不应该被解读为更改或是取代商务部秘书、OMB 主任或是任何联邦官员的现有职权。 12 | 13 | ## 1.2 目的和范围 14 | 15 | 此文档概述了建立一条安全的基本输入/输出系统（BIOS）完整性测定和报告链所需的安全组件和安全指导意见。BIOS 是系统中的关键安全组件，由于它在个人计算机（PC）架构中的独特和特权的地位。恶意或者老旧的 BIOS 可能会允许或者成为针对组织机构的高级攻击的一部分——可以是永久的拒绝服务（如果 BIOS 损坏）或者是持久的恶意软件存在（如果 BIOS 被植入恶意软件）。 16 | 17 | 此文档在 2.1 节标识出了关于此文档中的指导意见的两种激励场景。其一，BIOS 完整性测定机制的本意是为了检测存储于系统闪存中的系统 BIOS 代码发生的更改。针对系统 BIOS 代码的非授权更改可能会允许恶意软件在启动过程中被执行。其二，这些机制的本意是检测系统 BIOS 配置发生的更改。非授权的 BIOS 配置更改可能将系统置于不安全的配置之中，使其易受攻击。 18 | 19 | 此文档中的指导意见的本意是辅助开发那些能够检测 BIOS 问题的产品，以使得组织机构能够实施适当的补救措施以防止或者限制伤害。此文档中具体说明的安全控制和过程面向部署于企业环境中的台式机和笔记本。 20 | 21 | 尽管此出版物专注于用于 BIOS 完整性测定产品的安全属性和能力，它也会为组织机构中的管理员和安全官员提供关于这些类型的产品所能提供的担保以及那些当此技术被部署时需要被整合进系统采购和管理过程的程序的更好的理解。此文档中的指导意见仅可通过贯穿于组织机构的信息科技基础设施的硬件和软件支持的组合来实现。这包括终端机设备上的用于获取和报告测定数据的支持性的可信根和安全软件、对于企业级管理系统的测定数据的请求和解读的支持，以及对于网络设备的潜在支持以化解问题。这些组件将会成为 BIOS 完整性测定系统中的关键元素。 22 | 23 | ## 1.3 受众 24 | 25 | 此文档本意中的受众包括开发那些能够支持 BIOS 完整性测定机制的产品的硬件和软件厂商。这包括终端机厂商，通常是原始设备制造商（OEM）、操作系统（OS）厂商，以及安全应用软件厂商。系统管理员和信息系统安全专业人士也可以查询此文档以理解这些产品以及那些在部署这些技术时需要被整合进他们的系统管理过程中的程序的能力。 26 | 27 | 此文档中的素材是面向技术的，并且它假设读者至少拥有对于系统和网络安全的基本理解。此文档提供了背景信息，以帮助这些读者理解所讨论的话题。我们鼓励读者利用其他资源（包括列出于此文档中的）以获取更多细节信息。 28 | 29 | ## 1.4 文档结构 30 | 31 | 此文档的剩余部分被组织进以下的主要章节和附录中： 32 | 33 | * 第 2 章呈现了关于 BIOS 完整性测定及其在企业中的操作环境中检测针对 BIOS 的攻击的作用的概述 34 | * 第 3 章描述了测定 BIOS 完整性所必需的组件以及针对每个组件所建议的安全指导意见 35 | * 附录 A 包含关于系统 BIOS 完整性测定实现的安全指导意见的总结 36 | * 附录 B 定义了此文档中所使用的首字母缩略词、缩略语和用语 37 | * 附录 C 标识了参考文献 38 | * 附录 D 包含关于一家公司可以如何选择以实施可信根的一系列范例 39 | * 附录 E 包含关于一家公司可以如何选择以利用现存能力来实施这些指导意见的一系列范例 40 | 41 | ## 1.5 文档惯例 42 | 43 | 此文档中的关键字 MUST（**必须**）、MUST NOT（**必须不**）、REQUIRED（**要求**）、SHALL（**将要**）、SHALL NOT（**将不要**）、SHOULD（**应该**）、SHOULD NOT（**不应该**）、RECOMMENDED（**建议**）、MAY（**可以**）和 OPTIONAL（**可选**）等应当按照征求意见稿（RFC）2119 \[IETF-RFC-2119\] 中所描述的方式来解读。如果这些词语以常规大小写形式出现，例如 should（应该）或者 may（可以），它们本意上不需要作为 RFC2119 关键字来解读。 44 | 45 | 在此出版物中，将要求指认为 MUST/SHALL（**必须/将要**）、SHOULD（**应该**）和 MAY（**可以**）等的判据如下： 46 | 47 | * MUST/SHALL（**必须/将要**）：需要这些要求以支持于第 2 章所概述的场景，AND（**并且**）它们对于当前可用的技术而言在短期内是可行的 48 | * SHOULD（**应该**）：这些能力是非常值得拥有的，并且可能在某些情况下需要，以支持某种特定操作需求或者强壮度级别 49 | * MAY（**可以**）：可选的要求，它们在某些情况下可能是理想的。 50 | 51 | -------------------------------------------------------------------------------- /nist_ir_8176/front_matter.md: -------------------------------------------------------------------------------- 1 | # NIST 内部报告 8176 2 | 3 | # 用于 Linux 应用容器部署的安全性担保要求 4 | 5 | Ramaswamy Chandramouli 著 6 | 7 | 计算机安全分部，信息科技实验室 8 | 9 | 此出版物可从此处免费获得： 10 | 11 | [https://doi.org/10.6028/NIST.IR.8176](https://doi.org/10.6028/NIST.IR.8176) 12 | 13 | 2017 年十月 14 | 15 | 美国商务部 秘书 Wilbur L. Ross, Jr. 16 | 17 | 美国国家标准技术研究所 NIST 主任和标准技术商务次长 Walter Copan 18 | 19 | 美国国家标准技术研究所内部报告 8176，37 页（2017 年十月） 20 | 21 | > 此文档中可能会提到某些商业实体、设备或者器材以便充分地描述某种试验程序或者概念。这样的提名的本意并非暗示 NIST 对其的推荐或认可，也非暗示这些实体、器材或者设备一定是可用于该目的之最好的。 22 | 23 | > 此文档中可能会有对于 NIST 的当前正在开发中的其他出版物的引用，以便符合其被赋予的法定责任。此出版物中的信息，包括概念和方法论，可以被联邦政府机构使用，即使是在这些附带的出版物完成之前。因此，直到每部出版物完成之前，当前的要求、指导意见和过程在其所存在之处仍然有效。关于计划和迁移的目的，联邦政府机构可能想要紧密跟踪由 NIST 提供的这些新出版物的进展。 24 | 25 | > 我们鼓励组织机构在公开评论期间审阅所有出版物草案，并且向 NIST 提供反馈。除了上述出版物以外，NIST 的众多计算机安全出版物可以从 [https://csrc.nist.gov/publications](https://csrc.nist.gov/publications) 获取。 26 | 27 | 关于此出版物的评论可以被提交至： 28 | 29 | 美国国家标准技术研究所 30 | 31 | 收件人：计算机安全分部，信息科技实验室，办事处大道 100 号（8930 邮递点），盖瑟斯堡，马里兰州 20899-8930 32 | 33 | 邮件：[NISTIR8176@nist.gov](mailto:NISTIR8176@nist.gov) 34 | 35 | 所有评论必须在美国信息自由法（FOIA）条款下发布。 36 | 37 | ## 计算机系统技术报告 38 | 39 | 位于美国国家标准技术研究所（NIST）的信息科技实验室（ITL）通过为国家的测定和标准基础设施提供技术领导来提升美国经济和公众福利。ITL 通过开发测试、测试方法、参考数据、概念实现的证明以及技术分析来推进信息科技的发展及其生产性的使用。ITL 的职责包括为联邦信息系统中的国家安全相关信息以外的成本高效的安全性和隐私性开发管理、行政、技术和物理方面的标准和指导意见。 40 | 41 | ## 摘要 42 | 43 | 应用容器正在企业 IT 基础设施中逐渐得到采用。已有安全性指导意见和反制措施被提议以解决与应用容器平台部署相关联的安全性问题。为了对基于这些建议而实施的安全性解决方案的有效性进行评估，有必要分析这些解决方案并且对它们为实现其预期目标所必须满足的安全性担保要求进行概述。这是此文档的贡献。关注的焦点是 Linux 平台上的应用容器。 44 | 45 | ## 关键字 46 | 47 | 应用容器；能力；Cgroups；容器镜像；容器注册表；内核可加载模块；Linux 内核；名称空间；可信平台模块 48 | 49 | ## 致谢 50 | 51 | 作者对 Serban Gavrila 的技术反馈和 Isabel van Wyk 的编辑审阅表示感谢。 52 | 53 | ## 受众 54 | 55 | 此文档的目标受众包括企业基础设施或者用于作为总体云服务的一部分而提供容器服务的基础设施中的容器栈的系统架构师和系统管理员。 56 | 57 | ## 商标信息 58 | 59 | 所有注册商标或者商标属于其对应的组织机构。 60 | 61 | # 执行摘要 62 | 63 | 应用容器正在生产环境中逐渐得到采用，由于下列优势：较短的开发和部署周期，通过轻量级虚拟化而实现的资源效率，以及用于所涉及的过程的自动化的工具的可用性。与此同时，在部署过程中解决安全性问题对于企业而言同等重要。为了解决这些问题，NIST 已经通过 _应用容器安全性指南_（_Application Container Security Guide_）（NIST 特别出版 800-190）一文（在此文档中被引用为 _容器安全性指南_）提出了安全性指导意见和反制措施。 64 | 65 | _容器安全性指南_ 一文标识出了针对托管容器的平台的组件以及在启动之前构建容器并且存储它们的过程所涉及的与之相关联的东西的安全性威胁。考虑到对于涉及容器的整个生态系统的总体性的安全性启示，此文档也提供了用于 6 种实体，以及通过它们实施的安全性反制措施，包括硬件、宿主操作系统（OS）、容器运行时、镜像、注册表和编排器。 66 | 67 | 为了以反制措施的形式实施这些建议，需要一种或者更多种安全性解决方案。为了使得这些安全性解决方案能够有效地实现其安全性目标，有必要分析这些安全性解决方案并且以安全性担保要求的形式详细列出它们所必须满足的度量标准。这是此文档的目标和贡献。 68 | 69 | Linux 及其不同发行版构成了已部署的容器平台的宿主 OS 的主导组成部分。由于它们是开源产品，足够的安全性相关信息可用于分析那些可以利用 Linux 所提供的特性进行配置的安全性解决方案。因此，此文档关注的焦点是针对托管于 Linux 之上的应用容器的安全性解决方案的安全性担保要求。目标受众包括那些负责实际设计并且部署托管容器化的宿主的企业基础设施中的安全性解决方案的系统安全架构师和管理员。 70 | 71 | -------------------------------------------------------------------------------- /nist_sp_800-147b/chapter_3.md: -------------------------------------------------------------------------------- 1 | # 第 3 章 BIOS 安全性原则 2 | 3 | NIST SP800-147 所呈现的客户端系统的安全性原则——更新认证、闪存区域完整性和不可绕过性——直接适用于服务器级别的设备。这些安全性原则的本意是化解针对系统 BIOS 的威胁。服务器架构的复杂性以及服务器 BIOS 的多种更新途径要求对 NIST SP800-147 中的指导意见进行延伸。本章列举了主张 BIOS 更新安全性原则对服务器的要求。这些原则在以下的上下文环境中使用“授权”（authorize）和“认证”（authenticate）等词语。对镜像的认证保证它的完整性和来源。它通常植根于固件或者服务器制造商。认证是利用数字签名以密码学的方式实行的。授权是指允许某个更新被系统执行。对更新的授权通常植根于服务器管理员。 4 | 5 | ## 3.1 BIOS 更新认证 6 | 7 | 认证 BIOS 更新机制应该在 RTU（参见 2.5 节）中被实施。这些机制使用数字签名来保证 BIOS 更新镜像的合法性和完整性。RTU 的验证组件应该包含数字签名验证算法和一个密钥存储器。此密钥存储器应该包含用于验证 BIOS 更新镜像的签名的公钥，或者该密钥的一种许可的密码学散列值 \[FIPS180-4\]。在后一种情况下，更新机制应该计算由 BIOS 更新镜像提供的公钥的散列值，以保证它与出现在密钥存储器中的某个散列值相匹配，然后才能使用提供的公钥来验证 BIOS 更新镜像的签名。 8 | 9 | BIOS 镜像应该以符合 NIST SP800-89，关于获取数字签名应用程序的担保的建议 \[SP800-89\] 的方式被签名，使用一种在 NIST FIPS 186-4，数字签名标准（DSS） \[FIPS186-4\] 中具体说明的许可的数字签名算法，它提供至少 112 位的安全强度，以满足 NIST SP800-131A，过渡：关于密码学算法和密钥长度的使用的过渡的建议 \[SP800-131A\] 的要求。 10 | 11 | 认证更新机制应该保证在更新 BIOS 之前，BIOS 更新镜像经过数字签名，并且该数字签名可以使用某个已存储的密钥或者由 RTU 来验证。这些机制还可以在执行之前验证闪存存储器中的 BIOS 代码的数字签名，特别是当 BIOS 闪存未被保护时（参见 3.3 节）。恢复机制也应该使用认证更新机制，除非此恢复过程满足安全本地更新的指导意见。 12 | 13 | 系统应该提供能够防止非授权地将 BIOS 更改至较早的认证版本的机制。这种回滚限制机制可以这样实现，例如通过验证 BIOS 镜像的版本号高于当前安装的 BIOS 镜像版本号。适当的回滚保护方式取决于服务器的使用环境以及运行服务器的组织对安全性和可用性的需求。系统可以允许管理员授权回滚至较早版本、禁用这些机制或者基于他们的需求以其他方式配置这些机制。 14 | 15 | ## 3.2 安全本地更新 16 | 17 | 服务器可以可选地包括一种安全本地更新机制，它可以更新系统 BIOS 而无需使用认证更新机制。安全本地更新机制应该通过要求一位管理员物理存在于服务器面前指导更新来授权和认证 BIOS 更新镜像。这种对物理存在的要求化解了远程攻击者主导恶意更新至某个非法系统 BIOS 镜像的风险。 18 | 19 | 通过远程控制台与服务器进行交互并不满足这种对于物理存在的要求。例如，安全本地更新机制可以被用于从某个不能使用认证更新或者自动恢复机制来更新的损坏的 BIOS 中恢复。安全本地更新机制也可被用于在一台禁止回滚的系统上由物理存在的管理员更改至较早的 BIOS 版本。 20 | 21 | 然而请注意，实施了安全本地更新机制的系统潜在地容易受到恶意管理员的攻击，或者带有对服务器的物理访问的其他攻击。因此额外的物理、环境以及技术安全措施对于保护这些服务器至关重要，但是它们超出了此文档的范围。 22 | 23 | ## 3.3 固件完整性保护 24 | 25 | 如需防止执行非法或者恶意 BIOS 代码，系统 BIOS 应该在 RTU 验证系统 BIOS 和在启动过程中执行 BIOS 之间保持完整性。 26 | 27 | 为了防止在认证 BIOS 更新过程外对系统 BIOS 进行无意或者恶意的修改，包含 BIOS 的系统闪存存储器（即 BIOS 闪存），除了存储于非易失性存储器中，由系统 BIOS 所使用的配置数据以外，应该被保护起来以防止认证 BIOS 更新机制以外的修改。如果被实施，BIOS 闪存保护应该在执行 RTU 以外的代码之前被启用，并且应该由硬件机制来强制执行，该机制只能通过某种经过授权的机制（例如系统重置）禁用。 28 | 29 | 如果 BIOS 闪存保护未被实施，那么 BIOS 完整性应该在每一步执行过程之前利用 RTU 的验证组件进行验证以认证此 BIOS 镜像。如果验证失败，则系统应该引发恢复过程，这可以涉及操作人员的介入或者自动进行。引发恢复至某个受保护的合法 BIOS 的自动恢复机制应该被支持。自动恢复机制化解了拒绝服务攻击的风险，在此，攻击者将会加载某个非法 BIOS 并且将系统置于不可启动的状态。此系统可以允许授权的管理员在服务器上配置驱动这些恢复程序的安全策略。 30 | 31 | 每个 RTU 都应该被保护以防止认证更新机制以外的修改。保证 RTU 完整性的保护机制应该在执行 RTU 以外的代码之前被启用。RTU 完整性保护应该由硬件机制强制执行，该机制只能通过某种授权的机制，例如系统重置来禁用。 32 | 33 | ## 3.4 不可绕过性 34 | 35 | 系统及其附带的系统组件和固件的设计应该保证没有任何机制可以安装并执行非法 BIOS 代码，除了通过物理介入以及安全本地更新机制以外。 36 | 37 | 特别地，认证更新机制应该是在没有贯穿于安全本地更新机制的物理介入的情况下修改 RTU 的唯一机制。系统及其附带的系统组件和固件的设计应该保证没有任何机制可以允许宿主服务器或者任何其他系统组件绕过用于更新 RTU 的认证更新机制，除了安全本地更新机制以外。 38 | 39 | 现代平台也包含赋予了系统组件对 RTU 或者系统 BIOS 的直接访问的设计特性以改进性能和管理，例如将 BIOS 复制到内存中，或者用于系统管理模式操作。某个系统组件可能会拥有对于系统闪存存储器的读取访问权限，但是它不应该能够直接修改 RTU，除非该组件作为 RTU 的扩展或者就是 RTU 本身。 40 | 41 | -------------------------------------------------------------------------------- /nist_sp_800-155/front_matter.md: -------------------------------------------------------------------------------- 1 | # 美国商务部国家标准技术研究所 特别出版 800-155（草案） 2 | 3 | # BIOS 完整性测定指南（草案）——美国国家标准技术研究所的建议 4 | 5 | Andrew Regenscheid 和 Karen Scarfone 著 6 | 7 | 计算机安全分部，信息科技实验室，美国国家标准技术研究所，盖瑟斯堡，马里兰州 20899-8930，2011 年十二月 8 | 9 | 美国商务部 秘书 John Bryson 10 | 11 | 美国国家标准技术研究所 标准技术次长和主任 Patrick D. Gallagher 博士 12 | 13 | ## 计算机系统技术报告 14 | 15 | 位于美国国家标准技术研究所（NIST）的信息科技实验室（ITL）通过为美国国家的测量和标准基础设施提供技术领导以提升美国的经济和公众福利。ITL 通过开发测试、测试方法、参考数据、概念实现的证明以及技术分析来推进信息技术的发展和生产性的应用。ITL 的责任包括为美国联邦计算机系统的敏感未分类信息的经济高效的安全性和隐私性开发技术、物理、行政和管理方面的标准和指导意见。此特别出版 800 系列报导了 ITL 的研究、指导意见以及在计算机安全及其与工业、政府和学术组织的合作活动的领域中的延伸努力。 16 | 17 | 美国国家标准技术研究所 特别出版 800-155（草案），47 页（2011 年十二月） 18 | 19 | > 此文档中可能会提到某些商业实体、设备或器材，以便完整地描述一种实验过程或概念。这样的提名的本意并非暗示美国国家标准技术研究所对其的推荐或认可，也不是为了暗示该实体、器材或设备一定是可用于其目的之最佳选择。 20 | 21 | ## 致谢 22 | 23 | 作者想要感谢那些审阅了此文档草案并且为其技术内容作出贡献的同事。特别地，作者想要感谢来自 Wave Systems 的 Greg Kazmierczak 和 Robert Thibadeau 以及来自 Citrix 的 Kurt Roemer，他们为此文档的早期草案提供了有益的评论和反馈。我们还想要感谢 NIST 的那些审阅了此文档早期草案的同事，包括 Bill Burr、Donna Dodson、Tim Polk、Matthew Scholl、Murugiah Souppaya 和 David Waltermine。 24 | 25 | ## 摘要 26 | 27 | 此文档概述了建立安全的基本输入/输出系统（BIOS）完整性测定和报告链所需的安全组件和安全指导意见。对 BIOS 固件的非授权修改构成了一种重大威胁，由于 BIOS 在 PC 架构中的独特和特权的地位。此文档专注于两种场景：检测存储于系统闪存中的系统 BIOS 代码的更改；以及检测系统 BIOS 配置的更改。此文档本意用于开发能够支持安全 BIOS 完整性测定机制的产品的硬件和软件厂商，并且对于开发关于这些技术的企业采购或者部署策略的组织机构可能也会适用。 28 | 29 | ## 商标信息 30 | 31 | 所有商标或者注册商标属于其各自的组织机构。 32 | 33 | # 执行摘要 34 | 35 | 诸如台式机和笔记本等客户端计算机依赖基本输入/输出系统（BIOS）以便在启动过程中初始化其硬件。BIOS 是固件，并且它可以被配置。如果 BIOS 代码或者配置从其本意中的状态被更改，不论是恶意或者无意，此台式机或者笔记本可能会失去可靠性、完整性和可用性，并且会带来系统不稳定性、系统故障和信息泄露。同时，此台式机或者笔记本可能易受更加精心设计的攻击，诸如隐秘监视，并且这可以用作攻击其他系统的基石。这些后果强调了检测针对 BIOS 代码和配置的更改为何如此重要——并且这可以通过测定并且监视 BIOS 的完整性而实现。 36 | 37 | 此出版物解释了 BIOS 完整性测定的基础，诸如为了测定 BIOS 完整性而必须满足的基本要求，以及用于 BIOS 完整性测定和报告的典型数据流。这些素材为此文档的核心内容提供了基础，此文档为那些开发能够支持安全 BIOS 完整性测定机制的产品的硬件和软件厂商提供了指导意见。这些指导意见详细地定义了厂商为了支持 BIOS 完整性测定所需遵循的要求和建议。 38 | 39 | 以下内容是关于厂商支持 BIOS 完整性测定的关键要求和建议。注意，对于这些要求和建议的正式声明出现于第 3 章；以下这些是它们的总结，并且不能取代第 3 章的更加详细的声明。 40 | 41 | **为实施用于 BIOS 完整性测定的可靠的可信根提供必要的硬件支持** 42 | 43 | 可信根是构成一系列被无条件信任的功能的组件（软件、硬件，或者混合）和计算引擎。可靠和可信的 BIOS 完整性测定和报告依赖于软件代理；每种软件代理依赖可信根，并且每种代理的可信度级别取决于它的可信根。BIOS 完整性测定要求以下代理之间的协作：一个测定代理用于收集测定数据、一个存储代理用于保护测定数据以防止修改，直到它们可以被报告，以及一个报告代理用于可靠地报告此测定数据。这些代理中的每一个都拥有一个对应的可信根（测定可信根，等等）。这些可信根必须一致行动并且相互基于对方构建以实现可靠和可信的测定、报告以及对于 BIOS 完整性测定的验证。 44 | 45 | **使得终端机能够在启动时测定所有 BIOS 可执行组件和配置数据组件的完整性** 46 | 47 | 有意义的完整性测定比较方案中的一个关键因素是可靠地建立并且维护一组属性和测定数据的已知基线。终端机厂商有多种方式以将属性传达给用户；不论这是如何实现的，这些属性存在的原因是为了向用户提供一种方式以评估由终端机报告的 BIOS 完整性测定数据的有效性，以及在它所接收到的关于终端机的总体健康状况的报告中开发一种可靠度级别。此出版物定义了终端机厂商必须提供的属性以及所有终端机都必须能够报告的最小基本 BIOS 完整性测定数据。 48 | 49 | **将 BIOS 完整性测定数据安全地从终端机传输到测定评估权威机构（MAA）** 50 | 51 | 当测定数据被可靠地和稳固地报告时，MAA 可以准确地确定每台终端机上的与安全相关的 BIOS 配置项目的状态。这允许 MAA 对组织机构所关注的项目进行汇报或者采取行动。BIOS 完整性测定数据的安全传输保证了测定数据在传输过程中并未被恶意相关方修改、泄露或者非法复制。更进一步地，适当选择传输协议应该能够保证最大的可互操作性、新鲜度和效率。 52 | 53 | -------------------------------------------------------------------------------- /nist_ir_8176/chapter_6-10.md: -------------------------------------------------------------------------------- 1 | # 第 6 章 镜像完整性解决方案的担保要求 2 | 3 | 容器镜像的完整性至关重要，由于它们被转换为运行着的实例，其中的一些可能还会托管关键任务应用程序。_容器安全性指南_ 一文所覆盖的镜像反制措施包括关于监视镜像以查找恶意软件以及其他漏洞、适当的镜像配置、同镜像文件隔离机密信息，以及通过密码学签名以及常规更新来保证镜像中的信任等方面的建议。执行这些建议所需的安全性解决方案应该包括下列担保要求： 4 | 5 | * (a) 应该存在方式以创建将每一个镜像连接至其基本镜像的元数据 6 | * (b) 应该存在特性以自动重建镜像，如果与之连接的基本镜像发生更改 \[6\] 7 | * (c) 如果对基本镜像或者被依赖的镜像进行了任何修改（例如为漏洞打补丁），不应该对运行着的容器进行修改，与之相反，应该利用修改过的镜像重建对应的镜像，并且重新启动容器。因此，对于任何服务都需要维护单一的主镜像或者黄金镜像 8 | * (d) 如果将“镜像签名”解决方案用于对每一个镜像进行数字签名和唯一性识别，下列要求应该被满足 \[6\]： 9 | * 1. 应该存在强壮的密钥管理机制以使得密钥攻击的可能性最小化。一种方式是拥有 PKI 系统以便为每一位开发者签发专门用于签名镜像的证书。与此证书相关联的私钥将会成为“签名密钥”以被用于签名某个库中的所有容器镜像 10 | * 2. 必须通过在签名的容器镜像中嵌入过期时间戳来化解重放攻击。或者，某个特殊的密钥可以被用于签名该库的元数据，以保证该库中的镜像不包含带有有效签名的不新鲜版本的镜像 11 | * (e) 除了利用数字签名为镜像创建唯一的身份标识以外，此镜像的单个组件的完整性可以通过为每一个组件使用诸如配对的密钥/值等标签来保证 12 | * (f) 镜像应该以这样的方式来创建，以使得其中的应用程序不能被用于任何权限提升攻击。这可以通过禁用 `chmod a-s` 命令以移除 suid 位，或者移除其中的 setuid 和 setgid 二进制文件来实现 \[6\]。 13 | 14 | # 第 7 章 镜像注册表保护的担保要求 15 | 16 | _容器安全性指南_ 一文中提议的注册表反制措施包括开发对于注册表的安全连接，以及保证注册表中不包含过时的、易受攻击的镜像，通过某种自动化的过程将其删除，或者通过使用专用的版本号来控制其意外部署。某些与这些反制措施并不相关，但是对于涉及出入注册表的镜像的创建、发布和移除过程仍然至关重要的担保要求包括： 17 | 18 | * (a) 能够访问注册表的帐户数量必须被限制，由于某些环境中的普遍威胁是帐户劫持，如果一大批各式各样的帐户都拥有对某个容器注册表的访问权限。此类环境之一是由提供容器服务的云服务提供商维护的注册表 19 | * (b) 对于创建容器镜像注册表以及为注册表添加或者移除内容的许可必须以密码学方式来保护 20 | 21 | # 第 8 章 编排器功能的担保要求 22 | 23 | 在容器化的基础设施中使用编排器平台（由一套工具组成）的本意是执行下列功能： 24 | 25 | * 允许定义集群（一个命名的容器宿主的组，可以视为单一实体进行管理）以及将容器编排至集群中。集群的配置应该支持指定下列参数，诸如保留的 CPU/内存数量、副本（即要运行的相同容器的重复备份）数量，以及判断容器应该持续运行还是被下线的环境 26 | * 允许容器在不同集群宿主中的自动部署（容器计划），这是通过整合不同的自动化工具以便将自动化脚本作为编排工作流的一部分而执行，并且获取来自这些自动化任务的反馈和状态结果而实现的。此类整合依赖于自动化工具提供的接口以及它们所遵循的格式类型（开放或者封闭）\[14\] 27 | * 供货或者定义新的容器宿主，并且将其连接到现有的集群 28 | 29 | _容器安全性指南_ 一文中提议的编排器反制措施包括基于作为参数的宿主、容器、镜像的管理行为的粒度访问控制、使用强凭证和目录的企业级认证服务，以及基于运行于其中的应用程序的敏感度级别将容器隔离至独立的宿主。除了这些反制措施以外，编排器应该满足下列安全性担保要求： 30 | 31 | * (a) 集群应该拥有能力以记录日志并且监视单个容器的资源消耗特征，以避免资源使用中的意外峰值，由于这会导致关键资源的不可用性 32 | * (b) 编排器平台必须在具有多于一种宿主 OS 的容器化的基础设施中可用。换言之，所使用的编排器工具必须对于容器宿主 OS 中立。将不同的工具用于不同的容器宿主 OS 平台将会增加这些环境中的拒绝服务攻击的可能性，由于企业不能获取在其整个容器化的基础设施中运行的所有容器的资源使用的全局视图 33 | 34 | # 第 9 章 某些安全性解决方案的副作用 35 | 36 | 当在安全性目标（例如文件系统隔离）的上下文环境中讨论某种安全性解决方案（例如使用挂载名称空间）时，某些增强解决方案被推荐，由于被讨论的解决方案就其自身而言不能满足此目标。然而，对于某些安全性解决方案，无论采用何种增强控制，都会为某些容器功能的实用性和性能施加某些限制。尽管它们的直接影响只是功能和性能方面的，它们可能对于某些安全性参数具有间接影响。例如，在设置系统调用过滤器（带有白名单和黑名单）时使用 Seccomp 作为安全性解决方案（由于系统调用对于名称空间并不警觉，因此排除了使用名称空间特性的可能性）时，恶意进程的存在可能引发容器之间的泄漏。更进一步地，被允许的系统调用的选择是基于容器中的一组当前应用程序的，则此安全性解决方案具有引入应用程序不兼容性的潜在可能，由于应用程序可能出于负载均衡等原因在容器之间迁移。 37 | 38 | # 第 10 章 总结和结论 39 | 40 | 此文档中所分析的安全性解决方案可以总结如下： 41 | 42 | * (a) 利用诸如 TPM 和 vTPM 等基于硬件的可信根解决方案为容器栈的诸如 Linux（宿主 OS）、容器运行时以及容器等软件组件提供完整性的认证和证明 43 | * (b) 利用基于硬件的保护机制将容器彼此屏蔽开来，以及将容器同诸如 Linux 内核等高权限软件屏蔽开来，通过使用由硬件架构提供的安全执行环境（例如 Intel SGX） 44 | * (c) 利用 Linux 内核特性（名称空间、Cgroups、能力）以及可加载内核模块（LKM）特性来保护 Linux 内核本身，以及保护某个容器不受其他容器的影响 45 | * (d) 用于容器运行时、容器镜像、容器注册表以及容器编排器工具的保护措施 46 | 47 | 通过以上分析得出的结论是，每一种安全性解决方案必须满足某些安全性担保要求以便有效地提供必要和充分的安全性保证。 48 | 49 | -------------------------------------------------------------------------------- /nist_ir_8176/chapter_1.md: -------------------------------------------------------------------------------- 1 | # 第 1 章 简介 2 | 3 | 应用容器正在生产环境中逐渐得到采用，由于下列优势：较短的开发和部署周期，通过轻量级虚拟化而实现的资源效率，以及用于所涉及的过程的自动化的工具的可用性。为了解决这些环境中的安全性问题，_应用容器安全性指南_（美国国家标准技术研究所（NIST）特别出版 800-190）\[1\]（在此文档的剩余部分中被引用为 _容器安全性指南_）一文标识出了针对托管容器的平台的组件以及在启动之前构建容器并且存储它们的过程所涉及的与之相关联的东西的安全性威胁。考虑到对于涉及容器的整个生态系统的总体性的安全性启示，_容器安全性指南_ 一文也提供了用于 6 种实体，以及通过它们实施的安全性反制措施，包括硬件、宿主操作系统（OS）、容器运行时、镜像、注册表和编排器。 4 | 5 | 为了实施这些反制措施，需要一种或者更多种安全性解决方案。此文档讨论了能够提供反制措施所必需的功能的潜在的安全性解决方案，以及每一种安全性解决方案所应该满足的安全性担保要求的类型。这些安全性解决方案可以被宽泛地分类为： 6 | 7 | * (a) 用于提供启动过程完整性的基于硬件的可信根 8 | * (b) 使用宿主 OS 内核特性和内核可加载模块的配置选项 9 | * (c) 用于构建和存储容器镜像的保护措施 10 | * (d) 用于发布涉及多个容器和多个宿主的生产基础设施的编排器工具的配置选项 11 | 12 | 此文档的目的是在其被设计为去满足的安全性目标的上下文环境中检视每一种安全性解决方案，以及开发那些它们应该满足以使其有效的担保要求。被考虑的宿主 OS 是 Linux，由于以下原因： 13 | 14 | * (a) 其在容器栈中的广泛采用 15 | * (b) Linux 发行版是开源的，并且允许足够多的与安全相关的信息成为公共可用的 16 | 17 | ## 1.1 此文档的范围 18 | 19 | 容器技术栈的功能架构框图如图 1 所示。在此框图中，此栈由物理宿主（或者虚拟机（VM））、容器 OS（我们将会在此文档中将其引用为宿主 OS）、容器运行时，以及多个容器组成。此外，诸如下列任务全部由多种工具执行，并且被整合到编排器软件的整体控制之下：创建虚拟网络以便在容器宿主内部以及它们之间将容器连接起来（容器网络）、创建容器宿主集群（容器集群管理）、创建路径程序以便识别并且发现某个提供某种特定服务的特定容器（服务发现）、跨集群容器计划（容器计划），以及在不同容器内部计划特定的业务应用程序（应用程序计划）。在不同的容器宿主上将其作为容器实际启动起来之前，首先利用适当的开发工具创建一系列组件的模板，这些组件构成了一个称为容器镜像的容器。这些容器镜像被存储于容器注册表中（镜像管理）并且随后被推送至容器宿主并且利用容器运行时工具将其作为容器启动起来。容器运行时同时提供接口以用于配置宿主 OS 参数，以及与内核可加载模块相关联的设置以允许不同容器的安全部署。 20 | 21 | > 图 1——容器技术栈 22 | 23 | 如图 1 所示，安全功能层跨越了容器技术栈的所有功能层。然而，覆盖了这些层的安全性解决方案必须通过下列组件来实现： 24 | 25 | * (a) 物理宿主（即硬件，由于托管于 VM 之上的容器超出了此文档的范围） 26 | * (b) 容器 OS（宿主 OS）接口 27 | * (c) 容器运行时接口 28 | * (d) 镜像管理和注册表接口 29 | * (e) 编排器接口 30 | 31 | 运行于容器栈中的容器可以是系统容器或者应用容器。其行为类似于完整的 OS 并且运行诸如 `sshd`（安全会话建立）以及 `syslogd`（日志能力）的程序的容器称为系统容器。而仅仅运行应用程序的容器称为应用容器 \[2\]。此文档专注于应用容器。在分析安全性解决方案以及它们所应该满足的担保要求之前，有必要叙述应用容器的执行模型以及假想的攻击模型。首先，应用程序在容器中作为单一的操作系统进程而运行。容器拥有应用程序代码本身以及软件栈（包括二进制文件和库）的副本 \[3\]。在大多数情况下，此栈可以利用某种类型的库系统组装起来，从而避免需要由开发者来从头构建和配置该栈。这种快速组装的栈在不同的容器产品供应中被赋予了不同的名称（例如建构包（buildpack）、墨囊（cartridge）等）。有一些栈被用于众多的流行编程语言运行时，诸如 Java、PHP、Node.js 和 Ruby 等。对于特殊的应用程序，开发者可以创建他们自己的自定义的栈。容器架构的部署模型可能涉及在独立的容器中并行运行相同应用程序的副本，甚至是跨越不同的容器的宿主。在此场景中，基础设施可能拥有某种机制以利用某种形式的负载均衡将传入的请求分布至同一应用程序的所有实例。 32 | 33 | 此处假想的攻击模型是，容器中的应用程序代码的漏洞或者错误配置（例如此容器被配置为运行于高权限模式）已经被攻击者利用。这将会允许攻击者获得对于容器运行时以及宿主 OS 内核中的高权限代码的控制权并且对其进行攻击，在此，后者被容器中的应用程序代码信任以提供诸如进程隔离等一些保护担保 \[4\]。此类攻击的一个范例是重放、录制、修改和丢弃某个网络包或者文件系统访问。此文档中讨论的安全性解决方案的本意是防止对于容器运行时和宿主 OS 的此类攻击。关于解决应用程序代码本身的内在不安全特性，诸如编程 bug、设计瑕疵或者执行模型等的解决方案超出了此文档的范围。 34 | 35 | ## 1.2 文档结构 36 | 37 | 此文档的剩余部分被组织进下列章节和附录中： 38 | 39 | * 第 2 章提供了关于不同的 Linux 内核特性（名称空间、控制组（Cgroups）、能力（Capabilities））以及内核可加载模块在为容器化的栈提供安全性中的功能的概述 40 | * 第 3 章描述了用于容器环境的基于硬件的安全性解决方案 41 | * 第 4 章概述了宿主 OS 保护措施以及与之相关联的担保要求 42 | * 第 5 章详细呈现了若干种容器运行时配置解决方案，用以为下列事物提供容器隔离：进程、文件系统、进程间通信（IPC）以及网络。本章还呈现了关于限制资源以及保证最小化权限的解决方案。所有解决方案都得到了分析，并且还呈现了一组必须被满足的担保要求 43 | * 第 6 章定义了用于构建和维护容器镜像的担保要求 44 | * 第 7 章简要讨论了用于容器注册表保护的担保要求 45 | * 第 8 章概述了用于编排器工具的基本安全性担保要求 46 | * 第 9 章标识了某些安全性解决方案的某些不理想的副作用，以及在使用这些解决方案时需要加以注意的事项 47 | * 第 10 章总结了此文档所覆盖的不同的安全性解决方案领域 48 | * 附录 A 提供了此文档中所使用的首字母缩略词的定义，以及 49 | * 附录 B 包含参考文献的列表 50 | 51 | -------------------------------------------------------------------------------- /platform_firmware_security_defense/chapter_4-6.md: -------------------------------------------------------------------------------- 1 | # 第 4 章 防护工具和范例 2 | 3 | ## 4.1 工具：用于 UEFI、BIOS、SMM 和 ACPI 的 CHIPSEC 4 | 5 | CHIPSEC 是由 Intel 安全高级威胁研究（Intel Security Advanced Threat Research）开发的开源软件，并且是平台固件安全领域中的权威解决方案之一。CHIPSEC 不仅允许转储固件镜像并且计算散列值，并且可以对复杂 UEFI 平台固件上的可加载模块、变量及其他攻击面进行深度检测。CHIPSEC 提供了深度测试套件，包括诸如模糊测试等蛮力安全技术。尽管 CHIPSEC 非常完整，它是高度依存于架构的，并且只在最近十几年生产的 Intel x86/x86\_64 主板上工作得最好。 6 | 7 | CHIPSEC 是一款任何整合或者贩卖基于 Intel 的系统的人都应该使用的工具，甚至一直到任何包装他们自己的系统的零售商。尽管不能指望百思买开箱一台来自 OEM 的系统并且在出售前使用 CHIPSEC 对其进行测试，VAR 应该能够验证一台全新的系统能够通过所有 CHIPSEC 测试。这不是当今所发生的事情，但却属于您作为购买（或者提供购买指南）者对于众多系统所能够坚持要求的事情。 8 | 9 | CHIPSEC 可以用于在线和离线分析。如需进行离线分析，则需要一块 ROM 的副本（通常称为 _ROM.bin_ 文件）。CHIPSEC 可以生成 _ROM.bin_ 文件以用于离线分析，但是其他工具诸如 FlashROM、Google Pawn 和苹果的 eficheck 也可以。 10 | 11 | CHIPSEC 是关于软件应该对于所有平台固件，尤其是那些设计为可更新而非烧入 ROM 的固件可用（以及开源）的一个良好范例。 12 | 13 | ## 4.2 工具：PCIe 14 | 15 | 对于 PCIe 固件而言，解决方案的选项开始变得杂乱。大多数 PCIe 固件称为“选项 ROM”或者“扩展 ROM”，并且如同它们的名称所暗示的那样，对于相对简单的 PCIe 板卡，它们通常是 ROM 芯片，并且只能通过完整地更换芯片来更新。对于系统的物理访问对于执行此类攻击是必需的。 16 | 17 | 随着系统变得更加集成化，诸如扩展卡之类的 PCIe 设备以及雷电设备抬高了价值链，并且成为了更加复杂的设备，通常具有可由软件更新的 ROM。无人愿意仅仅由于初始化 ROM 或者通常是复杂的设备操作固件中的一处代码错误就扔掉一块价值 1000 美元的 GPU。 18 | 19 | 在使用 Linux 时，可以利用 _lspci_ 检查 PCIe 总线，以及利用 _sysfs_ 转储 PCIe 选项 ROM。并且 Linux 上的 _fwupd_ 和 Windows Update 固件更新是受管理的系统提供自动更新的开始。但是请注意，这些方法可能还远远谈不上完整——用以保证 GPU 在启动时能够工作的选项 ROM 只是现代 GPU 上的固件的很小一部分。当前只有来自 GPU 厂商的私有工具能够处理现代 GPU 上的固件，这也适用于网卡和 RAID 适配器。 20 | 21 | ## 4.3 更多工具 22 | 23 | 更多工具列出于我们的附录 _Awesome Firmware Security_ 中，这是一部进化中的文档，因此请确保阅读它的最新版本以紧跟时代发展，或者考虑订阅更新。 24 | 25 | # 第 5 章 帮助为每一个人改进固件安全性 26 | 27 | 作为一名系统管理员，或者其他 IT 业务的专业人士，您拥有独特的地位以在整个 IT 行业中改进固件安全性。当然，您可以并且应该帮助提升警觉性，以便在出现机会的时候教育同行 IT 专业和管理人士——也许甚至是通过分享本书。然而，撬动变革的最有力的杠杆还是您所持有的购买力。没有一位个人消费者可以同系统 VAR 和 OEM 进行那种您在常规基础上就能与之进行的对话。您所遇到的一般销售人员不一定能够明白您正在说什么，但是对于大多数采购，您将会有机会遇到一位更加技术型的销售工程师。这是您作为系统管理员的责任以引导您的雇主朝向最佳的 IT 采购方案，这也许不一定是可选项之中最便宜的。这是您的职责以平衡这其中涉及的所有因素，即高额采购是您的雇主的主要资本花费，而它将会被您的同事雇员使用多年。 28 | 29 | 我们在本书中所倡导的全部就是您应该考虑将硬件和固件层级的安全性作为众多购买决定因素之一，并且相应地询问问题以及利用杠杆对抗您的厂商。考虑向看重固件安全性的其他厂商开放您的流程，这些厂商可以采用提供校验散列值、通过标准化的机制（Windows Update _和_ LVFS fwupd）提供经过签名的更新，以及完全开源等方式。至少也要表达出对于您当前的厂商的硬件中所包含的所有闭源、不可验证的固件组件的担忧。 30 | 31 | 与 IT 专业人士所面临的众多问题相似，您也许不能一下子就为您自己的职业生涯或者工作环境带来改观。但是您可以为将来世界各地的 IT 专业人士，或者更宽泛地，为每个人作出一些积极的改变。今天也许没有这样的系统可供您购买，它们为其自带的所有固件完整地提供了软件工具、可验证性和安全性。但这并不一定还是若干年之后的情况。 32 | 33 | 制造商和 OEM 面临它们自身的挑战，其中最大的挑战就是计算机硬件的非常微薄的剩余价值。所有进步在某种程度上都必须从这些微薄的剩余价值中榨取。固件展现出了一个特别的挑战，由于制造商不愿意在其售出一台系统之后再次接触它，因此就地更新应当被支持。如果您开始要求变革，很可能会遇到一些挫折，但是仍然值得为之付出努力，并且这应当在您的剩余 IT 职业生涯中为您和您的同行 IT 专业人士带来回报。 34 | 35 | # 第 6 章 结论 36 | 37 | 平台固件为攻击者提供了一个平台以便在当前传统的反病毒和恶意软件检测软件的视觉之外安装持久的恶意软件。固件的复杂度和能力不断增加，因此攻击面也在增加，而关于此问题的警觉性仍然较低。 38 | 39 | 作为一名系统或者网络管理员，或者一名蓝队成员，您已经提高了对此问题的警觉性，现在您可以帮助教育其他人，开始实现防护，以及向您的 VAR 和 OEM 施压以得到更加符合安全性的硬件。 40 | 41 | ## 6.1 PreOS Security 的安全性解决方案 42 | 43 | 第一步是在开箱之后立即将所有可能的平台固件的镜像及其散列值整合到您的硬件生命周期，并且在机器的寿命之内周期性地进行检查，特别是在疑似遭到物理攻击或者操作系统级别的恶意软件入侵之后。PreOS Security 通过我们的软件客户端和网络仪表盘使得这一过程更加简单了，并且我们将会与您一同工作以便将我们的客户端与您的单窗格选择系统整合到一起。 44 | 45 | 您也可以与固件安全领域的最新发展保持同步，通过我们的季度新闻简报中的一段简短总结： 46 | 47 | [https://preossec.com/newsletter](https://preossec.com/newsletter) 48 | 49 | 我们将会持续精炼本书的内容，因此如果您有任何反馈，通过以下邮件地址发送给我们： 50 | 51 | editor@preossec.com 52 | 53 | -------------------------------------------------------------------------------- /nist_sp_800-147b/chapter_4.md: -------------------------------------------------------------------------------- 1 | # 第 4 章 各种更新机制的安全指导意见 2 | 3 | 下文提供了关于针对三种典型的安全 BIOS 更新机制实施本文档中的安全指导意见的详细建议。一台服务器可以实施这些机制中的一种或多种，而一台给定的服务器上所实施的方法可能由该平台上的硬件支持所决定。这些方法会因 RTU 可以于何时被建立以及用于防止对于存储于 BIOS 闪存存储器中的代码和数据的无意或者恶意的修改的闪存安全锁定机制的可用性而异。所有机制依赖于经过数字签名的 BIOS 更新镜像以及 RTU 中的验证组件利用某个公钥以验证该镜像的签名的能力。 4 | 5 | ## 4.1 更新机制 1：任何时机的安全 BIOS 更新 6 | 7 | 对于此种 BIOS 更新机制，对 BIOS 闪存存储器的安全更新可能发生于服务器的多种运行状态。这包括能够在服务器运行时更新 BIOS 闪存而无需重启。尽管新的 BIOS 被期望直到重启之前不会被执行，此闪存可以在运行时使用系统管理中断（SMI）处理程序、服务处理器或者其他安全方法来刷新。导致新 BIOS 被执行的重启可以发生于任何后续时机（在实际的闪存更新发生之后潜在地可达数月之久）。 8 | 9 | 由于此安全更新机制防止向 BIOS 闪存存储器写入非法代码，无需在重启时验证 BIOS。 10 | 11 | 对于实施此种 BIOS 更新机制的相关指导意见列于下方： 12 | 13 | * BIOS 更新镜像必须经过数字签名以满足 3.1 节所述的 BIOS 更新认证要求。实现方式可以将 BIOS 更新镜像分割为多个独立数字签名的部分 14 | * 如 2.5 节定义的 RTU 必须在运行时可用（并且可以在服务器的其他运行状态下可用）以更新 BIOS 闪存存储器 15 | * 锁定机制必须存在以使得只有 RTU 可以写入 BIOS 闪存。应该只有 RTU 能够解锁闪存，并且当解锁时，只有 RTU 可以拥有写入 BIOS 闪存存储器的能力。RTU 可以总是拥有 BIOS 闪存存储器的写入访问权限 16 | * 经过数字签名的 BIOS 更新镜像必须被传输到 RTU。RTU 必须有能力将 BIOS 更新镜像存储于某个不允许对 BIOS 更新镜像进行非授权的写入访问的位置。 17 | 18 | 实施这一机制的一般步骤包括： 19 | 20 | 1. 经过数字签名的 BIOS 更新镜像被传输到 RTU 21 | 2. RTU 将此 BIOS 更新镜像存储于只能被 RTU 写入的某个位置 22 | 3. RTU 验证此 BIOS 更新镜像是否合法。如果此 BIOS 更新镜像被确定为非法，则此 BIOS 更新镜像不会被写入 BIOS 闪存存储器。如果此 BIOS 更新镜像合法，RTU 配置锁定机制，使得只有 RTU 拥有对于 BIOS 闪存存储器的写入访问权限。可行的锁定机制设计可以允许 RTU 对于 BIOS 闪存存储器总是拥有写入访问权限，只要只有 RTU 拥有相同的能力 23 | 4. RTU 将 BIOS 更新镜像写入 BIOS 闪存存储器 24 | 5. RTU 保证 BIOS 闪存存储器在将控制权移交给 RTU 以外的代码（例如 Option ROM）之前被锁定，基于 3.3 节所述的固件完整性保护的每一项要求。 25 | 26 | 参见附录 B 以获取此更新机制的范例。 27 | 28 | ## 4.2 更新机制 2：重启时的安全 BIOS 更新 29 | 30 | 对于此种 BIOS 更新机制，BIOS 闪存存储器处理在服务器运行时被引发，然而实际的 BIOS 闪存存储器更新直到服务器重启之前都不会发生。此种 BIOS 更新机制防止非法代码被写入 BIOS 闪存存储器中。 31 | 32 | 对于实施此种 BIOS 更新机制的相关指导意见列于下方： 33 | 34 | * BIOS 更新镜像必须经过数字签名以满足 3.1 节所述的 BIOS 更新认证要求。实现方式可以将 BIOS 更新镜像分割为多个独立数字签名的部分 35 | * 对于 BIOS 闪存存储器的锁定机制必须存在，使得除了 RTU 以外没有任何实体在运行时对于 BIOS 闪存存储器拥有写入访问权限。尽管对于此种更新机制，RTU 不必须拥有对于 BIOS 闪存存储器的写入访问权限，可能还有确实有此要求的其他 BIOS 更新机制被支持 36 | * 如 2.5 节所定义的 RTU 必须在系统启动过程中可用，它可以在运行时更新 BIOS 闪存存储器。RTU 必须在重启时在 BIOS 闪存存储器更新之前被执行。RTU 将会在针对闪存的任何更改发生之前验证 BIOS 更新镜像的数字签名 37 | * 必须存在一块其内容在重启时可被保留的存储区域，使得经过签名的 BIOS 更新镜像可以于运行时被缓存到其中，并且 RTU 可以在重启过程中访问它以便在更新 BIOS 闪存存储器的内容之前验证 BIOS 更新镜像的数字签名。在重启过程中，保存 BIOS 更新镜像的存储区域在验证过程中必须不能被除了 RTU 以外的任何实体访问。 38 | 39 | 实施这一机制的一般步骤包括： 40 | 41 | 1. 经过签名的 BIOS 更新镜像被缓存到一块存储位置，其内容可以在服务器重启时被保留 42 | 2. 当服务器重启时，执行权被移交至 RTU 43 | 3. RTU 验证 BIOS 更新镜像是否合法。如果认定为合法，RTU 将会按需解锁 BIOS 闪存存储器并且将更新写入 BIOS 闪存存储器。如果此 BIOS 更新镜像被认定为非法，则 BIOS 闪存存储器不会被更新 44 | 4. BIOS 闪存存储器的锁定机制在执行任何不可信代码，包括 Option ROM 之前被启用。 45 | 46 | 参见附录 C 以获取此更新机制的范例。 47 | 48 | ## 4.3 更新机制 3：要求启动时验证的安全 BIOS 更新 49 | 50 | 对于此种更新机制，在运行时保护 BIOS 闪存存储器的锁定机制不存在或者受限，使得由 RTU 以外的实体对 BIOS 闪存存储器的写入不能被防止。对 BIOS 闪存存储器的恶意更新可能会发生，由于 BIOS 闪存存储器未被写保护或者锁定。然而，BIOS 闪存存储器的内容应该于每次启动时被执行前被认证。如果 BIOS 闪存存储器在启动过程中被认定为非法，将会引发恢复过程，而非法 BIOS 不会被执行。 51 | 52 | 对于实施此种 BIOS 更新机制的相关指导意见列于下方： 53 | 54 | * BIOS 镜像必须经过数字签名，以满足 3.1 节所述的 BIOS 更新认证要求 55 | * 如 2.5 节所定义的 RTU 必须在将镜像写入到 BIOS 闪存存储器之前验证 BIOS 更新镜像的数字签名 56 | * 由于系统 BIOS 在运行时未被保护以防止修改，RTU 必须包含能够在执行之前验证系统 BIOS 的验证组件，基于 3.3 节所述的固件完整性保护的每一条要求。验证组件必须在启动时被执行，并且在任何可更新的 BIOS 代码被执行之前验证系统 BIOS 57 | * 如果系统 BIOS 被认定为非法，RTU 必须引发恢复过程，并且非法系统 BIOS 必须从未被执行。 58 | 59 | 实施这一机制的一般步骤包括： 60 | 61 | 1. 经过数字签名的 BIOS 镜像被验证并且写入到 BIOS 闪存存储器中 62 | 2. 在每次启动时，执行权被移交给 RTU 63 | 3. 如果 RTU 的验证组件认定 BIOS 闪存存储器合法，执行权被移交给 BIOS 64 | 4. 如果 BIOS 闪存存储器被认定为非法，RTU 引发恢复过程，并且此非法 BIOS 从未被执行。 65 | 66 | 参见附录 D 以获取此更新机制的范例。 67 | 68 | -------------------------------------------------------------------------------- /peripheral-based_attack_memory/chapter_7.md: -------------------------------------------------------------------------------- 1 | # 第 7 章 结论和未来工作 2 | 3 | > 逻辑学是一种系统性的方法，用于满怀信心地得出错误的结论。——Manly's Maxim，Murphy 法则集锦 4 | 5 | 通过攻击计算机平台外设来攻击宿主平台内存代表了当前 rootkit 进化的顶峰。本论文呈现了关于利用这些 rootkit 技术针对计算机平台发动攻击的研究。平台外设非常适合隐藏恶意代码以攻击宿主平台。这些外设包含具有专用处理器和专用内存，并且能够直接访问宿主内存的隔离执行环境。在本工作之前，源自利用直接内存访问（DMA）的恶意软件的攻击曾经被看作是对于宿主 CPU _不可见_ 的。然而，本论文展示了 _宿主 CPU 仍然能够检测那些利用 DMA 的攻击。这允许宿主 CPU 化解此类攻击_。 6 | 7 | 最近，诸如管理控制器和网卡（NIC）等外设几乎存在于每一部计算设备中。服务器系统、台式机系统、笔记本、平板，以及甚至是移动电话都使用专用控制器以便从宿主 CPU 上卸载工作量。尽管渗透这样一部外设是一项资源密集型任务，然而就其隐秘性而言，这些环境仍然具有吸引力。DMA 机制是攻击宿主内存的基础。因此，我们将那些利用直接内存访问的基于外设的攻击代码称为 DMA 恶意软件。通过利用 DMA 恶意软件，攻击者可以以某种隐秘的方式读取和写入宿主内存。对手能够访问存在于主内存中的全部数据。因此，攻击者可以偷取诸如密码学密钥、口令、互联网银行凭证、打开的文件，以及所有用户输入等敏感数据。对手也可以向主内存中插入数据以实现内核后门。然而，这会降低隐秘攻击的成功率，由于理论上宿主软件可以检测到针对宿主内存的恶意修改。与之相反，攻击者也可以通过 DMA 攻击宿主检测软件以避免被检测到。 8 | 9 | 在本工作中，我们开发并且分析了一种 DMA 恶意软件概念验证。此恶意软件执行于某个隔离执行环境，其内部工作方式不可被宿主访问。本论文的目标是展示即使宿主 CPU 不能访问可疑外设的内部工作方式，宿主 CPU 仍然能够保护自己不受 DMA 恶意软件的攻击。我们用于我们的恶意软件概念验证的外设是 _Intel 管理引擎_（Intel ME）。除了其他事情以外，Intel 还利用 ME 环境实现了一台网络服务器，它为系统管理员提供了远程设备管理能力。管理员能够恢复宿主操作系统，即使该平台已经不能启动，例如由于操作系统内核完整性的损坏。Intel 应用了保护机制以确保 ME 特性不能被用于攻击宿主。然而，这种保护也确保了诸如反病毒软件等无法评估 ME 环境。与之相反，例如能够通过零日漏洞等方式渗透 ME 的攻击者同样得益于这种保护。 10 | 11 | 我们的恶意软件概念验证是一种 _基于直接内存访问的击键码记录器_（Direct memory Access based keystroke code loGGER）。DAGGER 展示了就宿主 CPU 的检测能力而言，实现隐秘恶意软件是可能的。攻击代码执行于专用的 ME 处理器上。因此，此击键码记录器对于宿主并不会造成可测量的性能开销。我们的恶意软件同样能够捕获短寿命数据，例如击键码。我们利用 ME 环境的隔离的带外网络特性来将诸如捕获的击键码等私密数据潜出至外部平台。此网络特性同样对于宿主不可见。我们对 DAGGER 的分析揭示了 DMA 恶意软件必须从宿主内存中搜索有价值数据。对宿主内存的这种搜索过程造成了额外的总线活动，而如果使用了内存地址随机化机制，或者如果私密数据存在于 CPU 缓存或者 CPU 寄存器中，这种额外的总线活动还会增加。我们还确定了不同设备的并行内存访问请求由内存控制器集线器进行仲裁。这导致了这样一种假设，即仲裁器可以造成 DMA 副作用，而我们能够利用这种副作用来检测 DMA 恶意软件。我们通过引导一次内存压力测试而确认了这一假设。有了这次实验，我们展示出了一种可靠的，可测量的 DMA 副作用。我们的测量考虑了基于宿主 CPU 时钟周期以及性能计数器的精确计时。 12 | 13 | 我们带着开发一种 DMA 恶意软件检测器的目标继续了本研究。我们分析了宿主 CPU 的性能计数器。最终，我们的调查得出了一种能够区分合法和非法内存总线传输的性能计数器配置。我们对宿主操作系统的预期总线活动进行了建模，并且将其同测量得到的总线活动进行比较。为了对预期总线活动进行建模，我们使用了操作系统内核中可用于宿主 CPU 的信息。 14 | 15 | 我们以一种操作系统内核模块的形式实现了我们的模型和测量机制，我们称其为 _总线代理运行时监视器_，简称 BARM。BARM 是一种运行时监视器，它同时考虑了瞬时攻击。我们的监视器只造成了可忽略的性能开销。BARM 不要求对固件或者硬件进行任何修改。我们的运行时监视器同样不要求对于潜在受到攻击的外设的内部工作方式的任何访问。在对我们的概念验证实现 BARM 进行评估之后，我们得出结论，即宿主 CPU 能够检测并且终止 DMA 恶意软件。我们的评估同样揭示了最小化的 BARM 测量结果波动。这些波动可能发生于使用性能计数器时，由于我们将这些性能计数器用于我们的概念验证实现。我们通过引入容错值来克服这一问题。此容错值是一个经验值，它代表可被容忍的总线传输次数，即在我们的案例中，容错值是 50 次总线传输。我们展示了 DMA 恶意软件在宿主运行时内存中搜索有价值数据时会造成大得多的总线活动。 16 | 17 | 然而，此容错值也展示了当前 BARM 实现的一种局限性。理论上，对手可以在每个采样区间内隐藏多达 2 _T_ 的总线传输。然而仅当对手能够精确地预测 BARM 检测到 - _T_ 次总线传输的时间点时，这才是可行的。与之相反，这也会导致更加迟缓的搜索阶段，而宿主 CPU 可以利用这一点来保护宿主内存中的目标数据。另一种局限性是一种由以太网控制器引导的可能的中间人攻击。我们通过实现一种合法报告信道来化解这种中间人攻击。用于报告平台状态的合法报告信道是本工作的另一个目标。在我们的场景中，此平台状态包括 DMA 恶意软件。BARM 将合法测定结果传送至外部平台。 18 | 19 | 诸如 TLS 等安全信道协议不足以胜任我们的场景。我们调整了 TLS 协议以满足合法平台状态报告的要求。同时考虑网卡是至关重要的，由于它可以潜在地修改或者拦截 BARM 数据包。为了逃避检测，网卡还可以实施 _中间人_（MitM）攻击，通过将另一平台的良好 BARM 测定结果中继到想要评估目标平台状态的平台上。另一个范例是通过 DMA 偷取存在于宿主运行时内存中的密钥素材。为了消除这些问题，此通讯信道被绑定到实际端点，即宿主 CPU。BARM 对总线活动的测定结果进行数字签名，并且确保私钥以及通讯信道的会话密钥被保护起来以防止 DMA 恶意软件攻击。为了实现一种关于合法平台状态报告应用的概念验证，我们必须改良 BARM 以考虑网卡的合法内存总线活动。关于我们的信道应用的评估确认了网卡可以被 BARM 可靠地考虑。 20 | 21 | ## 未来工作 22 | 23 | 尽管我们能够得出结论，即宿主 CPU 能够利用 BARM 保护自己不受 DMA 恶意软件的攻击，仍有一些任务留作我们的未来工作。首先，在非 Intel 硬件上评估 BARM 背后的理念将会十分有趣。诸如 ARM 等其他架构也提供了硬件性能计数器。基于 ARM 的平台同样用到了可以作为 DMA 恶意软件的潜在宿主的外设。当考虑到这些平台在其设计中广泛使用 _系统芯片_（SoC）时，这变得特别有趣。因此，位于相同设备封装或者芯片之中的外设可以被用于实现系统后门。 24 | 25 | 调查基于计时的 DMA 副作用是否也可被用于实现一种可靠的检测工具也很有趣。这可能对于那些不支持性能计数器的架构非常有用。BARM 实现还应该考虑其他外设。在我们看来，在 BARM 的检测模型中整合更多的外设更为重要。这也可能消除 BARM 测量结果中的波动。值得注意的是，整合更多的基于 DMA 的设备是一项资源密集型任务。因此，后续研究项目应该检查此过程能够在多大程度上自动化。 26 | 27 | -------------------------------------------------------------------------------- /nist_sp_800-125a/chapter_4.md: -------------------------------------------------------------------------------- 1 | # 第 4 章 HY-BF1 安全性建议 2 | 3 | 为了保证 VM 中运行的进程的隔离，下列要求必须被满足： 4 | 5 | * (a) 从客户 OS 到宿主处理器的高权限命令或者指令必须被调度，以使得 VMM/虚拟机监视器作为虚拟化资源控制器的基本功能得以维持 6 | * (b) 虚拟机监视器宿主的内存管理功能的完整性必须被保护，以防止诸如缓冲区溢出以及非法代码执行等攻击，特别是在存在管理多个 VM 的内存访问所必需的翻译表的情况下 7 | * (c) 内存分配算法必须保证所有 VM 中的负载都能够执行它们的功能 8 | * (d) CPU 分配算法必须保证所有 VM 中的负载都能够执行它们的功能 9 | 10 | 要求 (a) 和 (b) 可以利用基于软件的模块来满足。然而，相对于基于软件的解决方案，诸如指令集虚拟化和内存虚拟化等基于硬件的虚拟化辅助对于满足这些要求能够提供更多的担保，因而在 4.1 节中被推荐。在表述推荐之前，先简要地讨论一下基于硬件地虚拟化特性。要求 (c) 和 (d) 本意是要保证 VM 中运行的应用程序服务的可用性。用于提供这些保障的是内存分配和 CPU 分配算法中的某些特性，并且与之相关联的配置参数分别在 4.2 和 4.3 节中被表述为推荐。 11 | 12 | ## 4.1 硬件虚拟化辅助 13 | 14 | _指令集虚拟化_：用于支持指令集虚拟化的处理器架构提供两种操作模式：root 模式和非 root 模式，每一种都有 4 个层级的权限等级，其中 0 级为最高而 3 级为最低。此外，在这两种模式中，对于执行 CPU 指令，root 模式比非 root 模式具有更高权限。通过在 root 模式中运行虚拟机监视器，并且在高权限或者 0 环的非 root 模式中运行 VM（客户）OS，虚拟机监视器的安全得以保证，至少是通过防止来自任意客户 OS 的任何指令集类型的攻击。然而，VM 逃逸可能通过正常的网络协议而发生。此安全性是通过允许硬件捕获高权限指令以在非 root 模式中运行而在 root 模式中执行而得到保证的。此外，如果虚拟机监视器不必须执行额外的功能（例如利用诸如二进制翻译等技术翻译敏感指令），在虚拟机监视器中以高权限执行的代码将会减少，使得 TCB 更小，并且允许更好的担保验证。 15 | 16 | _内存虚拟化_：如果硬件允许利用基于硬件的页表而非由虚拟机监视器生成的影子页表将客户 OS 在其对应页表中的物理地址映射到宿主的物理地址，则称提供了硬件辅助的内存虚拟化。由此引起的用于执行此功能的高权限代码的减少可以提供相当于上述指令集虚拟化部分所提到的安全性优势。 17 | 18 | 硬件辅助的虚拟化平台的安全性优势包括以下方面： 19 | 20 | * 虚拟机监视器的潜在安全漏洞之一是来自驻留于虚拟化的宿主平台上的 VM 的缓冲区溢出攻击。作为硬件辅助虚拟化的一部分的内存管理（例如扩展页表，PET）的硬件支持可以被撬动以防止来自保留给数据存储的内存位置的代码执行，因此阻止缓冲区溢出攻击 21 | * 虚拟化的硬件扩展提供了两种执行模式：宿主或者 root 模式，以及客户或者非 root 模式。宿主模式运行在高于客户模式的权限等级上。提供基线功能 HY-BF1（处理器分配和内存管理）的虚拟机监视器代码运行于宿主模式而 VM 中的客户 OS 和应用程序运行于客户模式。因此客户 OS 中的任何漏洞利用代码不能破坏由虚拟机监视器代码提供的控制 22 | * 虚拟化平台中的一种常见威胁涉及能够访问属于其他 VM 的内存区域的恶意 VM。这称为 VM 逃逸攻击。具有 IOMMU 的硬件平台提供了针对这种威胁的安全性，通过诸如直接内存访问（DMA）重映射等特性，这将被允许的 DMA 访问限制在指定的保护域中（即阻止设备执行超出其分配区域的 DMA） 23 | * 为两种形式的虚拟化提供硬件辅助的优势在于，虚拟机监视器中的模拟模块可以呈现物理宿主的真实硬件架构而非修改过的硬件架构。这一特性的结果是，未经修改的客户 OS 及其原生设备驱动程序可以运行在 VM 中。启用这一特性的安全性启示是，可用于客户 OS 的 CVE 数据，以及可用于每一种 OS 版本的补丁版本以及认证的设备驱动程序的数量都会显著增加 24 | 25 | _安全性建议 HY-SR-2_：虚拟化的宿主的硬件应该利用 MMU 对指令集虚拟化和内存管理提供辅助，由于硬件支持提供了下列安全性担保，而这些是完全基于软件的虚拟化所不能保证的： 26 | 27 | * 更佳的内存管理控制可以防止诸如缓冲区溢出等攻击 28 | * IOMMU 中的 DMA 传输重映射特性提供更佳的 I/O 设备隔离。更进一步地，直接将 I/O 设备指认给某个特定 VM 并且允许直接访问这些资源这一特性消除了为该 VM 提供模拟设备驱动程序的需求，因此减少了可信代码的大小 29 | * 客户 OS 代码和虚拟机监视器代码执行于不同的处理器模式，提供了更佳的隔离 30 | * 权限层级的隔离可以为设备访问调度功能提供更佳的保护，并且硬件层级的内存保护可以提供更佳的 VM 层级保护 31 | * 通过支持完全虚拟化，COTS 版本的 OS 可以允许更简单的补丁和更新，而非必须对可以运行于准虚拟化平台的唯一类型的修改或者移植版本的 OS 进行相同操作 32 | * 由于现在众多虚拟化特性在硬件中可用，虚拟机监视器代码将会变小，允许更佳的安全性证明和验证 33 | 34 | ## 4.2 VM 内存分配计划选项 35 | 36 | 虚拟机监视器的内存调度程序负责在任何时间使得所有 VM 中运行着的所有负载满足其内存要求。类似于 OS，常见的虚拟机监视器利用物理内存和称为虚拟机监视器内核交换文件的交换文件来满足这一要求。更进一步地，常见的 VM 并不总是要求它所被配置的全部内存。基于这些原因，使得运行在某个虚拟化的宿主上的 VM 的配置内存总量超过物理内存总量是一种可能实现的总体虚拟化配置决策，如果 VM 中没有运行内存敏感的应用程序。然而，内存超量使用——即 VM 的配置内存总量和宿主的物理内存的比例——不应过高，由于这可能导致某些要求大量内存的 VM 负载的性能恶化。 37 | 38 | 对于 VM 中的某些负载，影响虚拟化的宿主或者虚拟机监视器的可用性的另一个因素是物理内存大小和由虚拟机监视器的内存调度程序维护的内核交换文件大小的比例。由于过低的比例将会拒绝某些 VM 中的某些负载的执行，虚拟机监视器中应该有一个配置选项以便为每个 VM 指定一个保证的物理内存量。同样，为了避免这样一种情形，即某个特定 VM 占用了相当于它的全部配置内存的物理内存，应该有一个特性以指定保证的物理内存的上限。最后，可能有某些负载是时间敏感的，则托管它们的 VM 应该相对于其他运行着的 VM 在获得必需的内存资源方面具有一定的优先级。因此，还应该存在一个配置选项以便为每一个 VM 指定一个优先级的值。 39 | 40 | 基于上述与虚拟机监视器的内存计划相关的问题，下面就是安全性建议： 41 | 42 | _安全性建议 HY-SR-3_：虚拟机监视器应该拥有配置选项以便为每一个要求内存的 VM 指定保证的物理内存量，以及该值的上限，此外还有在多个 VM 之间产生竞争的条件下用于获取必需的内存资源的优先级的值。更进一步地，允许所有 VM 的配置内存总量超过宿主的物理内存的内存超量使用特性应该默认禁用。 43 | 44 | ## 4.3 VM CPU 分配选项 45 | 46 | VM CPU 分配的安全性目标是保证所有 VM 的可用性。这可以通过对于处理诸如 CPU 内核和 CPU 时钟周期等物理资源的分配的配置选项的适当使用来实现。例如，一个普遍可用的配置选项是设置最小 CPU 要求，或者预留，以时钟周期计算。这里需要遵守的架构参数是，可以被部署的 VM 数量不能超过虚拟机监视器宿主可以提供的 CPU 时钟周期总数和每个 VM 要求的平均预留的比值。例如这样的场景，虚拟机监视器宿主拥有 6000 MHz 的 CPU 能力，而每一个 VM 所要求的平均预留为 1000 MHz，那么该虚拟机监视器宿主上不能有多于 6 个 VM 处于活动状态。因此，预留为每个 VM 所要求的 CPU 时钟周期设置了下限（保证）。类似地，还应该有一个特性来为每一个 VM 所能够使用的 CPU 周期设置上限，或者限制，以使得没有一个 VM（有时是恶意或者受到攻击的 VM）会消耗宿主的全部 CPU 资源并且对与之共同驻留的 VM 拒绝服务。更进一步地，为了在这样一种情况下辅助计划虚拟机监视器宿主的 CPU 时钟周期，即多个 VM 要求的时钟周期高于下限但是低于上限，应该有一个特性来为每一个 VM 指认一个优先级分值，或者份额。综合以上关于保证所有部署的 VM 之间的合理分配的理想特性，关于 VM CPU 分配的安全性建议如下所述： 47 | 48 | _安全性建议 HY-SR-4_：虚拟机监视器应该拥有强壮的配置特性以用于将虚拟资源提供给所有托管的 VM，以使得它不会超过某种关键物理资源（例如 CPU 内核数量） 49 | 50 | _安全性建议 HY-SR-5_：虚拟机监视器应该提供特性以便为每一个部署的 VM 所需的 CPU 时钟周期指定下限和上限，以及提供特性以便为每一个 VM 指定一个优先级分值，以便在多个 VM 竞争 CPU 资源的情况下辅助计划 51 | 52 | -------------------------------------------------------------------------------- /nist_sp_800-147b/front_matter.md: -------------------------------------------------------------------------------- 1 | # NIST 特别出版 800-147B 2 | 3 | # 服务器 BIOS 保护指南 4 | 5 | Andrew Regenscheid 著 6 | 7 | 计算机安全分部，信息科技实验室 8 | 9 | 此出版物可从此处免费获得： 10 | 11 | [http://dx.doi.org/10.6028/NIST.SP.800-147B](http://dx.doi.org/10.6028/NIST.SP.800-147B) 12 | 13 | 2014 年八月 14 | 15 | 美国商务部 秘书 Penny Pritzker 16 | 17 | 美国国家标准技术研究所 标准和技术商务执行次长和执行主任 Willie May 18 | 19 | ## 权力范围 20 | 21 | 此出版物由 NIST 开发以履行其在美国联邦信息管理法案（FISMA），公法（P.L.）107-347 下的法定责任。NIST 负责为联邦信息系统开发信息安全标准和指导意见，包括最低要求，但是这样的标准和指导意见在没有得到对这些系统行使政策权力的适当的联邦官员的明确许可的条件下不应该被应用到国家安全系统。此指导意见于美国行政管理和预算局（OMB）公告 A-130 第 8b(3) 节“防护政府机构信息系统”相一致，如同公告 A-130 附录 IV“关键章节分析”所分析的那样。补充信息由公告 A-130 附录 III“联邦自动化信息资源的安全性”提供。 22 | 23 | 此出版物中的任何内容都不应该被用于否认由美国商务部秘书在法定权力下规定的对于联邦政府机构具有强制性和法律约束力的标准和指导意见。这些指导意见也不应该被解读为更改或者取代商务部秘书、行政管理和预算局主任，或是任何其他联邦官员的现有权力。此出版物可以在自愿的基础上被非政府组织使用，并且不受美国版权的限制。但是 NIST 要求署名权。 24 | 25 | 美国国家标准技术研究所特别出版 800-147B 26 | 27 | Natl. Inst. Stand. Technol. Spec. Publ. 800-147B，32 页（2014 年八月） 28 | 29 | [http://dx.doi.org/10.6028/NIST.SP.800-147B](http://dx.doi.org/10.6028/NIST.SP.800-147B) 30 | 31 | CODEN：NSPUE2 32 | 33 | > 此文档中可能会提到某些商业实体、设备或者器材以便充分地描述某种试验程序或者概念。这样的提名的本意并非暗示 NIST 对其的推荐或认可，也非暗示这些实体、器材或者设备一定是可用于该目的之最好的。 34 | 35 | > 此文档中可能会有对于 NIST 的当前正在开发中的其他出版物的引用，以便符合其被赋予的法定责任。此出版物中的信息，包括概念和方法论，可以被联邦政府机构使用，即使是在这些附带的出版物完成之前。因此，直到每部出版物完成之前，当前的要求、指导意见和过程在其所存在之处仍然有效。关于计划和迁移的目的，联邦政府机构可能想要紧密跟踪由 NIST 提供的这些新出版物的进展。 36 | 37 | > 我们鼓励组织机构在公开评论期间审阅所有出版物草案并且为 NIST 提供反馈。所有 NIST 计算机安全分部的出版物，除了上述注记的以外，可以从 [http://csrc.nist.gov/publications](http://csrc.nist.gov/publications) 获得。 38 | 39 | 关于此出版物的评论可以被提交至： 40 | 41 | 美国国家标准技术研究所 42 | 43 | 收件人：计算机安全分部，信息科技实验室，办事处大道 100 号（8930 邮递点），盖瑟斯堡，马里兰州 20899-8930 44 | 45 | 邮件：[800-147comments@nist.gov](mailto:800-147comments@nist.gov) 46 | 47 | ## 计算机系统技术报告 48 | 49 | 位于美国国家标准技术研究所（NIST）的信息科技实验室（ITL）通过为国家的测定和标准基础设施提供技术领导来提升美国经济和公众福利。ITL 通过开发测试、测试方法、参考数据、概念实现的证明以及技术分析来推进信息科技的发展及其生产性的使用。ITL 的职责包括为联邦信息系统中的国家安全相关信息以外的成本高效的安全性和隐私性开发管理、行政、技术和物理方面的标准和指导意见。此特别出版 800 系列报导了 ITL 的研究、指导意见及其在信息系统安全领域的延伸努力，以及与行业、政府和学术组织之间的合作活动。 50 | 51 | ## 摘要 52 | 53 | 现代计算机依赖基本系统固件，通常称其为基本输入/输出系统（BIOS）以辅助硬件初始化过程并且将控制权移交给虚拟机监视器或者操作系统。恶意软件对 BIOS 固件的非授权修改构成了一种重大威胁，由于 BIOS 在 PC 架构中的独特和特权的地位。此文档中的指导意见包括避免在服务器上执行恶意或者损坏的 BIOS 代码所需的要求。它们适用于存储于 BIOS 闪存中的 BIOS 固件，包括 BIOS 代码、作为更新可信根的一部分的密码学密钥，以及静态 BIOS 数据。此指南的本意是为服务器平台厂商提供关于安全 BIOS 更新过程的建议和指导意见。 54 | 55 | ## 关键字 56 | 57 | 基本输入/输出系统（BIOS）；信息安全；补丁管理；服务器安全；固件；可信根；更新可信根 58 | 59 | ## 致谢 60 | 61 | 来自美国国家标准技术研究所（NIST）的作者 Andrew Regenscheid 想要感谢那些审阅了此文档草案并且为其贡献了技术内容的同事。特别地，NIST 感谢出自那些帮助指导本作品的来自业界和政府的专家的贡献。这些专家包括来自 AMD 的 Gary Simpson、来自思科的 Anthony Grieco、Bill Jacobs 和 Chirag Schroff、来自戴尔的 Mukund Khatri 和 Frank Molsberry、来自 IBM 的 Scott Dunham 和 Charles Palmer，以及来自 Intel 公司的 Lelia Barlow、Bob Hale 和 David Riss。 62 | 63 | NIST 还想要感谢来自美国国家安全局的 Mike Boyle、Tom Broström、Bob Clemons 和 Patrick Hagerty，他们也为此文档提供了实质性的贡献。 64 | 65 | # 执行摘要 66 | 67 | 现代计算机依赖基础系统固件，通常称其为基本输入/输出系统（BIOS）以辅助硬件初始化过程以及将控制权移交给虚拟机监视器或者操作系统。BIOS 通常由原始设备制造商（OEM）和独立 BIOS 厂商开发，并且由主板或者计算机制造商分发给最终用户。制造商频繁更新固件以修复 bug、为漏洞打补丁以及支持新硬件。此文档是关于 BIOS 保护的系列出版物中的第二部。于 2011 年四月发布的首部文档 SP800-147，BIOS 保护指南（_BIOS Protection Guidelines_）为在企业环境中部署的台式机和笔记本系统提供了指导意见。 68 | 69 | 恶意软件对 BIOS 固件的非授权修改构成了一种重大威胁，由于 BIOS 在现代计算架构中的独特和特权的地位。恶意 BIOS 修改可能成为针对组织机构的高级攻击的一部分——可以是永久的拒绝服务或者是持久的恶意软件存在。 70 | 71 | 此文档涵盖基本服务器、受管理的服务器和刀片服务器的 BIOS 保护。这些类型的服务器通常包含服务处理器——为管理员提供管理宿主服务器的接口的专用微控制器。服务器，特别是带有服务处理器的服务器，可能会实施多种 BIOS 更新机制。仅实施单一 BIOS 更新机制的服务器可以实行 SP800-147 中的指导意见，如果其更新机制与 PC 客户端系统足够相似，否则他们可以实施此文档中的指导意见。 72 | 73 | 此出版物中的安全指导意见并不试图防止通过供应链、利用物理替换 BIOS 芯片或是通过安全本地更新程序来安装非法 BIOS。 74 | 75 | 安全指导意见具体用于四种系统 BIOS 安全特性： 76 | 77 | * **认证 BIOS 更新机制**：由数字签名防止执行非法 BIOS 更新镜像 78 | * 可选的**安全本地更新机制**：要求一位管理员在系统面前物理存在以安装 BIOS 镜像而无需签名验证 79 | * **固件完整性保护**：在认证 BIOS 更新过程以外防止对于 BIOS 的无意或者恶意的修改 80 | * **不可绕过性**特性：保证没有任何机制可以允许主处理器或者任何其他系统组件绕过 BIOS 保护 81 | 82 | 此文档还提供了关于利用普遍实现于服务器之中的三种 BIOS 更新机制来实现 BIOS 保护的额外信息和建议。这些素材的本意是帮助实施者们设计系统以满足此出版物中的安全要求。 83 | 84 | 服务处理器是众多现代服务器设计中的关键管理组件。他们负责多种管理特性，取决于系统的实现。某些但不是全部服务处理器能够更新系统 BIOS。此文档描述服务处理器在系统 BIOS 更新过程中的可能的作用，并且描述此安全指导意见是如何适用于包含这些组件的系统的。 85 | 86 | -------------------------------------------------------------------------------- /nist_sp_800-193/front_matter.md: -------------------------------------------------------------------------------- 1 | # NIST 特别出版 800-193 2 | 3 | # 平台固件弹性指南 4 | 5 | Andrew Regenscheid 著 6 | 7 | 计算机安全分部，信息科技实验室 8 | 9 | 此出版物可从此处免费获得： 10 | 11 | [https://doi.org/10.6028/NIST.SP.800-193](https://doi.org/10.6028/NIST.SP.800-193) 12 | 13 | 2018 年五月 14 | 15 | 美国商务部 秘书 Wilbur L. Ross, Jr. 16 | 17 | 美国国家标准技术研究所 NIST 主任和标准技术商务次长 Walter Copan 18 | 19 | ## 权力范围 20 | 21 | 此出版物由 NIST 开发以符合其在 2014 年的美国联邦信息安全现代化法案（FISMA），美国法典第 44 章 3551 节及其下的内容，公法（P.L.）113-283。NIST 负责为联邦信息系统开发信息安全标准和指南，但是这些标准和指南不应该被应用于国家安全系统，如果没有对这些系统行使政策权力的适当的联邦官员的明确许可。此指南同美国行政管理和预算局（OMB）公告 A-130 的要求相一致。 22 | 23 | 此出版物中的任何内容都不应该被用于否认由美国商务部秘书在法定权力下规定的对于联邦政府机构具有强制性和法律约束力的标准和指导意见。这些指导意见也不应该被解读为更改或者取代商务部秘书、行政管理和预算局主任，或是任何其他联邦官员的现有权力。此出版物可以在自愿的基础上被非政府组织使用，并且不受美国版权的限制。但是 NIST 要求署名权。 24 | 25 | 美国国家标准技术研究所特别出版 800-193 26 | 27 | Natl. Inst. Stand. Technol. Spec. Publ. 800-193，45 页（2018 年五月） 28 | 29 | [https://doi.org/10.6028/NIST.SP.800-193](https://doi.org/10.6028/NIST.SP.800-193) 30 | 31 | CODEN：NSPUE2 32 | 33 | > 此文档中可能会提到某些商业实体、设备或者器材以便充分地描述某种试验程序或者概念。这样的提名的本意并非暗示 NIST 对其的推荐或认可，也非暗示这些实体、器材或者设备一定是可用于该目的之最好的。 34 | 35 | > 此文档中可能会有对于 NIST 的当前正在开发中的其他出版物的引用，以便符合其被赋予的法定责任。此出版物中的信息，包括概念和方法论，可以被联邦政府机构使用，即使是在这些附带的出版物完成之前。因此，直到每部出版物完成之前，当前的要求、指导意见和过程在其所存在之处仍然有效。关于计划和迁移的目的，联邦政府机构可能想要紧密跟踪由 NIST 提供的这些新出版物的进展。 36 | 37 | > 我们鼓励组织机构在公开评论期间审阅所有出版物草案，并且向 NIST 提供反馈。除了上述出版物以外，NIST 的众多计算机安全出版物可以从 [https://csrc.nist.gov/publications](https://csrc.nist.gov/publications) 获取。 38 | 39 | 关于此出版物的评论可以被提交至： 40 | 41 | 美国国家标准技术研究所 42 | 43 | 收件人：计算机安全分部，信息科技实验室，办事处大道 100 号（8930 邮递点），盖瑟斯堡，马里兰州 20899-8930 44 | 45 | 邮件：[sp800-193comments@nist.gov](mailto:sp800-193comments@nist.gov) 46 | 47 | 所有评论必须在美国信息自由法（FOIA）条款下发布。 48 | 49 | ## 计算机系统技术报告 50 | 51 | 位于美国国家标准技术研究所（NIST）的信息科技实验室（ITL）通过为国家的测定和标准基础设施提供技术领导来提升美国经济和公众福利。ITL 通过开发测试、测试方法、参考数据、概念实现的证明以及技术分析来推进信息科技的发展及其生产性的使用。ITL 的职责包括为联邦信息系统中的国家安全相关信息以外的成本高效的安全性和隐私性开发管理、行政、技术和物理方面的标准和指导意见。此特别出版 800 系列报导了 ITL 的研究、指导意见及其在信息系统安全领域的延伸努力，以及与行业、政府和学术组织之间的合作活动。 52 | 53 | ## 摘要 54 | 55 | 此文档提供了关于支持平台固件和数据对抗潜在地具有破坏性的攻击的弹性的技术指导意见和建议。平台是启动和运行一台系统所需的功能硬件和固件的集合。针对平台固件的成功攻击可以使得系统不可运行，可能是永久的，或者要求由原始制造商重新编程，造成对用户的重大妨碍。此文档中的指导意见通过描述下列安全机制来提升平台的弹性：保护平台防止非授权更改、检测已发生的非授权更改，以及快速和安全地从攻击中恢复。包括原始设备制造商（OEM）和组件/设备提供商在内的实现者可以利用这些指导意见以便在平台中构建更强的安全机制。系统管理员、安全专业人士和用户可以利用此文档以便为未来的系统指导采购策略和优先级。 56 | 57 | ## 关键字 58 | 59 | BIOS；代码签名；固件；Option ROM；平台固件 60 | 61 | ## 致谢 62 | 63 | 来自美国国家标准技术研究所（NIST）的作者 Andrew Regenscheid 想要感谢那些审阅了此文档草案并且为其贡献了技术内容的同事。特别地，NIST 感谢那些帮助指导此作品的来自业界和政府的专家所作出的贡献。这些专家包括来自思科的 Chirag Schroff；来自戴尔的 Mukund Khatri；来自慧与科技的 CJ Coppersmith、Gary Campbell、Shiva Dasari 和 Tom Laffey；来自惠普公司的 Jim Mann；来自 IBM 的 Charles Palmer；来自 Intel 公司的 Bob Hale、David Riss 和 Vincent Zimmer；来自微软的 Paul England 和 Rob Spiger，以及 Shane Steiger。 64 | 65 | NIST 还想要感谢来自美国国家安全局的 Kevin Bingham、Cara Steib 和 Mike Boyle，他们为此文档作出了实质性的贡献，以及来自 Noblis NSP 的 Jeffrey Bruke。 66 | 67 | ## 受众 68 | 69 | 此文档本意中的受众包括计算机系统的系统和平台设备厂商，其中包括客户端、服务器和网络设备制造商。此文档中所包含的安全原则和建议应该能够宽泛地适用于具有可更新的固件的其他类型的系统，包括物联网设备、嵌入式设备和移动设备。这些技术指导意见假设读者拥有平台架构方面的技能，并且主要面向负责在系统和设备中实现固件级安全技术的开发者和工程师。 70 | 71 | ## 商标信息 72 | 73 | 所有产品名称为其对应公司的注册商标或者商标。 74 | 75 | # 执行摘要 76 | 77 | 现代计算系统架构可以从层级上进行思考。顶层是 _软件_，由操作系统和应用程序构成。尽管它们提供了用户所使用的大部分功能能力，它们依赖于底层所提供的功能和服务，此文档总体性地称其为 _平台_。平台包括硬件和固件组件，它们是初始化组件、启动系统以及提供由硬件组件实现的运行时服务所必需的。 78 | 79 | 平台固件及其相关配置数据对于计算系统的可信度至关重要。此固件中的大部分在系统架构中具有高权限，并且由于此固件是系统运行所必需的，维修此固件可能具有挑战性。针对平台固件的成功攻击可以使得系统不可运行，可能是永久性的，或者要求由原始制造商重新编程，造成对用户的重大妨碍。其他高级恶意攻击可能尝试向固件中注入持久的恶意软件、修改关键的低级服务以破坏其运行、窃取数据或者以其他方式影响计算机系统的安全状态。 80 | 81 | 早期的 NIST 出版物应对了针对一种特定类型的平台固件的攻击的威胁：启动固件，通常称为基本输入/输出系统（BIOS）。然而，平台包含众多其他带有固件和配置数据的设备。这些设备，包括存储和网络控制器、图形处理器，以及服务处理器等，同样是高权限的，并且是系统安全和可靠地运行所必需的。 82 | 83 | 此文档提供了那些意在支持平台对抗潜在地具有破坏性的攻击的弹性的技术指导意见。这些指导意见基于以下三个原则： 84 | 85 | * **保护**：这些机制用于保证平台固件代码和关键数据仍然处于具有完整性的状态，并且被保护以防止损坏，诸如用于保证固件更新的合法性和完整性的过程 86 | * **检测**：用于检测平台固件代码和关键数据于何时受到损坏的机制 87 | * **恢复**：这些机制用于将平台固件代码和关键数据恢复至某种具有完整性的状态，如果任何这样的固件代码或者关键数据被检测到发生损坏，或者如果被迫通过某种授权的机制进行恢复。恢复被限制为恢复固件代码和关键数据的能力。 88 | 89 | 这些指导意见的本意是应对个人计算机（PC）客户端、服务器和网络设备中的平台，但是它们应该能够宽泛地适用于其他类型的系统。包括原始设备制造商（OEM）和组件/设备提供商在内的实现者可以利用这些指导意见以便在平台中构建更强的安全机制。系统管理员、安全专业人士和用户可以利用此文档以便为未来的系统指导采购策略和优先级。 90 | 91 | -------------------------------------------------------------------------------- /platform_firmware_security_defense/chapter_2.md: -------------------------------------------------------------------------------- 1 | # 第 2 章 针对固件的威胁 2 | 3 | 对于几乎每一类型的固件，都存在关于概念性的漏洞利用的例证。很多种类的固件漏洞的主动利用已经在公开领域被发现，并且其他一些已经在泄露的文档中被引用。随着固件的复杂度不断增加，可供利用的攻击面也在增大。操作系统尽管广泛存在漏洞，但是它们相对于固件更好地被系统管理员和安全专家所理解和保护。在某些案例中，常规的保护和现存的最佳安全实践仍然不足以对抗固件级别的攻击。 4 | 5 | 在几乎所有基于 Intel/AMD 的现代系统中，UEFI 取代了老旧的 BIOS。尽管曾经有过基于 BIOS 的攻击，它们通常需要一位对于它将要被应用于的目标 BIOS 和系统拥有相对深入的了解的攻击者以汇编语言编写。这种攻击不一定能够在目标系统和任何其他品牌或者型号的系统之间可移植，即使这些系统出自同一制造商。UEFI 是非常标准化的平台，使得众多厂商可以撬动一种称为 Tianocore（[https://tianocore.org](https://tianocore.org)）的强大的开源核心系统，它在很多方面就像一种发展完全的操作系统。数千行代码普遍存在于不同的 UEFI 实现中，其在不同系统之间的主要区别是标准化的模块，它们使用一种通用的 API，这在 UEFI 中称为协议（_protocol_）。可为 UEFI 编写的模块通常是用 C 语言编写的，但是 UEFI 也可支持若干种其他编程语言，包括 Python 甚至 Javascript，因此对于低级汇编语言的编程技能的需求较少。因此 UEFI 相对于 BIOS 呈现了大得多的攻击面。幸运的是，UEFI 经常与某些显著的安全性改进一同被实施，诸如安全启动。但是就像大多数安全性改进那样，诸如安全启动等技术为管理系统增加了额外的工作量，因此它们经常被禁用。 6 | 7 | 尽管 UEFI 是一个完全不同的案例，并且相对于其他系统固件明显更加标准化，某些相同的问题也适用于其他领域。ARM 和其他类似的微处理器的更低的成本、更高的可用性和能力使得对于内建于 PCIe 板卡、硬盘和固态硬盘的控制器而言，利用 C 语言或者更高级的语言进行构建来实现一种接口更加容易，通常也更加廉价。通常，固件可以从操作系统级别进行更新，允许就地修补而非返厂送修（RMA），但也会允许深度植入的恶意软件，始于操作系统级别的攻击。当然，只能由制造商更新的 ROM 并不能保证起到保护作用——由于可能会犯错，诸如将一台笔记本退还给错误的客户，此笔记本拥有诸如 _Computrace_（一种 LoJack 式的固件）这样的机密，对于它所涉及的另一位客户而言。 8 | 9 | 几乎所有固件，包括每一种正在生产中的 UEFI 版本，都包含闭源的已编译代码的二进制 blob，并且供应链上的几乎每一个步骤通常都会向完整的系统中添加额外的二进制 blob。很容易认为一台系统是来自一家特定的制造商的，但是即使它们真正地制造了这台系统，而非只是在其中加入它们的名字，通常也有一长串的原始设计制造商（_ODM_）和独立硬件厂商（_IHV_）位于原始设备制造商（_OEM_）的上游，而这还不算独立组件，诸如网络和硬盘控制器等的制造商。 10 | 11 | 如果您熟悉开源软件对于 bug 和安全透明性的原则，您不会在固件领域看到太多的透明性。带有安全性的启示的 bug 会被持续隐藏长得多的时间，并且恶意软件可以于二进制 blob 被添加的任何阶段被添加进来。 12 | 13 | ## 2.1 固件威胁的类型 14 | 15 | 在固件水平上，有可能执行几乎每一类在更高层级的软件领域可能更加为人们所熟知的攻击。在大多数直接的案例中，那些需要操作系统的恶意软件可以通过受到攻击的固件在操作系统运行时植入操作系统中，或者直接植入非易失性存储设备中。更为隐蔽的是，固件可以完全在操作系统以外运作——在存储设备（硬盘、固态硬盘等）中，固件可以在数据传入/传出存储设备的过程中将其损坏或者窃取，或者在外设中进行操作，在启用摄像头的同时使其指示灯保持为禁用状态。 16 | 17 | 以下所有这些范例，加上每一种额外的普通软件攻击，已经被发现能够影响固件： 18 | 19 | * 竞争条件 20 | * 缓冲区溢出 21 | * 权限提升 22 | * 语法分析错误 23 | * 不当配置 24 | 25 | ### 2.1.1 Intel 分类法 26 | 27 | Intel 于 Black Hat 2017 展示了固件安全话题，并且包括了一个很好的固件 bug 分类法——以及对于 bug 出现几率的评估。 28 | 29 | 尽管这些可以被看作标准软件 bug 的变体，从固件的视角将其考虑为特殊案例是有益的。此列表完全由 Intel 贡献： 30 | 31 | * 不一致的电源状态过渡检查 32 | * 无效的初始化状态（保存于内存中的机密，对于特定系统状态的猜测） 33 | * S3 启动脚本 34 | * 竞争条件 35 | * 启用保护机制（包括禁用/启用特定硬件元素，包括错误的模块启动顺序） 36 | * 检查时间/使用时间（TOCTOU）竞争条件 37 | * 信任输入（来自平台中的较低权限实体，或者拥有由不同威胁向量配置的不同内容） 38 | * 测定失败 39 | * 未能测定某些模块 40 | * 接受经过签名但适用于错误平台的更新，由于它们使用相同密钥 41 | * 在错误的时间接受加载特定模块（此时某些内容未被适当地保护） 42 | * 未能识别某种测定错误/问题 43 | * 平台能力未恰当配置 44 | * 未设置锁、设备未恰当地初始化、特性未被禁用等 45 | * 安全或者有意义的内容暴露给不受信任的实体 46 | * 例如 UEFI 变量 47 | * 硬件不当行为 48 | * 错误定义的架构、微架构、不良设计等 49 | * 平台组件行为与规格说明不符 50 | 51 | 尽管 Intel 在构建此列表时主要考虑的是 UEFI，它可以同等程度地适用于系统上的任何固件。 52 | 53 | ## 2.2 固件威胁案例 54 | 55 | ### 2.2.1 Hacking Team 的 UEFI Rootkit 56 | 57 | UEFI 极其强大。与 BIOS 相比，UEFI 拥有众多新增特性并且可扩展，这带来了相对于老旧的 BIOS 和小型启动固件大得多的攻击面。Hacking Team 在其文档于 2015 年被泄露时被发现拥有一种行之有效的攻击方法。Hacking Team 的攻击方法对于 Insyde 的 UEFI 实现是有效的，并且被发现需要对于目标机器的物理访问以启动进入 UEFI shell 并且加载攻击代码。此代码只是简单地注入（或者重新注入，如果需要）基于微软 Windows 的恶意软件，因此它对于非 Windows 操作系统不会奏效。然而，有证据显示 Hacking Team 曾经对攻击失败的案例提供支持，例如对于非 Insyde 实现的 UEFI。将其攻击代码移植到另一种 UEFI 实现对于 Hacking Team 这样的对手而言是一件相对简单的事情。如有必要，远程安装恶意软件可能也比较简单，这可能需要重启进入 UEFI shell，它有可能是由另一款恶意软件以 UEFI 更新的形式在操作系统内安装的。这种类型的攻击的主要目标是保证持续性，即使是在重新安装了操作系统的情况下。 58 | 59 | ### 2.2.2 BadUSB 60 | 61 | 通过 USB 的最明显的攻击方式就是一块带有自动运行文件或者其他恶意软件的闪存盘。当该文件被自动执行或者由用户打开时，该恶意软件便在应用程序层级上被植入操作系统。尽管更加复杂以及更具挑战性，存在多种从 USB 设备发动固件攻击的方式，考虑到对于攻击者而言，创建他们自己的驱动程序以骗过计算机有关该 USB 设备的功能的难易程度。诸如 Hak5 USB Rubber Ducky 这样的设备对于攻击者来说容易获得。 62 | 63 | 针对 USB 固件的攻击于 2014 年被展示，它们针对使用 Phison 控制器的设备。攻击者可以修改一块 USB 存储设备以使其如同一块 HID（键盘、鼠标等输入设备）那样运作，或者在该存储设备内部创建隐藏分区。这种攻击专用于 Phison 控制器，并且将会需要一位具有相似水平的技能的攻击者以构建一次针对其他 USB 设备的自定义攻击。 64 | 65 | ### 2.2.3 PCIe 和雷电的 DMA 攻击 66 | 67 | 将 PCIe 总线暴露给外部设备为具有物理访问的攻击者创造了一个新的攻击向量。一种专为此种类型的攻击而设计的通用设备称为 PCI Leech。当其被插入 PCIe 总线时，可以通过 DMA 直接从系统内存中窃取数据，或者修改该内存的内容以安插恶意软件。针对 Mac 的 Thunderstrike 攻击将会感染 PCIe 选项 ROM（_PCIe option ROM_）——存在于众多 PCIe 设备中的一块固件 blob。利用 Thunderstrike，攻击者可以感染一块特定的雷电设备，然后每当该设备被使用在一台新的系统上时，它将会感染新的宿主系统。 68 | 69 | ### 2.2.4 Equation Group 的硬盘固件攻击 70 | 71 | 将恶意软件安插到硬盘控制器的固件本身将会允许攻击者跳过磁盘加密，以及在磁盘或者固态硬盘读写数据时实时读取或者损坏数据。此技术也可用于注入操作系统层级的恶意软件，通过简单地感染一块可执行的在线磁盘。Equation Group 被发现曾经使用过此种攻击。 72 | 73 | -------------------------------------------------------------------------------- /nist_sp_800-125a/front_matter.md: -------------------------------------------------------------------------------- 1 | # NIST 特别出版 800-125A 修订版本 1 2 | 3 | # 基于服务器的虚拟机监视器平台的安全性建议 4 | 5 | Ramaswamy Chandramouli 著 6 | 7 | 计算机安全分部，信息科技实验室 8 | 9 | 此出版物可从此处免费获得： 10 | 11 | [https://doi.org/10.6028/NIST.SP.800-125Ar1](https://doi.org/10.6028/NIST.SP.800-125Ar1) 12 | 13 | 2018 年六月 14 | 15 | 美国商务部 秘书 Wilbur L. Ross, Jr. 16 | 17 | 美国国家标准技术研究所 NIST 主任和标准技术商务次长 Walter Copan 18 | 19 | ## 权力范围 20 | 21 | 此出版物由 NIST 开发以符合其在 2014 年的美国联邦信息安全现代化法案（FISMA），美国法典第 44 章 3551 节及其下的内容，公法（P.L.）113-283。NIST 负责为联邦信息系统开发信息安全标准和指南，但是这些标准和指南不应该被应用于国家安全系统，如果没有对这些系统行使政策权力的适当的联邦官员的明确许可。此指南同美国行政管理和预算局（OMB）公告 A-130 的要求相一致。 22 | 23 | 此出版物中的任何内容都不应该被用于否认由美国商务部秘书在法定权力下规定的对于联邦政府机构具有强制性和法律约束力的标准和指导意见。这些指导意见也不应该被解读为更改或者取代商务部秘书、行政管理和预算局主任，或是任何其他联邦官员的现有权力。此出版物可以在自愿的基础上被非政府组织使用，并且不受美国版权的限制。但是 NIST 要求署名权。 24 | 25 | 美国国家标准技术研究所特别出版 800-125A 修订版本 1 26 | 27 | Natl. Inst. Stand. Technol. Spec. Publ. 800-125A Rev. 1，38 页（2018 年六月） 28 | 29 | [https://doi.org/10.6028/NIST.SP.800-125Ar1](https://doi.org/10.6028/NIST.SP.800-125Ar1) 30 | 31 | CODEN：NSPUE2 32 | 33 | > 此文档中可能会提到某些商业实体、设备或者器材以便充分地描述某种试验程序或者概念。这样的提名的本意并非暗示 NIST 对其的推荐或认可，也非暗示这些实体、器材或者设备一定是可用于该目的之最好的。 34 | 35 | > 此文档中可能会有对于 NIST 的当前正在开发中的其他出版物的引用，以便符合其被赋予的法定责任。此出版物中的信息，包括概念和方法论，可以被联邦政府机构使用，即使是在这些附带的出版物完成之前。因此，直到每部出版物完成之前，当前的要求、指导意见和过程在其所存在之处仍然有效。关于计划和迁移的目的，联邦政府机构可能想要紧密跟踪由 NIST 提供的这些新出版物的进展。 36 | 37 | > 我们鼓励组织机构在公开评论期间审阅所有出版物草案，并且向 NIST 提供反馈。除了上述出版物以外，NIST 的众多计算机安全出版物可以从 [https://csrc.nist.gov/publications](https://csrc.nist.gov/publications) 获取。 38 | 39 | 关于此出版物的评论可以被提交至： 40 | 41 | 美国国家标准技术研究所 42 | 43 | 收件人：计算机安全分部，信息科技实验室，办事处大道 100 号（8930 邮递点），盖瑟斯堡，马里兰州 20899-8930 44 | 45 | 邮件：[sp800-125A-comments@nist.gov](mailto:sp800-125A-comments@nist.gov) 46 | 47 | 所有评论必须在美国信息自由法（FOIA）条款下发布。 48 | 49 | ## 计算机系统技术报告 50 | 51 | 位于美国国家标准技术研究所（NIST）的信息科技实验室（ITL）通过为国家的测定和标准基础设施提供技术领导来提升美国经济和公众福利。ITL 通过开发测试、测试方法、参考数据、概念实现的证明以及技术分析来推进信息科技的发展及其生产性的使用。ITL 的职责包括为联邦信息系统中的国家安全相关信息以外的成本高效的安全性和隐私性开发管理、行政、技术和物理方面的标准和指导意见。此特别出版 800 系列报导了 ITL 的研究、指导意见及其在信息系统安全领域的延伸努力，以及与行业、政府和学术组织之间的合作活动。 52 | 53 | ## 摘要 54 | 55 | 虚拟机监视器平台是一系列提供了硬件资源（诸如 CPU、内存、网络和存储等）虚拟化的软件模块的集合，并且因此允许称为虚拟机（VM）的多个计算栈（由操作系统（OS）和应用程序构成）运行在单一物理宿主上。此外，它还可能拥有在单一物理宿主内部定义网络（称为虚拟网络）的功能，以允许驻留在该宿主上的虚拟机之间以及该宿主外部的物理和虚拟机之间的通讯。由于有了全部这些功能，虚拟机监视器负有责任以调度对于物理资源的访问、在驻留的虚拟机之间提供运行时隔离，以及启用虚拟网络，该虚拟网络在虚拟机之间以及虚拟机和外部网络之间提供保持安全性的通讯流。虚拟机监视器的架构可以以不同方式进行分类。此文档中的安全性建议是关于保证虚拟机监视器的基线功能的安全执行的，并且因此对于虚拟机监视器的架构不可知。更进一步地，这些建议适用于针对服务器虚拟化而部署的虚拟机监视器的上下文环境，因此并不适用于其他应用案例，诸如嵌入式系统和桌面。关于虚拟网络的安全配置的建议在另一篇 NIST 文档中解决（特别出版 800-125B）。 56 | 57 | ## 关键字 58 | 59 | 虚拟化；虚拟机监视器；虚拟机；虚拟网络；安全配置；安全性监视；客户操作系统 60 | 61 | ## 致谢 62 | 63 | 作者 Ramaswamy Chandramouli 想要感谢他的同事 Tim Grance，由于他个人对内容的贡献以及对于此出版物的组织工作的帮助。特别感谢来自 Bosch Center of Competence Security 的 Andreas Bartelt，由于他对于关于设备虚拟化技术的宝贵贡献。作者还想感谢 Michael Bartock，由于他作为分部读者的宝贵审阅和反馈。最后，同样重要的是，作者感谢 Isabel van Wyk，由于她的详细的编辑审阅。 64 | 65 | ## 对审稿人的注记 66 | 67 | 此修订版本包括用于设备虚拟化的额外技术，诸如准虚拟化、透传和自虚拟化的硬件设备等，以及相关的安全性建议。此修订版本中的主要内容更改位于第 1.1、2.2.2 节和第 5 章。 68 | 69 | # 执行摘要 70 | 71 | 服务器虚拟化现在是用于数据中心和云服务中的企业级信息科技（IT）基础设施的一种已经确立的技术，由于它能够提供对于硬件资源的更佳利用，减少所需的物理空间，并且减少能耗和管理开销。用于服务器虚拟化的核心软件称为虚拟机监视器，它直接提供中央处理器（CPU）和内存的虚拟化。同它的支持模块一起，它允许所有硬件资源（例如 CPU、内存、网络和存储等）的虚拟化，并且因此允许多个称为虚拟机（VM）或者客户机的计算栈，其中每一个都托管操作系统（OS）（客户机 OS）和应用程序，运行在单一的物理宿主上。此物理宿主称为虚拟化宿主或者虚拟机监视器宿主。由于虚拟机监视器就其自身而言不能提供服务器虚拟化所需的所有功能，它拥有用于设备（例如网络和存储设备）虚拟化的软件模块（例如设备驱动程序），以及用于虚拟机生命周期操作和虚拟机监视器配置的管理模块。虚拟机监视器与这些支持模块以及宿主硬件一起构成了虚拟机监视器平台。虚拟机监视器可以直接安装在硬件或者裸机上（第 1 类虚拟机监视器），也可以安装在称为宿主操作系统的完整的传统操作系统上（第 2 类虚拟机监视器）。 72 | 73 | 初看起来，与虚拟机监视器及其硬件宿主（共同称为虚拟机监视器平台）的安全管理相关的所有活动可能看起来应该只是包含任何服务器级别的软件及其托管环境的已确立的最先进的技术实践。然而，仔细检查一下就会发现，用于支持虚拟机监视器所提供的硬件虚拟化的功能具有广泛的安全性后果，并且因此需要一组基于针对这些功能的安全执行的威胁的分析的目标明确的安全性建议。 74 | 75 | 由于存在多种方式对虚拟机监视器架构进行分类，此文档中所采用的方式是识别虚拟机监视器所执行的基线功能、每一项基线功能所涉及的任务、该任务的安全执行的潜在威胁，以及以安全性建议的形式给出的，能够提供担保以对抗利用这些威胁的反制措施。 76 | 77 | 以下 5 种功能被识别为虚拟机监视器平台的基线功能： 78 | 79 | * VM 进程隔离 80 | * 设备调度和访问控制 81 | * 来自客户 VM 的命令的直接执行 82 | * VM 生命周期管理 83 | * 虚拟机监视器平台的管理 84 | 85 | 除了为保证上述基线功能的安全执行提供安全性建议以外，此文档还提供了关于保证虚拟机监视器平台的所有组件的整体完整性的建议。这些建议涵盖了第 1 类和第 2 类虚拟机监视器。 86 | 87 | 此文档并未涵盖用于虚拟机监视器所安装在其上的物理宿主的程式化管理功能的安全执行。用于反制物理访问威胁以及用于运行在 VM 上的客户 OS 和应用程序的保护要求及其相关联的安全性建议同样超出了此文档的范围。更进一步地，这些安全性建议适用于针对服务器虚拟化而部署的虚拟机监视器，并且并不涵盖其他应用案例，诸如面向桌面和嵌入式系统的虚拟机监视器应用。 88 | 89 | -------------------------------------------------------------------------------- /nist_ir_8176/appendix.md: -------------------------------------------------------------------------------- 1 | # 附录 A——首字母缩略词 2 | 3 | 此论文中使用的部分选定的首字母缩略词和缩略语定义如下： 4 | 5 | * EPC：enclave 页缓存 6 | * IPC：进程间通信 7 | * MEE：内存加密引擎 8 | * NAT：网络地址转换 9 | * PID：进程 ID 10 | * PKI：公钥基础设施 11 | * SGX：Software Guard eXtensions 12 | * TPM：可信平台模块 13 | * UDP：用户数据报协议 14 | * UTS：Unix 分时系统 15 | * VM：虚拟机 16 | * VNI：虚拟网络接口 17 | 18 | # 附录 B——参考文献 19 | 20 | * \[1\] NIST Special Publication (SP) 800-190, _Application Container Security Guide_, National Institute of Standards and Technology, Gaithersburg, Maryland, September 2017. [https://doi.org/10.6028/NIST.SP.800-190](https://doi.org/10.6028/NIST.SP.800-190). 21 | * \[2\] W. Felter, A. Ferreira, R. Rajamony, and J. Rubio, _An Updated Performance Comparison of Virtual Machines and Linux Containers_, IBM Research Report, RC25482 (AUS1407-001), July 21, 2014. [https://domino.research.ibm.com/library/cyberdig.nsf/papers/0929052195DD819C85257D2300681E7B/$File/rc25482.pdf](https://domino.research.ibm.com/library/cyberdig.nsf/papers/0929052195DD819C85257D2300681E7B/$File/rc25482.pdf). 22 | * \[3\] Cloud Standards Customer Council, _Practical Guide to Platform-as-a-Service, Version 1.0_, September 2015. [http://www.cloud-council.org/deliverables/CSCC-Practical-Guide-to-PaaS.pdf](http://www.cloud-council.org/deliverables/CSCC-Practical-Guide-to-PaaS.pdf). 23 | * \[4\] E. Reshetova, J. Karhunen, T. Nyman, and N. Asokan, _Security of OS-level virtualization technologies_, Cornell University Library, July 16, 2014. [https://arxiv.org/abs/1407.4245](https://arxiv.org/abs/1407.4245). 24 | * \[5\] T. Combe, A.Martin, and R. Pietro, “To Docker or Not to Docker: A Security Perspective,” _IEEE Computer_ 3(5), September-October 2016, pp. 54-62. [https://doi.org/10.1109/MCC.2016.100](https://doi.org/10.1109/MCC.2016.100). 25 | * \[6\] A. Mouat, _Docker Security_, O’Reilly Media, 2015. 26 | * \[7\] S. Hosseinzadeh, S. Laurén , and V. Leppänen, “Security in container-based Virtualization through vTPM,” _Proceedings of IEEE/ACM 9th International Conference on Utility and Cloud Computing_, Shanghai, China, December 2016, pp. 214-219. [https://doi.org/10.1145/2996890.3009903](https://doi.org/10.1145/2996890.3009903). 27 | * \[8\] S. Arnautov, B. Trach, F. Gregor, T. Knauth, A. Martin, C. Priebe, J. Lind, D. Muthukumaran, D. O’Keeffe, M. L. Stillwell, D. Goltzsche, D. Eyers, R. Kapitza, P. Pietzuch, and C. Fetzer, “SCONE: Secure Linux Containers with Intel SGX,” _Proceedings of the 12th USENIX Symposium on Operating Systems Design and Implementation (OSDI ’16)_, Savannah, Georgia, United States, November 2–4, 2016. [https://www.usenix.org/system/files/conference/osdi16/osdi16-arnautov.pdf](https://www.usenix.org/system/files/conference/osdi16/osdi16-arnautov.pdf). 28 | * \[9\] grsecurity, [https://grsecurity.net/features.php](https://grsecurity.net/features.php) 29 | * \[10\] _Home Page of The PaX Team_ \[Web site\], [https://pax.grsecurity.net/](https://pax.grsecurity.net/) 30 | * \[11\] A. Grattafiori, _Understanding and Hardening Linux Containers – Version 1.1_, NCC Group Whitepaper, June 29, 2016. [https://www.nccgroup.trust/us/our-research/understanding-and-hardening-linux-containers/](https://www.nccgroup.trust/us/our-research/understanding-and-hardening-linux-containers/). 31 | * \[12\] N. Kratzke, “About Microservices, Containers and their Underestimated Impact on Network Performance,” _CLOUD COMPUTING 2015: The Sixth International Conference on Cloud Computing, GRIDs, and Virtualization_, Nice, France, 2015, pp. 165-169. [https://doi.org/10.13140/RG.2.1.2039.3046](https://doi.org/10.13140/RG.2.1.2039.3046). 32 | * \[13\] Linux Containers, _LxC project_, [https://linuxcontainers.org/lxc/introduction/](https://linuxcontainers.org/lxc/introduction/). 33 | * \[14\] B. Kirsch, _What to choose from the top orchestration software on the market_, January 2017. [http://searchitoperations.techtarget.com/feature/What-to-choose-from-the-top-orchestration-software-on-the-market](http://searchitoperations.techtarget.com/feature/What-to-choose-from-the-top-orchestration-software-on-the-market). 34 | * \[15\] K. Cook, _Using Simple Seccomp filters_, November 2012. [https://outflux.net/teach-seccomp/](https://outflux.net/teach-seccomp/) 35 | 36 | -------------------------------------------------------------------------------- /nist_ir_8151/chapter_1.md: -------------------------------------------------------------------------------- 1 | # 第 1 章 简介 2 | 3 | 对于显著减少软件漏洞的诉求正在发出自众多来源，包括 2016 年二月发布的美国联邦网络安全研发战略计划 \[FCRDSP16\]。此计划以描述众所周知的危险性开始：当前的系统正在执行着越来越关键的任务，并且其存在漏洞这一点广为人知。这些漏洞通常不易发现并且难于修复。网络安全并未跟上步伐，并且所需的步伐正在快速加速。此计划定义了近期、中期和长期的目标。此报告解决的是首个中期目标： 4 | 5 | > _取得 S&T \[科技\] 进展以逆转对手的非对称优势，通过开发和运行具有可持续的安全性的系统……这一目标是双管齐下的：首先是对于恶意网络活动（例如普遍存在的软件缺陷所引起的众多漏洞）具有高度抵抗力的软件、固件和硬件的设计和实现……_ 6 | 7 | “漏洞”一词具有众多不同的定义，它们覆盖了不同的概念的组合，包括知识、攻击、可利用性、风险、意图、威胁、范围，以及引入的时间等。出于此报告的目的，我们将 _漏洞_ 定义为可以被无意或者有意利用，并且导致对于理想的系统属性的侵犯的一个或者更多弱点。弱点是指系统的要求、设计或者实现中的不理想的特性 \[Black11a\]。这一定义排除了： 8 | 9 | * 手动配置或者操作的错误，诸如将某个程序安装为世界可读取，或者为管理员访问设置平凡的口令 10 | * 局中人的不法行为，诸如 Edward Snowden 的秘密潜出 11 | * 功能 bug，诸如混淆 SI（国际单位制）和英制单位，这导致了 1999 年的火星气候探测者号失事 \[Oberg99\] 12 | * 在常规代码中故意引入的恶意软件或者导致损坏的“不良特性”，诸如允许 root 访问，如果用户名是“JoshuaCaleb”，以及 13 | * 作为输入过滤或者其他化解措施的结果而不能（由“局外人”）利用的软件弱点 14 | 15 | 在定义软件漏洞，对其进行分类并且理解它们等方面已经实现了重大跨越。此外，在对软件社区进行关于漏洞、相关的补丁以及底层的弱点的教育中也已经实现了重大跨越。然而，此作品是不充分的。大量漏洞被程式化地发现，众多漏洞多年以来未被发现，并且补丁经常未被应用。很明显，一种不同的方式——依赖于改进软件的方式——是必需的。 16 | 17 | > _强化保护要求增加这样的担保，即人们所开发和部署的产品对于恶意网络活动具有高度抵抗力，由于它们只包含极少的漏洞……_ \[FCRDSP16, p. 17\] 18 | 19 | ## 1.1 报告的范围 20 | 21 | 此报告的目的是呈现一系列特定的技术方式，它们拥有在减少漏洞方面发挥显著作用的潜力——通过在漏洞发生之前阻止它们、在漏洞被利用之前发现它们，或者降低漏洞所造成的影响。 22 | 23 | * “在漏洞发生之前阻止它们”通常包括用于具体说明、设计和构建软件的改进方法 24 | * “发现漏洞”包括更好的测试技术以及对于多种测试方法的更有效的利用 25 | * “降低漏洞的影响”指的是用于构建更具弹性的架构的技术，以使得漏洞不能被用于造成重大伤害 26 | 27 | 此报告并未将这些方法分割为 3 块，由于某些方法可能包括来自多个方面的内容。此报告中的方法列表并不完备，它们的本意是为了展示范围宽泛的方法是如何能够产生某种重大影响的。新的方法将会持续被开发出来并且投入一般应用。 28 | 29 | 用于减少漏洞的方法列表专注于满足以下 3 个判据的方法： 30 | 31 | 1. 显著的影响 32 | 2. 3～7 年的时间框架，以及 33 | 3. 技术活动 34 | 35 | _显著_：这意味着这些方法广泛适用并且能够为将漏洞减少两个数量级这一目标作出重大贡献。在常规软件的情况下，这一数值的估计高达每 1000 行代码中包含 25 处错误 \[McConnell04, p. 521\]。将近 2/3 的漏洞来源于简单的编程错误 \[Heffley04\]。这些方法被选择以实现这样一种可能性，即增强将此类软件代码控制在每 100000 行包含 25 个错误以内这一雄心壮志，并且实现其他类别的软件中的相应的错误减少率。（在当今的航空航天行业，接近零错误的系统被程式化地制造出来，但是其成本数倍于常规软件。）要想确定某种方式是否能够带来显著的影响，需要有能力以测定它。测定软件质量是一项困难的任务。关于改进软件漏洞测定方法的并行努力正在进行中。 36 | 37 | _3～7 年的时间框架_：之所以选择这一时间框架，是由于它足够长远，以允许作出显著改变，基于那些并未达到实现其影响的全部潜力的程度的现存技术。这是一个可以合理地思考的时间框架。如果超过了这一时间框架，要想预测哪些新技术将会被开发出来，并且潜在地对于信息科技将会被如何使用这一点作出其自身的一套显著的改变，这件事过于困难。在不远的未来，强调的重点将会是实施那些已经部署的技术，诸如在安全的软件开发和测试中的工作。已经部署的技术和未来的技术之间的分界线并不脆弱。如果某项技术被广泛应用，或者被主要的软件开发者所使用，它并未被包括进来，尽管此技术的更加广泛的采用将会是有益的。 38 | 39 | _技术性_：有众多不同类型的方式以减少软件漏洞，它们中的很多主要来说并非技术性的——从帮助用户有意义地请求得到安全性，到资助研究和运行活动以及训练设计、构建、测试和使用软件的所有这些相关方。在此报告的开发过程中，很多理念被推进到这步阔步跨越以外。此报告只是应对了技术性的方法，以获得可管理的范围，这一范围构建于开发此报告期间的可用专业技能之上。这些其他领域也很重要。 40 | 41 | 在此报告的草案阶段，众多不在此报告的范围之内的优秀想法被提了出来，并且在第 4 章总结出来。这些活动的范例包括： 42 | 43 | * 改进的资助 44 | * 改进教育 45 | * 对于对软件的理解的不同方面的更多研究 46 | * 对于大规模挑战和竞争的增加利用 47 | * 为软件消费者提供更好的方法以对低漏洞的软件进行请求和评估 48 | * 责任和标准，以及 49 | * 威胁分析 50 | 51 | 此报告排除了一段关于硬件漏洞的讨论。这并不是说它并不重要。这些内容可以在另一篇报告中解决。此报告针对范围宽泛的软件，包括政府合同软件、私有和开源软件。它覆盖了用于通用目的、移动设备以及嵌入在家电和设备中的软件。其目的是防止新代码中的漏洞，以及识别并修补现存代码中的漏洞。 52 | 53 | ## 1.2 发现 54 | 55 | 尽管减少软件漏洞是一个困难的问题，并且很明显地需要技术、操作、管理、心理和文化等方面的改变相配合才能解决此问题，想要引起显著的改变仍然是可能的。此报告描述了 5 种中期方法，它们拥有潜力以解决此问题的技术方面。此处所包括的方式并非一个完整的列表；它们代表了范围宽泛的潜在方法，并且强调了减少软件漏洞可以如何实现。所有这些方法将会要求改进的研究基础设施，包括显著改良的度量方法。如同注释的那样，它们就其自身而言不能取得成功，并且需要被整合到更大的软件开发者和用户社区之中。更进一步地，此报告并不专注于已经投入大规模使用的安全的软件开发的当前趋势。 56 | 57 | ## 1.3 受众 58 | 59 | 此报告的主要受众是美国白宫科技政策办公室（OSTP）。可以预期的是，其他政策实体、资金提供者和研究人员也会发现此报告有用，由于他们将会考虑投资和项目以改进软件质量。由于此报告专注于 3～7 年的时间框架，它的本意并非作为软件开发者的指南。 60 | 61 | ## 1.4 措施 62 | 63 | 有多种努力以定义软件漏洞、它们的流行度、它们的可检测性，以及检测和化解技术的效率。测定软件的能力可以在显著减少软件漏洞中发挥重要作用。业界要求关于这样的漏洞的严重程度的证据，以及关于确定哪些技术对于开发具有显著减少的漏洞的软件最为有效的知识。有了可以发挥市场信号作用的有效措施，业界就可以倾向于并且选择低漏洞的软件，并且因此鼓励更好的软件的开发 \[Grigg08\]。更进一步地，以及更加关键的是，业界要求关于识别在代码中部署化解措施或者其他行为的最佳位置的指导。这些证据来自于在最宽泛的意义上测定或者评估软件的属性。 64 | 65 | 66 | ## 1.5 方法论 67 | 68 | 为了编纂这些方法的列表，科技政策办公室（OSTP）请求 NIST 领导一支基于社区的力量。此报告的开发历时 8 个月，鉴于时间框架的压缩，此报告的关注焦点被限制为上述判据，以强调出有前途的方法，而非进行一整套分析。NIST 咨询了来自下列软件担保社区的多位专家： 69 | 70 | * 两次由 OSTP 组织的跨部门圆桌会议 71 | * 软件和供应链担保（SSCA）夏季论坛中的半天时间的议程 72 | * 关于减少安全漏洞的软件措施和度量的全天研讨会 73 | * 关于减少软件缺陷和漏洞的两天时间的研讨会，此研讨会由网络和信息科技研发（NITRD）计划中的软件生产力、可持续性和质量（SPSQ）工作组组织，以及 74 | * 2016 年十月 4～18 日的公开评论 75 | 76 | ## 1.6 报告的组织 77 | 78 | 此报告被组织为两个主要章节。第一个主要章节是第 2 章，它枚举了技术方法，以及第二个主要章节，第 3 章，它解决了相关措施。 79 | 80 | 第 2 章分为关于应对软件中的漏洞的各个技术方法的小节。这些小节包括形式化方法，诸如可靠的静态程序分析、模型检查器以及布尔可满足性问题（SAT）求解器。它还建议拥有经过验证的工具和代码的目录。这一章解决了系统层级的安全性，包括操作系统容器和微服务。附加软件分析技术也得到了解决。最后，它讨论了移动目标防御（MTD）和自动软件多样性。这些包括编译时技术、系统或者网络技术，以及操作系统技术。 81 | 82 | 每个小节遵循相同的格式： 83 | 84 | * 定义和背景：对此领域及其背景的定义 85 | * 成熟度级别：此领域有多么成熟，包括关于此方法已经被应用于“真实世界”还是仅存于实验室中的讨论，以及与可放大性和可用性相关联的话题 86 | * 可信度的基础：关于为何此方法能够发挥作用的理论基础 87 | * 潜在影响的理论基础，以及 88 | * 延伸阅读，包括论文和其他素材 89 | 90 | 第 3 章覆盖了软件措施，它被设计为鼓励采用测定和工具以解决软件中的漏洞。它解决了产品措施以及如何开发更好的代码。它也解决了关于软件安全性和质量措施的关键性的问题。 91 | 92 | 在这两个主要章节之后是第 4 章，关于跨领域的问题，诸如雇佣研究社区、教育以及载体以使得这些技术方法能够转化为一般应用，以及第 5 章中的参考文献。 93 | 94 | -------------------------------------------------------------------------------- /nist_sp_800-147b/chapter_2.md: -------------------------------------------------------------------------------- 1 | # 第 2 章 背景 2 | 3 | 本章提供了关于系统 BIOS 和服务器架构类型的背景信息。它标识出了用于更新系统 BIOS 的主要方法，还讨论了系统 BIOS 的安全问题和威胁。最后，本章讨论了更新可信根的组件。 4 | 5 | ## 2.1 系统 BIOS 6 | 7 | 系统 BIOS 完全由那些可以被嵌入平台的硅基组件，例如处理器中的特定配置和安全代码组成。它是当计算机加电时在其主中央处理器（CPU）上所执行的首个软件。尽管系统 BIOS 最初负责为操作系统提供硬件访问，它在现代设备上的主要作用是初始化并且测试硬件以及加载操作系统。此外，BIOS 加载并初始化重要的系统管理功能，诸如电源和散热管理。系统 BIOS 还可以在启动过程中加载 CPU 微码补丁。 8 | 9 | 有若干种不同类型的系统 BIOS 固件。某些计算机使用 16 位的传统 BIOS，而众多较新的系统使用基于 UEFI 规范 \[UEFI\] 启动固件，或者使用其他自定义的启动固件。在此文档中，我们将所有类型的启动固件称为 BIOS 固件、系统 BIOS 或者简称为 BIOS。如有必要，我们将会这样将传统 BIOS 固件同 UEFI 固件区分开来，即分别称其为传统 BIOS 和 UEFI BIOS。 10 | 11 | 系统 BIOS 通常由服务器的原始设备制造商（OEM）开发。制造商频繁更新系统固件以修复 bug、为漏洞打补丁，以及支持新硬件。系统 BIOS 通常存储于电可擦除可编程只读存储器（EEPROM）或者其他类型的闪存存储器中。通常，系统 BIOS 固件由一种对于 BIOS 所存储于其中的非易失性存储组件具有特别知识的工具来更新。此工具可以运行在服务器本身的 CPU 之一上，也可以运行在服务器机箱内的一块管理服务器上。 12 | 13 | 一台给定的计算机系统可能在若干不同位置上拥有 BIOS。除了主板以外，BIOS 也可以在硬盘控制器、显卡、网卡及其他扩展卡上找到。这些额外的固件通常采用 Option ROM 的形式（包括传统 BIOS 和/或 UEFI 驱动程序）。它们在启动过程中由系统固件加载，并且在宿主 CPU 上执行。Option ROM 不应与设备固件相混淆；服务器中有众多带有运行其自身固件的微控制器的系统设备。 14 | 15 | 此文档中的指导意见适用于存储在 BIOS 闪存存储器中的 BIOS 固件，包括 BIOS 代码、作为更新可信根的一部分的密码学密钥，以及静态 BIOS 数据。与系统 BIOS 固件一同存储并且以相同机制更新的 Option ROM 出于此文档的目的也被看作 BIOS 的一部分。然而，这些指导意见并不适用于存储于服务器的其他位置，诸如一块扩展卡上的 Option ROM 及其他设备固件。 16 | 17 | 如需获得关于系统 BIOS 基础的更多信息，查阅 NIST SP800-147 第 2 章。 18 | 19 | ## 2.2 服务器架构 20 | 21 | 在本节中，我们将服务器分为三类：基本服务器、受管理的服务器和刀片服务器。此处所作出的区分必须与更新系统 BIOS 所采用的机制相关。 22 | 23 | **基本服务器**在架构上类似于拥有单一 BIOS 更新机制的客户端 PC 系统。为基本服务器保护 BIOS 更新的要求可以通过符合列出于此文档或者 NIST SP800-147 第 3.1 节的要求而被满足。通常，基本服务器上的更新可信根（RTU）是系统 BIOS 的一部分（参见 2.5 节以获得关于 RTU 的更多信息）。 24 | 25 | **受管理的服务器**是拥有用于设备维护和额外服务器管理特性的专用通道的计算机系统。除了宿主处理器外，受管理的服务器可能拥有能够进行系统管理，可能包括 BIOS 更新的服务处理器（见下文）。防止在服务处理器上执行恶意或者损坏的代码至关重要，由于它对于服务器的其他操作方面拥有直接控制权。作为一种潜在的 BIOS 更新机制，执行于服务处理器上的代码可能包含 RTU 并且必须被保护起来以防止非授权的修改。 26 | 27 | **刀片服务器**是一种专用的服务器硬件平台设计，它被配置为可安装于机架系统中的机箱/机柜中的可装配设备。这些平台通常拥有共享的电源和冷却系统以及共享的管理接口。刀片可以在一个机箱/机柜/机架内作为一排服务器自主地运作，或者由中央总线管理器控制。这种系统配置也可能拥有多种途径以更新用于运行独立刀片的 BIOS。从 BIOS 更新的视角来看，刀片服务器通常类似于受管理的服务器。业界也会使用多节点（或者模块化）服务器这一词语，它们拥有和刀片服务器相同的 BIOS 保护要求。 28 | 29 | 不同的服务器架构差别巨大，尽管大多数服务器适合于归入上述类别之一，在某些情况下，可能难于将一台服务器严格归类为属于上述类别之一。这些类别被作为范例而提供，以帮助澄清要求。然而此文档中的安全指导意见的本意是对任意类型的服务器拥有宽泛的可适用性。 30 | 31 | 一台服务器可能拥有一块服务处理器，有时称为基板管理控制器，这是一种专用的微控制器。服务处理器通常是一块特别的扩展卡，或者嵌入于服务器主板之上。服务处理器微控制器运行一种专用的操作系统，通常存储于闪存存储器中，并且为管理员提供接口以管理宿主服务器。服务处理器通常是现代服务器中的高权限组件，通常能够更新系统上的固件和软件、更改配置设置，以及读取系统内存。此文档假设管理员将会实施适当的计算机、网络和物理安全性控制以化解对于服务处理器的特有威胁。例如，管理员通常通过网络接口与服务处理器进行交互。最佳安全实践表明，服务处理器应该处于只能由系统管理员访问的私有局域网中。 32 | 33 | 服务处理器负责执行不同功能，取决于系统实现。服务处理器通常将会监视服务器中的不同传感器，例如用于散热和电源管理的温度和电源传感器。它可能会为管理员提供某种机制以更新服务器和宿主操作系统中的软件或者固件。维持服务处理器的安全对于维持服务器的完整性和可用性至关重要。参见第 5 章以获得关于服务处理器的安全要求。 34 | 35 | ## 2.3 系统 BIOS 更新机制 36 | 37 | 此出版物中的指导意见的本意是防护 BIOS 更新机制以使得只有合法的、经过授权的 BIOS 镜像被写入 BIOS 闪存存储器。这一过程有时被称为“刷”镜像。尽管客户端系统通常只有一种途径以更新 BIOS，服务器系统可能实施若干种更新机制以允许管理员在不同环境中更新 BIOS。此出版物标识了三种一般类别的认证 BIOS 更新机制。一台服务器通常将会实施这些更新机制中的一种或多种。每种更新机制简略描述如下： 38 | 39 | * **更新机制 1——可于任何时机发生的认证 BIOS 更新**：此更新机制允许 BIOS 闪存存储器被安全地更新，而无论服务器的操作状态。这包括能够在服务器运转时更新 BIOS 闪存而无需重启。此机制必须保护 BIOS 闪存存储器以防止非授权的修改。 40 | * **更新机制 2——重启时的认证 BIOS 更新**：此 BIOS 更新机制允许在服务器运行时期间引发刷新过程，但是对 BIOS 闪存存储器的实际更新直到系统重启时才会发生。与上一种机制类似，此机制必须保护 BIOS 闪存存储器以防止非授权的修改。 41 | * **更新机制 3——运行时的 BIOS 更新和重启时的 BIOS 验证**：利用这种 BIOS 更新机制，BIOS 只有在每次启动时被验证为合法才能被执行。此机制是必需的，如果 BIOS 刷新锁定机制不足以保护运行中的系统的 BIOS 闪存存储器的完整性。如果 BIOS 闪存存储器在启动时被确定为非法，将会引发恢复过程，并且非法 BIOS 不会被执行。 42 | 43 | 此外，某些服务器可能包含一种安全本地更新机制，它可以更新系统 BIOS 而无需使用上文讨论的三种认证更新机制中的任何一种。安全本地更新机制通过要求一位管理员物理存在于服务器面前指导更新来保证 BIOS 更新镜像的合法性和完整性。对物理存在的要求化解了针对系统 BIOS 的远程攻击的风险。 44 | 45 | ## 2.4 针对系统 BIOS 的威胁 46 | 47 | 服务器容易受到和那些对客户端系统构成威胁的相同形式的攻击。在服务器上执行操作系统层级的恶意软件可能先于 BIOS 攻击发生。未经认证为来自可信来源就执行的服务器 BIOS 更新易受攻击。由于服务器可能拥有多种 BIOS 更新机制，每种机制都有存在漏洞的风险。不同更新机制之间的相互作用还可能潜在地引入其他漏洞。 48 | 49 | 服务器中的服务处理器拥有提升的权限以执行系统管理，这可能包括修改 BIOS。尽管服务处理器可能是通过隔离的通讯信道被控制的，对此信道的非授权访问使服务器暴露于重大风险之中。尽管众多安全实践专注于数据网络，在没有为之付出特别努力的情况下，管理网络可能被较少地审查和保护。 50 | 51 | 如果保护不充分，服务器上的 BIOS 镜像备份（通常是为了恢复特性而保留的）容易受到重写攻击，即使主要 BIOS 被保护以防止修改。在成功破坏一份 BIOS 备份之后，对手可以利用其他手段以使得服务器通过受感染的备份镜像重启。 52 | 53 | ## 2.5 更新可信根 54 | 55 | 更新可信根（RTU）是被内在地信任的硬件和固件的组合，它执行安全 BIOS 更新并且维持 BIOS 的完整性。RTU 可能包括验证经过数字签名的 BIOS 镜像、启用或禁用写保护机制、将 BIOS 更新写入到闪存、执行 BIOS 恢复，以及更新 RTU 本身等功能。第 3 章具体说明执行安全 BIOS 更新和维持 BIOS 完整性对于 RTU 的要求。对 RTU 的内在信任是从隔离的执行环境中得到的——最小化破坏 RTU 功能的风险并且因此维持对 RTU 的内在信任。 56 | 57 | RTU 的每种功能组件可以被看作用于该特定功能的可信根： 58 | 59 | * **验证组件**负责验证经过数字签名的 BIOS 镜像以决定是否应该将控制权传递给该镜像。该组件拥有可信执行途径，由于它是从设备的一种已知正确的状态进入的。验证组件可用于将可信执行延伸到未受保护的内存区域中的代码上来。验证组件将会验证 BIOS 镜像，如果验证成功，则将控制权传递给该镜像。如果验证失败，则验证组件返回可信执行环境并且不将控制权传递给该镜像。 60 | * **恢复组件**负责引发系统返回至一种已知正确的状态。 61 | * **完整性组件**负责维护 BIOS 镜像的完整性。这可能包括启用基于硬件和固件的锁定机制以防止对镜像的非授权修改。它也会防止竞争/逻辑条件对 BIOS 镜像进行非授权修改。 62 | * **更新组件**负责执行安全 RTU 更新以及维持 RTU 的完整性。 63 | 64 | -------------------------------------------------------------------------------- /platform_firmware_security_defense/appendix_b-d.md: -------------------------------------------------------------------------------- 1 | # 附录 B 企业平台固件安全指南总结检查列表 2 | 3 | 此部分为关于本书文本和参考资料，特别是对于适用的 NIST 标准的检查列表总结。当您拾起此列表时，您将会在某种程度上贯穿您当前的所有硬件的_硬件生命周期_。我们建议您简单地开始从头实现（策略和程序），并且将此整个列表应用到您的下一批自然发生的硬件采购中来。然后，如果时间允许，为旧硬件贯穿实施此过程，从最为敏感的位置的硬件开始，例如： 4 | 5 | * 官员、财务和法务部门的笔记本 6 | * 符合 _PCI_、_HIPAA_ 等标准的服务器 7 | 8 | 这可能会由于安全性的原因触发某些计划外的采购，然而旧硬件可以在不那么敏感的应用中重复使用。 9 | 10 | --- 11 | 12 | ## 元问题：策略和程序 13 | 14 | * 复查并更新现存的公司安全策略以使其包括固件安全 15 | * 复查并更新现存的公司安全程序以使其包括固件安全 16 | 17 | ## 采购前调研阶段 18 | 19 | 将硬件和固件包含到威胁模型中来。宽泛地考虑固件。一台计算机包含多种固件镜像：微码、多种平台固件镜像（UEFI 或 BIOS、ACPI 等）、每一块适配器板卡上的固件、每一件外设及其适配器线缆中的固件。除了裸机固件以外，虚拟化技术还拥有同样可以受到攻击的虚拟固件驱动程序。虚拟固件存在其自身的一套攻击方式，有些同裸机固件相同，有些是 VMM 实现所特有的，还有些与传统的应用程序层级的攻击相同。除了存储于闪存和 NVRAM 中的固件 blob 以外，UEFI 将固件作为文件存储在基于 FAT 的磁盘分区上，即 EFI 系统分区（ESP），这在不带 ACL 的 FAT 卷上可以潜在地被攻击者编辑。 20 | 21 | 计划采购安全的和可以防护的系统，并且在所有层级上防护整个系统：硬件、固件和软件。阅读整篇指南文档并计划实施。 22 | 23 | 教育技术员工有关固件威胁的内容。为非技术用户防护系统，并且训练他们关于邪恶女仆攻击的内容——特别是对于拥有移动计算设备的用户。 24 | 25 | 将固件添加到硬件生命周期：系统管理员应该整合 NIST 147，它提供了安全固件生命周期，以增强现存的企业硬件生命周期。数字取证与事故响应（DFIR）团队应该扩展他们的检查列表以包括联系固件厂商、OEM 和 IBV。NIST 147 是一个起始点。 26 | 27 | 确保厂商特定固件工具的可获得性，测试并且学习使用它们，包括黄金镜像散列值，以及经过签名的更新。 28 | 29 | 更新对于固件的新闻和培训资源，包括普通的 bug 修复，以及重要安全更新。保证这种覆盖度，以及更新适合于目的。 30 | 31 | 请求来自厂商的安全数据。自行搜索这些数据，例如，获得一台新型号的样机并且确认它通过了 CHIPSEC 安全测试。 32 | 33 | 设置公司策略： 34 | 35 | * 关于所购买的新系统必须拥有的安全特性，例如，安全启动、验证启动、TPMv2、CHIPSEC 测试等 36 | * 拒绝购自灰色市场的硬件 37 | * 关于新系统所必须配置的安全特性 38 | 39 | 考虑当前已部署的系统。它们能否满足目的？是应该加速新硬件的采购呢，还是将旧系统部署到不那么敏感的应用中呢？ 40 | 41 | --- 42 | 43 | ## 供货阶段 44 | 45 | 基于公司的安全策略配置固件安全设置，例如，启用或禁用 VT/TPM/TXT、唤醒特性、固件/BIOS 口令、固件的网络能力、安全启动等。 46 | 47 | 确保所有厂商固件为最新，带有最新的密钥用于任何经过签名的代码。 48 | 49 | 在系统清单中注册终端机身份和 BIOS 完整性信息。 50 | 51 | 在最初的系统采购过程中，制作您自己的平台固件初始黄金镜像，保存该文件作为初始基线以用于将来的比对。如果厂商提供了它们自己的黄金镜像，将您的镜像或者散列值同它们的进行比对。 52 | 53 | 使用内建的硬件/固件安全特性：使用现存的厂商固件安全特性、TPM、UEFI 安全启动、验证启动、测定启动、可信启动、Heads 等。 54 | 55 | 使用经过签名的固件镜像：对于 UEFI，除了安全启动以外，仅使用经过适当签名的固件。理解代码签名过程以及哪里可能存在空当——例如，某些证书被赋予闭源的二进制文件并且不允许源代码审计。 56 | 57 | --- 58 | 59 | ## 操作和维护阶段 60 | 61 | 保持固件为最新：除了操作系统和应用程序外，也进行固件更新，理想情况是通过经过签名的、自动化的机制，例如 Windows Update、Linux _fwupd_（_LVFS_）等。 62 | 63 | 应用来自 [uefi.org](https://uefi.org/) 或者 [microsoft.com](https://www.microsoft.com) 的最新安全启动黑名单密钥数据库。 64 | 65 | 利用散列值验证固件更新。 66 | 67 | 执行周期性的固件安全扫描。下载固件 blob 并且利用散列值检查意外的更改。 68 | 69 | 将 IT 人员同最终用户设备之间的“亲手操作”互动视为运行自动化的固件层级安全测试的机会。 70 | 71 | 监视固件传出/传入的所有网络流量。 72 | 73 | 审计那些建议固件更新的操作系统层级代码。如果正在加固操作系统/应用程序，考虑将执行固件更新的工具限制为只有认证帐户才能访问。 74 | 75 | 在安全事故中，使用传统恶意软件分析技术以查找固件层级的恶意软件，并且添加固件专用工具，诸如 UEFITool、ACPItool 等。 76 | 77 | 在安全事故中，响应措施应当包括重新获取固件镜像以及重新运行固件安全测试（CHIPSEC 等），以便同之前的镜像/结果进行比对。 78 | 79 | 查询供应链中的所有厂商的厂商安全咨询站点以获得关于安全性的建议，以及可供使用的新的检测工具，包括主 CPU、TPM 厂商、操作系统厂商、OEM 以及所有 IHV 等。 80 | 81 | --- 82 | 83 | ### 恢复（事故响应）阶段 84 | 85 | 使用取证工具比较当前的 ROM 镜像和之前的扫描结果以查找更改。 86 | 87 | 重新运行安全测试，同最后一次已知正确的结果进行比对，以查找攻击者留下的记号。例如，SPI 保护曾经被禁用，但是现在被启用了。 88 | 89 | 如果系统被操作系统/应用程序层级的恶意软件攻击，它可能已经更新了固件。验证整个系统，进行固件和操作系统层级的测试。利用固件和操作系统的黄金镜像恢复系统。 90 | 91 | 安全事故之后，事故响应（IR）团队将会需要额外的时间以清除一台系统中的固件层级的恶意软件。在某些情况下，系统可能会变砖并且不能恢复。 92 | 93 | 安全事故之后，IR 团队的事后分析报告应该包含哪些厂商未能提供足够的工具/镜像以用于固件恢复，并且丢弃那些系统，或者将其重新部署到相对次要的应用中。 94 | 95 | --- 96 | 97 | ## 废弃处理阶段 98 | 99 | 废弃处理之前，将固件恢复至出厂状态。废弃处理一台系统之前，除了清除磁盘介质外，将固件重设至一种已知正确的状态，使用厂商的黄金镜像。 100 | 101 | 废弃处理之前，清除固件中的任何 PII。废弃处理一台系统之前，确保存储于固件中的任何 PII、用户认证数据、TPM 机密等都被重置。询问厂商如何恢复任何由固件存储的 PII。 102 | 103 | # 附录 C 作者传记 104 | 105 | ## Paul English 106 | 107 | Paul English 是 PreOS Security Inc. 的首席执行官。Paul 于 1998 年获得伍斯特理工学院的计算机科学学士学位。自 1996 年起，Paul 成为了一名 UNIX 和 Linux 系统管理员并且戴过很多其他 IT 帽子。其后他管理过少数人，而同时仍然偶尔管理服务器。在 2014～2017 年，Paul 曾经是专业系统管理员联盟（[https://lopsa.org](https://lopsa.org)）的一名委员会成员，该组织是一个非盈利性的专业协会，以推动系统管理实践的进步。 108 | 109 | LinkedIn：[https://www.linkedin.com/in/englishpaul/](https://www.linkedin.com/in/englishpaul/) 110 | 111 | Twitter：@[penglish_PreOS](https://twitter.com/penglish_PreOS) 112 | 113 | ## Lee Fisher 114 | 115 | Lee 是 PreOS Security Inc. 的首席技术官。他的 IT 职业生涯始于担任一名 VAX/VMS 和 AT&T Unix 系统管理员，彻夜工作以支持其完成大学学业。Lee 曾在微软的多个系统产品团队度过了多年，包括发布“Debugging Tools for Windows”（新的 Windbg）、“Windows NT HAL Kit”以及“Windows NT IFS Kit”。Lee 和他人共同运营了微软移植实验室（Microsoft Porting Lab），他在此帮助了大多数 OEM 和 IHV 将其驱动程序移植到 Windows NT。Lee 将众多开源项目——诸如 NCSA Mosaic——带到微软总部以帮助它们将其代码移植到 Windows。Lee 在 IT 行业中曾经以多种角色工作，但是更加倾向于使用 C 语言编写安全/系统工具。在创办 PreOS 之前，他正在为少数朋友的公司咨询少数特别的内核驱动程序。 116 | 117 | Lee 曾在几十场会议中做报告，包括 Security BSides Portland '16、LinuxFest NorthWest、ToorCon Seattle 和微软 WinHEC 等。 118 | 119 | Lee 的个人博客可以在这里找到：[https://FirmwareSecurity.com/](https://FirmwareSecurity.com/) 120 | 121 | LinkedIn：[https://www.linkedin.com/in/lee-fisher-b80b14143/](https://www.linkedin.com/in/lee-fisher-b80b14143/) 122 | 123 | Twitter：@[leefisher_PreOS](https://twitter.com/leefisher_PreOS) 124 | 125 | # 附录 D 勘误 126 | 127 | ## 勘误 128 | 129 | ## 改进 130 | 131 | * 更多插图和示意图 132 | * 带有指向所有攻击向量的名称/箭头的主板 133 | * 硬件生命周期流程图 134 | * 增加直接连接 PCI、USB、JTAG 的攻击向量范例 135 | 136 | -------------------------------------------------------------------------------- /nist_sp_800-125a/chapter_6.md: -------------------------------------------------------------------------------- 1 | # 第 6 章 HY-BF4 安全性建议 2 | 3 | ## 6.1 VM 镜像管理 4 | 5 | 由于基于 VM 的软件（例如客户 OS、中间件和应用程序）利用虚拟机监视器软件共享虚拟化的宿主的物理内存，并不令人惊讶的是，VM 是所有指向虚拟机监视器的攻击的最大来源。在操作中的虚拟化环境中，VM 很少是从头构建的，而是从 VM 镜像构建。VM 镜像是用于创建运行着的 VM 版本的模板。某个组织机构可以拥有其自身的判据以便在其 VM 库中对其使用的不同 VM 镜像进行分类。一些常用的判据包括：处理器负载（用于计算密集型应用程序的 VM）；内存负载（用于诸如数据库处理等内存密集型应用程序的 VM）；以及应用程序敏感度（运行使用关键任务数据的关键任务应用程序的 VM）。对于每一种 VM 镜像类型，必须遵循下列实践以保证所得到的运行中的 VM 是安全的： 6 | 7 | * 对于每一种 VM 镜像类型的黄金镜像文档。黄金镜像是由一组与 VM 镜像相关联的配置变量定义的。这些配置变量至少应该包括：客户 OS 厂商、版本、补丁级别、创建日期、vCPU 内核数量，以及内存大小等 8 | * VM 镜像库中的每一个 VM 镜像必须带有与之相关联的数字签名 9 | * 对 VM 镜像库的访问权限必须通过某种强壮的访问控制机制加以控制 10 | * 对存储 VM 镜像的服务器的访问应该拥有安全协议 11 | 12 | 与上述实践相关联的安全性建议如下所述： 13 | 14 | _安全性建议 HY-SR-9_：必须为所有类型的 VM 定义黄金标准，并且不符合此标准的 VM 镜像不应该被允许存储到 VM 镜像服务器或者库中。VM 镜像库中的镜像应该被周期性地扫描以查找过时的 OS 版本和补丁，这可能导致偏离标准 15 | 16 | _安全性建议 HY-SR-10_：存储于镜像服务器中的每一个 VM 镜像应该带有数字签名以作为合法性和完整性的标识，利用可信、强壮的密码学密钥签名 17 | 18 | _安全性建议 HY-SR-11_：向 VM 镜像库中迁入或者从中迁出镜像的许可应该通过某种强壮的访问控制机制强制实施，并且限制在一组授权的管理员中。如果没有访问控制机制，VM 镜像文件应该存储于加密设备中，该设备只能由一组限定的授权管理员利用具有足够复杂度的口令打开或者关闭 19 | 20 | _安全性建议 HY-SR-12_：对存储 VM 镜像的服务器的访问应该总是通过安全协议，诸如传输层安全性协议（TLS） 21 | 22 | ## 6.2 VM 即时迁移 23 | 24 | 即时迁移是一种存在于所有虚拟机监视器中的功能，它允许某个 VM 被从一个虚拟化的宿主上迁移到另一个上，而其上的客户 OS 和应用程序仍然在运行。此功能提供了如下的关键优势：容错性、负载均衡，以及宿主维护、升级和补丁。在即时迁移中，源宿主上的客户 OS 的状态必须被复制到目标宿主上。这要求迁移内存内容、处理器状态、存储（除非两个宿主共享同一存储）以及网络状态 25 | 26 | 大多数虚拟机监视器所采用的最常见的内存迁移技术称为 _预复制_。在此方式中，属于 VM 的内存页被传输到目标宿主，而此 VM 继续在源宿主上运行 \[5\]。在迁移过程中被修改的内存页被再次发送至目标以保证内存一致性。在此阶段中，VM 上的当前正在操作中的所有处理器寄存器的精确状态也被传输过去，并且正在迁移中的 VM 在源宿主上挂起。目标的处理器寄存器被修改以复制源的状态，并且新迁移的 VM 恢复其操作。存储迁移由这样一种特性提供，它允许管理员将 VM 的文件系统从一个存储位置移动到另一个，而没有停机时间。这种存储迁移甚至可以发生在没有 VM 迁移的情况下，例如，某个 VM 可以继续在宿主服务器上运行，与此同时，构成此 VM 的文件在存储阵列或者逻辑单元号（LUN）之间移动。 27 | 28 | 在上述过程中，内存和处理器状态迁移功能是虚拟机监视器设计的内在方面，而存储迁移功能是存储管理的组成部分，并且适用于虚拟化和非虚拟化的基础设施。网络状态在 VM 迁移之后得以维持，由于每个 VM 带有其自身的独特 MAC 地址，并且迁移过程为迁移目标施加了某些限制（例如源和目标宿主应该位于相同的 VLAN 中）。因此，从安全维护的角度来看，唯一需要考虑的方面就是迁移过程的适当认证和安全的网络路径。 29 | 30 | _安全性建议 HY-SR-13_：在 VM 即时迁移过程中，必须使用安全认证协议；执行迁移操作的管理员的凭证只被传输至目标宿主；内存内容和处理器状态的迁移通过安全网络连接进行；并且一个专用虚拟网段被同时用于源和目标宿主以承载此流量 31 | 32 | ## 6.3 VM 监视与安全策略强制实施 33 | 34 | 由于 VM 是针对虚拟机监视器的威胁的主要来源，针对 VM 状态和这些 VM 的出入流量的不间断监视是必要的，对于：(a) 控制流量类型，(b) 入侵检测和预防，以及 (c) 检测病毒和其他恶意软件。此功能可以通过两种方式实现： 35 | 36 | * 基于 VM 的安全监视和介入解决方案 37 | * 在 VM 或者虚拟网络对象（即虚拟交换机的端口/端口组）层级上的由具有流量规则强制实施功能的虚拟机监视器模块实现的安全监视和介入 38 | 39 | 在基于 VM 的安全监视和介入的方式中，软件或者软件代理（即安全工具）运行在某个 VM 之中以监视安全相关事件。此方式类似于运行基于宿主的 IDS。此方式的优势在于它对于运行在 VM 之中的代码提供了良好的可视性和上下文分析。然而，由于依赖底层客户 OS 上的安全工具，任何针对后者的攻击也会破坏此安全工具的功能，因此破坏这种反制措施。将安全工具作为可视化负载运行的另一个缺点是它对于其自身以及该 VM 上运行的其他应用程序负载的性能影响。 40 | 41 | _基于虚拟网络的安全监视_ 可以有两种形式： 42 | 43 | * (a) 用于保护每一个 VM 的专用安全设备 44 | * (b) 运行在虚拟网络中并且能够保护虚拟机监视器宿主中的多个 VM 的安全设备 45 | 46 | 专用的安全设备在虚拟网络中被部署在被监视的 VM 之前，并且监视出入该 VM 的全部流量。此方式的主要缺点是，如果该 VM 被迁移至其他物理宿主，此专用设备也必须被迁移。 47 | 48 | 部署在虚拟网络上并且被配置为监视多个 VM 的通用安全设备可能必须被不间断地重新配置，由于下列原因： 49 | 50 | * 被监视的该组 VM 总是不间断地处于某种状态流中，由于 VM 会被从一个虚拟化的宿主迁移到另一个，由于负载均衡、性能，甚至是安全性的原因 51 | * 如果虚拟局域网（VLAN）被用于在 VN 之间提供通讯层级的隔离，VLAN 的配置可能随着 VM 上的负载结构偏移而发生持续的更改，着可能要求重新配置网络流量镜像能力以保证所有虚拟网络流量流经影响着该虚拟化的宿主上的负载的总体性能的监控工具 52 | 53 | 在基于虚拟机监视器的安全监视解决方案中，监视并保护 VM（用户 VM）的安全工具运行在托管业务应用程序的 VM 之外，而是在某个安全加固的特殊 VM 中。被设计并且配置为运行在此种模式下的安全工具称为安全虚拟设备（SVA）。SVA 通过虚拟机监视器中的 _虚拟机自省_ API 获得对于 VM 状态（例如 CPU、寄存器、内存和 I/O 设备）以及虚拟机之间、虚拟机和虚拟机监视器之间的网络流量的可视性。这是理想的解决方案，由于： 54 | 55 | * (a) 它不易受到客户 OS 中的瑕疵的攻击 56 | * (b) 它独立于虚拟网络配置，并且每当虚拟网络配置由于 VM 迁移或者驻留于该虚拟机监视器宿主上的 VM 之间的连接性的改变而发生改变时，不必须重新配置它 57 | 58 | 因此，对于为了保护虚拟机监视器而创建的 VM 监视解决方案的安全性建议如下所述： 59 | 60 | _安全性建议 HY-SR-14_：应该存在机制以用于安全监视、VM 操作安全策略强制实施，以及检测 VM 中运行的恶意进程和出入 VM 的恶意流量。此监视和强制实施机制构成了用于构建杀毒（AV）和入侵检测及防止系统（IDPS）解决方案的基础 61 | 62 | _安全性建议 HY-SR-15_：用于 VM 的安全监视和安全策略强制实施解决方案应该基于 VM 外部，并且撬动虚拟机监视器的虚拟机自省能力。通常，这样的解决方案涉及在安全加固的或者可信 VM 中运行诸如安全虚拟设备（SVA）的安全工具 63 | 64 | _安全性建议 HY-SR-16_：运行于虚拟机监视器宿主中的所有反恶意软件工具（例如查毒软件、防火墙和 IDPS 等）应该拥有能力以执行基于一定周期的自主签名或者索引文件更新 65 | 66 | ## 6.4 VM 配置管理 67 | 68 | 每一个 VM 的配置都应该被监视和管理，贯穿其生命周期。在大多数案例中，除了虚拟机监视器自带的原生特性以外，这还可以通过利用专用的第三方工具来实现。这些工具的理想特性以安全性建议的形式提供如下： 69 | 70 | _安全性建议 HY-SR-17_：VM 配置管理工具应该具有能力以编译日志并且警示管理员，如果在被监视的任何 VM 中检测到配置更改 71 | 72 | ## 6.5 用于 VM 管理的精细粒度管理权限 73 | 74 | 拥有能力以对虚拟化的基础设施指认精细粒度的管理权限使得建立不同的管理模型及其相关授权机制成为可能。为了展示对于粒度许可的要求，检视用于虚拟化的基础设施中的管理操作的一些应用案例场景是有帮助的： 75 | 76 | * _VM 管理应用案例 1_：某个质量保证团队想要设置少量具有某些限定特性（诸如内存、CPU 等资源限额）的虚拟机以测试某些即将进入生产的应用程序。在此情况下，出于测试目的，在质量保证团队中专门指派一位或者更多位管理员以被授予特定的虚拟机设置的管理权限可能会有用 77 | * _VM 管理应用案例 2_：某位被指派了确定不同虚拟化的服务器上的操作负载和对额外的虚拟化的宿主的需求的任务的性能规划者可能需要权限以查看每一个虚拟化的宿主中的虚拟机的列表，而非需要对这些 VM 执行任何管理操作的权限。在此情况下，拥有能力以授予对于虚拟化的宿主中的 VM 列表的查看权限，但是拒绝此用户与任何可见的对象的交互的权限是理想的 78 | * _VM 管理应用案例 3_：在具有不同敏感度等级的 VM 运行于同一虚拟化的宿主之上的虚拟化的数据中心中，某位在虚拟机监视器层级被授予管理权限的管理员有时应该被禁止访问某个特定 VM，由于运行在该 VM 上的负载（即应用程序集合）的敏感性本质。在此情况下的理想能力是对于某个特别的子对象，拒绝其通过继承获得的权限 79 | * _VM 管理应用案例 4_：在某些情况下，对一组为某个特定组织分部或者部门控制一系列 VM 的管理员指认权限是必需的。此类管理实体的必然结果是对于一类想要管理运行着某种特定类型的负载（例如网络服务器）的 VM 的管理员的需求，无论其在组织结构中的位置。此类管理员可能并不要求对于某个 VM 的全套管理功能，而只是某些管理功能的任意集合，诸如配置 CD 介质、配置软盘介质、控制台交互、设备连接、开机、关机、重置，或是挂起等。此场景要求具有能力以创建自定义功能，即它可以包括与某个 VM 相关联的权限的任意集合，也需要具有能力以创建自定义对象，即它可以包括运行某种特定类型的负载（例如网络服务器）的 VM 的任意集合 80 | 81 | 综合所有 4 种管理场景中的能力要求，关于必需的权限粒度的总体安全性建议如下所述： 82 | 83 | _安全性建议 HY-SR-18_：用于 VM 管理的访问控制解决方案应该拥有粒度能力，既在权限授予层级，也在对象层级（即对于权限目标的具体说明可以是单一 VM 或者任何 VM 的逻辑组合，基于功能或者位置）。此外，还应该存在这样的能力以禁止对于某个 VM 组（例如运行具有特定敏感度等级的负载的 VM）中的某些特别对象的权限，尽管其拥有对于该 VM 组的访问权限 84 | 85 | -------------------------------------------------------------------------------- /nist_sp_800-155/chapter_2.md: -------------------------------------------------------------------------------- 1 | # 第 2 章 背景 2 | 3 | 诸如台式机和笔记本等客户端计算机包含用于辅助硬件初始化过程的程序代码。这些代码存储于非易失性存储器中，并且通常称为 _启动固件_。用于初始化系统的首要固件称为 _基本输入/输出系统_（_BIOS_）或者 _系统 BIOS_。如果 BIOS 从它的预想状态发生更改，不论是恶意还是无意，它所发生更改的设备可能会对组织机构产生负面影响，由于该设备不一定是以其预想状态运行的。可能的结果包括系统不稳定、系统故障、信息泄露，或是其他可靠性、完整性和可用性的丧失。此外，此系统可能易受更加精妙的攻击，诸如隐秘监控，并且攻击者可以将此系统用作攻击其他系统的基石。这些范例解释了为何通过测定和监测其完整性以检测针对 BIOS 及其配置的更改如此重要。 4 | 5 | 本章提供了关于 BIOS 完整性测定（BIM）的概述及其在组织机构检测、报告和化解操作环境中的针对 BIOS 的攻击中的作用。本章标识出了完成此任务所要求的主要组件并且对这种方法论所能解决的威胁进行了描述。 6 | 7 | ## 2.1 BIOS 完整性测定场景 8 | 9 | 本节呈现了那些定义了候选应用案例的场景，这些场景将会引导要求和建议在此文档的剩余部分中的呈现。这些应用案例用作识别用户操作、相关通讯、内在风险以及潜在的安全防护的基础。 10 | 11 | 这些场景基于 IT 组织机构在 BIM 领域的客观状态和过程成熟度。在很大程度上，这种客观状态近似地反映出了众多组织机构当今在终端机的补丁管理领域所使用的最佳实践。具体地，组织机构可以期望对于新的终端机实施这样一种供货过程，在这里，BIM 被完全整合进此模型中。例如，供货一台终端机将会包含这些额外的与 BIOS 完整性具体相关的活动，这些活动可以与现存的镜像、财产跟踪以及注册活动等互补。 12 | 13 | * 为一台给定的客户端安装并且/或者验证正确的 BIOS 修订版本 14 | * 利用适当的 BIOS 设置对该 BIOS 进行镜像 15 | * 设置 BIOS 口令 16 | * 主张任何要求物理存在的安全控制（可能包含可信平台模块（TPM）） 17 | * 将此终端机的身份和完整性度量注册到相关的 IT 数据库 18 | 19 | 这些安全变量中的任何更改可能提示一种异常状态，以及潜在地更具危险性的效应。当今存在的客户端操作系统代理在网络管理层上报告关于这些设置的基本信息，并且它们是用于评估 BIOS 安全状态的良好的初始工具。然而，每当可能时，这些报告代理需要立即被迁移到依赖于植根于防破坏的可信根的完整性基础设施上来。 20 | 21 | ### 2.1.1 场景 1：系统 BIOS 发生某些更改 22 | 23 | 针对客户端计算机的 BIOS 更新频繁发布。这些更新通常修复电源管理子系统、硬盘或网络管理，或者其他重要组件中的 bug。然而，BIOS 也可能出于恶意目的被修改。系统管理员能够分辨哪种版本的 BIOS 在一台设备上被加载以便能够正确地管理它是至关重要的。这必须在面对如下基本挑战的同时完成： 24 | 25 | * IT 管理部门必须能够信任所采集到的 BIOS 固件测定数据是正确的 26 | * 需要有一个可信根以信任 BIOS 固件完整性测定数据的采集 27 | * 关于 BIOS 固件的完整性测定数据的有效初始基线必须被采集，可以潜在地使用该设备的可信根以采集并报告基线测定数据 28 | * BIOS 固件完整性测定数据必须是可证明地新鲜的（其响应不能仅仅是某次较早的正确响应的重放） 29 | * BIOS 固件完整性测定数据必须拥有可证明的完整性（它在响应者和接收者之间未被更改） 30 | * BIOS 固件完整性测定数据的来源必须被确定（它来自 IT 部门所认为它来自的地方） 31 | * IT 管理部门必须能够解读被报告的 BIOS 固件完整性测定数据 32 | * 标准格式至关重要 33 | * 需要考虑系统的多样性 34 | * 用户和管理员必须能够知道 BIOS 在何时发生更改，而无需徒手进行庞杂的计算。 35 | 36 | ### 2.1.2 场景 2：BIOS 配置设置发生某些更改 37 | 38 | BIOS 设置对于系统安全性具有重大影响，需要回答的关于设置的部分问题列表包括： 39 | 40 | * 口令 41 | * 管理员口令是否被设置？ 42 | * 开机口令是否被设置？ 43 | * 硬盘口令是否被设置？ 44 | * 基于 BIOS 的管理（BBM）软件 45 | * 是否被启用？ 46 | * 基于 BIOS 的管理软件的配置是什么？ 47 | * 启动 48 | * 启动顺序是否发生更改？ 49 | * 计算机是否会从除硬盘外的任何位置启动？ 50 | * 端口和其他硬件接口 51 | * USB 端口是否被启用？ 52 | * 1394 端口是否被启用？ 53 | * PCMCIA 或者智能卡读卡器是否被启用？ 54 | * 近场通讯（NFC）端口是否被启用？ 55 | 56 | 这些设置发生的任何更改可能指示系统已经变得不那么安全，或者已被攻击。与第一种场景类似，用户和管理员都能确定 BIOS 设置是什么以及它们是否符合策略是至关重要的。此文档要求那些允许管理员辨别 BIOS 配置设置是否被更改的能力，并且鼓励使用那些允许管理员区分哪些设置被更改的能力。 57 | 58 | 识别 BIOS 配置更改要求以下能力，与识别 BIOS 代码更改所需的能力类似，但是对其进行了扩展： 59 | 60 | * IT 管理部门必须能够信任 BIOS 配置的完整性测定数据是正确的 61 | * 需要有一个可信根以信任 BIOS 配置的完整性测定数据 62 | * 测定数据必须是可证明地新鲜的 63 | * 测定数据必须拥有可证明的完整性 64 | * 测定数据的来源必须被确定 65 | * IT 管理部门必须能够解读响应 66 | * 标准格式至关重要 67 | * 需要考虑系统的多样性 68 | 69 | ## 2.2 BIOS 完整性测定流 70 | 71 | 为了测定 BIOS 的完整性，某些基本要求必须被满足，它们包括： 72 | 73 | * 生成并采集测定数据的方法 74 | * 存储测定数据的方法，它要么是能够抵抗破坏的，要么是能够使破坏显而易见的 75 | * 将测定数据传输到分析代理的方法 76 | * 分析测定结果的方法，以及基于此测定结果管理一台设备的方法 77 | 78 | 终端机设备必须拥有能够测定 BIOS 固件并且将这些测定数据转发至管理权威机构的方法。此终端机必须在执行此任务的同时保护这些测定数据的完整性、合法性、不可抵赖性，以及在某些情况下还有机密性。 79 | 80 | 图 1 显示了支持 BIM 的生成、转发、分析，以及基于此分析的补救行为的架构。这些解决方案可以由单一厂商提供，或者由多家厂商联合提供。在终端机上，用于测定、存储和报告的可信根构成了提供必要的安全服务的基础。3.1 节将会在更深的层次上涵盖可信根。 81 | 82 | > 图 1：BIOS 完整性架构 83 | 84 | BIOS 代码和配置数据代表测定目标。测定数据生成和报告代理作用于测定目标并且直接撬动可信根以便为每一次测定以及测定和报告过程提供安全防护。3.2 和 3.3 节为测定和与之关联的过程提供了更多见解。采集和传输代理提供了一种方法以可靠地采集测定数据并且将其传输至测定数据评估权威机构（MAA）以进行进一步分析。3.4 和 3.5 节讨论这些代理的功能。3.6 节讨论的恢复代理为管理权威机构提供了一种方法以采取行动来修复通过 BIOS 测定数据分析在终端机上发现的任何问题。 85 | 86 | 在评估测定数据时，MAA 参考一组特征。这些特征集合分为两类：要么是终端机属性和 BIOS 代码的测定数据，它们由原始设备制造商（OEM）、增值分销商（VAR）或者独立软件厂商（ISV）提供并且担保（利用证书），要么是配置设置的测定数据，它们由终端机的用户/管理员在该终端机的最初供货阶段采集，或者由 MAA 采集。理想的测定数据特征的集合称为 _黄金测定数据_。 87 | 88 | MAA 可以托管若干种服务，诸如管理控制台或者一种提供简易用户界面以分析 BIOS 属性和测定数据的控制面板，以允许管理员或者分析者快速确定以下方面： 89 | 90 | * 终端机设备的报告的可信度 91 | * 设备是否符合要求（与当前的一套黄金测定数据相匹配） 92 | * 设备是否需要恢复（BIOS 设置不符合要求，或者正在使用老旧的黄金测定数据） 93 | * 设备是否潜在地具有危险性（某些测定数据已知能够指示恶意活动） 94 | 95 | 基于这些报告，设备可以被允许或者拒绝访问资源（例如，允许访问网络资源、允许受限访问网络资源，诸如恢复网络，或者拒绝访问），这些报告也可触发其他管理行为。 96 | 97 | 图 1 描述了 BIOS 完整性测定和报告的典型数据流： 98 | 99 | 1. 获取一套初始的可信测定数据（黄金测定数据）。这些测定数据要么由第三方（例如 OEM）向 MAA 提供，要么由系统管理员在初始供货时生成 100 | 2. 在终端机的启动过程中，在植根于测定可信根（RTM）的信任链中由固件对 BIOS 固件及其配置设置进行一系列测定。RTM 存储这些测定数据的散列值表征，这些测定数据由存储可信根（RTS）存储或保护。一段可以根据它重建这些测定数据的日志存储于内存中的某处，以使得传输代理可以重建这些测定数据 101 | 3. 作为对终端机请求服务或者 MAA 请求行为的响应，MAA 生成一次测定请求，包含一个临时随机数。传输代理接收此请求，确定它属于 BIOS 完整性测定，并且因此将其传输至采集代理 102 | 4. 采集代理对请求进行语法检查，并且将临时随机数传输至报告代理，后者利用报告可信根（RTR）以获取此临时随机数的签名以及所存储的测定数据的散列值表征 103 | 5. 报告代理将此数据（连同从内存中获取的日志）传输回采集代理 104 | 6. 采集代理将此数据格式化为标准格式，并且将其传输回传输代理 105 | 7. 传输代理将此数据传输至 MAA 的验证代理 106 | 8. 验证代理验证散列值的签名，通过验证用于签名这些散列值以及签名本身的公钥，以及验证报告中包含的临时随机数与测定请求中发送的临时随机数匹配。它随后将这些签名的测定数据与它早先获取的黄金测定数据进行比较 107 | 9. 在这种比较的结果与来自其他设备的类似比较结果相核对之后，可以将其通过某个用户界面（诸如管理控制台或者控制面板）显示给管理员并且/或者提供给某个自动化的强制执行/访问点 108 | 10. 如果此结果被提供给某个自动化的强制执行/访问点，管理员或者其代理随后根据比较的结果作出决定，这可能是允许或者拒绝网络访问、发送信号至恢复代理，或者也可能是派遣一位服务技术人员到该设备以确定得到错误结果的原因。 109 | 110 | ## 2.3 过渡到理想状态 111 | 112 | 对于 BIM 的理想或者客观状态，BIOS 测定是程式化和自动化的客户端扫描的一部分。随着组织机构从它们当今所处的状态逐步进步到理想状态，必须迈出若干步骤。最初，这些测定数据只会随着其他客户端健康数据一同采集和存储。这些数据随后将会在常规的基础上被审阅和分析，以开发出一种关于组织机构内部的客户端 BIOS 的基线行为的理解。随着控制面板套件和其他操作工具被更新以便将 BIOS 完整性信息整合为第一级数据，用于 BIM 的附属活动和责任可以被移交给标准 IT 操作团队。随着时间进展，这又会简单地成为 IT 服务的另一个标准职位。 113 | 114 | -------------------------------------------------------------------------------- /nist_sp_800-125a/chapter_1.md: -------------------------------------------------------------------------------- 1 | # 第 1 章 简介、范围和目标受众 2 | 3 | 虚拟机监视器是提供服务器虚拟化的核心软件。同它的支持模块一起，它允许所有硬件资源（例如 CPU、内存、网络和磁盘等）的虚拟化，并且因此允许多个计算栈（基本上是由 OS 和应用程序构成）运行在单一的物理宿主上。这样的物理宿主称为虚拟化宿主（在此文档中有时也称为虚拟机监视器宿主），独立的计算栈被封装在称为虚拟机（VM）的东西中。为了成为独立可执行的实体，VM 的定义应该包括分配给它的资源（例如 CPU、内存等）。VM 也称为“客户机”，而它们内部运行的操作系统（OS）称为“客户 OS”。与 VM 相关联的资源是虚拟资源，与同物理宿主相关联的物理资源相对。虚拟机监视器同这些支持模块以及托管硬件一同构成了虚拟机监视器平台。 4 | 5 | 虚拟机监视器的主要功能是强制执行客户 OS 隔离，以及客户 VM 之间的受控资源共享。因此它起到了传统 OS 对于非虚拟化的宿主（服务器）所起的作用中的很多。正如传统 OS 为运行在服务器上的不同应用程序（或者进程）之间提供隔离那样，虚拟机监视器为运行在其上的一台或者多台 VM 之间提供隔离。同样，类似于 OS，虚拟机监视器在多个 VM 之间调度其对物理资源（设备）的访问。尽管对于 CPU 和内存访问（以保证进程隔离）直接由虚拟机监视器处理（分别通过指令集（CPU）虚拟化和内存虚拟化，不论是否得到来自硬件的辅助），虚拟机监视器通过调用运行于内核之中的，或者称为设备驱动程序 VM 的专用 VM 之中的软件模块来处理对设备访问（设备虚拟化）的调度。虚拟机监视器可以直接安装在硬件或者裸机上（第 1 类虚拟机监视器），或者安装在称为宿主 OS 的完整传统 OS 上（第 2 类虚拟机监视器）。 6 | 7 | 初看起来，与虚拟机监视器及其硬件宿主（共同称为虚拟机监视器平台）的安全管理相关的所有活动可能看起来应该只是包含任何服务器级别的软件及其托管环境的已确立的最先进的技术实践。然而，仔细检查一下就会发现，用于支持虚拟机监视器所提供的硬件虚拟化的功能具有广泛的安全性后果，并且因此需要一组基于针对这些功能的完整性的威胁的分析的目标明确的安全性建议。在此文档中，这些功能称为虚拟机监视器的基线功能。 8 | 9 | 虚拟机监视器的基线功能包括： 10 | 11 | * VM 进程隔离 12 | * 设备调度和访问控制 13 | * 来自客户 VM 的命令的直接执行 14 | * VM 生命周期管理 15 | * 虚拟机监视器平台的管理 16 | 17 | 对于上述功能的简略描述于下文 1.1 节给出。 18 | 19 | ## 1.1 虚拟机监视器的基线功能（HY-BF） 20 | 21 | 尽管虚拟机监视器的基本功能是虚拟化硬件（物理宿主）以允许运行多个虚拟宿主（普遍称之为 VM），商业虚拟机监视器供应带有不同的特性集合。提供相同特性集合的模块在不同的产品供应中被起了不同的名称。因此，为了达到此文档的目的，有必要定义一组虚拟机监视器的基线特性，它们能够涵盖用于支持硬件虚拟化的全部功能。在某些实例中，只是为 VM 提供一组虚拟化资源的模块称为虚拟机管理器（VMM）。如果 VMM 同提供 OS 层级服务的模块，诸如 CPU 中的 VM 计划相结合，它们便称为虚拟机监视器。虚拟机监视器的这些特性或者功能包括： 22 | 23 | * _HY-BF1：VM 进程隔离_——提供 VM 执行计划，管理在 VM 中运行的应用程序进程，诸如 CPU 和内存管理，以及在 VM 中运行应用程序的过程中进行不同的处理器状态之间的上下文切换。为了保证 VM 进程隔离，来自支持直接内存访问（DMA）设备的内存访问需要受到虚拟机监视器的控制（例如通过输入输出内存管理单元（IOMMU））。然而，此功能被认为属于 HY-BF2，由于它属于设备调度。 24 | * _HY-BF2：设备调度和访问控制_——使设备对于 VM 可用（例如通过模拟、准虚拟化、透传或者自虚拟化的硬件设备），并且控制哪些 VM 被允许访问哪些设备（例如网卡（NIC），诸如 IDE 驱动器的存储设备等）。 25 | * _HY-BF3：来自客户 VM 的命令的直接执行_——某些来自客户 OS 的命令是由虚拟机监视器直接执行的，而非通过中断或者上下文切换而触发。此功能适用于那些实现了准虚拟化而非完全虚拟化的虚拟机监视器。 26 | * _HY-BF4：VM 生命周期管理_——包括 VM 镜像的创建和管理、VM 状态的控制（开始、暂停、停止）、VM 迁移、制作快照、VM 监视，以及策略的强制执行等全部功能。 27 | * _HY-BF5：虚拟机监视器平台的管理_——定义虚拟机监视器软件模块中的不同配置参数中的东西和设置值，包括适用于虚拟机监视器中的虚拟网络以及这些模块的更新和补丁的配置的东西和设置值。 28 | 29 | 关于这 5 种基线功能的简略描述足以指导此文档剩余部分的讨论。关于这些功能的详细讨论于附录 A 提供。 30 | 31 | 上述功能由不同的虚拟机监视器组件或者软件模块执行。在不同的虚拟机监视器产品之间，功能的分布方式存在一些次要差别。虚拟机监视器组件的这些功能以及这些组件的位置在总体的虚拟机监视器架构中的映射于下文的表格 1 中给出： 32 | 33 | > 表 1：虚拟机监视器平台的基线功能 34 | 35 | |基线功能|组件（软件模块）|位置| 36 | |----|----|----| 37 | |VM 进程隔离（HY-BF1）|虚拟机监视器内核|OS 内核（带有内核模块）本身，或者安装在完整 OS（宿主 OS）上的组件| 38 | |设备调度和访问控制（HY-BF2）|设备模拟器或者设备驱动程序|专用 VM（称为设备驱动程序 VM）内部，或者虚拟机监视器内核自身内部| 39 | |来自客户 VM 的命令的直接执行（HY-BF3）|虚拟机监视器内核|仅适用于准虚拟化的虚拟机监视器，并且由此类虚拟机监视器中的超级调用接口来处理| 40 | |VM 生命周期管理（HY-BF4）|管理守护进程|安装在虚拟机监视器内核之上，但是运行于低权限模式| 41 | |虚拟机监视器平台的管理（HY-BF5）|一组具有 CLI（命令行界面）或者 GUI（图形用户界面）的工具|运行在虚拟机监视器内核之上的控制台或者 shell| 42 | 43 | 一般来说，功能 HY-BF1 和 HY-BF3 由运行于内核中的共同称为“虚拟机监视器”的模块提供，而 HY-BF2 由运行于专用 VM（称为设备驱动程序 VM）或者虚拟机监视器内核自身之中软件模块启用。功能 HY-BF4 和 HY-BF5 由称为管理或者服务控制台的模块，或者通过内核模块执行。正如执行 HY-BF2 功能的模块那样，此控制台是一个软件层，它通常不是构建于虚拟机监视器内核之中，而是作为一个高权限 VM 运行于其上，并且可以由安装于其中的完整 OS 或者由用于为应用程序接口（API）（shell 和网络访问）提供实用程序功能的超轻量级 OS 构建，这些功能只是用于辅助执行虚拟机监视器特定的配置和管理任务。 44 | 45 | ## 1.2 此文档的范围 46 | 47 | 为服务器虚拟化而部署的虚拟机监视器的架构可以按照不同方式分类： 48 | 49 | * (a) 基于虚拟机监视器所安装于其上的实体——第 1 类虚拟机监视器和第 2 类虚拟机监视器（已描述） 50 | * (b) 基于虚拟化的类型 51 | * 完全虚拟化——虚拟机监视器将真实世界中存在的硬件设备的接口暴露出来，并且该设备的驱动程序对于客户 OS 可用，并且虚拟机监视器将会完全模拟该设备的行为。这种模拟允许 VM 中运行的程序使用 VM OS 的驱动程序，此驱动程序被设计为同被模拟的设备进行交互，而无需安装任何由虚拟机监视器厂商指定的特定驱动程序或工具。 52 | * 准虚拟化——虚拟机监视器将并不存在于真实世界中的设备暴露出来，它只是软件，并且带有轻量级的接口。然而，此种场景要求 VM 中具有特定的驱动程序，有时要求对客户 OS 进行修改。这种方式的本意是提升 VM 中运行的应用程序的性能水平，相对于完全虚拟化所采用的模拟方式而言。 53 | 54 | 此文档中所描述的虚拟机监视器平台所假设的信任模型如下所述： 55 | 56 | * VM 中的所有组件均为不可信，包括客户 OS 及其运行于内核空间的相关实用工具（例如客户设备驱动程序）以及运行于用户空间的所有应用程序 57 | * 虚拟机监视器平台内部实现的设备驱动程序不可信，除非它们带有安全证书 58 | * 用于在 VM 之间提供隔离的虚拟机监视器内核组件可信 59 | * 宿主 OS 对于第 2 类虚拟机监视器可信 60 | * 虚拟机监视器宿主的硬件可信 61 | 62 | 有了关于虚拟机监视器架构的背景信息，以及假设的信任模型以后，对于 5 种基线功能（HY-BF1～HY-BF5）的安全性建议的范围涵盖下列方面： 63 | 64 | * 与功能 HY-BF1、HY-BF2 和 HY-BF4 相关联的所有任务 65 | * HY-BF3 与准虚拟化的虚拟机监视器的超级调用的处理相关联，它是虚拟机监视器的可信功能，并且并未包含于安全性建议中 66 | * HY-BF5 之下的所有任务都被包括进来，除了与虚拟网络的定义和配置相关联的内容（虚拟网络的安全配置由另一篇 NIST 文档 SP800-125B 所涵盖） 67 | 68 | 同时提供了用于保证整体平台完整性的建议。 69 | 70 | 安全性建议并未涵盖下列内容： 71 | 72 | * 虚拟机监视器宿主的用户帐户管理 73 | * 虚拟机监视器宿主的认证和访问控制 74 | * 宿主 OS 的程式化管理（例如保持补丁为最新） 75 | * 客户 OS 的程式化管理 76 | * 运行于 VM 上的客户 OS 的安全性 77 | * 运行于 VM 上的应用程序/服务的安全性 78 | 79 | ## 1.3 目标受众 80 | 81 | 此文档中的安全性建议的目标受众如下： 82 | 83 | * 想要开发虚拟化基础设施以便在虚拟机（VM）上托管不同的业务（LOB）应用程序系统的私人企业或者政府机构的企业 IT 部门的首席安全官（CSO）或者首席技术官（CTO） 84 | * 想要提供虚拟化基础设施以便为云服务客户托管安全的云服务，诸如基础设施即服务（IaaS）的数据中心管理者 85 | 86 | ## 1.4 与其他 NIST 指南文档的关系 87 | 88 | 就技术领域而言，与此文档相关联的 NIST 指南文档是 NIST 特别出版（SP）800-125，_完全虚拟化技术安全性指南_。与当时的技术发展状态相一致（SP800-125 发布于 2011 年一月），SP800-125 为两种虚拟化应用范型：服务器虚拟化和桌面虚拟化中的组件应用提供了高级安全性建议。此后，服务器虚拟化在 IT 数据中心领域得到了广泛应用，既用于托管机构内部或者预先定制（企业）的应用程序，也用于为云服务托管应用程序以及提供计算单元。 89 | 90 | 伴随这一技术应用趋势而来的是虚拟机监视器的特性集合，以及用于配置和管理由虚拟机监视器衍生出来的虚拟化的基础设施的工具集合的市场可获得性的增加。此文档的目标是专注于一组用于虚拟机监视器（及其所有构成组件）的部署，包括 VM 的创建和供货所涉及的步骤的安全性建议的开发。此文档在类似的 NIST 指南文档的上下文环境中所提供的这组安全性建议的独特特性列于下方： 91 | 92 | * 提供了一组目标明确的安全性建议，它们对于虚拟机监视器的部署是架构不可知的 93 | * 由于真实世界中的部署过程包括 VM 供货，因此所有 VM 生命周期操作都被涵盖，从 VM 镜像的创建和管理到它们的使用粒度权限的管理 94 | * 由于认识到虚拟机监视器是一种基于目的构建的操作系统（OS）内核，以及服务器 OS 的安全性取决于它的最弱一环这两点，无论其发行版（例如驱动程序软件），此文档也提供了与这些组件相关联的安全性建议 95 | * 由于认识到虚拟机监视器会执行特定的高权限操作，而不会受到来自虚拟化的宿主中的任何其他实体的干涉，以及为这些操作撬动硬件支持将会为虚拟机监视器的部署的整体安全性带来显著差异这两点，这些安全性建议也会提升性能，如果虚拟化特定的功能（例如多个 VM 的内存表）被卸载（撬动）到处理器而非通过软件功能实现 96 | * 所有安全性建议的本意是提供担保以对抗那些针对虚拟机监视器的基线功能所涉及的任务的威胁的利用 97 | 98 | -------------------------------------------------------------------------------- /nist_sp_800-147/chapter_3.md: -------------------------------------------------------------------------------- 1 | # 第 3 章 化解威胁 2 | 3 | BIOS 是安全系统中的重要组成部分。作为在启动过程中首先被执行的代码，系统 BIOS 被系统中的软硬件组件隐含地信任。上述章节描述了系统 BIOS 在启动过程中的作用、它对攻击者的吸引力，以及可能导致对 BIOS 的未经授权的修改的潜在威胁。本章呈现了 BIOS 实现的安全指导意见以及在企业环境中推荐的 BIOS 管理实践。3.1 节提供了安全 BIOS 更新过程的指导意见，它本意是用于平台厂商设计、实施或者选择一种 BIOS 实现。尽管产品可能不会立即可获得，组织机构可以在它们投入采购过程时采用这些指导意见，并且开始开发计划，以便在产品可获得时利用这些安全特性。组织机构可以在开发这些计划时使用 3.2 节所建议的 BIOS 管理实践。这些建议本意是防止对 BIOS 的未经授权的修改。 4 | 5 | ## 3.1 对于系统 BIOS 实现的安全指导意见 6 | 7 | 本节提供的指导意见的本意是在供货之后通过防护用于更新 BIOS 的机制来维持 BIOS 的完整性。特别地，本节定义了用于安全 BIOS 更新机制的系统 BIOS 实现的指导意见。安全的 BIOS 更新机制包括： 8 | 9 | 1. 一种过程，用于验证 BIOS 更新的合法性和完整性 10 | 2. 一种机制，用于确保 BIOS 受到保护，不受安全更新过程以外的修改。 11 | 12 | 认证过程确认 BIOS 更新镜像是由合法的来源生成的，并且未被替换。所有系统 BIOS 更新应该要么执行 3.1.1 节所描述的认证 BIOS 更新机制，要么使用一种符合 3.1.2 节中的指导意见的最优安全本地更新机制。 13 | 14 | 这些安全 BIOS 更新机制指导意见并不能化解与系统 BIOS 相关联的全部风险。某些对于系统 BIOS 的未经授权的修改的威胁仍然存在。例如，这些指导意见不能防止对系统拥有物理访问的个人修改系统 BIOS，它们也不能保证系统 BIOS 实现没有漏洞。关于系统 BIOS 的指导意见应当与组织已有的安全策略和过程联用。 15 | 16 | ### 3.1.1 BIOS 更新认证 17 | 18 | 认证 BIOS 更新机制使用数字签名以保证 BIOS 更新镜像的合法性。如需使用认证 BIOS 更新机制来更新 BIOS，应该有一个更新可信根（RTU），它包含一种签名验证算法以及一个包含了验证 BIOS 更新镜像的签名所需的公钥的密钥存储器。此密钥存储器和签名验证算法应该以一种受保护的方式存储于计算机系统上，并且应该仅可使用认证更新机制或者 3.1.2 节所列举的一种安全本地更新机制来修改。 19 | 20 | 存储于 RTU 中的密钥应该包括用于验证 BIOS 更新镜像的签名的公钥，或者在公钥的一份副本由 BIOS 更新镜像提供的情况下包含此公钥的散列值 \[FIPS180-3\]。在后一种情况下，更新机制应该计算由 BIOS 更新镜像所提供的公钥的散列值，以确保它与出现在密钥存储器中的散列值相匹配，然后再用所提供的公钥来验证 BIOS 更新镜像的签名。 21 | 22 | BIOS 镜像应该以符合 NIST SP 800-89，_Recommendation for Obtaining Assurances for Digital Signature Applications_（关于获得数字签名应用程序的担保的建议）\[SP800-89\] 的方式签名，使用一种在 NIST FIPS 186-3，_Digital Signature Standard_（数字签名标准）\[FIPS186-3\] 中具体说明的一种许可的数字签名算法，它提供至少 112 位的安全强度，以符合 NIST SP 800-131A，_Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths_（过渡：关于密码学算法和密钥长度的使用的过渡的建议）\[SP800-131A\] 的要求。 23 | 24 | 更新机制应该保证 BIOS 更新镜像经过数字签名，并且在更新 BIOS 之前，该数字签名可以使用 RTU 中的密钥进行验证。恢复机制也应该使用认证更新机制，除非恢复过程符合安全本地更新指导意见的要求。认证更新机制应该能够防止未经授权地将 BIOS 回滚到一个带有已知的安全弱点的早期认证版本。这种回滚限制机制可以通过例如验证 BIOS 镜像的版本号大于当前所安装的 BIOS 镜像的版本号等方式来实现。 25 | 26 | 某些组织可能想要在高度安全环境下主张对于 BIOS 更新的更大控制权。认证更新机制可以被设计为允许组织对于更新过程的控制，在此，更新 BIOS 或者回滚至早期版本的操作仅当此更新或者回滚过程得到组织授权时才被允许。例如，特定的 BIOS 镜像可以被组织许可，通过使用由组织控制的密钥对其附署签名，这可以在更新过程中被验证。 27 | 28 | ### 3.1.2 安全本地更新 29 | 30 | BIOS 实现可以可选地包括一种安全本地更新机制，以便在不使用认证更新机制的情况下更新系统 BIOS。安全本地更新机制如果被实施，应该仅被用于加载首个 BIOS 镜像，或者从一个不能由 3.1.1 节描述的认证更新机制修复的系统 BIOS 损坏中恢复。安全本地更新机制应该通过要求物理存在来保证 BIOS 更新镜像的合法性和完整性。安全本地更新机制中的未来的保护可以通过在允许更新系统 BIOS 之前要求输入管理员口令或者解锁某个物理锁（例如某个主板跳线）来实现。 31 | 32 | ### 3.1.3 完整性保护 33 | 34 | 为了防止认证 BIOS 更新过程以外的针对系统 BIOS 的无意或者恶意的修改，RTU 和系统 BIOS（不包括那些存储于非易失性存储器中的被系统 BIOS 所使用的配置数据）应该通过某种在认证 BIOS 更新以外不能被超越的机制保护起来，使其不会受到无意或者恶意的修改。此保护机制本身也应该被保护起来，使其不会受到非授权的修改。 35 | 36 | 认证 BIOS 更新机制应该被某种机制保护起来，使其不会受到无意或者恶意的修改。此机制至少和保护 RTU 和系统 BIOS 的机制一样强。 37 | 38 | 此保护机制应该在执行任何无需使用认证更新机制或者安全本地更新机制就能被修改的固件或者软件前保护包含系统 BIOS 的系统闪存的相关区域。这种保护应该由除了通过认证更新机制以外不可更改的硬件机制来强制执行。 39 | 40 | ### 3.1.4 不可绕过性 41 | 42 | 认证 BIOS 更新机制应该是在没有贯穿于安全本地更新机制的物理介入的情况下更新系统 BIOS 的唯一机制。系统及其附带的系统组件和固件的设计应该保证没有任何机制可以允许系统处理器或者任何其他系统组件绕过认证更新机制，除了安全本地更新机制以外。任何诸如此类能够绕过认证更新机制的机制可能会创建一种漏洞以允许恶意软件利用来自非法来源的 BIOS 镜像修改系统 BIOS 或者重写系统闪存。 43 | 44 | 现代平台拥有这样的设计特性，它赋予系统组件对于系统 BIOS 的直接访问以提升性能，例如将 BIOS 复制到内存或者将其用于系统管理模式操作。系统组件可能拥有对于 BIOS 闪存的读取访问权限，但是它们不应该能够直接修改系统 BIOS，除非是经过认证更新机制，或者通过某种要求物理介入的认证机制。例如，能够绕过主处理器的总线控制（例如，对于系统闪存的直接内存访问）不应该能够直接修改固件。同样，系统中的微控制器不应该能够直接修改固件，除非该微控制器的硬件和固件组件在 RTU 处是以相同的机制保护的。这些不可绕过性的指导意见并不适用于存储于非易失性存储器中的由系统 BIOS 所使用的配置数据。 45 | 46 | ## 3.2 关于 BIOS 管理的实践建议 47 | 48 | 本节介绍在企业操作环境中管理系统 BIOS 以撬动现存策略、过程和操作实践的考虑。它专注于围绕作为其整体平台生命周期的一部分的系统 BIOS 的供货、部署、管理和废弃处理等阶段的关键活动。在恢复阶段所执行的活动也被具体说明以处理例外情况。 49 | 50 | **供货阶段**：组织机构在企业范围内为不同的计算机系统制定一套用于标识、列入清单和跟踪的机制以贯穿其生命周期是至关重要的。识别并监视 BIOS 镜像的特征，诸如制造商名称、版本号或者时间戳允许该组织进行更新、回滚和恢复。该组织应该在安全的离线存储中为每种许可的系统 BIOS，包括其废弃的版本维护一套“黄金主镜像”。 51 | 52 | 如果平台拥有可配置的更新可信根（RTU），该组织需要维护一套密钥存储器和签名验证算法。如果 RTU 被集成到系统 BIOS 中，那么只需维护 BIOS 黄金镜像就能满足此指导意见。如果 RTU 并未集成到系统 BIOS 中，为 RTU 提供的安全性应该至少和用于 BIOS 黄金镜像的一样强。 53 | 54 | 大多数组织机构将会依赖制造商作为经过认证的 BIOS 的来源。在这种情况下，该组织并未维持任何私钥，并且 RTU 仅包含由制造商提供的公钥。如果组织机构想要通过附署签名某些或者全部经过许可的系统 BIOS 更新来积极地参与 BIOS 认证过程，RTU 可能包含一个或者多个与该组织相关联的公钥。在这种情况下，该组织必须安全地维持对应地私钥，以使得下一次 BIOS 更新可以被签名。私钥应该采用多方控制来维护，以防止局中人攻击。对于组织的密钥，对应的公钥也必须安全地维持（以保证来源的合法性）。 55 | 56 | 此外，对于每种平台的通用配置基线必须被创建以符合组织的策略，该基线应该保证完整性保护和不可绕过性的特性被启用（如果它们可配置），并且组织的口令策略和启动设备顺序策略被强制执行。最后，每种平台的 BIOS 镜像信息和与之相关的设置基线应该被记录在配置管理计划中（脚注 2）。 57 | 58 | > 脚注 2：参见 NIST SP 800-128 草案，_Guide for Security Configuration Management of Information Systems_（信息系统的安全配置管理指南）\[SP800-128\] 以获得关于开发配置管理计划的指导意见。 59 | 60 | **平台部署阶段**：安全本地更新过程应该被用于从黄金主镜像为该平台提供经过许可的 BIOS。对应的 RTU 应该被安装，并且在计算机系统部署之前，与 BIOS 相关的配置参数应该被建立。这会帮助组织维护一种一致的、已知的初始状态。组织应该周期性地进行评估以确保组织的 BIOS 策略、过程和程序被恰当地遵循。 61 | 62 | 具体地，程序必须保证恰当的系统 BIOS 被安装，RTU 包含所有必需的密钥并且没有非授权的密钥，以及完整性保护和不可绕过性的特性被启用，如果它们可配置。 63 | 64 | **操作维护阶段**：本阶段包含那些对于在操作环境中维持 BIOS 的安全性和可靠性至关重要的操作和维护活动。系统 BIOS 更新应该使用更改管理过程来实施，并且新的经过许可的版本应该被记录在配置计划中，并且注释之前的 BIOS 镜像已被其取代。 65 | 66 | BIOS 镜像和配置基线还应该被连续监视。如果一个由此基线衍生的未经许可的版本被检测到，此事件应该被调查、记录并且作为事故响应活动的一部分而被修复。事故响应计划应该记录此过程以及可用于捕获证据以帮助确定其根本原因的经过认证的配套工具（脚注 3）。安全本地更新机制应该被用于从 BIOS 镜像攻击中恢复。 67 | 68 | > 脚注 3：关于如何建立事故响应能力以及高效地应对事故的额外信息，参见 NIST SP 800-61 修订版本 1，_Computer Security Incident Handling Guide_（计算机安全事故处理指南）\[SP800-61\]。 69 | 70 | 如果需要新的 BIOS 镜像以扩展系统能力、改进系统可靠性或是修复软件漏洞，BIOS 更新应该使用认证更新过程来执行。如果组织积极参与更新过程，多方控制过程必须被执行以便从安全存储中获取私钥并且生成数字签名。BIOS 安装包也应该被签名，并且此数字签名应该在执行前被验证。一旦更新成功执行，配置基线应该被验证以确认该计算机系统仍然符合组织的既定策略。 71 | 72 | **恢复阶段**：在某些情况下，所需的 BIOS 更新不能使用认证更新过程来完成。例如，损坏的系统 BIOS 或者 RTU 可能无法执行或者调用认证程序。在这种情况下，BIOS 更新可能会有意料之外的结果，迫使组织回滚到某个早期版本。对于认证更新，可能需要额外的步骤以认证回滚（如果在标准认证过程中比较了版本号或者时间戳），或者可能需要安全本地更新过程以重建安全基线。如同在操作维护阶段那样，在 BIOS 回滚或者重新安装之后验证 BIOS 配置是否满足组织的既定策略是至关重要的。 73 | 74 | **废弃处理阶段**：在计算机系统被废弃处理并且离开组织之前，组织应该从系统 BIOS 中移除或者销毁任何敏感数据。配置基线应该被重置为制造商的默认设置；特别地，诸如口令等敏感设置应该从系统中删除，密钥也应该从密钥存储器中移除。如果系统 BIOS 包含任何组织特定的自定义，那么由厂商提供的 BIOS 镜像应该被安装。平台生命周期的这一阶段减少了意外数据泄露的机会。 75 | 76 | -------------------------------------------------------------------------------- /nist_sp_800-125a/chapter_2.md: -------------------------------------------------------------------------------- 1 | # 第 2 章 开发安全性建议的方式 2 | 3 | 开发针对诸如虚拟机监视器的复杂软件的部署和使用的安全性建议需要对于潜在威胁的了解，这些威胁一旦被利用，将会影响虚拟机监视器功能的机密性、完整性和可用性这 3 种安全属性。此文档中用于开发针对虚拟机监视器的部署的安全性建议的方式如下所述： 4 | 5 | * 保证虚拟机监视器平台的所有组件的完整性，从宿主的基本输入/输出系统（BIOS）到虚拟机监视器的所有软件模块。这可以通过第 3 章作为 HY-SR1 而列出的安全启动过程来实现 6 | * 识别典型虚拟机监视器平台中的威胁来源。简要讨论了来自恶意或者受到攻击的 VM 的威胁的本质（2.1 节） 7 | * 对于 5 种基线功能 HY-BF1～HY-BF5 中的每一种（除了 HY-BF3，由虚拟机监视器执行高权限操作以外），识别每一种功能之下的不同任务，并且对于每一种任务，识别对于该任务的安全执行的潜在威胁。那些能够提供担保以对抗这些威胁的利用的反制措施构成了安全性建议的基础（2.2 节） 8 | 9 | 必须注意到的是，在某些大型开源和商业软件环境的案例中（例如数据库管理系统（DBMS）平台），用于安全部署和使用的方式是研究发布于公开漏洞数据库中的关于不同产品供应的报告，通过在线公开论坛或者软件厂商查找可用的补丁，并且查找建议的安全配置设置（同样通过在线公开论坛或者软件厂商的网站）。我们并未在此文档中采用此方式，由于此文档本意中的目的并非为某个特定的开源或者商业虚拟机监视器产品供应提供安全性建议，而是为整个产品类型基于其基线功能提供安全性建议。 10 | 11 | ## 2.1 虚拟机监视器平台的威胁来源 12 | 13 | 虚拟机监视器软件驻留在连接到企业网络的物理宿主上，它拥有被远程管理的能力。与此同时，它支持多个通常是该物理宿主内部的软件定义的虚拟网络结点的虚拟宿主（虚拟机或者 VM）。在某些情况下，它们可以是隔离网络的结点或者共享宿主网络。基于这一场景，某人可以识别针对虚拟机监视器平台的 3 种基本威胁来源，每一种均由符号 HY-TS\# 标识： 14 | 15 | * HY-TS1：来自或者通过虚拟机监视器（虚拟化的宿主）所驻留于其中的企业网络的威胁 16 | * HY-TS2：通过诸如共享虚拟机监视器内存以及虚拟机监视器宿主内部的虚拟网络等信道，产生自恶意或者受到攻击的 VM 的威胁 17 | * HY-TS3：来自网络接口，面向 VM 管理守护进程和虚拟机监视器管理控制台的威胁 18 | 19 | 来自来源 HY-TS1 和 HY-TS3 的威胁普遍存在于所有服务器级别的软件，并且在其他 NIST 文档中被良好地认识和应对。而来自来源 HY-TS2 的威胁是由虚拟机监视器所定义的虚拟化环境所特有的。我们将会在下一节中审视来自 HY-TS2 的威胁的本质。 20 | 21 | 虚拟机监视器控制着 VM 对物理硬件资源的访问，并且在 VM 之间提供隔离。VM 对诸如 CPU 和内存的硬件资源的访问由虚拟机监视器直接控制，而对于诸如网络和存储设备等资源的访问则是通过驻留于内核模块或者高权限 VM（即管理 VM）中的模块（驱动程序）来控制的。VM 之间的网络隔离是通过为每个 VM 指认一个独特的网际协议（IP）或者介质访问控制（MAC）地址、定义虚拟局域网（VLAN）或者覆盖网络并且为每个 VM 指认适当的网络标识符的方式来提供。来自恶意或者受到攻击的 VM 的威胁的本质可以通过以下方式来表明： 22 | 23 | 注意，每一种威胁由符号 HYP-T\# 来进行标识，其中 HYP 表示虚拟机监视器，T 表示威胁，\# 表示序号。 24 | 25 | * _进程隔离突破——VM 逃逸（HYP-T1）_：来自恶意 VM 的针对任何虚拟机监视器的主要威胁。恶意 VM 成功地破坏了由 VMM/虚拟机监视器提供的对于诸如内存页和存储设备等硬件资源的隔离功能。换言之，恶意或者受到攻击的 VM 可以访问属于虚拟机监视器或者其他 VM 的内存区域，以及它们未被授权访问的存储设备。此类威胁的可能原因包括：(a) 虚拟机监视器的设计漏洞，或者 (b) 恶意或者易受攻击的设备驱动程序。由恶意 VM 获得虚拟机监视器的控制权带来的潜在下游影响包括安装 rootkit 或者对于同一虚拟化的宿主上的其他 VM 的攻击 26 | * _网络隔离突破（HYP-T2）_：针对隔离的潜在威胁包括诸如由恶意 VM 进行的 IP 或者 MAC 地址伪造以及流量窥探，或者旨在针对同一虚拟网段上的 VM 的虚拟网络流量的拦截等攻击。对这些网络控制的破坏所造成的影响是机密性的丧失。某些 VM 将会能够查看它们并未被授权查看的信息 27 | * _拒绝服务（HYP-T3）_：配置不当的或者恶意 VM 可能会消耗不成比例的高百分比的宿主资源，导致对于该虚拟机监视器宿主上的其他 VM 的拒绝服务 28 | 29 | ## 2.2 针对虚拟机监视器的基线功能的潜在威胁 30 | 31 | 本节检查了虚拟机监视器的 5 种基线功能（除了 HY-BF3 以外）中的每一种的每一项任务，并且对于针对这些任务的安全执行的威胁通过与上一节中标识出的原因进行关联以加以分析。 32 | 33 | ### 2.2.1 _针对 HY-BF1 的潜在威胁_ 34 | 35 | 针对虚拟机监视器的 HY-BF1 功能（VM 进程隔离）的主要威胁是进程隔离突破（HYP-T1）。如 2.1 节所述，造成此威胁的原因之一是虚拟机监视器的设计漏洞。适用于此威胁的某些潜在设计漏洞在这里加以讨论，并且带有对于它们所可能表现出来的上下文环境的解释。每一种漏洞以符号 HYP-DV\# 标识，其中 HYP 表示虚拟机监视器，DV 表示设计漏洞，\# 表示编号。 36 | 37 | * _虚拟机控制结构（HYP-DV1）_：为了适当地计划某个独立 VM 的任务（即由于每个客户 VM 被分配给一组虚拟 CPU（vCPU），它们称为 vCPU 任务），寄存器状态必须被适当地处理。为了允许保存和加载每个 vCPU 的状态，虚拟机监视器使用一种称为虚拟机控制结构（VMCS）的数据结构。对此数据结构的错误实现已知能够导致虚拟机监视器内存泄漏 38 | * _处理敏感指令（HYP-DV2）_：在不提供虚拟化辅助的硬件平台上，应该有一种软件机制以发现敏感或者关键指令，将其发送至 VMM（虚拟机监视器），并且在硬件执行它们之前，利用诸如二进制翻译等技术将其替换为较为安全的指令。未能捕获关键指令或者错误翻译中发生的任何错误都可能拥有其形式为客户 OS 被允许执行高权限指令的安全性启示 39 | * _内存管理单元——MMU（HYP-DV3）_：虚拟机监视器运行一种基于软件的内存管理单元（MMU），它为每个 VM 分配影子页表，由于客户 VM 不能被赋予对于基于硬件的 MMU 的直接访问权限，由于这可能会潜在地允许它们访问属于虚拟机监视器和其他共同托管的 VM （在某些情况下）的内存。然而，基于软件的 MMU 的错误实现可能导致任意地址空间的数据泄漏，诸如属于虚拟机监视器和共同托管的 VM 的内存段，因此导致内存隔离突破 40 | * _输入/输出内存管理单元，IOMMU（HY-DV4）_：虚拟机监视器撬动硬件输入/输出内存管理单元以对使用直接内存访问（DMA）的设备驱动程序和进程强制实施内存隔离。此特性构建于虚拟机监视器之中，并且利用固件开关在硬件中启用。如果未被启用，它可能导致一种漏洞，在此，DMA 可以潜在地被某一 VM 用作普通攻击向量，以覆盖由其他 VM 和进程使用的物理内存 41 | 42 | 其中，漏洞 HYP-DV1 和 DYP-DV2 应该通过适当地编写代码和测试这些模块来解决。因此，没有安全性保护措施可以被应用于部署和使用阶段。然而，内存侵犯漏洞 HYP-DV3 和 DMA 侵犯漏洞 HY-DV4 可以通过在这样的硬件平台上托管虚拟机监视器来解决，此硬件平台分别通过对于虚拟化警觉的硬件内存管理单元和通过 DMA 传输重映射进行 DMA 传输来提供内存虚拟化辅助。由于这 2 种漏洞，威胁 HYP-T1，进程隔离突破，将会在第 4 章通过安全性建议 HY-SR-2 得到解决。 43 | 44 | 进一步地，正确执行隔离要求每一个 VM 获取其所托管的应用程序所必需的适当的内存和 CPU 资源，并且不会发生拒绝服务。通过适当的内存分配选项配置来保证足够的内存这一点将会通过安全性建议 HY-SR-3 得到解决。而通过 vCPU 分配选项的适当配置来保证适当的虚拟 CPU 分配这一点将会通过安全性建议 HY-SR-4 和 HY-SR-5 得到解决。 45 | 46 | ### 2.2.2 _针对 HY-BF2 的潜在威胁_ 47 | 48 | 在 VM 中执行的应用程序需要访问诸如网络和存储设备。对设备访问的调度在虚拟机监视器宿主中通过设备虚拟化（也称为 IO 虚拟化）来处理。有 3 种常见的设备虚拟化方式：(a) 模拟，(b) 准虚拟化，和 (c) 透传或者自虚拟化的硬件设备。 49 | 50 | 在模拟中，代码被如此实现以呈现某个虚拟设备，它拥有与之对应的真实（硬件）设备，客户 OS 已经拥有它的驱动程序。这允许运行未经修改的客户（VM），由此实现完全虚拟化。模拟代码运行于虚拟机监视器中。来自客户 VM 应用程序（通过其客户 OS）的 I/O 调用被虚拟机监视器内核拦截，并且转发到此代码，由于客户 VM 在此设置之下不能直接访问物理设备。这也可以将来自客户 VM 的模拟虚拟设备的访问多路传输至底层物理设备。 51 | 52 | 在准虚拟化方式中，虚拟机监视器向客户呈现某个人工设备的某个接口，此设备没有相应的硬件对应体。这允许在客户上安装特定的，简化的，对虚拟机监视器警觉的 I/O 驱动程序（称为准虚拟化的驱动程序）。来自客户 VM 中的这些准虚拟化的设备驱动程序的调用由另一个设备驱动程序（称为后端驱动程序）来处理，这些驱动程序直接与物理设备交互，并且调度来自准虚拟化的客户到该物理设备的访问。在某些实例中，来自准虚拟化的客户驱动程序的调用直接由虚拟机监视器通过其超级调用接口（与之相对应的调用称为超级调用）来处理。对于由这些超级调用产生的威胁的分析将于下一节提供。 53 | 54 | 设备虚拟化的第 3 种方式，透传方式（或者直接设备指认）被部署于这样的情形，在此，由于性能的原因，某个 VM 需要对于某个设备（例如 NIC、硬盘控制器、主机总线适配器（HBA）、USB 控制器、串口、火线控制器、声卡等）的专属访问，以避免由于模拟造成的开销。由于这对于外设组件互连标准（PCI）设备来说通常是必需的，它因此也称为 PCI 透传。由于这些设备中的很多拥有内存映射的接口，它们可以直接读取或者写入主内存，并且因此被称为具有直接内存访问（DMA）能力的设备。为了提供 VM 对于具有 DMA 能力的设备的专属访问，此设备的内存页被映射到客户 VM 的地址空间。随之而来的是由于具有 DMA 能力的设备而造成的威胁。 55 | 56 | _由于具有 DMA 能力的硬件设备而造成的威胁（HY-DV5）_：来自具有 DMA 能力的设备的安全性威胁在于，由于 VM 控制该设备，它可以编程该设备以执行 DMA 操作，指向任意物理（宿主）内存位置，包括属于其他 VM 或者虚拟机监视器的区域 \[6\]。因此，此类直接设备指认具有破坏 VM 之间的隔离（因而使得由 MMU 强制实施的隔离功能（作为 HY-BF1 的一部分）失去意义）的潜力。 57 | 58 | 除了上述 3 种类型的设备虚拟化之外，虚拟机监视器宿主还可以支持自虚拟化的硬件设备。这些设备拥有能够导出对应于某种物理功能（PF）的一组虚拟功能（VF）的接口。虚拟机监视器可以随后将这些 VF 指认给多个客户 VM，而它仍然保持对 PF 的控制。这些设备遵守单根 I/O 虚拟化（SR-IOV）规范，并且由此允许具有 DMA 能力的设备在 VM 之间共享（如同虚拟化和多路传输是由这些设备自身实现的）而非如同在透传模式中那样由单一 VM 专用。 59 | 60 | ### 2.2.3 _针对 HY-BF3 的潜在威胁_ 61 | 62 | 上一节呈现了这样一种场景，即准虚拟化，在此，虚拟机监视器必须通过其超级调用接口执行特定指令。关于超级调用的一个潜在的安全性问题在于，缺少对于特定操作的适当的验证（例如，不会验证操作范围，并且因此允许对于 VM 的虚拟机控制块进行完整转储），可能潜在地导致整个虚拟机监视器宿主崩溃。这也是一种设计漏洞，必须通过适当的验证和对相关的虚拟机监视器代码进行测试，而非通过配置或者部署过程来解决。 63 | 64 | ### 2.2.4 _针对 HY-BF4 的潜在威胁_ 65 | 66 | 对于此功能（即 VM 生命周期管理）之下的任务的安全执行的潜在威胁包括： 67 | 68 | * 非标准 VM 镜像在库中的存在，包括那些具有过时的 OS 和补丁的镜像，这可能导致任何平台层级的威胁（HYP-T1～HYP-T3） 69 | * 运行着的非标准 VM 实例的存在，由于其基于非标准镜像的创建、从快照恢复、由于监视中的疏忽而导致的对于标准的偏离，以及可能导致任何平台层级的威胁（HYP-T1～HYP-T3）的更新 70 | 71 | 在大多数实例中，对于 VM 的管理操作是利用通过 GUI 或者脚本环境提交的命令来执行的，二者均由位于后端的管理守护进程支持。上述操作的安全执行通过第 6 章的安全性建议 HY-SR9～HY-SR18 来解决。 72 | 73 | ### 2.2.5 _针对 HY-BF5 的潜在威胁_ 74 | 75 | 此功能之下的任务与虚拟机监视器宿主（即虚拟化的宿主）和虚拟机监视器软件的整体管理相关联，并且通常是通过对用户友好的网页界面或者面向网络的虚拟控制台来执行的。针对这些任务的安全执行的威胁常见于任何远程管理，并且因此并未在此文档中解决。然而，具有虚拟化的宿主的数据中心中的核心要求是拥有对于虚拟机监视器的基于不同判据的统一配置，诸如基于一组托管的 VM 的应用程序的敏感度、业务线，或者云服务环境中的客户端等。因此，这些安全性建议包括一种对于虚拟机监视器配置的中心化管理（HY-SR-19）和一种用于管理流量的专用网段（HY-SR-20）。 76 | 77 | 某些传统的安全性修补方式对于托管虚拟机监视器的宿主而言可能并不可行。例如，对于针对未被虚拟化的物理服务器的网络攻击，只要关闭发动攻击的端口即可成为阻止该服务器利用机器人攻击向网络发送垃圾信息的解决方案。然而，这样的解决方案对于虚拟机监视器宿主来说并不可行，由于虚拟机监视器宿主的物理网卡的相同端口可能由若干运行着的 VM 所共享。因此，一种特殊的安全性修复，诸如禁用使用这些端口的 VM 的虚拟 NIC 是必需的。 78 | 79 | -------------------------------------------------------------------------------- /the_impact_of_open_source_software_and_hardware/chapter_03.md: -------------------------------------------------------------------------------- 1 | # 3. 方法论概述 2 | 3 | ## a. 简介 4 | 5 | 由于尽管对于 OSS 的相关性的认可已有将近二十年（参见文献综述），仍然没有良好建立的方法论以衡量 OSS 的影响，一种基于若干支柱的方法论被开发出来。开发这样一种方法论的挑战对于 OSH 而言更高，由于缺少先前的研究和经验证据，尤其是数据。因此，对于 OSH 采取了一种独立的方法，它主要基于案例研究。 6 | 7 | 下图显示了我们的不同方法论的概述，以分析 OSS 和 OSH 及其不同影响，基于对于现存文献的完整综述。这些方法将会在后续章节中详细解释。此外，还举行了若干场研讨会，代表不同股东集团的一百多位专家在会上对于与案例研究和政策分析相关的方法进行了评审。 8 | 9 | ![图 3.1：方法论概述](images/image-008.png) 10 | 11 | ## b. 案例研究、商业模型和命名法 12 | 13 | 根据文献综述以及同专家的讨论，识别出了若干种命名法，包括商业模型命名法，它们潜在地同此研究的分析阶段相关。对于一系列有意义的命名法的采纳可以达到两种目的。主要目的是保证此研究以某种具有一致性的方式被执行，以使得可以在不同的项目之间进行有效的比较，既对于此研究期间获取的数据，也对于来自于现存来源的可用数据。次要目的是提议一种框架以辅助尤其是案例研究的数据采集，以最小化转换误差与假设的方式。 14 | 15 | 值得注意的是，尤其是与 OSH 相关时，已有数量有限的数据集合可用。尽管那些已经被用于采集这些现存数据集合的命名法可能对于我们的目的尚不理想，然而，在某些情况下，在不同的命名法之间进行转译是可能的，要么是直接转译，要么是带有相对少量的额外研究以及最小化的信息丢失。在某些情况下，并没有现存的命名法可用，因此要求开发出我们自己的命名法。在其他情况下，存在着互相竞争的命名法，因此必须选择或者采纳一种适当的命名法用于此研究。 16 | 17 | 在我们最初的专家会议召集期间，有些专家询问，将对于那些专注于商业化私有设计的组织的研究包括进来是否恰当，如果此研究专注于 OSS 和 OSH。看起来，对于 OSSH 的影响的底层研究问题的回答同样包括对于那些吸收并且利用开源的组织的考虑，即使它们所商业化的产品（全部或者主要地）并非开源。这导致了关于“开放性”是否应该以一种更加细致的方式而被考虑这一问题的考虑。在研讨会上讨论的正是关于“多么细致”的问题。类似地，“硬件性”这一概念的引入提示了这一点，即在关于 OSS 的数据采集和分析中存在更多价值，每当可能时使用和用于开放硬件相同的一套命名法。 18 | 19 | 其他命名法更加直白（诸如同地理相关的）或者是被整体引进以辅助同现存数据集合的整合的（例如，开源硬件协会（OSHA）用于其认证产品数据库的分类方法）。 20 | 21 | 这些命名法和商业模型分类法被用于数据采集和分析，既在桌面研究阶段，也在评审和调研阶段。 22 | 23 | 通过使用通过桌面研究和专家输入而获取的数据，若干主要项目被识别出来，并被选作五项案例研究。从这些项目之中，适当的项目被识别为案例研究的输入，并且执行了一系列评审。在五项案例研究中，五个相关的成功案例被识别出来并且详细叙述。基于这些案例研究，进行了一项基于行业领域案例研究的欧洲经济 SWOT 分析。 24 | 25 | 对于这些案例研究中的商业模型的分析与对于具有成功的基于 OSS 的商业模型的组织的概述，以及对于由 CrunchBase 提供的展示了受影响的部门和技术的多样性的初创企业的更大样本的描述的分析相互补充。最后，对于基于 OSH 的初创企业的较小的样本，进行了一项对于商业模型的深度分析。 26 | 27 | ## c. 经济影响分析：宏观和微观水平 28 | 29 | 由于文献综述揭示了 OSS 的若干种影响维度，不同的方法被应用于应对不同层级上的不同影响维度。 30 | 31 | 起始点是由 GitHub 提供的数据库，它是最重要的开源版本库。从 GitHub 开发者平台获取的 OSS 数据由 TU Delft 在 GHTorrent 项目（）的上下文环境中提供。此来源特别地有希望，并且因此也成为我们关于获得 OSS 的经济影响的方法论的主要数据库。作为最大的 OSS 项目版本库，GitHub 提供了关于各个国家和组织之间的 OSS 流行度的独特的系统化数据。诸如 GitLab 和 Software Heritage 等其他数据库当前尚未提供足够的数据。GitHub 作为数据库的相关性和稳定性是由日益增长的提到 GitHub 的论文数量支撑的。我们的经济分析仅仅涵盖了直到 2018 年的数据。因此，GitHub 被微软接管一事对于我们的分析的影响极小。 32 | 33 | 然而不幸的是，关于 OSS 代码的扩散的数据基本上不可获得。但是，如同在文献综述中所概述的那样，OSS 可以被看作用户创新或者开发者和用户之间的某种形式的共创。因此，对于 GitHub 上的 OSS 代码的贡献也能反映出它们的使用情况。因此，我们提议依赖于对于 GitHub 上的代码的贡献，根据 Nagle (2019a) 和其他人的研究，这些研究假设对于 OSS 的贡献同样会导致 OSS 的实现。在下一步中，这同样促进了对于贡献者的研究，由于他们从更有经验的用户人群中收到反馈，因此能够更好地从物品的使用中捕获价值 (Nagle 2018)。 34 | 35 | 由 GitHub 提供的数据将会被用于不同目的。超过 10 亿项提交和超过 3000 万名用户的庞大数量能够生成对于所有欧盟成员国的足够长的、鲁棒的时间序列。这些时间序列被用作宏观经济学面板回归的输入，这允许我们确定 OSS 对于欧盟的 GDP、劳动生产率、竞争性、创新以及市场准入等等的影响。基于 GitHub 活跃用户的提交贡献，有可能计算出 OSS 的宏观经济学影响，它整合了全部的直接与间接影响。然而，由于来自诸如 Eurostat 和 OECD 等得到高度认可的组织的可用宏观经济学变量并非专注于 OSS，而是在总体上关于经济，某些宏观经济学模型并不能产生重大结果。然而，在欧盟成员国的层级上，有可能识别出贡献者和提交的数量，这允许我们计算出必要的投资以作为在欧盟生产 OSS 的成本基线。这些成本数字被同基于这些投资所创造的 GDP 相关联，并且最终用于确定成本收益比例。 36 | 37 | 此外，由 GitHub 提供的数据同样被用于更加分散的级别，即组织级别。在超过 3200 万名用户中，有 60 多万是挂靠到诸如公司、基金会等组织以及项目的。然而，项目级别并不适合于 OSS 经济影响的分析，由于它们不能归属于具体国家或者整个欧盟，并且没有外部金融数据可用于项目级别。因此我们决定专注于组织，或者更好地，公司以进行微观级别的分析。它被浓缩至具有最多的用户或者贡献者数量的 1 万多个组织。它们吸引了在 GitHub 显示为挂靠到某个组织的用户的三分之一强。将这些组织同 Amadeus 公司数据库相匹配，产生了将近 2000 家位于欧洲的，或者与某个欧盟成员国相关联的公司。 38 | 39 | 最终，这些公司中的 1000 多家的 2018 年营业额和雇员数量可获得。这一信息同用户，即雇员，以及他们的提交数量相匹配。因此，通过部门、雇员以及营业额的类别将这些公司区分开来是可能的。最终，这些公司对于 OSS 的投资被计算出来，并且与它们的收益相比较，以作为一种成本收益分析。 40 | 41 | 最后，股东调研中也有一个用于确定成本收益比例的部分。这些比例被再次同宏观和微观经济学成本评估的发现相关联，并且被用于验证目前确定的成本收益比例。 42 | 43 | ## d. 股东调研 44 | 45 | 如同上文所示，我们的方法论中的另一个重要元素是完整的股东调研的效果。股东调研的目的是收集并分析大范围股东对于 OSS 和 OSH 的影响这一话题的看法，由此创建一种对于至关重要的看法和问题的鲁棒的经验表达。此外，由来自文献、数据库和案例研究的见解驱动的评估 OSS 和 OSH 的影响的方法通过来自股东调研对象的输入而得到补充。 46 | 47 | 实施了下列步骤： 48 | 49 | 1. 以基于事先完成的研究（诸如文献检索、案例研究设计和现存数据调研等）的问卷设计开始 50 | 2. 利用基于网页的工具编程设计问卷 51 | 3. 实地测试该调研 52 | 4. 通过设置联系人数据库准备将问卷送达调研参与者 53 | 5. 通过将问卷并加上两条提示信息发送至不同社区和目标团体而执行调研 54 | 6. 利用代表最先进技术的软件和统计技术分析结果 55 | 56 | 调研结构如下所示： 57 | 58 | * 回答问卷的个人的职位 59 | * 关于该组织的基本信息（包括关于软硬件规模和商业模型的立场，创新行为等） 60 | * 关于保护该组织或者企业单位的专门技能的策略 61 | * 对于 OSSH 的参与 62 | * 该组织对于 OSSH 的参与形式 63 | * 对于加入 OSSH 开发的激励的相关性 64 | * 版权许可证的作用 65 | * 对于 OSSH 在其中被使用、集成、开发或者参与的领域的区分 66 | * OSSH 带来的成本和收益 67 | * 额外评论，包括对于欧洲联盟委员会对于开源的潜在支持的建议 68 | 69 | ## e. 最终分析 70 | 71 | 所有不同分析方法的见解被用于分析和验证最终发现。因此，那些主要是自上而下的，尤其是来自宏观经济学层级的基于经济学分析的主要是定量的发现，通过自下而上生成的，来自股东调研以及最终来自案例研究的主要是定性的见解而加以分析。 72 | 73 | 因此，经济学分析的结果首先被汇总，随后在以下章节通过股东调查汇总，以及最终通过案例分析而得到补充。最后，这些发现根据参与 OSS 或者 OSH 的股东、主题，以及最终根据影响维度而被组织起来。 74 | 75 | 这些基于不同来源或者证据的发现构成了得出一般性以及具体话题的政策建议的基础。 76 | 77 | ## f. 公共政策分析 78 | 79 | 政策分析的主要目标是识别在目标国家对开源造成影响的相关公共政策行为与因素。在定义用于公共政策研究的最终指标时，对于导出政策建议的需求已经被考虑。用于公共政策分析的目标国家遍布全世界，并且由此展示了对于开源的不同方法。 80 | 81 | 首先，为了识别相关行为，有必要依赖于不同信息来源。开源不是一个主流公共政策领域，因此关于它的信息通常并非广泛可用，尤其是在各个国家的水平上。为了收集必要的信息，我们利用了学术来源、专家访谈、政府来源和专业研究的组合。这些基于各个国家的水平而加以调整。 82 | 83 | 尽管在某些国家，学术资源可以获得，并且执行了相对深度的研究，而在其他国家，就大多数国家而言，学术资源不可用。尽管如此，仍有约 150 篇学术论文被筛选出来以用于政策分析的目的。专家访谈是第二重要的信息来源。 84 | 85 | 专家能够以更加非正式的方式提供信息，提供关于政策行为的成功与失败的上下文环境和背景以及信息，并且因此对于理解未成文法律和文化特殊性，以及在影响到不同国家之间的公共政策的语言鸿沟之间架设桥梁等方面至关重要。专家还能为研究带来重要的起跑优势，发挥事半功倍的作用，以及提供关于学术和政府来源的重要信息。出于公共政策研究的目的，我们进行了超过 50 场专家访谈。这些访谈基于半结构化的问卷。 86 | 87 | 政府，尤其是在民主国家，通常以政府报告、策略文件与法律等形式为其自身提供大量关于政策行为的信息。这是用于政策行为的内容分析的重要工具。此外，咨询公司和其他专业服务通常也能提供关于政策行为的重要信息。 88 | 89 | 除了识别政策行为及其内容外，为了能够通过此分析得出结论以及将其用于制定公共政策建议，我们进行了政策行为比较。 90 | 91 | 这样一种比较使得收集可供比较的信息成为必需。因此，数据采集基于一种横跨所有案例的通用分析框架，它于下文概述，并且在公共政策分析的一章中进一步详细叙述。此分析围绕两种维度而构建——其一是围绕针对公共部门公共政策行为，其二是针对私营部门。 92 | 93 | 数据基于此框架而被采集和分析。这种比较基于通过以上维度和判据得出的指标标识出了公共政策行为的扩展性。因此，每个被分析的国家都拥有一段详细的国家报告以及基于其政策扩展性的相对得分。 94 | 95 | 表 3.1 公共政策分析框架 96 | 97 | | 维度 | 判据 | 98 | | --- | --- | 99 | | 关于有关公共权力机构如何在其自身组织中实现 OSS 和 OSH 的针对公共部门的政策 | \* 政策在整个司法程序中的规定性等级
\* 公开采购政策考虑 OSSH 的程度
\* 政策被执行的有效性
\* 关于公共权力机构中的 OSS 和 OSH 的竞争性等级 | 100 | | 关于有关公共权力机构如何与其他参与者，尤其是私营部门中的参与者接洽的针对私营部门的政策 | \* 司法部门在多大程度上支持私人参与者采用并开发 OSS 和 OSH
\* 司法部门在多大程度上使得指导原则对于私人参与者可用
\* 司法部门的行政管理机构是否关于 OSS 和 OSH 社区发挥作用（以及如果是，发挥什么作用）
\* OSS 和 OSH 在多大程度上被相邻政策领域考虑 | 101 | 102 | ## g. 政策建议 103 | 104 | 在整个工作中，核心团队成员之间就可能的观察以及关于建议和结论的想法存在持续不断的意见交换。核心团队职员同样在很大程度上参与实地工作，以确保全体团队成员得到“全景”，而非以孤立的方式局限于特定任务而不知更为宽泛的上下文环境。来自政策分析和比较的结果对于得出政策建议具有重大作用。在常规团队会议期间，新想法、结论以及建议的选项被讨论。一旦有了来自不同方法的第一批结果，它们被基于不同的证据基础分析，以便权衡每一种方法的利弊。在所有相关阶段，决策咨询成员作为我们的想法和建议的切磋对象而参与进来。特别地，五场研讨会提供了对于导出政策建议的有价值输入。最后，进度报告与同欧洲联盟委员会的会议使得关于朝向这些建议的开发进展的意见交换成为可能。 105 | 106 | 这一系列有限但是良好定义的建议基于反映了对于基于证据的建议的请求的先前工作的输出而被导出。特别地，对于影响的分析揭示了关于首先是公共政策措施合理化，其次是作为这些政策措施的目标群体，例如小微企业和中小企业而参与 OSS 和 OSH 的股东的见解。这些案例研究、SWOT 分析和股东调研为政策措施应该专注的特殊领域，以及欧洲联盟委员会应该专注的方法提供了见解。 107 | 108 | 公共政策分析提供了结构化的，基于指标的概览，不仅对于现存的政策措施，它可能需要被扩展或者适配，也对于来自其他国家的应当被欧洲联盟委员会考虑的最佳实践。 109 | 110 | 总的来说，这一需求被识别为既针对 OSSH 相关的具体政策倡议，也针对将 OSSH 政策方面整合到诸如教育、竞争或者公共采购等其他政策倡议之中。每当可能时，这种分析被独立执行于诸如人工智能等新兴技术以及部门应用中。由于 OSS 对于 IT 安全具有高度影响，这些建议是通过与面向提供安全且可信的 ICT 解决方案的 OSS 与 OSH 联合贡献相关联而得出的。最后，OSS 对于公共部门具有巨大潜力，并且这些建议是针对加强 OSS 在可互操作的解决方案与公共服务的开发中的作用而得出的。 111 | 112 | -------------------------------------------------------------------------------- /nist_sp_800-193/chapter_2.md: -------------------------------------------------------------------------------- 1 | # 第 2 章 平台架构 2 | 3 | 确保平台的固件代码和关键数据总是处于某种具有完整性的状态对于确保一台计算系统可以不受恶意软件困扰地运作至关重要。现代客户端和服务器计算系统可以看作分为两层高级架构，_平台_ 和 _软件_。出于此文档的目的，我们会将这两层逻辑架构的组合描述为系统。注意，图 1 只是示意性的，其本意并非为了表示平台中所有可能的设备，也不是为了表示任何特定设备的范例架构。在较高层级上，蓝色阴影方框中的项目是将要被视为平台的一部分的设备。 4 | 5 | 宽泛地说，_平台_ 是由将系统启动至软件和操作系统可以被加载的阶段所必需的硬件和固件构成的；_软件_ 是由加载操作系统以及操作系统随后处理的所有应用程序和数据所要求的元素构成的。注意，某些固件在软件启动之后继续执行。现存的业界最佳实践，以及诸如 NIST SP800-147，_BIOS 保护指南_ \[1\]、NIST SP800-147B，_服务器 BIOS 保护指南_ \[2\] 等 NIST 出版物已经着手应对保护平台的宿主处理器启动固件（传统上称为 BIOS，近来称为 UEFI \[3\]）（脚注 1）的完整性及其更新机制的问题，但是，保护只是网络弹性的三大关键元素之一（另外两个是检测和恢复）。此外，平台上的其他关键固件的弹性的解决程度并未达到宿主处理器启动固件的对应程度。尽管识别和定义包含固件的硬件的每一种类别和架构超出了此文档的范围，此文档适用于任何包含固件的平台中的设备，包括个人计算机、服务器、网络设备、智能电话、平板等。 6 | 7 | > 脚注 1：出于此文档的目的，宿主处理器启动固件将会被一般性地指代传统基本输入/输出系统（BIOS）或者统一可扩展固件接口（UEFI）。 8 | 9 | ## 2.1 平台设备 10 | 11 | 如上文所述，平台是提供操作系统和应用程序所需的功能能力和服务的一系列设备。尽管作为一个整体的平台的弹性是终极目标，认识到平台是由众多不同设备构成的，并且通常是由不同厂商开发和制造的是至关重要的。基于此原因，此文档中的技术指导意见以面向独立平台设备的指导意见的形式描述。 12 | 13 | 为了描述具有弹性的平台，本节提供了通常对于平台的正常和安全运作至关重要的设备的列表。这些设备通常包含可变的固件，并且被此文档中的安全性指导意见的预想范围所覆盖。 14 | 15 | 然而，这不应该被视为每一种感兴趣的平台中的所有设备的完整列表。平台厂商需要仔细考虑那些应该被视为处于它们的特定平台范围中的其他设备。 16 | 17 | 在传统的基于 x86 的平台（台式机、笔记本、服务器、网络交换机）的情况下，这些设备标识于图 1 中，并且于下文定义。注意，这里的编号指的是用于在图 1 中标识这些设备的编号，其顺序并非为了指示任何优先级或者次序。 18 | 19 | 1. **嵌入式控制器（EC）/ Super I/O（SIO）** 20 | 21 | EC 通常与移动平台（笔记本、变形本、平板）相关联，而 SIO 通常与基于桌面的平台（台式机、基于桌面的工作站、一体机、瘦客户端）相关联。这并非普遍确切，但是通常足够确切以确定在某种类型的客户端系统中能够找到 EC 还是 SIO。EC 或者 SIO 通常控制平台中的诸如键盘、指示灯、风扇、电池监测/充电、散热监测等功能。此外，它通常是平台中的首个执行代码的系统板载设备，甚至会使得宿主处理器处于重置状态，直到 EC / SIO 准备就绪以允许宿主处理器获取它的首行宿主处理器固件代码。 22 | 23 | 2. **可信平台模块（TPM）** 24 | 25 | TPM \[4\] 是一块能够安全地存储和使用密码学密钥以及平台状态测定数据的安全协处理器。这些能力可以被用于在其他事物之中保护存储于系统上的数据、提供强壮的设备身份，并且验证系统状态。尽管并非所有平台都包括或者使用 TPM，在任何包括并且使用 TPM 的系统上，它的固件必须被保护，鉴于它在帮助确保平台的可信度方面的至关重要性。TPM 还包含非易失性存储器，它可以包含关键数据，并且如果是这样，它必须被保护。TPM 可以是独立的硬件设备，也可以被实现在平台的主机控制器或者其他微控制器所执行的固件中（后者有时被称为固件 TPM 或者 fTPM）。 26 | 27 | 3. **基板管理控制器（BMC）/ 管理引擎（ME）** 28 | 29 | BMC 与服务器平台相关联，而 ME 通常与客户端平台相关联。在这两种情况下，其功能的核心方面是作为一种带外管理设备，以允许管理员管理一个平台而无需要求宿主操作系统运行。尽管对于服务器或者客户端平台的基本计算功能而言并非总是严格必需，大多数现代服务器和客户端平台包含 BMC / ME，使得它们的固件不会对宿主处理器的安全域的完整性状态造成负面影响这一点至关重要。 30 | 31 | 4. **宿主处理器【又称为中央处理器（CPU）、应用处理器（APU）】** 32 | 33 | 宿主处理器是通常平台中的处理单元，在传统上称为 CPU，现在有时也称为 APU 或者系统芯片（SoC）。这是主操作系统（和/或虚拟机监视器）以及用户应用程序所运行的处理单元。这是负责加载并执行宿主处理器固件的处理器。 34 | 35 | 5. **网卡（NIC）** 36 | 37 | 不论是独立的还是作为 SoC 的一部分而集成的，大多数现代客户端和服务器平台拥有至少一块 NIC（有线或者无线），并且可能拥有多块，包括多种类型（有线、Wi-Fi、蜂窝）。尽管拥有一块 NIC 对于启动一个平台并非严格必需，在当今的互联世界中，在系统启动之后的某个时间点拥有某种形式的连接性是至关重要的。更为重要的是，受到攻击的 NIC 固件镜像可以作为对系统中的其他漏洞的利用的发射台，被用于窃取数据、作为中间人等。除了由微控制器运行的固件以外，NIC 可能还包含在启动过程中加载并且由宿主处理器执行的扩展只读存储器（ROM）固件。NIC 的扩展 ROM 固件同样受到保护是至关重要的。此扩展 ROM 固件可以同宿主处理器启动固件一同存储（对于集成 NIC 的情况），或者对于作为扩展卡的情况，可以独立存储于 NIC 本身。NIC 通常还包含关键数据，例如，介质访问控制（MAC）地址可能存储于可变存储器中。针对此关键数据的攻击可能导致针对此平台以及具有匹配的 MAC 地址的另一台系统的拒绝服务（DoS）。 38 | 39 | 6. **图形处理器（GPU）** 40 | 41 | GPU 是作为客户端平台中的主要“输出型”人体学接口设备（HID）的设备。在某些情况下，GPU 也可以被用作协处理器以支持高性能计算。GPU 可以作为对系统中的其他漏洞的利用的发射台。除了由微控制器运行的固件以外，GPU 可能包含在启动过程中加载并且由宿主处理器执行的扩展 ROM 固件。此扩展 ROM 固件可以同宿主处理器的启动固件一同存储（对于集成 GPU 的情况），或者对于作为扩展卡的情况，可以独立存储于 GPU 本身。 42 | 43 | 7. **串行外设接口（SPI）闪存** 44 | 45 | 大多数现代平台包括一定数量的 SPI 闪存以存储固件，通常是用于宿主处理器的启动固件，尽管它也可被用于其他目的。 46 | 47 | 8. **A）用于大容量存储设备的主机控制器（HC）** 48 | 49 | 对于大多数现代平台，需要有某种采用硬盘（HDD）或者固态硬盘（SSD）形式的本地大容量存储设备以启动操作系统并且存放用户的应用程序和数据。为了使得数据能够被存储到该大容量存储设备上，主机控制器（HC）被用于通过某种存储总线（例如 SATA、SCSI、PCIe）将数据从平台的主内存中移至物理存储介质中。HC 可以被集成到 SoC 中，也可以是独立的设备或者位于扩展卡上。 50 | 51 | **B）硬盘（HDD）/ 固态硬盘（SSD）** 52 | 53 | HDD 或者 SSD 代表了当前用于存储大量数据的传统平台中的最先进技术。这些设备与主机控制器（HC）相耦合。在 HDD 或者 SSD 内部，微控制器及其相关联的固件被用于执行将数据从平台的主内存发送至大容量存储设备的实际存储操作。对 HDD 或者 SSD 的固件的攻击同样可以用作对系统中的其他漏洞的利用的发射台，也可以被用于攻击用户和/或平台数据。 54 | 55 | 9. **嵌入式多媒体存储卡（eMMC）/ 通用闪存存储（UFS）** 56 | 57 | eMMC 和 UFS 作为移动系统的标准大容量存储设备而出现。它们中的每一种都可以包含它们自己的扩展 ROM 固件和/或带有与之相关联的固件的微控制器。 58 | 59 | 10. **宿主处理器启动固件** 60 | 61 | 在大多数现代平台中，宿主处理器启动固件包含在 SPI 闪存设备中。BIOS 和统一可扩展固件接口（UEFI）是此类固件的范例。 62 | 63 | 11. **平台运行时固件** 64 | 65 | 除了启动固件以外，还有平台运行时代码。此代码在平台启动以后仍然驻留在内存中并且可执行。这对于在系统完全运行时需要执行固件以执行某些功能的微控制器而言最为常见。被看作运行时代码的宿主处理器固件的一个范例是系统管理模式（SMM）代码。 66 | 67 | 12. **电源** 68 | 69 | 某些电源拥有它们自己的微控制器和与之相关联的固件。通常的电池架构还包括内部逻辑和固件以管理该电池的充放电行为。 70 | 71 | 13. **粘合逻辑（CPLD、FPGA）——_未在图中显示_** 72 | 73 | 现代嵌入式系统使用可编程的逻辑组件以提供粘合逻辑功能。有两种类型的可编程逻辑组件，称为 FPGA 的现场可编程逻辑门阵列和称为 CPLD 的复杂可编程逻辑器件。FPGA 通常在加电时通过比特流程序从所连接的闪存设备中加载。而 CPLD 由比特流进行一次编程并且保持其功能，直到在现场被再次编程。通常，此功能是系统的基本操作所需要的，如果损坏，可能导致平台的永久拒绝服务。 74 | 75 | 14. **风扇——_未在图中显示_** 76 | 77 | 某些风扇拥有其自身的微控制器及其相关联的固件。 78 | 79 | ## 2.2 平台设备中的代码和数据 80 | 81 | 上述设备通常在其非易失性存储器中拥有某些固件和数据的组合，它们可以驻留在设备本身，或者位于共享存储设备（例如 SPI 闪存）。本节描述固件代码和数据，并且简要讨论此文档与这些组件相关的范围。 82 | 83 | ### 2.2.1 代码 84 | 85 | 固件代码是由任何设备的处理单元所使用以执行由设备所要求的操作的指令的集合。在历史上，平台设备中的固件极少在现场被修改，尽管系统或者组件厂商可以开发固件更新以便为漏洞打补丁、修复 bug 或者添加新功能。随着固件的复杂度增加，固件更新变得更加普遍，而硬件和操作系统厂商提供工具以帮助管理员更新他们的固件。 86 | 87 | 由于固件在很大程度上驱动着设备的行为，使其在平台上保持处于可信状态至关重要。针对固件代码的攻击可能使得设备不能运行，或者向设备中注入恶意功能。固件应该仅从授权的来源加载，通常是系统或者平台设备的制造商。 88 | 89 | 此文档中的指导意见描述了通过利用数字签名验证更新来保护固件的机制。它们还描述了检测针对固件的非授权修改的机制以及安全恢复的方法。 90 | 91 | ### 2.2.2 数据 92 | 93 | 数据是平台固件代码用以执行其操作的信息片断，如同其代码所指示。数据可以进一步分为关键和非关键。关键数据包括配置设置和策略，它们需要处于有效状态以使得设备维持其安全状态。非关键数据包括所有其他数据。 94 | 95 | #### 2.2.2.1 关键数据 96 | 97 | 关键数据可以被用于不同目的，包括： 98 | 99 | * **配置设置**：这些数据告知代码如何配置设备的操作方面 100 | * _范例_：启用某个被企业安全策略禁止的外设 101 | * _范例_：硬盘中的不可用扇区表 102 | * **策略**：这些数据告知代码选择何种路径或者如何响应 103 | * _范例_：系统的启动顺序描述了尝试用于启动的有效设备及其顺序 104 | * _范例_：UEFI 安全启动，一系列安全性配置以控制 BIOS 将控制权移交给哪些第三方代码 105 | 106 | 关键数据难于精确定义，由于对于某一设备可能属于关键的数据对于其他设备可能并非关键。然而，关键数据的共同特征包括： 107 | 108 | * 它必须处于有效状态以允许设备的正常启动和运行时操作 109 | * 它在加电周期之间持续存在（例如存储于非易失性存储器中） 110 | * 它会改变设备的行为或者功能 111 | * 它必须处于有效状态以支持平台固件及其相关联的数据的保护、检测和/或恢复 112 | 113 | 某些关键数据被硬编码到代码中，并且仅可通过固件镜像更新而更新。出于此文档的目的，硬编码的数据被看作代码的一部分，并且根据固件代码的保护、检测和恢复指导意见来保护。 114 | 115 | 平台设备通常拥有在其正常操作时可由平台管理员、硬件、固件或者软件配置的其他数据。由于关键数据的损坏可能影响系统的正常或者安全运作，保护关键数据防止损坏，并且能够在检测到问题时进行恢复是至关重要的。然而，对于某些形式的关键数据的强保护可能在架构上难于实现，由于这样一些期望，即诸如操作系统以及设备驱动程序等某些实体拥有更改这些设置的访问权限。 116 | 117 | 某些配置数据只能通过由平台层级的代码控制的限定的接口来更改，例如，UEFI 运行时变量属于此类。这一基本层级的保护可以防止攻击者直接修改配置数据，并且允许平台固件在将更改提交至存储设备之前验证其输入。然而，某些实体可能能够利用这些限定的接口来作出格式良好但却是恶意的配置更改。 118 | 119 | 为了防止这样的破坏，针对某些特别敏感的配置数据的更改可以要求在使用上述限定的接口应用更改之前通过授权。在某些情况下，诸如宿主处理器启动固件或者服务处理器固件等平台设备可能能够先于允许平台管理员作出更改对其进行认证。其他认证技术可以允许平台固件对更改的来源和完整性进行密码学验证。 120 | 121 | 某些关键数据由不会通过外部接口暴露为可编程的固件管理（例如耗损平均技术数据），并且如果丢失或者损坏，可能导致设备功能永久丧失。此类状态数据需要在最高层级进行保护，并且不可从平台的其他位置写入。 122 | 123 | #### 2.2.2.2 非关键数据 124 | 125 | 非关键数据可以被用于不同目的，包括： 126 | 127 | * **信息性 / UI**：这些数据仅是信息性的，或者用作最终用户的用户界面（UI）的一部分 128 | * _范例_：在启动过程中显示名为“Property of NIST”的财产标签 129 | * **状态**：不会影响平台完整性的状态设置 130 | * _范例_：系统启动时的数字锁定键的状态；BIOS 执行快速启动还是标准启动 131 | 132 | 非关键数据对于平台的安全启动或者操作不应该具有决定性。在实践中，所有由平台固件消费的数据都可能是安全敏感的，包括某些并不直接影响平台的正确和安全操作的数据。由平台固件消费的任何数据的错误或者对其的恶意攻击都可能暴露并且利用该代码中的漏洞。就其本身而言，对于由平台消费的任何非可信输入或者数据需要给予特别的关照。 133 | 134 | -------------------------------------------------------------------------------- /nist_sp_800-147/chapter_2.md: -------------------------------------------------------------------------------- 1 | # 第 2 章 背景 2 | 3 | 诸如台式机和笔记本等现代计算机包含辅助硬件初始化过程的程序代码。该代码存储于非易失性存储器中，并且通常被称为启动固件。用于初始化系统的主要固件称为基本输入/输出系统（_BIOS_）或者 _系统 BIOS_。本章提供了关于系统 BIOS 及其在启动过程中的作用的背景信息并且使用传统 BIOS 和统一可扩展固件接口（UEFI）BIOS 作为范例。它识别了用于更新系统 BIOS 的主要方法，以及关于系统 BIOS 的安全问题和威胁。 4 | 5 | ## 2.1 系统 BIOS 6 | 7 | 当计算机加电时，系统 BIOS 是主要中央处理器（CPU）所执行的第一个软件。尽管系统 BIOS 最初负责为操作系统提供硬件访问，它在现代设备上的主要职责是初始化并测试硬件组件以及加载操作系统。此外，系统 BIOS 加载并且初始化重要的系统管理功能，诸如电源和散热管理。系统 BIOS 可能还会在启动过程中加载 CPU 微码补丁。 8 | 9 | 有若干种不同类型的 BIOS 固件。某些计算机使用 16 位的传统 BIOS，而众多较新的系统使用基于 UEFI 规范 \[UEFI\] 的启动固件。在此文档中，我们将所有类型的启动固件称为 BIOS 固件、系统 BIOS 或者简称为 BIOS。如有必要，我们将会通过将其分别称为传统 BIOS 和 UEFI BIOS 来区分传统 BIOS 固件和 UEFI 固件。 10 | 11 | 系统 BIOS 通常由原始设备制造商（OEM）和独立 BIOS 厂商开发，并且随计算机硬件分发到最终用户。制造商频繁更新系统固件以修复 bug、为漏洞打补丁以及支持新硬件。系统 BIOS 通常存储于电可擦除可编程只读存储器（EEPROM）或者其他形式的闪存中，并且可由最终用户修改。一般来说，系统 BIOS 固件通过使用某种对于 BIOS 所存储于其中的非易失性存储器组件拥有特别知识的工具来更新。 12 | 13 | 一台给定的计算机系统可能在若干不同的位置拥有 BIOS。除了主板以外，BIOS 可以在硬盘控制器、显卡、网卡和其他扩展卡中找到。这种额外的固件通常采用 Option ROM 的形式（包含传统 BIOS 和/或 UEFI 驱动程序）。它们在启动过程中由系统固件加载并执行。其他系统设备，诸如硬盘和光驱，可能拥有它们自身的微控制器和其他类型的固件。 14 | 15 | 如同 1.2 节所注释的那样，此文档中的指导意见适用于存储于系统闪存中的 BIOS 固件，这包括随系统 BIOS 固件一起保存并且由相同机制更新的 Option ROM 和 UEFI 驱动程序。它并不适用于存储于计算机系统的其他位置的 Option ROM、UEFI 驱动程序和固件。 16 | 17 | ## 2.2 系统 BIOS 在启动过程中的作用 18 | 19 | 系统 BIOS 的主要功能是初始化重要硬件组件以及加载操作系统，此过程称为启动。系统 BIOS 的启动过程通常在以下步骤中执行： 20 | 21 | 1. 执行核心可信根：系统 BIOS 可能包括一小块核心固件，它首先被执行并且能够验证其他固件组件的完整性。它在传统上曾经被称作 BIOS 启动块。对于可信计算应用程序，它还可以包含用于测定的核心可信根（CRTM） 22 | 2. 初始化并测试低级硬件：在启动过程的极早期，系统 BIOS 初始化并测试计算机系统中的关键硬件，包括主板、芯片组、内存和 CPU 23 | 3. 加载并执行额外组件模块：系统 BIOS 执行额外的固件，这些固件扩展了系统 BIOS 的能力或者初始化系统启动所必需的其他硬件组件。这些额外的模块可能存储于和系统 BIOS 相同的闪存中，或者可能存储于它们所初始化的硬件设备中（例如显卡、局域网卡等） 24 | 4. 选择启动设备：当系统硬件被配置后，系统 BIOS 查找一个启动设备（例如硬盘、光驱、USB 驱动器等）并且执行存储于该设备上的引导程序 25 | 5. 加载操作系统：在系统 BIOS 仍然控制计算机时，引导程序开始加载并且初始化操作系统内核。一旦内核开始发挥功能，计算机系统的主要控制权就从系统 BIOS 移交给操作系统。 26 | 27 | 此外，系统 BIOS 加载系统管理中断（SMI）处理程序（又称为系统管理模式（SMM）代码），并且初始化高级配置与电源接口（ACPI）表和代码。它们为运行着的计算机系统提供重要的系统管理功能，诸如电源和散热管理。 28 | 29 | 本章描述基于传统 BIOS 的系统以及基于 UEFI 的系统中的启动过程。尽管传统 BIOS 被应用于当今所部署的众多台式机和笔记本，业界已经开始过渡到 UEFI BIOS。 30 | 31 | ### 2.2.1 传统 BIOS 启动过程 32 | 33 | 图 1 展示了运行传统 BIOS 的 x86 兼容系统的一种典型启动过程。传统 BIOS 通常在 16 位实模式中执行，尽管某些后期的实现在保护模式中执行。某些基于传统 BIOS 的固件拥有一小块这样的 BIOS 固件——称为 BIOS 启动块——它在逻辑上同 BIOS 的其余部分相分离。在这些计算机系统上，该启动块是启动过程中最先被执行的固件。启动块负责检查其余 BIOS 代码的完整性，并且可能提供恢复机制，如果主板 BIOS 固件损坏。在大多数可信计算架构中，BIOS 启动块作为该计算机系统的 CRTM，由于此固件被隐含地信任，以便自举在本机上执行的其余固件和软件的后续验证的测定链的构建过程 \[TCG05\]。 34 | 35 | 启动块执行传统 BIOS 中用于初始化大部分硬件组件的那部分代码——加电自检（POST）代码。在 POST 过程中，计算机系统中的关键低级硬件被初始化，包括芯片组、CPU 和内存。系统 BIOS 初始化显卡，它可能加载并执行其自身的 BIOS 以初始化图形处理器及其内存。 36 | 37 | > 图 1 传统 BIOS 启动过程（脚注 1） 38 | 39 | > 脚注 1 此图基于可在 \[Duarte08\] 中找到的信息和示意图 40 | 41 | 接下来，系统 BIOS 查找其他外设和微控制器，并且执行这些组件上的任何必需的 Option ROM 以初始化它们。Option ROM 在启动过程的非常早期被执行，并且可以为启动过程添加一系列特性。例如，网络适配器的 Option ROM 可以加载预启动执行环境（PXE），它允许一台计算机通过网络启动。 42 | 43 | 接下来，系统 BIOS 搜索计算机系统以查找已被标识为启动设备的存储设备。在通常情况下，BIOS 试图从它所找到的第一个拥有有效的主引导记录（MBR）的启动设备启动。该 MBR 指向存储于硬盘上的引导程序，它随之开始加载操作系统的进程。 44 | 45 | 在启动过程中，系统 BIOS 加载 SMI 处理程序并且初始化 ACPI 表和代码。SMI 处理程序在 CPU 上以一种特别的高权限模式运行，称为系统管理模式，这是一种 32 位模式，它可以绕过保护模式的众多硬件安全机制，诸如内存分段和页保护。 46 | 47 | ### 2.2.2 UEFI 启动过程 48 | 49 | 在较高层级上，如图 2 所示的 UEFI 启动过程遵循一种同传统 BIOS 启动过程相似的流程。区别之一是 UEFI 代码在 CPU 上以 32 位或 64 位保护模式运行，而非以传统 BIOS 中经常出现的 16 位实模式。大多数基于 UEFI 的平台始于一小块核心代码，它主要负责认证计算机系统上随后执行的代码。这与传统 BIOS 中的启动块的作用非常相似。这部分启动过程称为安全（SEC）阶段，并且作为计算机系统的核心可信根。 50 | 51 | > 图 2 UEFI BIOS 启动过程 52 | 53 | UEFI 启动过程的下一个阶段是前 EFI 初始化（PEI）阶段。PEI 阶段的本意是要初始化关键系统组件，诸如处理器、芯片组和主板。在某些情况下，安全阶段和 PEI 阶段的代码构成了 UEFI 系统中的核心可信根。 54 | 55 | PEI 阶段的目的是为驱动程序执行环境（DXE）阶段准备系统。DXE 阶段是大部分系统初始化被执行的阶段。在此阶段执行的固件负责查找并执行那些在启动过程中提供设备支持或是额外特性的驱动程序。在此阶段中，UEFI BIOS 可能执行传统的 Option ROM，它们拥有相似的目的。 56 | 57 | UEFI 启动过程的 PEI 和 DXE 阶段为加载操作系统奠定基础。加载操作系统的最后必要任务在启动设备选择（BDS）阶段中完成。此阶段为系统上的简单输入/输出操作初始化控制台设备。这些控制台设备包括本地文字或图形接口，以及远程接口，诸如 Telnet 或者基于 HTTP 的远程显示。BDS 阶段还会加载任何必要的额外驱动程序以管理控制台或者启动设备。最后，固件从首个 MBR 或者全局唯一标识分区表（GPT）格式的启动设备中加载引导程序，并且加载操作系统。 58 | 59 | 在启动过程中，UEFI BIOS 加载 SMI 处理程序并且初始化 ACPI 表和代码。 60 | 61 | UEFI 启动过程的运行时（RT）阶段始于操作系统准备就绪以从 UEFI BIOS 接管控制权时。在此阶段中，UEFI 运行时服务对操作系统可用。 62 | 63 | ## 2.3 更新系统 BIOS 64 | 65 | 系统及其支持管理软件和固件可能提供若干种认证的机制以合理地更新系统 BIOS。这些机制包括： 66 | 67 | 1. 由用户触发的更新：系统和主板制造商通常会为最终用户提供能够更新系统 BIOS 的工具。在历史上，最终用户从外部介质启动以执行这些更新，但是今天大多数制造商提供了能够从用户的正常操作系统中更新系统 BIOS 的工具。取决于系统所实施的安全机制，这些工具可能是直接更新 BIOS，或是它们能够为下一次系统重启时安排一次更新 68 | 2. 受管理的更新：一台给定的计算机系统可能拥有基于硬件和软件的机制以允许系统管理员远程更新系统 BIOS 而无需同用户之间的直接交涉 69 | 3. 回滚：在应用更新之前对其进行认证的系统 BIOS 实现可能也会在更新过程中检查版本号。在这些情况下，系统 BIOS 对于将已安装的固件回滚到某个早期版本可能拥有一种特别的更新过程。例如，回滚过程可能要求用户的物理存在。这种机制防止了攻击者刷入带有已知漏洞的旧固件 70 | 4. 手动恢复：为了从损坏或者工作异常的系统 BIOS 中恢复，众多计算机系统提供机制以允许在启动过程中具有物理存在的用户以某种已知正常的版本和配置来替换当前系统 BIOS 71 | 5. 自动恢复：有些计算机系统能够检测系统 BIOS 于何时被损坏，并且从备份固件镜像中恢复，它存储于不同于主要系统 BIOS 的独立存储位置（例如，第二块闪存芯片、硬盘上的隐藏分区）。 72 | 73 | ## 2.4 BIOS 完整性的重要性 74 | 75 | 作为主 CPU 所执行的第一批代码，系统 BIOS 是计算机系统的重要安全组件。尽管系统 BIOS，有可能会用到可信平台模块（TPM），可以验证启动过程中随后执行的固件和软件的完整性，系统 BIOS 的全部或者部分通常是被隐含地信任的。 76 | 77 | 系统 BIOS 是一个潜在地对攻击者具有吸引力的目标。运行在 BIOS 层级的恶意代码可以拥有对于计算机系统的极大的控制权。它可以被用于攻击在启动过程中随后被加载的任何组件，包括 SMM 代码、引导程序、虚拟机监视器和操作系统。BIOS 存储于其内容在供电周期之间持续存在的非易失性存储器上。写入 BIOS 中的恶意软件可以被用于重新感染设备，即使是在安装了新的操作系统或者更换了硬盘之后。由于系统 BIOS 在设备上以极高的权限在启动过程的早期运行，运行在 BIOS 层级的恶意软件可能很难检测。由于 BIOS 首先被加载，反恶意软件的产品没有机会来具有权威性地扫描 BIOS。 78 | 79 | 可利用的 BIOS 漏洞像是高度系统具体化的——指向某个特定版本的系统 BIOS 或者特定硬件组件（例如，某种特别的主板芯片组）。与之相反，大多数以软件为目标的恶意软件在操作系统内核之中或其上运行，它在此处容易开发，并且可以攻击更大范围类别的设备。BIOS 层级的恶意软件更有可能被用于对高价值计算机系统的针对性攻击。迁移到基于 UEFI 的 BIOS 可能使得恶意软件以一种大范围的方式针对 BIOS 变得更容易了，由于这些 BIOS 实现基于通用的规范。 80 | 81 | 基于以上列举的原因，只有极少已知的 BIOS 层级恶意软件的实例。此时，唯一公开已知的曾经感染了数量可观的计算机的针对系统 BIOS 的恶意软件是 CIH 病毒，也称为切尔诺贝利病毒 \[Sym02\]，它最初被发现于 1998 年。此病毒的负载的元素之一试图覆盖那些使用当时被广泛部署的一种特定芯片组的系统的 BIOS。此恶意软件依赖的若干种漏洞在现代设备上已经不复存在。 82 | 83 | 安全研究人员已经展示了针对传统 BIOS 和 EFI/UEFI 固件的其他潜在攻击。概念验证已经被展示为允许向允许未签名更新的传统 BIOS 实现中插入恶意代码 \[SaOr09\]。其他研究人员已经在一种现代平台的 EFI BIOS 中发现缓冲溢出漏洞。尽管这种 EFI BIOS 在启动过程早期写保护固件，并且仅可向固件刷入签名更新，缓冲溢出允许研究人员通过在写保护应用之前执行固件更新包中的某个未签名部分以绕过安全更新过程 \[WoTe09\]。 84 | 85 | 诸如此类的漏洞可能会允许攻击者创建运行在系统的极高权限下的隐形恶意软件。系统 BIOS 在将计算机的控制权移交给操作系统之前加载 SMI 处理程序。写入 BIOS 的恶意代码可以修改 SMI 处理程序以创建能够以 SMM 运行的恶意软件 \[EmSp08\]。这将会赋予恶意软件针对物理内存和连接到宿主机的外设的不受限制的访问权，并且它将很难被运行在操作系统上的软件检测到。 86 | 87 | ## 2.5 针对系统 BIOS 的威胁 88 | 89 | 上述章节证实了维持系统 BIOS 完整性的重要性。本节描述系统 BIOS 完整性可能遭受攻击的一些不同方式，并且识别那些将会在第 3 章中所具体说明的安全控制和过程的范围中所考虑的那些攻击。 90 | 91 | 对系统 BIOS 的完整性的第一个威胁来自系统在供应链中运动时。供应链安全技术不在此文档所具体说明的安全控制范围之内。然而，3.2 节所具体叙述的某些程序可以被用于识别并且拯救那些拥有非授权的系统 BIOS 的系统。 92 | 93 | 假设系统自带的是制造商本意想要安装的系统 BIOS，在此系统的生命周期内，系统 BIOS 的完整性面临着各种威胁： 94 | 95 | * 最难防止的威胁是由用户触发的恶意系统 BIOS 安装。由用户触发的 BIOS 更新工具通常是更新系统 BIOS 的首要方法。此文档所包含的指导意见并不能够防止用户安装未经许可的 BIOS 镜像，如果他们拥有对于计算机系统的物理访问。如同供应链威胁那样，安全过程可能能够检测并且清除未经许可的系统 BIOS，诸如引发恢复过程以恢复到一个经过许可的 BIOS 96 | * 恶意软件可以撬动弱的 BIOS 安全控制或者利用系统 BIOS 本身的漏洞以重刷或者修改系统 BIOS。通用目的的恶意软件不太可能包含此功能，但是针对某一组织的攻击可以指向该组织的标准系统 BIOS。恶意 BIOS 可以通过网络或者利用介质而带到系统中。此文档中的指导意见被设计为防止此类攻击 97 | * 基于网络的系统管理工具也可能被用于在组织范围内发动针对系统 BIOS 的攻击。例如，考虑一台由组织维护的用于该组织的已部署系统的 BIOS 更新服务器；一台被攻击的服务器可以向组织内的计算机系统推送恶意系统 BIOS。这是一种具有重大影响的攻击，但是需要一位局中人或者攻击该组织的更新过程。此文档所呈现的指导意见被设计为防止此类攻击 98 | * 上述任何机制都可能被用于回滚到一种经过认证但是包含漏洞的系统 BIOS。这是一种特别隐秘的攻击，由于“坏的”BIOS 是经过认证的（即由制造商提供）。后续章节所具体说明的安全控制主要专注于验证系统 BIOS 的来源和完整性。此文档包含对于回滚保护的建议控制。 99 | 100 | 后续章节描述的控制主要专注于防止由运行在计算机系统上的潜在地具有恶意的软件进行的未经认证的系统 BIOS 修改。在供应链中、由拥有物理访问的个人，或是通过回滚到一个经过认证但是具有漏洞的系统 BIOS 等方式而进行的未经许可的系统 BIOS 安装并未被 3.1 节中的控制所解决，但是可以通过使用 3.2 节所具体说明的过程来解决。 101 | 102 | -------------------------------------------------------------------------------- /nist_sp_800-193/appendix.md: -------------------------------------------------------------------------------- 1 | # 附录 A——首字母缩略词 2 | 3 | 此论文中使用的选定的首字母缩略词和缩略语定义如下。 4 | 5 | * BIOS：基本输入/输出系统 6 | * CoT：信任链 7 | * CPLD：复杂可编程逻辑器件 8 | * CTD：检测信任链 9 | * CTRec：恢复信任链 10 | * CTU：更新信任链 11 | * FPGA：现场可编程逻辑门阵列 12 | * ROM：只读存储器 13 | * RoT：可信根 14 | * RTD：检测可信根 15 | * RTRec：恢复可信根 16 | * RTU：更新可信根 17 | * UEFI：统一可扩展固件接口 18 | 19 | # 附录 B——词汇表 20 | 21 | * **活动关键数据**：用于初始化或者配置设备的那一份关键数据副本。_注释：活动关键数据并不包括关键数据的备份。_ 22 | * **扩展卡**：用于指代可以通过诸如 PCI 等连接总线插入到平台中或者从平台中移除的任何设备的通用术语。扩展卡通常被插入到平台的物理机箱内部，而非物理存在于平台外部。扩展卡拥有其自身的设备及其相关联的固件，并且可能拥有其自身的扩展 ROM 固件。 23 | * **认证更新**：使用认证更新机制的更新。 24 | * **认证更新机制**：一种更新机制，它保证更新固件镜像经过数字签名，并且该数字签名可以在更新该镜像之前利用更新可信根（RTU）的密钥存储器中的某个密钥进行验证。 25 | * **授权更新**：使用授权更新机制的更新。 26 | * **授权更新机制**：一种更新机制，它在安装更新之前检查是否得到了批准。批准可能包括检查是否拥有凭证、由物理存在的人员进行确认，或者类似的方式。 27 | * **启动固件**：用于描述在平台上执行以启动（启动、初始化）设备的任何固件的通用术语。这可能包括但不限于初始化设备内存、初始化设备寄存器、初始化连接性接口、设备的健康度检查等。启动固件的一般目的是使得设备或者平台对于正常操作使用准备就绪。 28 | * **信任链（CoT）**：信任链（CoT）是植根于可信根（RoT）中的一系列协作性的元素，该元素通过当它移交其控制权时将相同的信任属性传递给下一个元素来延伸当前元素的信任边界。其结果是两个元素都能同等程度地完成信任功能，如同它们是一个可信元素那样。这一过程可以被延续，以进一步延伸信任链。一旦控制权被移交给未经验证或者不能被验证的代码，则信任链终结。这也被称为将控制权移交至某个非协作性的元素。 29 | * **代码**：由处理器或者类似设备（FPGA、CPLD 等）直接执行的指令。也包括由程序进行解读的指令。_源代码_ 是被翻译成代码并且随后执行的人类可读指令。 30 | * **损坏**：损坏是指固件代码的完整性的丧失，或者关键数据中的错误或者意外的值，这可能是一系列不同原因中的任意一种的结果，包括但不限于：恶意活动（例如攻击者）、编写不良的代码（例如缓冲区溢出、算法错误）、意外事件（例如用户疏忽的行为）、未能安装某个安全补丁、非授权更改，或者由硬件引发的（例如信号完整性、阿尔法粒子、供电故障等）。 31 | * **关键数据**：关键数据是在加电循环之间持续存在的可变数据，并且必须处于由平台管理员授权的某种有效状态，以使得平台的恢复和/或启动过程可以安全和正确地进行。 32 | * **关键平台固件**：所有具有这些特征的平台固件的集合：(a) 执行任何平台固件的保护、检测、恢复和更新功能；(b) 维护关键数据的安全性；或者 (c) 实现了不可绕过的关键数据接口。 33 | * **设备**：用于指代平台上的任何计算或者存储元素，或者计算或者存储元素的组合的通用术语。设备的范例包括中央处理器（CPU）、应用处理器（APU）、嵌入式控制器（EC）、基板管理控制器（BMC）、可信平台模块（TPM）、图形处理器（GPU）、网卡（NIC）、硬盘驱动器（HDD）、固态硬盘（SSD）、只读存储器（ROM）、闪存 ROM 等。 34 | * **设备固件**：仅用于某个特定设备的非宿主处理器固件和扩展 ROM 固件的组合。此固件通常由设备制造商提供。 35 | * **扩展 ROM 固件**：用于指代在宿主处理器上执行的、被扩展设备在启动过程中所使用的固件的外设元件互连标准（PCI）术语。这包括 Option ROM 固件、UEFI 应用程序和 UEFI 驱动程序。扩展 ROM 固件可以作为宿主处理器启动固件的一部分而捆绑，也可以是独立的（例如来自扩展卡）。在此文档中，我们在一般性地指代 Option ROM 固件或者 UEFI 驱动程序和应用程序时使用扩展 ROM 固件这一术语。 36 | * **固件**：用于描述存储于芯片中的任何代码的通用术语，这些代码要么驻留于对应处理器的重置向量（或者等价物），要么作为其他固件的扩展而提供（诸如扩展 ROM 固件）。存储于芯片中的通用目的操作系统在此文档的范围中一般不被看作固件。 37 | * **宿主设备**：辅助共生设备建立满足此文档中的保护、检测和/或恢复指导意见所必需的可信根和信任链的设备。宿主和共生设备之间的功能分配取决于实现。宿主设备自身必须独立满足对其固件的指导意见。注意，这不应该同宿主处理器相混淆。宿主处理器可以作为宿主设备，但是宿主设备不一定是宿主处理器。 38 | * **宿主处理器**：宿主处理器是平台中的主要处理单元，在传统上称为中央处理器（CPU），现在有时也被称为应用处理器（APU）或者系统芯片（SoC）。这是主操作系统（和/或虚拟机监视器）以及用户应用程序所在其上运行的处理单元。这是负责加载并执行宿主处理器启动固件的处理器。 39 | * **宿主处理器启动固件**：用于描述由宿主处理器加载并且执行、为平台提供基本启动能力的固件的通用术语。此类固件包括传统 BIOS、系统 BIOS 和 UEFI，以及其他实现。在传统 BIOS 和 UEFI 之间的区别并不重要的情况下，将会使用宿主处理器启动固件这一术语。在这种区别至关重要的情况下，将会根据实际情况进行指代。扩展 ROM 启动固件也可以被看作宿主处理器启动固件的一部分。扩展 ROM 固件可以被作为宿主处理器启动固件的一部分而嵌入，也可以是独立于宿主处理器启动固件的（例如从扩展卡加载）。宿主处理器启动固件包括可能在运行时可用的固件。 40 | * **不可变的**：不可发生更改的。在此文档的上下文环境中，这仅仅指代不能在现场通过制造商本意中的机制和/或限定的接口进行更改。注意，平台或者设备制造商可能仍然能够通过直接连接到本地（物理）存在的平台或者设备的生产或者服务工具来作出更改。 41 | * **传统 BIOS（基本输入/输出系统）**：用于使用传统 x86 BIOS 架构的 x86 平台的一种宿主处理器启动固件形式。这种形式的宿主处理器启动固件已经或者正在被 UEFI 取代。 42 | * **可变的**：可发生更改的。在此文档的上下文环境中，这仅仅指代能够在现场通过制造商本意中的机制和/或限定的接口进行更改。这样的机制可能要求密码学机制或者无歧义的物理存在。 43 | * **非关键数据**：非关键数据是在加电循环之间持续存在，但是对于设备的启动、运作或者恢复并不具有决定性的可变数据。 44 | * **非宿主处理器**：非宿主处理器是用于描述平台上的任何不是宿主处理器的处理单元（例如微控制器、协处理器等）的通用术语。 45 | * **非宿主处理器固件**：非宿主处理器固件是用于描述被平台上的任何不是宿主处理器的处理单元所使用的固件的通用术语。 46 | * **Option ROM 固件**：用于通常在宿主处理器上执行、在启动过程中被设备使用的启动固件的传统术语。Option ROM 固件可以被包括在宿主处理器启动固件中，也可以由设备（例如扩展卡）独立提供。 47 | * **外设（又称为外部设备）**：外设（又称为外部设备）是物理存在于平台外部并且通过有线或者无线的方式连接到平台的设备。外设由其自身设备构成，它们可能拥有其自身的固件。尽管此文档中的原则和知道意见在概念上也可以同等程度地适用于外设，它们不属于此文档的范围之中。 48 | * **平台**：平台由被组装起来共同工作以带来某种特定计算功能的一个或者多个设备所组成，但是并不包含作为平台中的设备的一部分的固件以外的任何其他软件。平台的范例包括笔记本、台式机、服务器、网络交换机、刀片等。 49 | * **平台管理员权限**：管理平台设备中的固件和关键数据所必需的权限。特别地，这种权限可能是授权固件更新、更改固件配置设置，以及固件恢复操作所需要的。 50 | * **平台管理员**：拥有平台管理员权限的实体。 51 | * **平台固件**：平台上的所有设备固件的组合。在此文档中，平台固件这一术语可以被用于指代平台上所有被设备所使用的固件的组合。 52 | * **主固件镜像**：存储于设备上的可执行代码。主固件镜像的不同部分可以通过不同方式保护。 53 | * **只读存储器（ROM）**：一旦经过初始设置，就不能通过任何机制重写的存储器设备，使得该存储器成为不可变（不可更改）的。 54 | * **具有弹性的**：具有特定性质的系统在干扰发生之前、之中和之后吸收该干扰、恢复到某种可接受的性能级别，并且维持该级别达到一段可接受的时间的能力。 55 | * **可信根（RoT）**：构成了提供一项或者多项安全特定功能，诸如测定、存储、报告、恢复、验证、更新等的基础的元素。RoT 被信任为总是以预期的方式运作，由于它的不当行为不能被检测到，以及它的恰当运作对于提供其安全特定功能至关重要。 56 | * **运行时固件**：用于描述平台上的任何在运行时（在启动完成之后）活动/起作用或者可用的固件的通用术语。 57 | * **软件**：软件由加载操作系统、操作系统和随后由操作系统处理的所有用户应用程序和用户数据所必需的元素构成。参见图 1 以获得图形描述。 58 | * **共生设备**：共生设备是完全或者部分依赖另一个设备（宿主设备）以建立为符合此文档中的保护、检测和恢复指导意见所必需的可信根和信任链的设备。宿主设备和共生设备之间的功能分配取决于实现。例如，宿主设备验证更新并且备份关键数据，而共生设备负责满足所有其他指导意见。共生属性可以具有传递性：一个设备可以是一个宿主设备的共生设备，而这两个设备可以随后作为另一个共生设备的宿主设备，等等。 59 | * **系统**：系统是计算实体的整体，包括 _平台_（硬件、固件）和 _软件_（操作系统、用户应用程序、用户数据）中的所有元素。系统可以被看作逻辑构造（例如软件栈）或者物理构造（例如笔记本、台式机、服务器、网络交换机等）。参见图 1 以获得图形描述。 60 | * **UEFI（统一可扩展固件接口）**：使用统一可扩展固件接口（UEFI）架构（如同 UEFI 论坛所定义）的一种宿主处理器启动固件形式。 61 | * **UEFI 驱动程序**：在启动过程中加载以处理特定硬件部分的独立二进制可执行文件。 62 | * **无歧义的物理存在**：由不能被恶意软件伪造的本地人员指示授权。 63 | 64 | # 附录 C——参考文献 65 | 66 | * \[1\] D. Cooper, W. Polk, A. Regenscheid, and M. Souppaya, _BIOS Protection Guidelines_, NIST Special Publication (SP) 800-147, National Institute of Standards and Technology, Gaithersburg, Maryland, April 2011, 26pp. [https://doi.org/10.6028/NIST.SP.800-147](https://doi.org/10.6028/NIST.SP.800-147) 67 | * \[2\] A. Regenscheid., _BIOS Protection Guidelines for Servers_, NIST Special Publication (SP) 800-147B, National Institute of Standards and Technology, Gaithersburg, Maryland, August 2014, 32pp. [https://doi.org/10.6028/NIST.SP.800-147B](https://doi.org/10.6028/NIST.SP.800-147B) 68 | * \[3\] Specifications, Unified Extensible Firmware Interface Forum \[Web site\], [http://www.uefi.org/specifications](http://www.uefi.org/specifications) \[accessed 5/2/18\] 69 | * \[4\] TPM Library Specification, Trusted Computing Group \[Web site\], [https://trustedcomputinggroup.org/tpm-library-specification/](https://trustedcomputinggroup.org/tpm-library-specification/) \[accessed 5/2/18\] 70 | * \[5\] S. Bradner, _Key words for use in RFCs to Indicate Requirement Levels_, RFC 2119, Internet Engineering Task Force, March 1997, 2pp, [https://doi.org/10.17487/RFC2119](https://doi.org/10.17487/RFC2119) 71 | * \[6\] U.S. Department of Commerce. _Secure Hash Standard_, Federal Information Processing Standards (FIPS) Publication 180-4, August 2015, 36pp. [https://doi.org/10.6028/NIST.FIPS.180-4](https://doi.org/10.6028/NIST.FIPS.180-4) 72 | * \[7\] U.S. Department of Commerce. _Digital Signature Standard_, Federal Information Processing Standards (FIPS) Publication 186-4, July 2013, 130pp. [https://doi.org/10.6028/NIST.FIPS.186-4](https://doi.org/10.6028/NIST.FIPS.186-4) 73 | * \[8\] E. Barker, _Recommendation for Key Management, Part 1: General_, NIST Special Publication (SP) 800-57 Part 1 Revision 4, National Institute of Standards and Technology, Gaithersburg, Maryland, January 2016, 160pp. [https://doi.org/10.6028/NIST.SP.800-57pt1r4](https://doi.org/10.6028/NIST.SP.800-57pt1r4) 74 | * \[9\] E. Barker, _Recommendation for Obtaining Assurances for Digital Signature Applications_, NIST Special Publication (SP) 800-89, National Institute of Standards and Technology, Gaithersburg, Maryland, November 2006, 38pp. [https://doi.org/10.6028/NIST.SP.800-89](https://doi.org/10.6028/NIST.SP.800-89) 75 | * \[10\] International Council for Systems Engineering, “Resilient Systems Working Group Charter,” November 2011. 76 | * \[11\] R. Ross, R. Graubart, D. Bodeau, and R. McQuaid, _Systems Security Engineering: Cyber Resiliency Considerations for the Engineering of Trustworthy Secure Systems_, NIST Special Publication 800-160 Volume 2 (DRAFT), National Institute of Standards and Technology, Gaithersburg, Maryland, March 2018, 158pp. [https://csrc.nist.gov/CSRC/media/Publications/sp/800-160/vol-2/draft/documents/sp800-160-vol2-draft.pdf](https://csrc.nist.gov/CSRC/media/Publications/sp/800-160/vol-2/draft/documents/sp800-160-vol2-draft.pdf) 77 | 78 | -------------------------------------------------------------------------------- /nist_ir_8151/chapter_4.md: -------------------------------------------------------------------------------- 1 | # 第 4 章 非技术方法和总结 2 | 3 | 作为对 2016 年二月的美国联邦网络安全研发战略计划的回应，OSTP 请求 NIST 标识出可用于显著减少软件漏洞的方式。NIST 与软件担保社区协同工作以标识出 5 种有前途的方法。此报告为每一种方式呈现了一些背景，同时带有关于该方法的成熟度的总结叙述，以及关于它为何有可能带来显著改变的理论基础，同时为每一种方法提供了延伸阅读。希望能有其他方法在未来被标识出来。 4 | 5 | 这些方法专注于具有 3～7 年视界的技术行为。关于改进软件的众多至关重要的方面并未被探讨，诸如创建更好的规范、使用今天可用的测试工具、理解并且控制依赖，以及创建并且遵守项目指导原则等。尽管这些领域位于此报告的范围以外，它们对于现在和未来都至关重要。类似地，此报告并未探讨作为对于软件和漏洞的更为宽泛的理解的一部分而必需的研发过程。诸如识别漏洞来源、漏洞如何表现为 bug，以及开发阶段的改进扫描等话题同样至关重要，但是它们同样不属于此报告的范围之内。 6 | 7 | 报告的这一章概述了前进所必需的一些步骤，通过雇佣更加广泛的社区，包括研究人员、资金提供者、开发者、经理和消费者/用户。本章解决了这些问题：1) 雇佣和支持研究社区，2) 教育和培训，以及 3) 授予软件的消费者和用户有意义地参与的权利，而非仅仅要求质量，而是推进它。 8 | 9 | ## 4.1 雇佣研究社区 10 | 11 | 除了简单地资助安全的软件的研究以外，还有众多方式以雇佣研究社区。 12 | 13 | ### 4.1.1 大挑战、奖金和奖励 14 | 15 | 众多组织机构曾经发起过大挑战，其中有些是普通的研究目标，而有些是竞赛。更加安全的软件可以作为挑战的焦点或者额外的好处，即竞赛可以专注于非安全性的目标，但是要求胜者生产安全的软件。例如，DARPA 网络安全大挑战的评分反映出了软件能够多么好地发现漏洞并且保护宿主 \[DARPA16\]。其他挑战可以专注于特定技术，诸如抽象释义、符号执行或者新编程语言的分析。众多组织机构利用 bug 赏金计划来为研究社区提供激励以查找并且通知组织机构有关 bug 的信息。 16 | 17 | ### 4.1.2 研究基础设施 18 | 19 | 存在若干种非常成功的与安全的软件相关的数据版本库，诸如美国国家漏洞数据库。然而还需要更多。可以有版本库用于分享相关研究成果，以及源代码的开放版本库，如 4.3.6 节所提到的。还需要关于弱点和 bug 的更好的理解。例如，多大比例的漏洞来源于实现错误，多大比例来源于设计错误？SPSQ 研讨会的参与者呼吁对于缺陷和弱点的更多深度理解。具体的问题包括对于关于漏洞的类型和流行度的经验数据的需求、编程和测试技术的有效性，以及“更加安全”的语言的好处和代价。新语言要求新的分析工具，以及在某些案例中还要求新的分析算法。强壮的研究基础设施还可以被用于研究可能影响软件质量的其他因素，包括管理实践、教育和培训、复杂度水平以及程序员过载。研究人员需要能够重现结果并且测试跨类型的代码。所有这些活动要求大型、公开的研究基础设施。 20 | 21 | ## 4.2 教育和培训 22 | 23 | 教育和培训的作用再怎么强调也不为过。开发者训练没有技术上的替代品。教育不仅仅是关于教会开发者如何编写更好的软件的，它还包括教育用户如何指定更好的软件，以及教育经理如何设置能够得到更高质量的软件的环境。 24 | 25 | 此外，教育和培训是将此报告中所讨论的技术方法从研究社区转移到开发社区和用户/消费者社区的首要机制。 26 | 27 | 对开发者社区的教育和培训需要应对当前教育体系中的后起之秀的开发者，也要应对需要提升其技能的当前开发者。 28 | 29 | 近两年来，高等教育的焦点已经转移到了更加强调一上来就内建安全性的软件设计，而非在其后添加安全性。K-12 教育也已经在网络安全努力中看到了成长——从用户和生产者的视角。很明确的是，计算机科学和网络安全共同成为安全编程的主题。理解网络安全的原理对于确保软件安全可用至关重要。越来越多的学术计划正在教育它们的学生在编程时脑子里始终记住安全性。 30 | 31 | 当前的开发者需要暴露于新方法和新技术之中。为了使得开发者作出改变，他们需要看到关于新方法和新技术有效的证据，以及培训素材。为了补充前线软件开发者的培训，经理和管理层也必须被教育，关于软件漏洞的风险管理启示，以及在网络安全和低漏洞软件领域进行投资的重要性。为了使得这种培训获得成功，还需要关于在安全的软件中的投资将会具有成本高效性的证据。 32 | 33 | 哪些教育学的技术最为有效这一点在当前尚不明确。早期研究显示了为开发者提供关于弱点的更好的理解可以创建更好的程序这一事实 \[Wu11\]。更多的研究以及从应用案例到指南教程的培训素材对于成功的过渡是必需的。美国联邦政府可以以身作则培训它自己的开发者社区。 34 | 35 | 美国国家网络安全教育倡议（NICE）的战略计划 \[Plan16\] 列出了关于改进教育和培训的 3 个目标。 36 | 37 | **加速学习和技能开发**：启发公众和私人领域的紧迫感以应对高技能网络安全工作人员的短缺是至关重要的。必需的步骤包括： 38 | 39 | * 刺激那些能够更加快速地增加合格网络安全工作人员供给的方法和技术的开发 40 | * 推广那些能够减少获取与有需求的工作岗位相关的知识、技能和能力所需的时间和成本的程序 41 | * 雇佣那些可用并且有意愿继续从事网络安全工作的离职人员或者待业个人 42 | * 试验利用学徒身份和合作教育计划以提供一支立即可用的劳动力的方式，他们在挣得工资的同时还能学会必需的技能，以及 43 | * 探索方法以识别网络安全技能中的鸿沟，并且唤起关于应对所识别出的劳动力需求的培训的意识 44 | 45 | **培养多样化的学习社区**：需要强化跨生态系统的教育和培训以强调学习、测定其成果，以及使得网络安全劳动力多样化。必需的步骤包括： 46 | 47 | * 改进教育计划、课程联合经验和培训，以及认证 48 | * 鼓励那些能够有效测定和验证个人天赋、知识、技能和能力的工具和技术 49 | * 在小学阶段启发学生的网络安全职业生涯意识，在初中阶段刺激网络安全职业生涯探索，在高中阶段使其为网络安全职业生涯做好准备 50 | * 增加创新性和高效的努力以增加女性、少数民族、退伍军人、残疾人以及其他未获充分代表的群体在网络安全领域中的劳动力数量，以及 51 | * 辅助关于网络安全职业生涯的学术通道的开发和传播 52 | 53 | **引导职业生涯开发和劳动力计划**：雇员需要帮助以应对市场需求并且加强征募、招聘、开发以及留住网络安全天才。必需的步骤包括： 54 | 55 | * 识别并且分析那些支持呈现现在和未来的对于合格网络安全工作人员的需求和供给的数据来源 56 | * 发布并且唤起对于美国国家网络安全劳动力框架的意识，并且鼓励其采用 57 | * 辅助各州和区域联盟以识别网络安全通道，以应对本地劳动力需求 58 | * 提升辅助人力资源专业人士和招聘经理的工具以用于征募、招聘、开发以及留住网络安全专业人士，以及 59 | * 开展国际合作以分享网络安全职业生涯发展和劳动力计划的最佳实践 60 | 61 | ## 4.3 由消费者实现的技术转让 62 | 63 | 更好的软件的驱动因素之一在于软件的用户、消费者和购买者是否要求它。尽管用户社区明确地想要高质量的软件，他们很难有意义地要求它以及知道他们是否已经得到了它，并且因此发出关于开发低漏洞软件的信号。市场的需求促进了以消费者为中心的措施，以及其他政策和经济方式。一项措施为了能够显著地向消费者提供信息，它需要普遍性、可理解性、简洁性和高效性。一个范例是美国国家公路交通安全管理局（NHTSA）的 5 星安全评级。一旦评级持续出现在新车上，1 星和 2 星的车辆迅速变得稀少 \[Rice08\]。政策和经济方式超出了此报告的范围，但是它们对于用于改进的软件的成功技术转让至关重要。本节概述了于不同研讨会期间讨论过的一些方式。 64 | 65 | ### 4.3.1 合同和采购 66 | 67 | 美国联邦政府可以通过在合同和采购阶段要求软件质量以及更改一般预期来领导软件质量的显著改进。模型合同语言可以包括关于软件依附于更高的编码和担保标准的激励，或者关于对这些标准的拙劣的违反的惩罚性措施。用于网络安全和安全的软件的样本采购语言已经由防御社区 \[Marien16\]、金融部门、汽车行业和医疗领域发表。其评估必须包括提供“目的适用性”作为安全的软件的考虑因素。 68 | 69 | ### 4.3.2 责任 70 | 71 | 在软件社区中存在关于责任的大量讨论，包括在用于减少安全漏洞的软件测定和度量（SwMM-RSV）研讨会期间。众多参与者认为开发软件的企业应该为在软件送达之后发现的漏洞负有合同上的责任。很多人并不认为此时应该有法律上的责任。另一方面，这样的责任条款的语言应该足够严格，以使得如同某位参与者所写道的那样“使得企业对马虎的以及容易避免的错误和瑕疵负责”。 72 | 73 | 定义“马虎的以及容易避免的”并不是一件平凡的事。使其更加复杂的另一个因素是，责任涉及谁应该为之负责的概念。对于“开源”或者可免费获得的软件的案例，责任可能难于界定。 74 | 75 | ### 4.3.3 保险 76 | 77 | 随着网络的重要性持续增长，网络保险成为了一个增长的领域。针对关键基础设施保护和美国国土安全的金融服务部门协调委员会（FSSCC）编写了一部 26 页的文档，其标题为“网络保险产品购买者指南”，它定义了这种保险是什么、解释了为何组织机构需要它、描述了它可以被如何采购，以及给出其他有用信息。 78 | 79 | ### 4.3.4 厂商——消费者关系 80 | 81 | 如果软件拥有一份“物料清单”以使得使用它的人可以对新的威胁作出响应，在此，软件中的某些部分成为了攻击向量，那么将会有助于最终用户。用户有时被软件许可证禁止发布评估或者同其他工具的比较。乔治城大学最近发布了一项关于此问题的研究 \[Klass16\]。此研究受到美国国土安全部（DHS）科技理事会（S&T）网络安全分部通过安全和软件工程研究中心（S2ERC）的赞助。 82 | 83 | ### 4.3.5 标准 84 | 85 | 标准和指导原则的开发和采用，以及一致性评估程序被跨越多个行业应用以应对质量问题。美国志愿者业界共识标准系统允许巨大的灵活性以应对需求。在某些案例中，美国政府（联邦、各州和地方）设置行政法规标准和社区自律。例如，电气电子工程师学会（IEEE）于 2015 年发布了医疗器械软件安全的构建代码 \[Haigh15\] 并且发起了一项努力以便为能源和电力分配系统开发一份类似的最佳实践文档 \[Landwehr15\]。另一个范例是 NIST 的 _用于改进关键基础设施的网络安全性的框架_ \[Framework14\]。 86 | 87 | ### 4.3.6 测试和代码版本库 88 | 89 | 我们在 2.1 和 2.4 节解释了经过良好测试的代码的额外版本库的好处。软件的深度测试是困难并且耗时的，但是对于普遍使用的关键模块而言是必要的。SPSQ 研讨会的参与者指出了政府和基于社区的努力在测试关键软件中的价值。代码版本库提升了代码的重复使用并且鼓励组织机构通过提供结果可以被发表的位置来测试代码。版本库可以连同代码一起存储某些担保级别测定结果，或者甚至拥有内建的代码测定工具。版本库还可以包含具有低 bug 密度的项目的范例，诸如 Tokeneer \[Barnes06\]。 90 | 91 | ### 4.3.7 威胁分析 92 | 93 | 威胁分析，有时称为“威胁模型分析”或者“风险分析”，是一种评估风险或者威胁的方式 \[Fundamental08\]。通过威胁分析，软件可以被设计为避免引入某些漏洞并且降低其他漏洞的严重性。例如，一种形式的威胁分析是通过文档记录攻击面以理解对手可能如何利用接口以提升权限。威胁分析最好同时在架构和设计层级执行，如若不然，软件可能包含原本可以避免的漏洞 \[Shostack14\]。架构威胁分析可以显著增加软件的架构及其高级设计的安全强壮性和弹性，以显著降低漏洞的数量和严重性 \[Diamant11\]。 94 | 95 | ## 4.4 结论 96 | 97 | 对于显著减少软件漏洞的诉求发出自多个来源，包括 2016 年的美国国家网络安全行动计划。此报告识别了 5 种方法以实现此目标。每一种方法满足以下 3 个判据：1) 拥有显著改进软件质量的潜力，2) 能够在 3～7 年的时间框架内带来显著改变，以及 3) 是技术行为。被识别出来的方法应用了多种策略： 98 | 99 | * 在漏洞发生之前阻止它们，包括用于指定和构建软件的改进的方法 100 | * 查找漏洞，包括更好的测试技术以及对于多种测试方法的更有效的利用，以及 101 | * 通过构建更具弹性的架构来降低漏洞的影响，使得漏洞不能被有意义地利用 102 | 103 | **形式化方法**：形式化方法包括多种基于数学和逻辑的技术，其范围从语法分析、类型检查、正确性证明、基于模型的开发，到自动建构校正。尽管之前被认为是过于耗时的，形式化方法已经在众多幕后应用中成为主流，并且在构建更好的软件以及支持更好的测试方面展示出了巨大的前途。 104 | 105 | **系统层级安全性**：系统层级安全性降低漏洞的影响。操作系统容器和微服务已经成为美国国家信息基础设施的重要组成部分。鉴于使用它们所带来的明显的可管理性、成本和性能方面的优势，有理由预计它们的应用将会继续增长。这些技术的安全增强的版本一经采用，即可对整个美国国家信息基础设施中的软件漏洞利用产生广泛的抑制效果。 106 | 107 | **附加软件分析**：有众多类型的软件分析——有些是通用的，有些针对非常特定的漏洞。附加软件分析的目的是能够将多种工具用作生态系统的一部分。这将会增加特定的软件分析工具的使用，以及在工具和技术之间获得协同作用的能力。 108 | 109 | **更多成熟的领域特定软件开发框架**：此方法的目标是提升经过良好测试和良好分析的代码的使用（和重复使用），并且因此减少可被利用的漏洞的发生几率。 110 | 111 | **移动目标防御（MTD）和自动软件多样性**：此方法是一系列技术的集合以改变软件的细节结构和属性，以使得攻击者在利用任何漏洞时的难度大大增加。自动软件多样性和 MTD 的目的是降低攻击者利用软件中的任何漏洞的能力，而非降低软件中的弱点的数量。 112 | 113 | 关于改进安全性的一项关键需求是使得软件拥有更少并且更加难于利用的漏洞。我们所描述的测定、技术和方法将会能够做到这一点。然而，高质量软件并不会被完全独立地创建出来。必须有强壮的研究基础设施、教育和培训，以及消费者需求。高质量软件是一个必要的步骤，但是还不够。跨越整个系统的生命周期的强壮的操作和维护过程仍然是必需的。 114 | 115 | ## 4.5 首字母缩略词列表 116 | 117 | * ACM：美国计算机协会 118 | * AI：人工智能 119 | * API：应用程序接口 120 | * ASLR：地址空间配置随机加载 121 | * AST：抽象语法树 122 | * BLP：Bell-LaPadula 123 | * BSIMM：在成熟度模型中构建安全性 124 | * CAP：网络安全担保计划 125 | * CEGAR：由反例指导的抽象详细化 126 | * CII：核心基础设施倡议 127 | * CIL：通用中间语言 128 | * CISQ：信息科技软件质量联盟 129 | * CMU：卡内基梅隆大学 130 | * CPU：中央处理器 131 | * CWE：通用缺陷列表 132 | * DARPA：美国国防高级研究计划局 133 | * DHS：美国国土安全部 134 | * DoD：美国国防部 135 | * DSL：领域特定语言 136 | * ESAPI：企业安全性应用程序接口 137 | * FAA：美国联邦航空管理局 138 | * FSSCC：金融服务部门协调委员会 139 | * GNU：Gnu's Not Unix 140 | * GPU：图形处理器 141 | * GUI：图形用户界面 142 | * ICT：信息及通信技术 143 | * IDE：集成开发环境 144 | * IEEE：电气电子工程师学会 145 | * iFACTS：临时未来领域控制工具支持 146 | * I/O：输入/输出 147 | * IoC：控制反转 148 | * IR：中间表示 149 | * ISO：国际标准化组织 150 | * ITS：入侵容忍系统 151 | * KDM：知识发现元模型 152 | * LoC：代码行数 153 | * ML：元语言 154 | * MTD：移动目标防御 155 | * NaN：非数 156 | * NATS：英国国家航空交通服务控股公司 157 | * NHTSA：美国国家公路交通安全管理局 158 | * NICE：美国国家网络安全教育倡议 159 | * NICTA：澳大利亚国家信息及通信技术卓越研究中心 160 | * NIST：美国国家标准技术研究所 161 | * NITRD：网络和信息科技研发 162 | * OBDD：有序二元决策图 163 | * OS：操作系统 164 | * OSTP：美国白宫科技政策办公室 165 | * OWASP：开放式网络应用程序安全项目 166 | * SAFES：软件担保发现表达纲要 167 | * SAL：源代码注释语言 168 | * SAT：布尔可满足性问题 169 | * S2ERC：安全和软件工程研究中心 170 | * SI：国际单位制 171 | * SMT：可满足性模数理论 172 | * SPSQ：软件生产力、可持续性和质量 173 | * SSCA：软件和供应链担保 174 | * S&T：科技 175 | * TCSEC：可信计算机安全性评估判据 176 | * TOIF：工具输出整合框架 177 | 178 | -------------------------------------------------------------------------------- /peripheral-based_attack_memory/chapter_1.md: -------------------------------------------------------------------------------- 1 | # 第 1 章 简介 2 | 3 | > 我认为，大多数人甚至都不知道 rootkit 是什么，那么他们为什么要去关心它呢？——Thomas Hesse，索尼全球数字业务前主席 4 | 5 | 大多数人可能会将 _rootkit_ 这一术语同针对计算机平台的攻击相关联。实际上，对手部署 rootkit 是为了攻击计算机用户。基于 rootkit 的攻击被用于引导行业和政治间谍活动以及网络犯罪 \[参见 16，p.22-25\]。对手通过引导行业间谍活动来偷取知识产权以减少技术开发周期的成本。政治间谍活动不同于行业间谍活动。在政治间谍活动中，对手所感兴趣的是国家机密而非新技术。网络犯罪分子利用 rootkit 来偷取互联网银行凭证、口令以及其他敏感信息。rootkit 也可被用于引导对最终用户的持久监控。rootkit 还可被用于强制执法，以执行对嫌疑人的监控 \[参见 16，p.21\]。但是，准确地说，rootkit 到底是什么？它是 _后门_ 吗？它是 _特洛伊木马_ 吗？换言之，rootkit 所包含的恶意负载是什么类型，以及目标计算机是如何被此 rootkit 所渗透的？ 6 | 7 | 术语 rootkit 的若干种定义可以在这样一些文献中找到，例如 Bill Blunden 所著的 _The Rootkit Arsenal: Escape And Evasion In The Dark Corners Of The System_ \[16\]。他的著作同时评估了 Mark Russinovich（此人以 _Windows Internals_ \[106\] 系列著作而闻名）和 Greg Hoglund（_Rootkits: Subverting the Windows Kernel_ \[60\] 一书的作者）对于 rootkit 的定义。最后，Bill Blunden 得出了他自己的定义 \[参见 16，p.12\]： 8 | 9 | > rootkit 在一台设备上建立了一个远程接口，此接口使得系统可以被操纵……数据可以被收集（例如监控），以某种难以被观察到的方式（例如隐藏）。 10 | 11 | 所有这些定义提示了 rootkit 在总体上所展现出来的一个重要属性，即能够隐秘地运作的能力。攻击者通过部署 rootkit 来掩护用于攻击目标计算机的代码。这一点回答了关于 rootkit 的恶意负载的问题。此负载可以被用于执行在用户看来是恶意行为的任何东西。此恶意行为也可以是后门。后门被用于绕过诸如认证请求等安全机制以获得对某台计算机系统的访问权限。后门还可以为攻击者提供对于某台计算机的远程访问权限。在攻击者看来，将此后门隐藏起来是有意义的。此后门应该在计算机用户毫不知情的情况下被使用。因此，后门可以得益于 rootkit 机制。rootkit 负载的另一个例子是监控程序，此程序通过激活目标计算机的话筒和摄像头以暗中监视该计算机的用户。能够捕获由某位计算机用户所输入的所有击键的击键码记录器也是恶意负载的常见范例。 12 | 13 | 然而，对于攻击者的挑战在于渗透目标计算机平台。此攻击者必须实现某种类型的 rootkit 安装程序。rootkit 安装程序通常被称为 _释放器_ \[参见 16，p.9\] \[33\]。这样的释放器可以基于最常见的渗透机制之一，即特洛伊木马，或者简称木马。木马的目的在于在目标计算机将要安装某个预想的程序、特性或者功能时对其进行误导。与之相反，其结果是用户安装了诸如击键码记录器或者后门等恶意负载。诸如此类的负载通常被部署于高权限环境，并且利用 rootkit 技术加以掩护。另一种常见的渗透方式是利用某个安全漏洞。此 rootkit 安装程序可以实现某种 _漏洞利用_。漏洞利用是一段利用安全漏洞的攻击代码。所谓的 _零日漏洞_ 相对于非零日漏洞更具威胁性。零日漏洞所利用的是某个此前未知的安全漏洞，这可能对于攻击者更加有利。它使得攻击者能够引导一次对于目标计算机的隐秘渗透。 14 | 15 | rootkit 的另一个关键属性是其代码运行于可能的最高权限之上。其目标是获得至少是高于任何潜在的检测机制的权限。这使得 rootkit 能够控制并且修改检测机制。在某种程度下，检测机制将会无法检测 rootkit 或者由此 rootkit 掩护的恶意负载。这是攻击者寻求新的、更加强大的攻击向量的原因。攻击者获得的权限越多，其所获得的对于目标计算机的控制也就越多。 16 | 17 | 攻击者的目标是获得对目标计算机的绝对控制。_rootkit 进化_ 记录了攻击者和反恶意软件社区之间的军备竞赛。相对于早期的 rootkit，现在的 rootkit 已经前进到了更高权限的执行环境。近年来 \[35，36，47，134，135\] rootkit 的进化达到了一个新的水平。攻击者开始利用平台外设的隔离执行环境。具有专用处理器、专用内存以及直接访问宿主的运行时内存的硬件特性的外设能够掩护用于攻击目标计算机的恶意负载。这样的攻击被认为是隐秘的。市场上可获得的现代反病毒软件之类尚未考虑基于外设的执行环境。这样的软件执行于宿主处理器上，并且通常只将硬盘和主内存考虑为能够存储恶意代码。 18 | 19 | ## 1.1 问题表述 20 | 21 | 恶意软件是对数据的机密性、完整性以及可用性的威胁。对于基于外设的恶意软件的情况，攻击者可以利用外设的隐形潜力。隐藏在平台外设中的恶意软件不会被反病毒软件所考虑。取决于外设，安全软件甚至不能访问该设备的内部工作。例如某些管理控制器拥有对全部宿主内存的访问，并且提供远程管理特性。为了防止滥用，制造商应用保护机制以阻止对此执行环境的内部工作的访问。 22 | 23 | 这种机制，如果被基于外设的恶意软件所利用以攻击宿主，则称之为直接内存访问或者 DMA。在本工作中，我们将会引入术语 _DMA 恶意软件_ 以用于诸如此类的攻击。DMA 恶意软件拥有同 rootkit 相似的特性。当前的反制措施无法应对 DMA 恶意软件的挑战。例如，对本意将要在外设上运行的代码进行加载时完整性检测等机制并不能阻止运行时攻击。这同样适用于数字签名的固件镜像的情形。另一种方式是基于延时的证明。此类证明要求一段散列值在一定的时间框架内被计算出来。然而，这同样要求修改外设固件，并且不能阻止瞬时攻击。诸如特殊监控以及内存总线嗅探等其他方式基于特殊硬件或者硬件特性。阻止敏感数据出现在主内存中同样不能奏效。这些数据可以通过 DMA 攻击被转储到主内存中 \[脚注 1\]。 24 | 25 | > 脚注 1：具体细节可以在 3.2 节“相关工作——反制措施”部分找到。 26 | 27 | 一种被提议的针对 DMA 攻击的反制措施是使用一种所谓的 _输入/输出内存管理单元_（I/OMMU）。这样的管理单元可以限制外设对宿主的部分主内存的访问。然而，此技术具有重大缺陷。已有证据表明 I/OMMU 可以被攻击并且绕过 \[111，146，147，148\]。因此，I/OMMU 不一定可信。某些操作系统，诸如 Windows，并不提供驱动程序以支持 I/OMMU。此外，并非每种芯片组都提供 I/OMMU。更进一步地，I/OMMU 不能处理内存访问策略冲突。例如，Bulygin \[25\] 展示了如何利用外设以揭示存在于宿主的运行时内存中的恶意软件。我们将相同的执行环境用于第 4 章的攻击研究。例如，如果 I/OMMU 被配置为允许外设扫描宿主的全部运行时内存以揭示 rootkit，那么我们的攻击代码同样可以访问全部运行时内存以偷取敏感数据。因此，本工作并不依赖 I/OMMU 作为一种反制措施。更进一步地，I/OMMU 可能会引入显著的性能开销 \[13，150\]，这使得 I/OMMU 对于某些场景并不理想。由于这些考虑，我们相信缺少这样一种能够检测恶意内存访问并且具有可忽略的性能开销的运行时监视器。这样一种运行时监视器的缺失正是推动本工作的动力之一。 28 | 29 | ## 1.2 研究问题和方法论 30 | 31 | 我们的研究兴趣基于现代 x86 平台的隐形能力。这些能力被对手以利用以隐藏恶意代码，如同 rootkit 进化所记载，同时参见 2.1 节。这提出了这样一个问题，即不可被检测到的软件是否能够存在。为了检验这个问题，我们考虑了 rootkit 中的下一个逻辑步骤，即利用平台外设以攻击宿主的运行时内存。 32 | 33 | 我们开发了一种恶意软件的 _概念验证_（PoC），它执行于某个隔离的外设上。此外设的硬件提供了对宿主的运行时内存的访问。我们以击键码记录器的形式实现了一次攻击。这意味着我们的恶意软件搜索宿主操作系统的键盘缓冲并且监视该缓冲以捕获击键码。对此击键码记录器的评估指导了我们后续的一个研究问题，即宿主系统能否保护自己以对抗基于外设的宿主主内存攻击？为了回答这个问题，我们实现了一个运行时监视器，它执行于宿主 CPU 上。有了这个监视器，我们想要展示这一点，即来自平台外设的对宿主主内存的额外（恶意）访问事实上是可以被检测到的。我们要求基于宿主 CPU 的检测程序能够检测恶意访问，即使它不能访问该恶意外设的隔离执行环境。 34 | 35 | 我们利用我们的恶意软件样本以得出此类恶意软件的一般属性。随后我们利用了这些属性以检测由恶意软件所引导的内存访问。我们定义了这样一种属性，它是每一种攻击宿主内存的基于外设的恶意软件都体现出来的。基于此，我们将我们的恶意软件概念验证视为对于此类恶意软件典型的。我们实现了基于宿主 CPU 的检测程序以揭示由平台外设通过直接内存访问所引导的非法内存访问。其目标是实现这样一种运行时监视器，它不仅对于宿主 CPU 只造成最小化的性能开销，同时能够阻止瞬时攻击。 36 | 37 | 我们还在我们的研究的最后一部分考虑了网卡。网卡同样可以托管恶意软件。特别是在企业环境中，某个计算机平台被要求向某个中央管理员平台报告其状态。这样的状态报告可以被执行于网卡上的恶意软件修改。因此，我们开发了一种合法报告信道。此信道有助于揭示针对此类状态报告的攻击。 38 | 39 | ### 实验研究环境 40 | 41 | 我们的实验环境基于 Intel x86 硬件。我们用于执行我们的基于外设的恶意软件的隔离环境是 _Intel 管理引擎_（Intel ME \[79\]）。Intel ME 是一种特殊的微控制器，它运行某种强大的平台管理固件。管理员可以利用此管理固件远程重装操作系统，即使操作系统已经不可引导，并且该平台不可通过操作系统的网络栈抵达。ME 同样能够在平台处于待机或者关机的情况下运作。由于这些特性，其制造商 Intel 建立了这样的保护机制，它们不能在不付出巨大努力的情况下被绕过。ME 是同宿主系统相隔离的。Intel ME 环境是同宿主完全隔离的，而其他外设可以通过调试寄存器以及其他机制来访问。 42 | 43 | 从检测程序的角度来看，ME 是用于托管基于外设的恶意软件的执行环境的最坏的案例。宿主 CPU 无法访问 ME 环境。我们将这一最坏案例环境用于我们的研究。我们通过应用某个只能工作在特定芯片组 \[脚注 2\] 上的漏洞来渗透 ME 环境。请注意，此工作并不致力于查找未被发现的安全漏洞。我们重复利用了某个已知的安全漏洞来设置我们自己的实验环境，是由于缺少一块适合的 Intel 开发板。 44 | 45 | > 脚注 2：此漏洞利用仅适用于刚好具有特定版本 BIOS 的 Intel Q35 芯片组。Intel 通过提供 BIOS 更新堵住了对应的安全漏洞。 46 | 47 | ## 1.3 论文贡献的影响 48 | 49 | 例如为了引导行业间谍活动或者偷取在线银行凭证等，攻击者要求能够隐秘运作的恶意软件。基于外设的恶意软件保证了攻击仍然不可被检测到。能够满足隐秘恶意软件运作的需求的外设存在于几乎每一部现代计算机平台中。诸如显卡、网卡和管理控制器等是台式机、服务器系统以及其他计算机终端的组成部分。移动电话和平板计算机也具有那些带有独立处理器、内存以及对宿主运行时内存的直接访问的外设。这意味着所有现代平台都易受基于外设的恶意软件的攻击。这样的恶意软件执行于隔离环境中，并且处于由操作系统内核所设置的反病毒软件和安全机制的视野之外。由于缺少针对基于外设的恶意软件的检测程序以及在反病毒软件中缺少类似功能，本论文的贡献可能对上述计算机设备及其用户具有重大影响。我们将本论文的主要贡献总结如下： 50 | 51 | ### DMA 恶意软件研究 52 | 53 | 我们定义了 DMA 恶意软件以便能够区分不同的 DMA 代码。这样的恶意软件执行于某个外设上，并且能够通过直接内存访问攻击宿主。我们开发了一种 DMA 恶意软件实现的概念验证，它能够利用某个隔离的外设来引导隐秘攻击。我们的概念验证称为 DAGGER，它来自于 _DmA-based keystroke code loGGER_（基于 DMA 的击键码记录器）。DAGGER 可以攻击不同的宿主操作系统。DAGGER 强调了 DMA 恶意软件在实践中是多么地高效。我们识别了 DMA 恶意软件的核心属性以研究诸如此类的恶意软件的属性。这些属性是 DMA 恶意软件检测程序的基础。在一次早期实验中，我们提供了关于 DMA 的副作用存在的证据。我们展示了这样一种效应可以如何利用通常的宿主 CPU 特性进行测定。这是 DMA 恶意软件检测程序开发的第一步（参见第 4 章）。 54 | 55 | ### 检测 DMA 恶意软件 56 | 57 | 我们开发了一种监视器，它能够通过比较实际的内存总线活动和预期的内存总线活动来检测 DMA 恶意软件。我们的方法能够确定并且比较实际的总线活动而不受任何固件或者硬件修改的影响。此检测器基于这样一种特性，它实现了永久的运行时监控并且运行在宿主 CPU 上。我们实现并且评估了这样一种概念验证，我们称之为 _总线代理运行时监视器_（BARM）。我们的监视器实现了这样一种监视策略，它会考虑瞬时攻击。它只会造成可忽略的性能开销。BARM 可以检测并且立即终止 DMA 恶意软件（参见第 5 章）。 58 | 59 | ### 排除了 DMA 恶意软件干扰的合法平台状态报告 60 | 61 | 我们展示了我们的检测方法同样适用于这样的场景，在此，一部计算机平台必须向某个中央管理员平台报告其状态。我们建立了这样一种合法报告信道，它能够揭示由执行于网卡上的恶意软件所引导的攻击。这意味着我们改良了 BARM 以揭示 _中间人_（MitM）攻击，并且阻止由网卡引导的中继攻击。我们实现了一种信道以便将平台状态信息安全地传输至一台外部计算机。此平台状态信息允许远程实体评估 BARM 的测定结果。这意味着远程实体可以确定其对端是否受到了 DMA 恶意软件的攻击。我们的信道将宿主 CPU 视为信道的端点，而非完整的目标平台。这排除了网卡作为端点的一部分。我们改良了 BARM 以说明由网卡所造成的内存总线活动。此改良的 BARM 利用 _OpenSSL_ 来实现合法报告信道。我们还修改了 TLS 握手协议以便在通讯会话的最初阶段就说明平台状态信息。我们的修改仍然符合 TLS 规范（参见第 6 章）。 62 | 63 | 具体的工作细节可以在各对应章节找到。 64 | 65 | ## 1.4 论文结构 66 | 67 | 根据我们的方法论，我们按照如下方式组织论文结构。下一章，我们将会介绍必需的技术背景、预备知识以及假设。用于我们的评估的目标平台是一种基于 Intel x86 的现代系统，参见 2.2，2.3，2.4，2.5 和 2.6 节。这些章节介绍了关于该目标平台的大部分重要术语，特别是宿主 CPU、_直接内存访问_（DMA）、总线主控以及 _输入/输出内存管理单元_。我们还在 2.7 节介绍了我们的假设以及由此得出的对手模型。第 3 章覆盖了相关工作。由于我们同时考虑攻击以及攻击检测和防护两端，我们必须认真研究两端的相关工作。关于 DMA 攻击的相关工作描述于 3.1 节。3.2 节呈现了那些考虑了反制措施的前期工作。更进一步地，我们想要使得我们的目标平台能够向外部平台报告其关于基于 DMA 的恶意软件的状态。为了达成这一目的，我们要求一种能够揭示由网卡发动的中间人攻击的通讯信道。这是必需的，由于我们同时将网卡视为能够隐藏 DMA 攻击代码的专用硬件。 68 | 69 | 我们引导了针对 DMA 恶意软件的研究并且将其结果呈现于第 4 章。关于 DMA 恶意软件的定义给出于 4.1 节。在 4.2 节，我们呈现了 DMA 恶意软件的核心功能。我们自己的 DMA 恶意软件的设计和实现呈现于 4.3 节。4.4 节描述了对于 DAGGER 的评估。4.5 节考虑了反制措施并且特别讨论了 I/OMMU 的问题。在同一节中，我们描述了我们如何能够利用这些属性以显示首个 DMA 副作用。由于宿主 CPU 无法直接意识到由受到攻击的外设所引导的非法内存访问，我们试图触发一种发生于外设访问主内存时发生的副作用。 70 | 71 | 第 4 章所呈现的 DMA 副作用是推动我们实现我们于第 5 章所介绍的运行时监视器的动力。在第 5 章“DMA 恶意软件检测初步”中，我们展示了 DMA 副作用可以被如何利用以开发检测工具。我们定义了一种通用检测模型，它有助于我们构建检测工具，参见 5.1 节。随后，我们在 5.2 节中呈现了一种基于流行的 Intel x86 平台的概念验证实现。我们在 5.3 节评估了我们的实现。我们同时利用我们于第 4 章开发的 DMA 恶意软件测试了 BARM。最后，BARM 利用了这一事实，即我们的 DMA 恶意软件必须搜索有价值的数据，由此造成了一定量的总线传输。 72 | 73 | 在第 6 章，我们改良了我们的检测工具以实现一种合法状态报告应用程序。此应用程序将 BARM 测定结果发送至某个外部平台。其目标是实现这样一种安全通讯信道，此信道排除了由运行于网卡之上的恶意软件引导中间人攻击的可能性。在 6.1 节，我们呈现了一种模型以协商一种合法报告信道。我们需要一种诸如 TLS 的安全信道，它绑定于实际的通讯端点，即宿主 CPU。我们关于合法报告应用程序的概念验证基于 OpenSSL，参见 6.2 节。此实现章节同时描述了为了考虑网卡而必需的 BARM 改良。关于我们的实现的评估呈现于 6.3 节。我们还利用我们自己的 DMA 恶意软件 DAGGER 测试了关于网络的 BARM 改良。合法报告信道的安全性考虑于 6.4 节讨论。我们关于此论文的结论以及今后的工作呈现于最后一章，第 7 章。 74 | 75 | -------------------------------------------------------------------------------- /platform_firmware_security_defense/chapter_3.md: -------------------------------------------------------------------------------- 1 | # 第 3 章 固件防护 2 | 3 | ## 3.1 理想解决方案 4 | 5 | 固件问题的终极解决方案是一个巨大的挑战。哪怕是单块主板的众多独立设计商和制造商都需要被说服以执行它，并且遵循最佳实践以及诸如 NIST 这样的组织的建议。如此做将会要求它们在一种剩余价值极低的业务模式中投入资金到系统开发中来。对于最终用户而言，固件拥有低得多的可见性，以及慢得多的更新周期。设计商和制造商同样需要将思维模式从历史性的闭源/二进制 blob 和知识产权保护转变到一种即使不是完全开源也应该更加透明的模式上来，出于可审计性的考虑。 6 | 7 | 某些专家，诸如 Invisible Things 的 Joanna Rutkowska 提议将固件从硬件中分离并且隔离开来，以使得它可以被跟踪更改，以及创建一种无状态计算机。 8 | 9 | 尽管如此之多的业界潮流反对进步，作为一名手握购买决定权以行使或者影响权力的系统管理员，您确实拥有能力以影响事物使其变得更好。事实上，如果那些影响大规模购买决定权的人们不争取进步，进步将肯定不会发生。 10 | 11 | ## 3.2 真实的解决方案 12 | 13 | 今天可供您使用的实践上的解决方案涉及到对您现有的实践方式进行修订，诸如硬件生命周期管理。在此领域中，安全性至今也没有得到多少关注，更不必说固件安全性。此外，有一些小范围的微调是可以应用于您很可能已经在执行的常规最佳安全实践的，以针对固件方面的考虑进行增补和调整。 14 | 15 | 下一章将会进行更加深入的介绍，并且在我们的尾注中，我们将会包括一个详尽（但是简洁）的检查列表以供您用于您的组织。 16 | 17 | 以下是关于开始思考这个问题的快捷但是不完整的概括： 18 | 19 | * 当应用于固件时，遵循通常的最佳安全实践，包括： 20 | * 锁定固件设置 21 | * 设置口令 22 | * 禁用不需要的服务（例如远程管理、PXE 等） 23 | * 启用安全启动——并且在大规模部署时考虑部署或者管理您自己的安全启动密钥 24 | * 将固件添加到硬件生命周期 25 | * 确保您正在购买您所能买到的最安全的硬件，基于其他限制条件（预算等） 26 | * 在部署之前，锁定固件设置，转储并且计算散列值 27 | * 当 IT 人员着手操作硬件时，检查并测试固件 28 | * 是否有必要的更新 29 | * 转储并计算散列值 30 | * 检查散列值 31 | * 使用 CHIPSEC、FWTS 及其他工具 32 | * 在废弃处理之前，确保硬件已经被适当地抹除——包括固件，特别是存储于诸如 TPM 等位置的机密信息，更改固件口令以及安全启动密钥 33 | * 遵循 NIST 对于固件的建议 34 | * 使用 CHIPSEC、固件测试套件（FWTS）及其他工具 35 | 36 | ## 3.3 遵循最佳安全实践 37 | 38 | 作为一名 IT 专业人士，您很可能已经知道并且遵循比一般的非技术人士安全得多的最佳实践。这其中的某些可能完全不适用于固件——但是请记住，固件也是软件，并且通常是具有完整网络栈以及连续网络访问的软件。大多数现存的实践只需相对较少的逻辑性的修改就可以涵盖固件安全性。 39 | 40 | 下面的列表可能会遗漏某些项目并且作者将会欢迎那些可以整合到此书的未来版本中的建议。 41 | 42 | 我们的起点是这篇优秀的文章“保护固件免受攻击的 5 条提示”（_5 Tips for Protecting Firmware from Attacks_），其中带有来自 Eclypsium（之前来自 Intel 高级威胁研究（ATR））的 Yuriy Bulygin 和 John Loucaides 的输入内容，此外还有 NIST SP 800-147 标准。 43 | 44 | ### 3.3.1 理解并传播针对固件的威胁是真实存在的这一点：技术员工和管理教育 45 | 46 | 通过阅读本书，您将会比您的大多数同行更好地理解威胁。分享这本书，并且和您的同行以及经理分享您从中所学到的。最为紧迫的步骤是确保您了解您的系统所使用的哪种固件，并且以一种及时的方式更新制造商的固件升级，这将会需要您和 IT 及安全部门的合作与努力。 47 | 48 | 由于这些固件实现通常并不包括启用互联网的自动更新功能，这项任务落到了您身上。在大多数企业环境中，大量相同配置的机器使得这项任务变得容易了，但是跟踪固件版本和更新的可用性，并且部署它们仍然是一项繁重的任务。您已经有过管理操作系统和应用程序更新的实践，诸如保证更新以一种及时的方式被完全应用，尤其是当您允许用户延迟更新时。理想情况下，您可以在此过程中整合您的固件更新管理，如果不是实际的固件更新本身的话。 49 | 50 | ### 3.3.2 对固件进行宽泛的思考 51 | 52 | 记住，每一台现代计算系统的几乎每一个组件都包含固件。这不仅包括笔记本和服务器及其内建组件，诸如板载 WiFi 适配器或者硬盘等，也包括您可能将其完全视为外设的组件，诸如监视器等。记住包含那些并不严格属于计算机的计算设备，诸如交换机和路由器等。保持这样一种警觉性，即当今的几乎每一台电子设备都是某种形式的计算机，或者拥有与其相连接的某种形式的计算机。即使暂时还没有，很可能很快就会如此。 53 | 54 | ### 3.3.3 实践基本安全性 55 | 56 | 大部分固件只能在拥有物理访问或者 root/管理员权限的情况下进行更新。因此保护这些权限是至关重要的。遵循带有防火墙、沙盒、IDS/IPS 以及操作系统和应用程序更新的深度防护。 57 | 58 | ### 3.3.4 物理安全性 59 | 60 | 物理安全性就其自身而言是一整个独立的主题，自从人类农业起源之时就有其专业技能和知识。因此自然而然地有大量此类技能存在于信息技术世界以外。完全覆盖物理安全性，甚至只是在它涉及固件安全的情况下，也已经大大超出本书的范围。从根本上说，物理安全性是关于访问的——确保只有经过认证的个人拥有访问权，并且记录访问，不仅是那些认证过的个人的访问，甚至还包括非认证的个人的访问，例如在一次系统入侵中。 61 | 62 | 对于固件安全而言，物理访问是一个更加重要的方面，由于我们所讨论的众多类型的固件只能在拥有对包含该目标固件的机器的物理访问的情况下被修改。诸如通过主板上的 JTAG 端口，或者在重启过程中的控制台的物理存在。 63 | 64 | #### 3.3.4.1 服务器的物理安全性 65 | 66 | 对于服务器的情况，物理访问通常是高度控制的，以符合最佳实践。如果没有，则存在诸多额外的理由使得固件安全经受物理安全性的检查批准。应当注意的是，物理访问保护是必要的，但对于服务器而言还不够，由于在大部分现代系统上，众多固件 ROM 可以直接被远程修改（在远程访问 IP KVM、IPMI、iLOM、BMC 和 Redfish 等案例中），而且更有可能是经过操作系统和操作系统层级的工具来间接修改。 67 | 68 | #### 3.3.4.2 终端机的物理安全性 69 | 70 | 对于诸如台式机、笔记本和移动设备这样的客户终端系统而言，解决其物理安全性的问题看似不可能。然而，已有用于管理此类问题的最佳实践，并且在大多数情况下，在简单地遵循最佳实践的基础上仍有大量余地以进行改进，对于管理移动设备的物理访问，以及训练携带它们的人员。 71 | 72 | 关于终端机的固件安全性的最重要考虑是未知来源访问。最为明显的案例是经典的邪恶女仆攻击（_Evil Maid Attack_），其中一台遗留在酒店客房的无人值守的笔记本被一位装扮成酒店雇员的攻击者以物理方式访问。 73 | 74 | 在当今或是将来，旅行要求可能会鼓励或者要求人们将其笔记本放置在接受检查的行李中，这为机场安检以及行李搬运工提供了访问机会。即使您并不关注国家级别的威胁，某些国家可能会在边境或者旅行中鼓励或者协助企业间谍行为，以获取对于商业机密和知识产权的访问权，从而获得竞争优势。 75 | 76 | 对于终端机的标准安全建议，诸如： 77 | 78 | 1. 要求使用强口令 79 | 2. 使用强固件口令 80 | 3. 不要给予用户本地管理员权限 81 | 4. 使用全盘加密 82 | 5. 使用安全启动 83 | 84 | 并不足够，一旦一台笔记本被攻击者物理接触，所有这些假设都将不复存在。 85 | 86 | 还有一种更为隐蔽的版本称为“局中人下属”（insider affiliate）。由 Alice 所拥有的一台经常离开受到安全保护的公司办公环境的笔记本可能轻松地被朋友或者家庭成员访问而不被 Alice 所知，尽管她在绝大多数情况下保持了对该笔记本的物理访问权，并且不像在经典的邪恶女仆攻击的上下文中那样将其视为一台独自遗留在一个陌生位置的笔记本。这带来了几点重要的建议： 87 | 88 | 1. 总是保有大量经审查确认清洁（包括固件更新和安全扫描）的可供随时取用的笔记本，使得您不会由于这种轮换而过多地影响 Alice 的生产力 89 | 2. 开发并且持续改进笔记本轮换过程，使其保持尽可能高的效率 90 | 3. 考虑在每次出国旅行之后增加一次笔记本轮换 91 | 4. 使得针对更新和安全性的固件扫描成为任何移动式部署的一个常规部分，如同您对于病毒和恶意软件那样。每天一次甚至多次也不为过 92 | 93 | Linux 基金会工作站安全性检查列表在此领域中会有所帮助，带有针对固件考虑的具体指导，并且其大多数建议可以同等程度地适用于其他操作系统。 94 | 95 | #### 3.3.4.3 运输过程中的物理安全性 96 | 97 | 您可能会发现您自己需要运送任何类型的机器，包括服务器、笔记本、工作站、平板等。通常，这将会需要被快速办理，由于某些正当的商业理由。运输包装的物理破坏抵抗和检测是一项完善建立起来的技术。但是，值得对其进行某些思考，例如，如果您的企业通常运送的是整个货架的指尖陀螺，而您正在要求您的运输部门运送计算机设备。在运输过程中拦截硬件以植入间谍软件或者恶意软件是一种已知的攻击结构（称为“禁运”（_interdiction_））并且如果您使用全盘加密或者攻击者希望得到持久性，那么固件就是首选目标，特别是如果攻击者可以接触硬件足够长的时间以访问主板上的 JTAG 端口。因此运输之前的一整套固件更新、镜像提取和散列值计算的操作是合情合理的，还有对于以上相同元素的运输后验证。 98 | 99 | ### 3.3.5 黄金镜像（及其散列值） 100 | 101 | 这部分内容也许是您认为遗留在您安装操作系统的那段 IT 职业生涯中的东西，但是在固件领域，这仍然是高度相关的。某些固件实现可以被设计为或者期望为在其服务的生命周期内不会发生改变，即使它们的内容是可升级的，例如通过 JTAG 端口。制造商可能仅仅期望在保修送回时进行更新，或者例如只是将可升级性作为一种确保万无一失的特性。即使固件可以被期望进行相当频繁的更新，诸如 UEFI，它们拥有相当缓慢的更新周期，相对于您已经熟悉的操作系统和应用程序更新而言。 102 | 103 | 因此，在您初次购买时，为您的系统上的尽可能多的不同固件 ROM 制作黄金镜像以及当前级别（SHA256 或者更高）的散列值，并且周期性地在每一台设备上验证它们。注意，更改变量内容（例如 UEFI 中的启动设备顺序等）将会改变散列值。在现场使用中，此类更改应该不会非常频繁地发生，并且在理想情况下，制作黄金镜像及其散列值将会以至少相同的频率进行。这些镜像和散列值可以随同您已经保存的其他类似的可审计性的信息一同保存起来。 104 | 105 | ### 3.3.6 安全扫描 106 | 107 | 诸如开源项目 CHIPSEC、来自 Intel 的工具以及来自 Ubuntu Linux 的固件测试套件（_FWTS_）等工具允许对固件进行深度安全扫描。理想情况下，每一个品牌的基于 Intel 芯片和 UEFI 固件的系统都应该通过 CHIPSEC 中的每一项测试。作为一名系统管理员，使用您的购买杠杆以就这一问题向您的厂商施压，与此同时，您至少可以运行全部 CHIPSEC 测试，并且为每一台新系统记录信息，然后周期性地重复。您也可以利用您的 CHIPSEC 失败记录来影响未来的购买决策。 108 | 109 | ### 3.3.7 最终用户和非技术员工的教育 110 | 111 | 大多数企业当前并未对其员工进行起码足够的信息安全教育，但是移动设备的物理安全性是必需的。既然您当前的用户教育很可能确实需要改进，为何不包含某些关于物理安全性的训练呢？如果您的雇主事实上或者实际上要求员工将其笔记本带到工作单位以外，请确保并且强调一种“不加指责”（blameless）的方式来应对一起物理攻击事故——雇员们的工作要求他们的笔记本被非雇员接触并不是他们的过错。事故也是每个人学习如何改进安全性以及精炼您的事故响应计划的一次机会。同时，利用这次机会以宣传您的极低争执与快速的过程以将他们的可能受到攻击的笔记本轮换为完整功能的替代机。 112 | 113 | ### 3.3.8 将固件添加到硬件生命周期 114 | 115 | 将固件添加到硬件生命周期是固件安全中的远超其他方面的最为重要的组成部分。在 NIST SP 800-147 中详细描述的生命周期可以被用于增强您已有的硬件生命周期。当前的硬件生命周期通常和安全性只有很少甚至没有关系。对于传统硬件生命周期的关注焦点就是将硬件财产作为资产严加管理。在这里，至多只有一种关于跟踪财产的关注，包括如有可能就防止或者监测一台诸如笔记本的硬件财产于何时完全被盗，或是由于事故或者疏忽而丢失。即使是在被盗或者丢失的情况下，关于一笔昂贵财产的损失的关注可能会压倒其潜在的 IT 安全启示。 116 | 117 | 将固件安全性添加到硬件生命周期应该不会带来显著的额外工作量。最为重要的事情是为每一台全新的系统在其开箱之后的最早的步骤中制作黄金镜像并且计算散列值。在理想情况下，这些散列值将能够与制造商所提供的散列值进行比对，尽管当前制造商并不能可靠地提供散列值以供比对。在这样一个至关重要的节点上，捕获一条基线仍是可能的。在系统上安装或者配置软件之后，尤其是将该系统连接到网络之后，它就肯定不可能再用作基线。 118 | 119 | 下一步的精炼是在硬件的生命周期内的不同时间点添加固件检查。由于系统固件事实上是软件，在理想情况下，它应该以相同于操作系统和应用程序的频率被检查，很像反病毒软件。这对于大部分情况在当前并不可行，尽管 PreOS Security 的软件应该很快就能为此提供帮助。与此同时，为何不在一台系统从外部重新回到 IT 部门的控制范围时就添加固件重新转储和扫描的步骤呢？每当一台系统受到过物理访问攻击或者怀疑发生过一次攻击时都添加这些检查特别重要。 120 | 121 | 尽管关于固件安全性的新的关注可能会突出显示当前硬件生命周期过程中的问题，记住，硬件生命周期如同大多数 IT 过程与实践那样，总是可以改进，并且通过改进它往往还能得到其他好处。如果您的首席财务官最近还没有就财产跟踪问题打扰您，您将不会知道他（她）何时将会开始，也许您会迎来一位坚持要求在一夜之间就如此做的新任首席财务官。为何不现在就开始遵循更佳实践呢？ 122 | 123 | ## 3.4 NIST 指导意见总结 124 | 125 | 在同业界的顶尖专家共同工作的过程中，NIST 提供了一些关于固件安全性的优秀指南。这些文档比本书长得多，但是我们试图为您提供一段实用的总结。对于将来的阅读，推荐您阅读这些文档中的每一篇的摘要和执行摘要。如果您将要从头到尾地阅读其中一篇，从最新的开始，以及全面但仍处于草案阶段的 NIST SP 800-193。 126 | 127 | ### 3.4.1 NIST SP 800-147：BIOS 保护指南 128 | 129 | 发布于 2011 年的 NIST SP 800-147 的总体关注焦点是普遍应用于 x86 和 x86\_64 PC 系统的老旧的 BIOS 固件。然而其建议可以被简单地延伸并且应用于任何平台固件，特别是那些允许就地更新的固件。 130 | 131 | 首先，BIOS 更新应该使用数字签名以防止安装不可信的 BIOS 升级镜像。其次，如果可能，可信的 BIOS 升级安装应该要求操作人员的物理存在。在 BIOS 内部或者周边应该存在完整性保护特性，以防止对 BIOS 进行无意或者恶意的更新，包括防止其他系统组件跳过认证更新机制。 132 | 133 | 此文档的关注焦点看起来完全是 OEM 和制造商，然而，保证所购买和使用的系统以这样一种方式与这些要求相兼容使得它们实际上能够被强制执行是系统管理员或者安全专业人士的责任。而系统操作人员也应该为将这些要求以这样一种方式整合进硬件生命周期负责，以使得例如 IT 员工能够足够经常地与移动系统进行物理接触，以便能够以一种及时的方式进行要求的更新。 134 | 135 | ### 3.4.2 NIST SP 800-147b：服务器 BIOS 保护指南 136 | 137 | 在 NIST SP 800-147 中，有关更加复杂的服务器的间隔由 NIST SP 800-147b 解决。这些更加复杂的服务器包括诸如带有服务处理器的刀片和网络设备，其每一个刀片及其机箱本身都拥有多级 BIOS 或者 UEFI 固件。作为简洁的总结，所有相同的保护措施都应当被应用到每一级，包括在每个系统组件之间阻止未经许可的更新。 138 | 139 | ### 3.4.3 NIST SP 800-155：BIOS 完整性测定指南 140 | 141 | NIST SP 800-155 加入了可信根以及完整性测定的安全传输的概念。尽管此文档完全面向 OEM、操作系统厂商以及安全应用程序厂商，仍然值得理解系统的能力和限制，不论是从整体角度还是从您所管理的系统中所实现的角度。您可能还想理解这篇文档，以便就这些问题向您的系统厂商施压。 142 | 143 | ### 3.4.4 NIST SP 800-193：平台固件恢复能力指南 144 | 145 | 固件安全领域的最新文档，NIST SP 800-193，明确地概括了针对所有平台固件的讨论，并且包括了针对 OEM 和组件/设备提供商的指南，以保证所有系统固件都考虑并且实施了安全性的原则。再重复一遍——如果您将要只读一篇 NIST 指南，我们推荐您从 SP 800-193 开始。 146 | 147 | -------------------------------------------------------------------------------- /nist_sp_800-193/chapter_3.md: -------------------------------------------------------------------------------- 1 | # 第 3 章 原理和关键概念 2 | 3 | 本章为平台弹性的指导原则提供了简要的描述，它们为此文档中的指导意见提供了基础。本章还讨论了用于整篇文档的主要架构方面的概念和考虑。 4 | 5 | ## 3.1 支持平台弹性的原则 6 | 7 | 此文档中的安全性指导意见基于下列三个原则： 8 | 9 | * **保护**： 10 | 11 | 保证平台固件代码和关键数据处于某种具有完整性的状态，并且受到保护以防止损坏的机制，诸如保证固件更新的合法性和完整性的过程 12 | 13 | * **检测**： 14 | 15 | 检测平台固件代码和关键数据于何时发生损坏或者从某种授权的状态发生更改的机制 16 | 17 | * **恢复**： 18 | 19 | 用于将平台固件代码和关键数据恢复至某种具有完整性的状态的机制，如果任何上述代码或者关键数据被检测为发生损坏，或者如果被迫通过某种授权机制来进行恢复。恢复被限制为恢复固件代码和关键数据的能力 20 | 21 | 第 4 章的技术指导意见围绕这些原则进行组织。第一个原则，保护，其范围和目的类似于 NIST SP 800-147，_BIOS 保护指南_ \[1\] 中的指导意见。关于保护的基本原则在此文档中得到扩展以适用于平台中的更为宽泛的一组固件和配置数据。 22 | 23 | 尽管保护机制的本意是防止针对平台固件和关键数据的破坏性和恶意攻击，这些机制在所有类别的设备上的实现可能不完美或者不现实。在这些情况下，检测和恢复机制的本意是发现并且化解攻击，从而重新得到设备的正常和安全的运行。 24 | 25 | ## 3.2 弹性属性 26 | 27 | 此文档中的技术指导意见根据针对单个平台设备的指导意见而写作，以使得它们广泛适用于一系列设备、平台和系统。抛开对于设备的狭窄专注，此文档的本意是通过保证底层平台具有弹性从而建立起支持系统整体弹性以对抗破坏性攻击的指导意见。 28 | 29 | 平台可能不能为其所有平台设备完整地提供保护、检测和恢复能力。哪怕只是一个设备的功能丧失也可能足以使得整个系统永久性地不能运作，如果该特别设备在启动或者运行平台中具有关键作用。作为一个整体的平台若要称其为具有对抗破坏性攻击的弹性，其中对于最小限度地恢复系统运作所必需的，以及足以恢复系统的合理的功能的那一组平台设备，其本身应该是具有弹性的。我们称这组设备为 _关键平台设备_。特定的弹性属性可能因平台而异。 30 | 31 | * _受保护的_ 32 | 33 | 平台若要被看作 _受保护的_，所有关键平台设备必须满足 4.1 和 4.2 节的保护指导意见，但可以不完全地提供恢复设备地固件和/或关键数据的能力 34 | 35 | * _可恢复的_ 36 | 37 | 平台若要被看作 _可恢复的_，所有关键平台设备必须提供 4.1 和 4.3 节所描述的检测损坏的方法，并且提供满足 4.1 和 4.4 节的指导意见的从损坏中恢复的方法 38 | 39 | * _具有弹性的_ 40 | 41 | 平台若要被看作 _具有弹性的_，所有关键平台设备必须满足第 4 章的所有指导意见。非关键设备也应该满足这些要求，或者至少是如此设计的，即针对这些设备之一的攻击不会影响作为整体的平台的安全性。具有弹性的平台将会尝试防止那些能够干扰平台正确运行的攻击，同时还能提供机制以检测所发生的恶意或者意外的问题并且从中恢复 42 | 43 | ## 3.3 可信根和信任链 44 | 45 | 此文档中所描述的安全机制建立在可信根（RoT）之中。可信根是构成了提供一项或者多项诸如测定、存储、报告、恢复、验证和更新等具体针对安全性的功能的基础的元素。RoT 必须被设计为总是以预期的方式运作，由于它的恰当运作对于提供它的具体针对安全性的功能至关重要，并且由于它的不当行为不能被检测到。RoT 通常是信任链（CoT）中的首个元素，并且可以作为这样一条信任链中的锚点，以提供更加复杂的功能。RoT 的责任和能力可以完全在 RoT 内部实现，也可以利用通过一条植根于 RoT 的信任链由其 RoT 衍生的代理来执行。例如，当某个恢复代理（RTRec）被触发时，它将会通过启动另一个元素来引发恢复过程，该元素确定一种适当的恢复序列并且启动一连串的后续元素以执行恢复操作。图 2 提供了关于信任链如何从某个初始 RoT 建立的高层级描述。 46 | 47 | 通常，后续元素在维持由 RoT 开始的信任链中具有协助性。信任链中的组件具有提升的权限以执行安全性关键任务，诸如执行那些对于不那么受信任的软件不可用的设备更新。RoT 和 CoT 可以拥有机制以放下这些权限，一旦其安全功能执行完毕，或者如果该安全功能被确定为非必要。CoT 也可以在将控制权移交给某个非协助性的元素之前放下这些权限。 48 | 49 | 由于 RoT 对于提供关键安全功能至关重要，它们需要在设计上是安全的。确定 RoT 的可信度方面的主要考虑包括对于 RoT 的攻击面的分析，以及对于用于保护该攻击面的化解方法的评估。确保 RoT 的可信度是提供可信根的厂商的责任。厂商通常通过使得 RoT 不可变，或者通过保证在针对 RoT 的任何更新的完整性和合法性得到验证之后才执行这样的更新来保护它们。通常，RoT 运行在隔离环境中，并且运行在高于任何可能修改它的事物的权限等级之上，并且/或者能够在任何事物可能修改它们之前完成其功能，以保证其他设备不能在操作过程中攻击其行为。 50 | 51 | 此文档的 4.1 节提供了关于支持平台弹性的 RoT 的能力和属性的具体指导意见。 52 | 53 | 平台通常由大量设备组成，通常在设备以及不同制造商之间存在隔离边界。一个平台可能需要多个独立的 RoT 和 CoT 以提供对于弹性的完整覆盖。例如，硬盘控制器可能拥有不同于宿主平台的独立微控制器和固件。硬盘控制器和宿主平台可能都需要其各自独立的恢复信任链，如果它们各自的关键数据损坏。 54 | 55 | ## 3.4 设备关系 56 | 57 | 由于缺少能力或者功能，某些平台设备可能并不拥有它们自己的可信根以执行更新、检测或者恢复。我们将需要协助的设备称为共生设备，而将提供协助的设备称为宿主设备。依赖关系可以被如此确立，如果宿主设备和共生设备可以共同满足保护、检测和/或恢复的指导意见，而共生设备不能独立满足这些要求。这样的依赖关系可以撬动安全通讯信道或者其他技术。为了能够高效地提供协助，宿主设备需要自身满足那些关于它们所协助传递给共生设备的机制的指导意见。合在一起，宿主和共生设备提供了一条用于实现保护、检测和/或恢复的安全性指导意见的 CoT。 58 | 59 | 设备之间可能存在这样的关系，这里的信任是隐式的——即这种信任由系统架构来提供。一个设备可以从另一个设备接收关于无歧义的物理存在的指示，在此，一种隐式的信任关系已经存在。另一个设备通过可信路径发送消息这一事实意味着此设备可以信任该请求。 60 | 61 | 图 3 中的示意图显示了共生设备和宿主之间的关系的不同方面；这种关系可以位于隔离边界内部，或者跨越隔离边界、跨越设备。它还显示了在具有多个可信根、多条信任链以及多条通讯路径的情况下，不同的设备可以如何共存。 62 | 63 | 可能还存在其他关系，它们既不暗示也不要求任何信任级别。考虑一个负责接收更新的设备。该设备可以随后将这些更新传递至其他设备。由于每个设备（或者连同其宿主设备的共生设备）负责验证其自身的更新，在发布更新的设备和被提供这些更新的设备之间没有信任要求。 64 | 65 | ## 3.5 固件更新机制 66 | 67 | 固件保护指导意见的核心原则是保证只有合法并且经过授权的固件更新镜像可以被应用到平台设备。如果来源（例如设备、系统制造商或者其他经过授权的实体）和完整性可以被成功验证，则称此更新镜像为合法的。在应用更新之前验证镜像的技术过程称为 _认证更新机制_。 68 | 69 | 而授权则是许可执行某个更新的过程。尽管认证过程通常植根于设备或者系统制造商，执行更新的授权过程通常植根于设备或者系统所有者。 70 | 71 | ### 3.5.1 认证更新机制 72 | 73 | 认证更新机制利用数字签名以保证固件更新镜像的合法性。利用认证更新机制更新固件镜像依赖更新可信根（RTU），它包含一种签名验证算法和一个密钥存储器，该密钥存储器包含验证固件更新镜像的签名所需的公钥。此密钥存储器和签名验证算法以某种受保护的方式存储于计算机系统上，并且仅可通过使用认证更新机制或者安全本地更新机制来修改。 74 | 75 | RTU 中的密钥存储器包含用于验证固件更新镜像的签名的公钥 \[7\] 或者包含该公钥的散列值 \[6\]，如果该公钥由固件更新镜像提供。在后一种情况下，更新机制计算由固件更新镜像提供的公钥的散列值，并且保证它和出现在密钥存储器中的某个散列值相匹配，然后才会使用提供的公钥来验证固件更新镜像的签名。 76 | 77 | 密钥存储器中的与该公钥对应的私钥有可能受到“攻击”，例如，该私钥被盗并且被曝光，获得此密钥的访问权限的攻击者可以签名无效固件，它可以损坏平台设备或者向平台中注入恶意软件。对于签名的恰当使用因此使得供货成为必需，以便从密钥攻击中恢复。一系列技术可用于从这些情况中恢复。范例可以复杂到包括密钥层级，也可以简单到包括在恢复（或者更新）镜像的其余部分时更新密钥存储器。 78 | 79 | ### 3.5.2 授权更新机制 80 | 81 | 系统及其支持管理软件和固件可以提供若干种授权机制以便合法地更新固件镜像。这些包括： 82 | 83 | 1. **由用户引发的更新**：厂商通常为最终用户提供能够更新固件镜像的工具。这可以是通过外部介质以执行这些更新，也可以是通过能够从用户的正常操作系统中更新固件镜像的工具。取决于系统上所实现的安全机制，这些工具可以直接更新固件镜像，或者它们可以安排在下次系统重启时更新。更新后的代码将会遇到由不同修订版本的代码写入的关键数据。更新后的代码应该保证平台继续正常工作，可以通过保持同关键数据兼容、通过更新关键数据以使其同更新后的代码兼容，或者至少是通过将关键数据的值重置为其默认值来实现。 84 | 2. **受管理的更新**：一台给定的计算机系统可能拥有基于硬件和软件的代理，它们允许系统管理员远程更新固件镜像而无需来自用户的直接介入。 85 | 3. **回滚**：在应用更新之前对其进行认证的实现可能也会在更新过程中检查版本号。在这些情况下，固件镜像可能拥有一种特殊的更新过程，用于将已安装的固件回滚至某个早期版本。例如，回滚过程可能要求用户的物理存在。此机制可以防止攻击者安装具有已知漏洞的老旧固件。 86 | 4. **手动恢复**：为了从损坏或者不能正常工作的固件中恢复，计算机系统可以提供机制以允许具有物理存在的用户在启动过程中将固件镜像替换为已知良好的版本和配置。 87 | 5. **自动恢复**：某些计算机系统能够检测固件镜像于何时损坏并且从存储在不同于损坏的镜像的位置（例如第二块闪存存储器芯片、存储设备的保护区域等）的备份固件镜像恢复。 88 | 89 | ### 3.5.3 安全本地更新 90 | 91 | 尽管此文档建议固件更新通过 3.5.1 节所描述的某种认证更新机制来实施，某些设备也可以支持一种安全本地更新机制。这些机制通过某种能够说明无歧义的物理存在的过程来替代授权固件更新。例如，安全本地更新机制可以被用于从某个不能利用认证更新或者自动恢复机制更新的损坏的固件镜像中恢复。安全本地更新机制也可被一位物理存在的管理员用于在一个不允许回滚的设备上将其更新至某个早期固件镜像。 92 | 93 | 为了防止远程攻击利用安全本地更新机制，这些机制验证用户是否已经物理授权该更新是至关重要的。诸如通过远程控制台同设备或者系统进行交互等远程机制不满足关于物理存在的要求。类似地，可以被运行在系统或者设备上的恶意软件伪造的机制不满足此要求。参见 3.6.2 节以获得更多细节。 94 | 95 | 然而请注意，实现了安全本地更新机制的设备潜在地易受来自恶意管理员的攻击，以及对该设备或者系统具有物理访问权限的其他攻击。额外的物理、环境和技术方面的安全性措施对于保护这些设备至关重要，但是这些超出了此文档的范围。 96 | 97 | ## 3.6 关于平台弹性的其他考虑 98 | 99 | 此文档并未解决购买者、用户或者 IT 管理员可能考虑到的属于平台网络弹性的某些其他考虑。关于这些其他考虑的不完全列表和讨论见下文。 100 | 101 | ### 3.6.1 管理 102 | 103 | 厂商在设计具有弹性的平台时应该仔细考虑它们的目标客户，以保证恰当的管理和控制策略以及配置设置能够以最好地服务于客户要求的方式来管理。策略和配置设置的管理可以在本地或者远程进行。取决于平台类型，客户可能期望安全地从远程位置完整地管理平台的能力。某些客户可能期望要求物理存在的用户批准策略更改。其他客户可能期望能够远程提取任何日志数据，或者它们可能希望阻止提取日志数据，除非通过授权的本地机制。 104 | 105 | ### 3.6.2 授权机制 106 | 107 | 某些恢复和管理操作可能对平台固件或者软件作出重大修改。例如，固件设置可以控制启动顺序，而软件恢复代理可能还原一份备份而删除最近创建的数据。修改这些设置可能要求平台层级的授权以表明请求此更改的实体被授权如此做。对于某些环境，诸如大型组织机构或者数据中心，专业平台管理员可以利用提供给管理平台用的凭证来远程授权操作。在其他环境中，例如消费者或者小型企业，可能没有远程平台管理员。然而某些系统可能拥有可以本地使用的平台管理员凭证。或者，某些系统可以允许用户主张平台层级的授权，通过确保物理存在的用户发出命令或者请求更改。在这些系统上，平台必须无歧义地验证物理存在的用户授权了此操作。如果正确处理，恶意软件不能伪造涉及来自物理存在的用户的确认的授权检查。我们使用“无歧义的物理存在”这一词语来指示不能被恶意软件伪造的本地用户。 108 | 109 | 无歧义的物理存在允许主张平台层级的授权（或者平台层级授权的一部分），通过表明此人正在同设备或者平台进行物理交互。通过保证恢复操作或者关键数据更改得到了物理存在的人员的授权，无歧义的物理存在提供了一种本意是要防止恶意软件的影响的管理路径。 110 | 111 | 创建能够恰当和可靠地验证来自物理存在的人员的确认的平台和设备是复杂的。专用的物理按钮或者硬件跳线可以提供一种相对直接和显式的方法，以此表明物理存在。平台设计或者部署方面的考虑可以防止某人拥有直接物理机制以便同每一个支持某种依赖无歧义的物理存在的功能的设备进行交互。在这些情况下，需要在用于验证无歧义的物理存在的机制和将要以管理员的名义执行操作的设备之间存在一条可信路径。为了满足此文档后面提到的不可绕过性的指导意见，这条可信路径，它可能包括输入/输出设备（例如人体学接口设备、显卡等）和内部总线，需要被保护以防止其被恶意软件操控。 112 | 113 | 有一系列技术可以在验证无歧义的物理存在的物理机制和平台或者设备之间提供可信路径。一个范例可能是仅当平台可以被信任为处于某种具有完整性的状态，先于恶意软件可能干扰这些过程，诸如在启动过程的早期，才可以接受或者确认来自物理存在的人员的命令。在其他情况下，系统架构可能会在服务处理器（例如 EC、BMC）和其他平台设备之间提供可信路径。 114 | 115 | 依赖无歧义的物理存在而非平台管理员凭证以授权管理操作的设备可能易受具有该设备的物理访问权限的个人的攻击。因此它的应用可能不适合于缺少强物理安全性的应用或者环境。 116 | 117 | ### 3.6.3 网络辅助恢复 vs. 本地恢复 118 | 119 | 在大多数情况下，通过本地从损坏中恢复的能力将会是最为简便的，能够提供最高等级的客户满意度，并且可能是必需的，如果没有网络连接性。然而公认的是，这并非总是可能的，特别是鉴于众多设备所具有的存储限制。在本地恢复不可能的情况下，网络辅助恢复可以被实现，如果以某种安全并且可信的方式实施，这可能包括使用加密、数字签名、安全传输方法等。尽管本地或者网络辅助的恢复都是可接受的实现机制，一台设备同时支持二者的能力提供了更高级别的弹性，因而是推荐的。 120 | 121 | ### 3.6.4 自动恢复 vs. 手动恢复 122 | 123 | 恢复可以通过三种方式之一进行： 124 | 125 | 1. _完全自动_——引发恢复或者在恢复过程中无需用户交互 126 | 2. _部分自动_——自动引发恢复，但是在恢复过程中的某些时间点要求用户交互 127 | 3. _手动_——要求用户交互以引发恢复 128 | 129 | 完全自动恢复机制可能被某些用户所偏好，由于它可以在发生大范围攻击时允许更快速的大规模恢复。 130 | 131 | 完全自动恢复可能并不被所有系统支持，或是所有用户都想要的。例如，系统可能要求管理员凭证或者授权以继续恢复过程。 132 | 133 | 手动恢复可能被某些用户所偏好，以使得平台管理员被告知发生了某些错误，然后等待管理员决定接下来将要采取何种步骤。这可能也会有用，如果平台管理员希望捕获信息以帮助取证分析。 134 | 135 | 由管理员定义的策略通常定义了手动恢复的行为和权限要求。这样的策略可能也会影响自动恢复。例如，一条由管理员定义的策略可能会限制在恢复过程中可以被安装的固件版本。设置恢复策略者必须谨慎行事。策略中所设置的固件版本可能刚好就是被成功攻击从而使得恢复成为必需的版本。简单地重写易受攻击的版本可能导致攻击/恢复的循环。 136 | 137 | 策略本身也可能成为攻击目标，因此，恢复实现的设计必须说明该策略不可用的可能性。同时，由于恢复可能是多步骤的过程，一条将会在恢复过程结束时被满足的策略要求可能在中间步骤过程中未被满足。 138 | 139 | 重写固件镜像的恢复方案可能会在恢复过程中破坏那些将会有助于分析攻击的证据。恢复方案应该在可行的情况下提供方法以保留或者记录被攻击的镜像以及其他信息，在那些恢复固件时可能会丢失该信息的情况下。 140 | 141 | ### 3.6.5 事件日志 142 | 143 | 记录固件和恢复相关事件的日志通常可能有助于多种目的，包括但不限于： 144 | 145 | * 允许系统的平台管理员捕获关于可能导致针对平台的攻击或者实际平台攻击的信息的取证分析。这可能有助于确定平台是否可能包含未知安全漏洞，或者理解是否可能存在具有类似性质的大规模攻击。 146 | * 提供一条审计路径以获知某一事件于何时发生，以及某次更新或者恢复是否得到授权、由谁授权以及何时授权。 147 | 148 | 平台和设备制造商需要决定它们的系统可能要求何种级别的事件日志记录，为这些系统考虑预想中的用户环境。记入日志的事件应该以一种能够提供对其完整性的担保，并且允许日志事件的安全恢复和传输的方式来记录。必须谨慎行事以保证对事件日志的访问权限受到控制。非授权的人员可以利用事件日志数据分析以拓宽攻击面。 149 | 150 | -------------------------------------------------------------------------------- /the_impact_of_open_source_software_and_hardware/front_matter.md: -------------------------------------------------------------------------------- 1 | # 开源软件和开源硬件在欧盟经济中对于技术独立性、竞争性和创新的影响——最终研究报告 2 | 3 | Knut Blind，Mirko Böhm，Paula Grzegorzewska，Andrew Katz，Sachiko Muto，Sivan Pätsch 和 Torben Schubert 著 4 | 5 | 手稿完成于 2021 年五月，第一版 6 | 7 | 版权所有 (C) 欧盟 2021 8 | 9 | 欧洲联盟委员会关于文档的重用政策由 2011 年十二月 12 日关于重用委员会文档（OJ L 330, 14.12.2011, p. 39）的委员会决议 2011/833/EU 实施。除非另有注释，对于此文档的重用由知识共享：署名 4.0 国际版（CC-BY 4.0）许可证（）授权。这意味着如果给出了适当的认可并且指示出任何更改，重用此文档将被允许。 10 | 11 | 对于任何并非由欧盟拥有的元素的使用或者复制，可能需要直接向各自的权利持有人请求许可。 12 | 13 | 如何引用此报告： 14 | 15 | Blind, K.; Böhm, M., Grzegorzewska, P., Katz, A., Muto, S., Pätsch, S., Schubert, T. (2021). The impact of Open Source Software and Hardware on technological independence, competitiveness and innovation in the EU economy, Final Study Report. Brussels. 16 | 17 | # 摘要 18 | 19 | 此研究分析了开源软件（OSS）和开源硬件（OSH）对于欧洲经济的影响。它是受欧洲联盟委员会之 DG CONNECT 的委托。 20 | 21 | 据估计，位于欧盟境内的公司于 2018 年在 OSS 方面投资约 10 亿欧元，这带来了对于欧洲经济的 650 至 950 亿欧元之间的影响。该分析估计了超过 1:4 的成本效益比例，并且预测 10% 的 OSS 贡献增量将会每年产生额外的 0.4% 到 0.6% 的额外 GDP，以及欧盟境内超过 600 家额外的 ICT 初创企业。案例研究显示了，通过采购 OSS 而非私有软件，公共部门可以减少所有权的总成本、避免厂商锁定，并且由此增加数字自主权。此研究还包括对于欧洲和世界范围内的现存公共政策行为的分析。 22 | 23 | 然而，欧洲关于 OSS 的制度能力的规模不成比例地小于由 OSS 所创造的价值的规模。此研究因此给出了若干旨在获得数字自主的公共部门、开放的研发赋能的欧洲增长，以及数字化的具有内在竞争力的工业的具体公共政策建议。 24 | 25 | # 执行摘要 26 | 27 | ## a. 简介 28 | 29 | 此研究是受欧洲联盟委员会之 DG CONNECT 委托以分析开源软件（OSS）和开源硬件（OSH）对欧洲经济的影响。它提供了关于当前的 OSS 商业使用、成本和收益，以及利用并放大由使用 OSS 带来的收益的全球政策努力的完整情况。基于这一信息，此研究评估了欧盟（EU）通过使用、推广以及支持 OSS 和 OSH 而实现其政策目标（包括经济增长、更强的竞争力、创新，以及职位创造）的潜力。 30 | 31 | 此研究涉及对于相关文献、若干案例研究和统计分析的效果，以及一份在具有代表性的公司和开发者样本之间进行的详细调查的综述。在由咨询到的不同来源所提供的数据和专门为此研究所采集的数据之间观察到了强烈的一致性。 32 | 33 | ## b. 经济计量学分析见解 34 | 35 | 欧盟 OSS 开发者（个人开发者、学术科研人员、政府部门人士及雇员）为全球 OSS 生态系统作出了显著的贡献。在欧盟，最有可能贡献 OSS 代码（提交）的是小企业和小微企业雇员，而在美国，提交主要是由大型 ICT 公司作出的，这些大型公司成功地将它们的相关商业模型基于大量可自由获得且持续改进的 OSS 代码。 36 | 37 | 基于公有领域的信息，位于欧盟的公司于 2018 年在 OSS 方面投资约 10 亿欧元。此研究得出如下结论，即 OSS 池对欧盟的 GDP 作出了重大贡献，并且增加 10% 的贡献将会每年为欧盟产生 0.4% 至 0.6% 的额外 GDP。此研究同样的出结论，即 10% 的增量将会每年在欧盟产生多于 600 家额外的初创企业。案例研究显示，通过采购 OSS 而非私有软件，公共部门不仅能够减少所有权的总成本，还能减少或者防止厂商锁定。总体来看，开源的好处远远超过与之相关的成本。这些好处主要与开放性（包括标准和独立性）和劳动成本的节约，而非额外的收益生成有关。 38 | 39 | 对于欧盟成员国的 GDP 数据的经济计量学时间序列分析显示，在 2018 年，全体成员国的 OSS 经济影响介于 650 至 950 亿欧元之间。个人贡献者的数量达到至少 26 万，相当于 2018 年欧盟在计算机编程领域的约 310 万名雇员的 8%。在 2018 年来自欧盟成员国的超过 3000 万次提交相当于近 10 亿欧元的人员投资（基于全职工作相当量），并且这笔投资的成果可用于公有领域，并且因此无需被其他人再次开发。 40 | 41 | 该数据显示，公司规模越小，在 OSS 方面的相对投资就越大（在我们的关于 OSS 领域最为活跃的公司样本之中，拥有不超过 50 名雇员的公司作出了近半数的提交）。尽管超过 50% 的贡献者来自 ICT 行业（整个欧盟参与 OSS 开发的全体雇员的 8%），同样有来自专业、科技公司，以及在较小程度上，来自批发、零售和金融公司的强力介入。 42 | 43 | 此研究估计，直到 2018 年，在累计基础上，OSS 对于欧盟 GDP 的贡献，以及欧盟雇员对于 OSS 的贡献，得到了略微高于 1:10 的成本效益比例。在考虑 26 万名欧盟 OSS 贡献者的硬件及其他资本成本以后，此成本收益比例仍然略高于 1:4。 44 | 45 | ## c. 调查见解 46 | 47 | 共有 900 多个公司和开发者作出了回应，其中 100 多个回应了全部问题，这些问题专注于在先前的 OSS 研究中并未很好地覆盖的领域内的关于成本和收益的信息。将近 25% 的受访者是软件开发公司，另有 10% 的受访者为个人开发者。还有 40% 的受访公司生产配件、最终产品及服务，或者是平台提供商、系统集成商，或者网络运营商。只有少数受访者以有意义的方式参与了 OSH 开发。初创公司得到了强有力的代表。在这些调查受访者中，包括初创企业等小微公司对于 OSS 作出了不成比例地重要的贡献和投资，不论是按绝对价值计算，还是相对于它们的规模。一些小型和小微公司报导，其超过半数的财产可归因于 OSS，尤其是与 OSS 相关联的服务。受访者（特别是小型和小微企业受访者）还报导了高比例的与创新相关的开销，并且其对于 OSS 的将近 50% 的贡献与内部产品开发相关，而另外 40% 与现存的 OSS 相关。受访者很少提交与其公有代码贡献相关的专利申请，但是确实找到了其他方式以保护其知识产权。 48 | 49 | 按重要性排序的参与 OSS 的动机包括：寻找技术解决方案、避免厂商锁定、推进最先进的技术、开发高质量的代码、知识探索，以及知识创造。个人参与者的兴趣同样重要。通过为 OSS 做贡献而获取新的市场和消费者并不特别具有激励性。然而，节约成本是一项重大动力，通过降低内部维护工作量、获得对于免权利金的代码的访问，以及增加研发投入的回报。其他位于平均水平以上的动力包括：建立网络、开发非差异化的特性（例如常用库），以及提高声誉等。使用 OSS 并且为 OSS 项目贡献代码的受访者将支持开放标准和互操作性看作能够产生最高的收益，其带来好处是间接的，来自于网络界外效应，而非来自直接收入。受访者还为以下方面给出了中等水平以上的重要性：获取源代码、减少开销、避免厂商锁定、对于知识交流的活跃社区的访问、参与行为带来的创新促进效应，以及安全性和质量的提升。 50 | 51 | 就其自身对于总体成本效益比例的评估而言，三分之一的受访者给出了极高收益和低成本，另有超过三分之一的受访者给出了极高收益和中等成本，或者至少是高收益和低成本的评价，被引用最多的比值是 1:10，其次是 1:5。作为比较，通过考虑非人员成本（例如硬件），此研究基于经济计量学的收益，将此成本收益比例估计为 1:4。 52 | 53 | ## d. 案例研究见解 54 | 55 | 为了应对来自文献和我们的调查的数据缺乏问题，尤其是对于 OSH，我们进行了五项关于开源软硬件（OSSH）社区开发的案例研究，这些社区开发可以降低参与门槛，允许进行试验，以及为事实上的标准的开发做贡献。基金会是 OSS 和 OSH 生态系统中的重要驱动力，它可以提供若干重要服务，诸如标准化、知识转移和项目管理等。企业参与基金会以便同 OSSH 社区建立更深层次的关系，并非仅仅作为技术消费者，而是同时作为关键贡献者以及统筹者。然而，尽管若干 OSS 和 OSH 项目（有些是由公共资金支持的）总部位于欧盟，对其的参与并不限于欧盟的个人或公司。参与程度与公司规模有关，因此众多参与公司是将 OSS 用于其基于平台的业务模型的美国大型企业。因此难以明确区分欧洲的 OSS 或者 OSH 项目。同样，在众多案例中评估其效益为时尚早，由于 OSH 学科仍在兴起，其产品开发尚未开始。然而，这些案例确实显示 OSS 和 OSH 生态系统高度而高效地整合，且具有某些重叠，例如对于 OSH 的软件支持。来自这些案例研究的定性见解被用作欧盟强弱危机分析（SWOT）的基础。 56 | 57 | ## e. 政策分析 58 | 59 | 此研究综述了若干欧盟成员国（保加利亚、法国、德国、意大利、波兰、西班牙）以及位于欧洲（英国）、美洲（美国、巴西）和亚洲（中国、日本、印度、韩国）的其他国家的政府与 OSS 相关的公共部门和私营部门政策的范围、有效性和影响。此研究同时使用了定性和定量方法。该综述显示了不同地域之间在范围和目的上的显著差别。最后，创立并实施行之有效的 OSS 和 OSH 政策仍具挑战性。 60 | 61 | 总体来看，发现了四种主要的动机，其重点随时间而发生变化：(i) 节约成本；(ii) 转换成本和网络效应；(iii) 公共物品的生产不足；以及 (iv) 市场竞争和技术中立性。此研究同时指认了政府对于 OSS 的支持的两波主要浪潮，第一次始于 21 世纪 00 年代早期，而第二次始于 21 世纪 10 年代中期。这两波浪潮是由于不同的话题而驱动的。 62 | 63 | 公共部门政策致力于提升关于开源（OS）的能力以及在公共部门优化其结果，或者在公共采购相对于私有软件更加倾向 OSS。这样的政策拥有不同范围、实施机制以及规定性的等级，从具有强制约束力的法律到简单的范式。私营部门政策措施更加多样化。它们包括对于 OSS 的指导与支持。某些政府通过强制执行业界政策或者对其施加影响以便通过 OSS 取得创新，而其他一些政府则是同大学进行合作以支持 OSS 培训和开发，或者直接为 OSS 社区的创立或者对它的支持提供支持。政府还可以直接资助或者认证开源项目以实现政策目标。 64 | 65 | 宽泛地说，欧洲和美洲的政府政策专注于公共部门，而亚洲政府则倾向于关注私营部门。大部分受访的欧盟成员国和其他欧洲国家拥有国家层面的关于开源的正式政策——在大多数情况下是某种 OSS 公开采购政策。总体而言，此研究发现公共部门的 OSS 政策通常并不成功，甚至是在公共采购的情况下。唯一真正有说服力的实施发生于这样一种情况，在此，开源成为了数字化转型的核心组成部分，并且因此深入政府执政的数字文化的核心。要求在公共部门开发并复用 OSS 的法律在总体上也并不成功，通常是由于缺少具体的实施指导意见。在那些当今在其私营部门增强了软件能力的国家（即，韩国和中国等），开源在其业界政策中发挥了重要作用。欧洲政府采取了一种更加自由放任的方式，并且在今天，欧盟在涉及此领域的能力问题时处于劣势。私营部门的成功与经济刺激相关，在此，开源发挥的作用小于其在公共部门的作用。 66 | 67 | 对于 OSH，它与 OSS 之前存在显著差异，由于：OSS 解决方案的潜在市场远比 OSH 的宽泛，资助基于 OSS 的初创企业可能通常比资助那些基于 OSH 的廉价，而启动众多 OSH 企业需要更大程度上的管理能力。而业界能否找到某种针对硬件的开源方式以使其像在软件领域中那样具有吸引力仍有待观察。因此相对于 OSS 的情况，关于 OSH 的公共资金投入的回报更具风险性，并且很可能更加微薄。 68 | 69 | 最后，当前的事件为欧盟的领导及其对于得到不成比例的效果的承诺提供了一个机遇窗口。由于近期的贸易冲突，众多 OSS 基金会以及标准开发者重新回到欧盟。由此，以众多非政府实体将其总部设立在欧盟这一事实为代表的中立性历史对于这样一种很可能不论其他地区的政策变化而持续存在的问题提供了具有吸引力的解决方案。 70 | 71 | ## f. 政策建议 72 | 73 | 基于我们的经验分析结果，我们得出了下列建议。 74 | 75 | ### 数字自主的公共部门 76 | 77 | #### 构建制度能力 78 | 79 | * 建立一个由多达 20 家旨在支持并加速开源技术的消费、创造和应用的开源项目办公室（OSPO）组成的，由委员会资助的网络。 80 | 81 | #### 建立合法性 82 | 83 | * 建议通过开源提升数字自主权和技术主权。 84 | * 建议将 OSS 及其社区不仅整合到欧洲研究和创新政策之中，也整合到诸如欧洲绿色协定和欧洲工业战略等总体政策框架中来。同研究和创新计划中的 OSSH 基金会建立良好关系可能会为管理资金和支持提供一种适当的方法。 85 | * 建议对直接为 OSS 做贡献的选项进行评估。 86 | * 建议在针对开源立法时参考开放源代码促进会关于开源的定义。 87 | 88 | #### 战略情报 89 | 90 | * 建议将开源整合到欧洲统计局的数据采集行动以及欧盟基准行动之中。 91 | * 建议以战略情报部门扩展开源观测站 92 | 93 | ### 推动欧洲增长的开源研发 94 | 95 | #### 知识创造 96 | 97 | * 建议通过诸如欧洲地平线等现存计划以及新的促进会等提供更多与 OSS 和 OSH 项目相关的研发资金，尤其是针对中小企业甚至小微企业和初创企业，以及个人开发者；这些资金应该专注于限定于欧盟的目标，诸如欧洲绿色协定和欧洲工业战略。 98 | * 建议为 OSS 和 OSH 社区、学生和教授设立研究奖励和奖金。 99 | 100 | #### 知识传播和网络 101 | 102 | * 建议为将由公共资金支持的研发项目产生的代码上传到公众可访问的位于欧盟的 OSSH 版本库中的行为提供强大刺激。 103 | * 建议支持对于平台和存储库，以及托管于欧盟的网络的开发和维护。对当前的开源观察站的能力范围进行扩展可能成为起始点。 104 | 105 | #### 创业行为 106 | 107 | * 建议成员国的高等教育机构提供创业技能以支持基于 OSSH 的初创者，例如在创业学硕士计划以及 ICT 研究中。 108 | * 建议通过提供金融支持的方式支持 OSS 和 OSH 基金会，例如用于它们的教育计划及其同特别是中小企业和初创企业等公司的合作。 109 | 110 | #### 人力资本开发 111 | 112 | * 建议将 OSS 和 OSH 作为议题加入欧洲职能标准框架（EQF）。 113 | * 建议负责教育的国家组织促使其高等教育机构（HEI）将开源（开发、商业模型和授权许可）包括到其学位计划中来。 114 | * 建议为 HEI、公共研究组织（PRO）和商学院提供激励，以提供专注于 OSSH 的管理课程，诸如小型工商管理硕士。 115 | * 建议为在特别领域发展开源技能的个人开发一种欧盟认证体系。 116 | * 建议欧盟增加开源贡献者的多样性，以某项研究计划开始。 117 | 118 | ### 数字化与具有内在竞争力的工业 119 | 120 | #### 金融资本开发 121 | 122 | * 建议将来自个人和企业的 OSSH 贡献看作出于纳税目的的慈善捐赠。 123 | * 建议继续增强的欧洲创新理事会（EIC，包括 EIC 加速器）计划，并且明确使其对于年轻、高风险、研发密集型的基于 OSSH 的创业者开放，以解决在欧洲小型企业生态系统中缺乏风险资本的问题。 124 | * 建议启动诸如专注的风险投资资金等融资手段，以帮助新近获得资助的基于 OSSH 的初创企业同已建立的公司合作。 125 | * 建议以某种更具战略性和系统性的方式完全利用先市场性采购和 OSSH 之间潜在的协同效应。 126 | 127 | #### 管制环境 128 | 129 | * 建议明确个人开发者对于 OSSH 的责任。 130 | * 建议利用公共资源资助对于那些要求提升安全性的特定更改的关键 OSS 项目的安全审计。 131 | * 建议在标准化基础上推广 OSS 以作为未来的知识和技术转移信道，例如作为欧洲地平线计划项目的明确的传播信道。 132 | * 建议促进将 OSS 包含到公共采购中，例如在指示和策略中，考虑基于 OSS 的中小企业的需求。 133 | * 建议在未来的欧洲版权和专利立法修订中考虑开源。 134 | * 建议在相关政策促进会中考虑 OSS（以及 OSH 和开放数据）之间的相互联系。 135 | 136 | #### 市场创造 137 | 138 | * 建议明确地在竞争和平台政策中考虑开源，例如与对开源社区的管治相关的政策。 139 | * 建议明确地在中小企业政策中考虑开源。 140 | 141 | #### 关于开源硬件的具体建议 142 | 143 | * 建议资助一个项目以开发针对 OSH 的创新性管制机制，诸如与白频段光谱部署相关正在被考虑的方法。 144 | * 建议资助 OSH 领域的卓越研究中心的发展，它们包括学术界、研究机构和私营部门之间合作关系。 145 | 146 | #### 关于领域的具体建议 147 | 148 | * 建议对与人工智能（AI）相关的 OSS 开发者和公司提供资助机会。 149 | * 建议在欧盟未来的 AI 战略中明确考虑 OSS。 150 | * 建议对欧洲标准化实体启动一项标准要求（强制）以便为现场可编程逻辑门阵列（FPGA）开发一种比特流格式的欧洲标准。 151 | 152 | #### 可持续性 153 | 154 | * 建议建立一种维修的权利，包括在厂商终止设备支持的情况下对软件进行更改的权利，由于 OSSH 通过延长设备的生命周期、允许重用组件，以及减少重复开发的工作量而对可持续性作出贡献。 155 | * 建议为对 OSS 和 OSH 项目的支持提供额外的资助或者激励，如果它们能够带来额外的绿色效益。 156 | 157 | -------------------------------------------------------------------------------- /nist_sp_800-125a/appendix.md: -------------------------------------------------------------------------------- 1 | # 附录 A 虚拟机监视器基线功能描述 2 | 3 | 关于 5 种虚拟机监视器基线功能中的每一种的详细描述提供如下： 4 | 5 | * _HY-BF1：VM 进程隔离_——提供 VM 执行计划，管理在 VM 中运行的应用程序进程，诸如 CPU 和内存管理，以及在 VM 中运行应用程序的过程中进行不同的处理器状态之间的上下文切换。如果具有 DMA 能力的设备被用于虚拟机监视器宿主，这些设备的内存访问也需要被控制。然而，此功能被认为属于 HY-BF2，由于它属于设备调度。 6 | * _HY-BF2：设备调度和访问控制_——使设备对于 VM 可用（例如通过模拟、准虚拟化、透传或者自虚拟化的硬件设备），并且控制哪些 VM 被允许访问哪些设备（例如网卡（NIC），诸如 IDE 驱动器的存储设备等）。 7 | * _HY-BF3：来自客户 VM 的命令的直接执行_——某些来自客户 OS 的命令是由虚拟机监视器直接执行的，而非通过中断或者上下文切换而触发。此功能适用于那些实现了准虚拟化而非完全虚拟化的虚拟机监视器。 8 | * _HY-BF4：VM 生命周期管理_——这涉及从 VM 镜像的创建和管理、VM 状态的控制（开始、暂停、停止）、VM 迁移、制作快照、VM 监视，到策略的强制执行等全部功能。 9 | * _HY-BF5：虚拟机监视器平台的管理_——这涉及定义虚拟机监视器软件模块中的不同配置参数中的一些东西和设置值，包括适用于虚拟机监视器中的虚拟网络的配置的东西和设置值。 10 | 11 | 关于上述基线功能的详细描述如下： 12 | 13 | ## A.1 HY-BF1（VM 进程隔离） 14 | 15 | 提供 VM 执行计划，管理在 VM 中运行的应用程序进程，诸如 CPU 和内存管理，以及在 VM 中运行应用程序的过程中进行不同的处理器状态之间的上下文切换。为了保证 VM 进程隔离，来自支持 DMA 的设备的内存访问也需要受到虚拟机监视器的控制（例如通过 IOMMU）。然而，此功能被认为属于 HY-BF2，由于它属于设备调度。 16 | 17 | ## A.2 HY-BF2（设备调度和访问控制） 18 | 19 | 在 VM 中执行的应用程序需要访问诸如网络和存储设备。对设备访问的调度在虚拟机监视器宿主中通过设备虚拟化（也称为 IO 虚拟化）来处理。有 3 种常见的设备虚拟化方式：(a) 模拟，(b) 准虚拟化，和 (c) 透传或者自虚拟化的硬件设备。 20 | 21 | 在模拟中，代码被如此实现以呈现某个虚拟设备，它拥有与之对应的真实（硬件）设备，客户 OS 已经拥有它的驱动程序。这允许运行未经修改的客户（VM），由此实现完全虚拟化。模拟代码运行于虚拟机监视器中。来自客户 VM 应用程序（通过其客户 OS）的 I/O 调用被虚拟机监视器内核拦截，并且转发到此代码，由于客户 VM 在此设置之下不能直接访问物理设备。这也可以将来自客户 VM 的模拟虚拟设备的访问多路传输至底层物理设备。 22 | 23 | 在准虚拟化方式中，虚拟机监视器向客户呈现某个人工设备的某个接口，此设备没有相应的硬件对应体。这允许在客户上安装特定的，简化的，对虚拟机监视器警觉的 I/O 驱动程序（称为准虚拟化的驱动程序）。来自客户 VM 中的这些准虚拟化的设备驱动程序的调用由另一个设备驱动程序（称为后端驱动程序）来处理，这些驱动程序直接与物理设备交互，并且调度来自准虚拟化的客户到该物理设备的访问。在某些实例中，来自准虚拟化的客户驱动程序的调用直接由虚拟机监视器通过其超级调用接口（与之相对应的调用称为超级调用）来处理。 24 | 25 | 设备虚拟化的第 3 种方式，透传方式（或者直接设备指认）被部署于这样的情形，在此，由于性能的原因，某个 VM 需要对于某个设备（例如 NIC、硬盘控制器、HBA、USB 控制器、串口、火线控制器、声卡等）的专属访问，以避免由于模拟造成的开销。通常，这对于 PCI 设备来说通常是必需的，并且因此也称为 PCI 透传。由于这些设备中的很多拥有内存映射的接口，它们可以直接读取或者写入主内存，并且因此被称为具有直接内存访问（DMA）能力的设备。为了提供 VM 对于具有 DMA 能力的设备的专属访问，此设备的内存页被映射到客户 VM 的地址空间。 26 | 27 | 除了上述 3 种类型的设备虚拟化之外，虚拟机监视器宿主还可以支持自虚拟化的硬件设备。这些设备拥有能够导出对应于某种物理功能（PF）的一组虚拟功能（VF）的接口。虚拟机监视器可以随后将这些 VF 指认给多个客户 VM，而它仍然保持对 PF 的控制。这些设备遵守单根 I/O 虚拟化（SR-IOV）规范，并且由此允许具有 DMA 能力的设备在 VM 之间共享（如同虚拟化和多路传输是由这些设备自身实现的）而非如同在透传模式中那样由单一 VM 专用。 28 | 29 | ## A.3 HY-BF3（来自客户 VM 的命令的直接执行） 30 | 31 | 某些来自客户 OS 的命令是由虚拟机监视器直接执行的，而非通过中断或者上下文切换而触发。这些命令称为超级调用，并且由虚拟机监视器中的特殊接口支持。此功能仅适用于那些实现了准虚拟化而非完全虚拟化的虚拟机监视器。 32 | 33 | ## A.4 HY-BF4（VM 生命周期管理） 34 | 35 | 这包括 VM 上的所有管理操作，贯穿其生命周期。它们包括但不限于： 36 | 37 | * 遵守标准镜像的 VM 创建，保证镜像的完整性并且保护镜像的存储和获取过程；供应具有适当的 vCPU、内存、网络和存储的镜像 38 | * 将 VM 从一个虚拟机监视器宿主迁移到另一个 39 | * 监视 VM 执行与出入流量，以及总体配置管理 40 | * 对于 VM 管理的精细粒度访问控制，包括改变 VM 状态的基本操作——启动、暂停、停止 41 | * 快照的访问控制和管理 42 | 43 | 管理任务通过利用提供了网络接口的管理守护进程而实现。_这些接口通常不是作为虚拟机监视器内核模块的一部分，而是在高权限 VM（管理 VM）上实现，它作为虚拟机监视器平台启动过程的一个组成部分而启动。_ 44 | 45 | ## A.5 HY-BF5（虚拟机监视器平台管理） 46 | 47 | 这些任务包括虚拟机监视器宿主（虚拟化的宿主）和虚拟机监视器软件本身的配置所涉及的任务。重要的任务包括：将 VM 供应至虚拟机监视器宿主，创建和管理虚拟机监视器集群，以及配置虚拟机监视器宿主内部的虚拟网络。虚拟网络是虚拟机监视器宿主内部的由软件定义的网络，它允许 VM 之间的连接性，以及 VM 到外部网络（例如 LAN、WAN 等）的连接性。 48 | 49 | # 附录 B 关于虚拟机监视器的基线功能的安全性建议的可溯源性 50 | 51 | |编号|安全性建议|基线功能| 52 | |----|----|----| 53 | |HY-SR-1|所启动的虚拟机监视器应该成为平台以及整体基础设施的一部分，它包括：(a) 具有基于标准的密码学测定能力和存储设备的支持 MLE 的硬件，以及 (b) 应该具有能力以利用这些来提供一条从硬件开始直到所有虚拟机监视器组件的信任链的证明过程。被测定的元素（组件）至少应该包括下列：核心内核、内核支持模块、设备驱动程序，以及虚拟机监视器的原生管理应用程序（用于 VM 生命周期管理和虚拟机监视器管理）。信任链应该为所有被测定的组件未被破坏并且它们的版本正确（即整体启动完整性）提供担保。如果信任链将要被延伸至客户 VM，虚拟机监视器应该提供一个虚拟接口到基于硬件的 MLE。|无| 54 | |HY-SR-2|虚拟化的宿主的硬件应该利用 MMU 对指令集虚拟化和内存管理提供辅助，由于硬件支持提供了下列安全性担保，而这些是完全基于软件的虚拟化所不能保证的：
* 更佳的内存管理控制可以防止诸如缓冲区溢出等攻击
* IOMMU 中的 DMA 传输重映射特性提供更佳的 I/O 设备隔离。更进一步地，直接将 I/O 设备指认给某个特定 VM 并且允许直接访问这些资源这一特性消除了为该 VM 提供模拟设备驱动程序的需求，因此减少了可信代码的大小
* 客户 OS 代码和虚拟机监视器代码执行于不同的处理器模式，提供了更佳的隔离
* 权限层级的隔离可以为设备访问调度功能提供更佳的保护，并且硬件层级的内存保护可以提供更佳的 VM 层级保护
* 通过支持完全虚拟化，COTS 版本的 OS 可以允许更简单的补丁和更新，而非必须对可以运行于准虚拟化平台的唯一类型的修改或者移植版本的 OS 进行相同操作
* 由于现在众多虚拟化特性在硬件中可用，虚拟机监视器代码将会变小，允许更佳的安全性证明和验证|HY-BF1（VM 进程隔离）| 55 | |HY-SR-3|虚拟机监视器应该拥有配置选项以便为每一个（要求内存的）VM 指定保证的物理内存量，以及该值的上限，并且指定一个优先级的值，以用于在多个 VM 之间产生竞争的条件下获取必需的内存资源。更进一步地，允许所有 VM 的配置内存总量超过宿主的物理内存的内存超量使用特性（如果可用）应该默认禁用。|HY-BF1（VM 进程隔离）| 56 | |HY-SR-4|虚拟机监视器应该拥有强壮的配置特性以便以这样的方式将虚拟资源提供给所有托管的 VM，即它不会超过某种关键物理资源（例如 CPU 内核数量）|HY-BF1（VM 进程隔离）| 57 | |HY-SR-5|虚拟机监视器应该提供特性以便为每一个部署的 VM 所需的 CPU 时钟周期指定下限和上限，以及提供特性以便为每一个 VM 指定一个优先级分值，以便在多个 VM 竞争 CPU 资源的情况下辅助计划|HY-BF1（VM 进程隔离）| 58 | |HY-SR-6A，HY-SR-6B，HY-SR-6C|_安全性建议 HY-SR-6A（模拟）_：由于通过软件模拟硬件的复杂性，模拟方式除了受到性能损失以外，还会增加 TCB 的大小，特别是在客户 OS 拥有原生设备驱动程序并且设备模拟代码作为内核模块运行在和虚拟机监视器相同的权限层级的情况下。因此，模拟应该仅被应用于这种复杂性可控时（例如 USB 主机控制器）
_安全性建议 HY-SR-6B（准虚拟化）_：在准虚拟化的设备驱动程序被用于 VM 中的情况下，对物理设备的访问的调度应该通过在专用 VM 而非在虚拟机监视器中运行后端设备驱动程序（它们控制着连接到虚拟机监视器宿主的物理设备）来启用。这有助于使得后端设备驱动程序代码运行在低于虚拟机监视器的权限层级上。此外，虚拟机监视器平台应该包括输入/输出内存管理单元（IOMMU）形式的硬件支持以便验证并且翻译从驱动程序域的底层硬件设备到宿主内存的访问。强制性的具体 IOMMU 特性包括 DMA 重映射，在此，从设备到客户物理地址（GPA）的 DMA 调用必须被翻译到宿主物理地址（HPA），并且随后被检查该 HPA 地址是否落在指认给该设备的保护域内。结合这些机制可以减少 TCB 的大小，并且降低错误的设备或者设备驱动程序的行为的影响（限制在设备驱动程序 VM 范围内，而非虚拟机监视器）
_安全性建议 HY-SR-6C（透传或者自虚拟化的硬件设备）_：对于 VM 需要被赋予对具有 DMA 能力的设备的专用访问权限的情况，虚拟机监视器平台应该包括输入/输出内存管理单元（IOMMU）形式的硬件支持以便验证并且翻译所有设备对宿主内存的访问。此建议也适用于启用虚拟化的硬件设备的使用（基于 SR-IOV 规范）。强制性的具体 IOMMU 特性包括 DMA 重映射，在此，从设备到客户物理地址（GPA）的 DMA 调用必须被翻译到宿主物理地址（HPA），并且随后被检查此 HPA 是否落在指认给该设备的保护域内|HY-BF2（设备调度和访问控制）| 59 | |HY-SR-7|应该可能设置访问控制列表（ACL）以便将每一个 VM 进程的访问权限限制为仅对指认给该 VM 的设备。为了实现这一点，虚拟机监视器配置应该支持某种特性以标识（标记） VM（从语义上讲，一组任务），并且/或者拥有某种特性以便为每一个 VM 指定一组设备白名单（被允许的设备列表）|HY-BF2（设备调度和访问控制）| 60 | |HY-SR-8|应该可能为每一个 VM 的网络带宽和 I/O 带宽（例如硬盘读/写速度）设置资源限制以防止拒绝服务（DOS）攻击。更进一步地，对资源限制的适当使用可以使得 DOS 攻击对定义了资源限制的 VM 或者集群的影响定域化|HY-BF2（设备调度和访问控制）| 61 | |HY-SR-9|必须为所有类型的 VM 定义黄金标准，并且不符合此标准的 VM 镜像不应该被允许存储到 VM 镜像服务器或者库中。更进一步地，VM 镜像库中的镜像应该被周期性地扫描以查找将要过时并且因此偏离标准的 OS 版本和补丁|HY-BF4（VM 生命周期管理）| 62 | |HY-SR-10|存储于镜像服务器中的每一个 VM 镜像应该带有数字签名以作为合法性和完整性的标识，利用可信、强壮的密码学密钥签名|HY-BF4（VM 生命周期管理）| 63 | |HY-SR-11|向 VM 镜像库中迁入或者从中迁出镜像的许可应该通过某种强壮的访问控制机制强制实施，并且限制在一组授权的管理员中。如果没有访问控制机制，VM 镜像文件应该存储于加密设备中，该设备只能由一组限定的授权管理员利用具有足够复杂度的口令打开/关闭|HY-BF4（VM 生命周期管理）| 64 | |HY-SR-12|对存储 VM 镜像的服务器的访问应该总是通过安全协议，诸如 TLS|HY-BF4（VM 生命周期管理）| 65 | |HY-SR-13|在 VM 即时迁移过程中，应该谨慎以确保安全认证协议被用于执行即时迁移；执行迁移操作的管理员的凭证只被传输至目标宿主；内存内容和处理器状态的迁移通过安全网络连接进行；并且一个专用虚拟网段被同时用于源和目标宿主以承载此流量|HY-BF4（VM 生命周期管理）| 66 | |HY-SR-14|应该存在机制以用于安全监视、VM 操作安全策略强制实施——对于 VM 中运行的恶意进程和出入 VM 的恶意流量。此监视和强制实施机制构成了用于构建杀毒（AV）和入侵检测及防止系统（IDPS）解决方案的基础|HY-BF4（VM 生命周期管理）| 67 | |HY-SR-15|用于 VM 的安全监视和安全策略强制实施解决方案应该基于“VM 外部”，并且应该撬动虚拟机监视器的虚拟机自省能力。通常，这样的解决方案涉及在安全加固的或者可信 VM 中运行诸如安全虚拟设备（SVA）的安全工具|HY-BF4（VM 生命周期管理）| 68 | |HY-SR-16|运行于虚拟机监视器宿主中的所有反恶意软件工具（查毒软件、防火墙和 IDPS 等）应该拥有能力以执行基于一定周期的自主签名或者索引文件更新|HY-BF4（VM 生命周期管理）| 69 | |HY-SR-17|VM 配置管理工具应该具有能力以编译日志并且警示管理员，如果在被监视的任何 VM 中检测到配置更改|HY-BF4（VM 生命周期管理）| 70 | |HY-SR-18|用于 VM 管理的访问控制解决方案应该拥有粒度能力，既在权限授予层级，也在对象层级（即对于权限目标的具体说明可以是单一 VM 或者任何 VM 的逻辑组合——基于功能或者位置）。此外，还应该存在这样的能力以禁止对于某个 VM 组（例如运行具有特定敏感度等级的负载的 VM）中的某些特别对象的权限，尽管其拥有对于该 VM 组的访问权限|HY-BF4（VM 生命周期管理）| 71 | |HY-SR-19|对于企业中安装的所有虚拟机监视器的管理应该利用企业虚拟化管理系统（EVMS）以中心化的方式实现。更进一步地，用于不同类型的负载和集群的企业黄金标准虚拟机监视器配置必须通过 EVMS 进行管理（强制实施）。此黄金标准配置至少应该覆盖下列方面——CPU、内存、存储、网络带宽，以及（如有必要）宿主 OS 加固|HY-BF5（虚拟机监视器平台管理）| 72 | |HY-SR-20|对于虚拟机监视器宿主和软件管理功能的保护应该通过分配一块专用的物理 NIC 来保证，如果这不可行，则改为将虚拟机监视器的管理接口置于专用的虚拟网段中，并且利用防火墙强制实施流量控制（例如，在企业网络中指定子网，从这些子网到管理接口的流入流量被允许）|HY-BF5（虚拟机监视器平台管理）| 73 | 74 | # 附录 C 用语 75 | 76 | * 完全虚拟化——一种形式的虚拟化，其中，虚拟机监视器呈现的虚拟化资源反映了底层硬件的架构，因此未经修改的客户 OS 可以在其上运行 77 | * 客户操作系统（OS）——虚拟机（见下）执行栈中的操作系统组件，其他组件包括虚拟硬件、中间件和应用程序 78 | * 虚拟机监视器——利用某种特殊的 OS 内核以及支持性的内核模块构建的软件，这些内核模块为虚拟机（见下）所呈现的不同执行栈提供隔离 79 | * 虚拟化的宿主——诸如虚拟机监视器等虚拟化软件所安装于其上的物理宿主。通常，虚拟化的宿主将会包含特别硬件平台以辅助虚拟化——特别是指令集和内存虚拟化 80 | * 虚拟机（VM）——由软件定义的完整的执行栈，由虚拟化的硬件、操作系统（客户 OS）和应用程序构成 81 | * 虚拟化——用于硬件资源模拟或者抽象化的方法，以允许完整的执行栈，包括软件应用程序，在其上运行 82 | 83 | # 附录 D 参考文献 84 | 85 | * 1. _Mastering VMware vSphere 5.5_, Scott Lowe et al., Wiley Publishing Incorporated (2013) 86 | * 2. _Running Xen: A Hands-On Guide to the Art of Virtualization_, J.N. Matthews et al., Prentice Hall (2008) 87 | * 3. _Building the Infrastructure for Cloud Security: A Solutions View_, R.Yeluri, and E.Castro-Leon, Apress Media/Springer Science (2014) 88 | * 4. _Trusted Platform Module (TPM) Main Specification_: [http://www.trustedcomputinggroup.org/resources/tpm_main_specification](http://www.trustedcomputinggroup.org/resources/tpm_main_specification) 89 | * 5. S.Shirinbab, L. Lundberg and D. Ilie, _Performance Comparison of KVM, VMware and Xenserver using a Large Telecommunication Application, Proceedings of the Fifth International Conference on Cloud Computing, GRIDs, and Virtualization (CLOUD COMPUTING)_, 2014. [http://bth.diva-portal.org/smash/record.jsf?pid=diva2%3A834000](http://bth.diva-portal.org/smash/record.jsf?pid=diva2%3A834000) 90 | * 6. E. Bugnion, J. Nieh and D. Tsafrir, Hardware and Software Support for Virtualization, 91 | 92 | -------------------------------------------------------------------------------- /nist_sp_800-147/appendix.md: -------------------------------------------------------------------------------- 1 | # 附录 A 系统 BIOS 实现指导意见总结 2 | 3 | 此附录包含了可在 3.1 节找到的用于系统 BIOS 实现的安全 BIOS 更新指导意见的总结。这些指导意见本意是用于平台厂商设计、实现或者选择一种系统 BIOS 实现。读者应该查询此文档正文中的相关章节以获取那些深入描述此指导意见的目的和上下文的更多信息性的文字。 4 | 5 | ## 1. 许可的 BIOS 更新机制 6 | 7 | * 1-A 所有系统 BIOS 更新应该使用 3.1.1 节描述的认证更新机制，或者符合 3.1.2 节所述指导意见的可选安全本地更新机制。 8 | 9 | ## 2. BIOS 更新认证 10 | 11 | * 2-A 应该有一个更新可信根（RTU），它包含一种签名验证算法以及一个包含用于验证 BIOS 更新镜像的签名的公钥的密钥存储器。 12 | * 2-B 密钥存储器和签名验证算法应该以一种受保护的方式存储于计算机系统上，并且仅可使用认证更新机制或者 3.1.2 节所述的安全本地更新机制来修改。 13 | * 2-C RTU 中的密钥存储器应该包含用于验证 BIOS 更新镜像的签名的公钥或者用于验证包含公钥的 BIOS 更新镜像的公钥的散列值 \[FIPS180-3\]。在后一种情况下，更新机制应该保证由 BIOS 更新镜像提供的公钥的散列值出现在密钥存储器中，然后才能使用提供的公钥来验证 BIOS 更新镜像的签名。 14 | * 2-D BIOS 更新镜像应该以符合 NIST SP 800-89，_Recommendation for Obtaining Assurances for Digital Signature Applications_（关于获得数字签名应用程序的担保的建议）\[SP800-89\] 的方式来签名，使用一种在 NIST FIPS 186-3，_Digital Signature Standard_（数字签名标准）\[FIPS186-3\] 中具体说明的经过许可的数字签名算法，它提供至少 112 位的安全强度，以符合 NIST SP 800-131A，_Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths_（过渡：关于密码学算法和密钥长度的使用的过渡的建议）\[SP800-131A\] 的要求。 15 | * 2-E 认证更新机制应该保证 BIOS 更新镜像经过数字签名，并且该数字签名可以在更新 BIOS 之前利用 RTU 中的密钥存储器中的密钥之一来验证。 16 | 17 | ## 3. 安全本地更新（可选） 18 | 19 | BIOS 实现可以可选地包括一种安全本地更新机制，在此，由物理存在来认证 BIOS 更新镜像的安装，而无需使用认证更新机制。 20 | 21 | * 3-A 安全本地更新机制应该通过要求物理存在来保证 BIOS 更新镜像的合法性和完整性。 22 | 23 | ## 4. 完整性保护 24 | 25 | * 4-A RTU 和 BIOS（除了存储于非易失性存储器中的被 BIOS 使用的配置数据）应该被保护以防止无意或者恶意的修改，使用一种在认证 BIOS 更新机制以外不能被超越的机制。 26 | * 4-B 保护机制应该被保护以防止非授权的修改。 27 | * 4-C 认证 BIOS 更新机制应该被保护以防止无意或者恶意的修改，利用一种至少和保护 RTU 和系统 BIOS 的机制一样强的机制。 28 | * 4-D 保护机制应该在执行那些无需使用认证更新机制或者安全本地更新机制就能修改的固件和软件前保护包含系统 BIOS 的系统闪存的相关区域。 29 | * 4-E 保护应该由除了通过认证机制以外不可更改的硬件机制来强制执行。 30 | 31 | ## 5. 不可绕过性 32 | 33 | 这些不可绕过性的指导意见不适用于存储于非易失性存储器中的由系统 BIOS 所使用的配置数据。 34 | 35 | * 5-A 认证 BIOS 更新机制应该是在没有贯穿于安全本地更新机制的物理介入的情况下更新系统 BIOS 的唯一机制。 36 | * 5-B 系统及其附带的系统组件和固件的设计应该保证没有任何机制可以允许系统处理器或者任何其他系统组件绕过认证更新机制，除了安全本地更新机制以外。 37 | * 5-C 尽管系统组件可能拥有对 BIOS 闪存的读取访问权限，它们不应该能够直接修改系统 BIOS，除了通过认证更新机制或者利用某种要求物理介入的认证机制以外。 38 | * 5-C.i 能够绕过主处理器的总线控制（例如，对于系统闪存的直接内存访问）不应该能够直接修改固件。 39 | 40 | 系统中的微控制器不应该能够直接修改固件，除非微控制器的硬件和固件组件使用和 RTU 相同的机制被保护。 41 | 42 | # 附录 B 术语 43 | 44 | 此出版物中使用的部分选定的术语定义见下文。 45 | 46 | * **基本输入/输出系统（BIOS）**：在此出版物中，总体地用于指代基于传统 BIOS、可扩展固件接口（EFI）和统一可扩展固件接口（UEFI）的启动固件。 47 | * **传统 BIOS**：用于众多 x86 兼容计算机系统的老旧启动固件，也称为遗产 BIOS。 48 | * **用于测定的核心可信根（CRTM）**：在启动过程中，主处理器上所执行的第一段 BIOS 代码。在一台具有可信平台模块的系统上，CRTM 被隐含地信任，以自举该计算机系统上所执行的其他固件和软件的后续认证的测定链的构建过程。 49 | * **可扩展固件接口（EFI）**：关于操作系统和平台固件之间的接口规范。1.10 版本是 EFI 规范的最终版本，由统一可扩展固件接口论坛制定的后续修订版本属于 UEFI 规范的一部分。 50 | * **固件**：包含在只读存储器（ROM）中的软件。 51 | * **Option ROM**：由系统 BIOS 调用的固件。Option ROM 包含扩展卡（例如显卡、硬盘控制器、网卡等）上的 BIOS 固件以及用于扩展系统 BIOS 功能的模块。 52 | * **保护模式**：见于 x86 兼容处理器的一种操作模式，具有内存保护、虚拟内存和多任务的硬件支持。 53 | * **实模式**：见于 x86 兼容处理器的一种老旧的高权限操作模式。 54 | * **系统管理模式（SMM）**：见于 x86 兼容处理器的一种高权限操作模式，用于低级系统管理功能。系统管理模式仅可在系统生成系统管理中断时进入，并且仅可执行来自隔离的内存块中的代码。 55 | * **系统闪存存储器**：系统 BIOS 所在的非易失性闪存，通常是主板上的电可擦除可编程只读控制器（EEPROM）闪存存储器。尽管系统闪存存储器是一个技术具体的词语，此文档中的指导意见本意是将系统闪存存储器应用于指代包含系统 BIOS 的任意非易失性存储介质。 56 | * **可信平台模块（TPM）**：构建于某些计算机主板中的防破坏集成电路，它可以执行密码学操作（包括密钥生成）以及保护少量敏感信息，诸如口令和密码学密钥。 57 | * **统一可扩展固件接口（UEFI）**：正在广泛部署到新的基于 x86 的计算机系统上的针对传统 BIOS 的可能的替代品。UEFI 规范继承自 EFI 规范。 58 | 59 | # 附录 C 首字母缩略词和缩略语 60 | 61 | 此附录包含此指南中用到的一组选定的首字母缩略词和缩略语。 62 | 63 | * ACPI：高级配置与电源接口 64 | * BDS：启动设备选择 65 | * BIOS：基本输入/输出系统 66 | * CPU：中央处理器 67 | * CRTM：用于测定的核心可信根 68 | * DXE：驱动程序执行环境 69 | * EEPROM：电可擦除可编程只读存储器 70 | * EFI：可扩展固件接口 71 | * FIPS：美国联邦信息处理标准 72 | * FISMA：美国联邦信息安全管理法案 73 | * GPT：全局唯一标识分区表 74 | * GUID：全局唯一标识 75 | * HTTP：超文本传输协议 76 | * IT：信息科技 77 | * ITL：信息科技实验室 78 | * MBR：主引导记录 79 | * NIST：美国国家标准技术研究所 80 | * OEM：原始设备制造商 81 | * OMB：美国行政管理和预算局 82 | * OS：操作系统 83 | * PEI：前 EFI 初始化 84 | * POST：加电自检 85 | * PXE：预启动执行环境 86 | * ROM：只读存储器 87 | * RT：运行时 88 | * RTU：更新可信根 89 | * SMI：系统管理中断 90 | * SMM：系统管理模式 91 | * SP：特别出版 92 | * TPM：可信平台模块 93 | * UEFI：统一可扩展固件接口 94 | 95 | # 附录 D 参考文献 96 | 97 | 以下列表提供了此出版物的参考文献。 98 | 99 | * \[Duarte08\] G. Duarte. “How Computers Boot Up.” 5 June 2008. [http://www.duartes.org/gustavo/blog/post/how-computers-boot-up](http://www.duartes.org/gustavo/blog/post/how-computers-boot-up) 100 | * \[EFI\] _EFI 1.10 Specification_. Intel. 1 November 2003. [http://www.intel.com/technology/efi/](http://www.intel.com/technology/efi/) 101 | * \[EmSp08\] Shawn Embleton, Sherri Sparks, and Cliff C. Zou. "SMM Rootkits: A New Breed of OS Independent Malware," _Proceedings of 4th International Conference on Security and Privacy in Communication Networks_ \(_SecureComm_\), Istanbul, Turkey, September 22-25, 2008. 102 | * \[FIPS180-3\] FIPS 180-3, _Secure Hash Standard_. October 2008. 103 | * \[FIPS186-3\] FIPS 186-3, _Digital Signature Standard_. June 2009. 104 | * \[DuGr09\] Loïc Duflot, Olivier Grumelard, Olivier Levillain and Benjamin Morin. “ACPI and SMI handlers: some limits to trusted computing.” _Journal in Computer Virology_. Volume 6, Number 4, 353-374. 105 | * \[Graw09\] D. Grawrock. _Dynamics of a Trusted Platform: A Building Block Approach_. Hillsboro, OR: Intel Press, 2009. 106 | * \[Heas07a\] J. Heasman. “Firmware Rootkits: A Threat to the Enterprise.” _Black Hat DC_. Washington, DC. 28 February 2007. [http://www.nccgroup.com/Libraries/Document_Downloads/02_07_Firmware_Rootkits_The_Threat_to_the_Enterprise_Black_Hat_Washington_2007_sflb.sflb.ashx](http://www.nccgroup.com/Libraries/Document_Downloads/02_07_Firmware_Rootkits_The_Threat_to_the_Enterprise_Black_Hat_Washington_2007_sflb.sflb.ashx) 107 | * \[Heas07b\] J. Heasman. “Hacking the Extensible Firmware Interface.” _Black Hat USA_. Las Vegas, NV. 2 August 2007. [https://www.blackhat.com/presentations/bh-usa-07/Heasman/Presentation/bh-usa-07-heasman.pdf](https://www.blackhat.com/presentations/bh-usa-07/Heasman/Presentation/bh-usa-07-heasman.pdf) 108 | * \[Intel03\] _Intel Platform Innovation Framework for EFI- Architecture Specification v0.9_. Intel. September 2003. [http://www.intel.com/technology/framework/](http://www.intel.com/technology/framework/) 109 | * \[KGH09\] A. Kumar, G. Purushottam, and Y. Saint-Hilaire. _Active Platform Management Demystified_. Hillsboro, OR: Intel Press, 2009. 110 | * \[Sal07\] Salihun, Darmawan. _BIOS Disassembly Ninjutsu Uncovered_. Wayne, PA: A-LIST, 2007. 111 | * \[SaOr09\] A. Sacco, A. Ortéga. “Persistant BIOS Infection.” _Phrack_. Issue 66. 6 November 2009. [http://www.phrack.com/issues.html?issue=66&id=7](http://www.phrack.com/issues.html?issue=66&id=7) 112 | * \[SP800-57\] NIST SP 800-57, _Recommendation for Key Management – Part 1: General_. March 2007. 113 | * \[SP800-61\] NIST SP 800-61rev1, _Computer Security Incident Handling Guide_. March 2008. 114 | * \[SP800-89\] NIST SP 800-89, _Recommendation for Obtaining Assurances for Digital Signature Applications_. November 2006. 115 | * \[SP800-128\] Draft NIST SP 800-128, _Guide for Security Configuration Management of Information Systems_. March 2010. 116 | * \[SP800-131A\] NIST SP 800-131A, _Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths_. January 2011. 117 | * \[Sym02\] _W95.CIH Technical Details_. Symantec. 25 April 2002. [http://www.symantec.com/security_response/writeup.jsp?docid=2000-122010-2655-99](http://www.symantec.com/security_response/writeup.jsp?docid=2000-122010-2655-99) 118 | * \[TCG05\] _PC Client Work Group Specific Implementation Specification for Conventional Bios Specification, Version 1.2_. Trusted Computing Group. July 2005. [http://www.trustedcomputinggroup.org/resources/pc_client_work_group_specific_implementation_specification_for_conventional_bios_specification_version_12](http://www.trustedcomputinggroup.org/resources/pc_client_work_group_specific_implementation_specification_for_conventional_bios_specification_version_12) 119 | * \[UEFI\] _UEFI Specification Version 2.3_. Unified EFI Forum. May 2009. [http://www.uefi.org/specs/](http://www.uefi.org/specs/) 120 | * \[Wech09\] F. Wecherowski. “A Real SMM Rootkit: Reversing and Hooking BIOS SMI Handlers.” _Phrack_. Issue 66. 6 November 2009. [http://www.phrack.com/issues.html?issue=66&id=11](http://www.phrack.com/issues.html?issue=66&id=11) 121 | * \[WoTe09\] R. Wojtczuk and A. Tereshkin. “Attacking Intel BIOS.” _Black Hat USA_. Las Vegas, NV. 30 July 2009. [http://www.blackhat.com/presentations/bh-usa-09/WOJTCZUK/BHUSA09-Wojtczuk-AtkIntelBios-SLIDES.pdf](http://www.blackhat.com/presentations/bh-usa-09/WOJTCZUK/BHUSA09-Wojtczuk-AtkIntelBios-SLIDES.pdf) 122 | 123 | -------------------------------------------------------------------------------- /nist_ir_8176/chapter_5.md: -------------------------------------------------------------------------------- 1 | # 第 5 章 容器运行时配置的担保要求 2 | 3 | 如前文 2.5 节所述，用于容器的所有安全性配置参数之中，除了那些用于处理集群管理和计划的以外，都是利用容器运行时提供的 API 设置的。尽管它们中的大多数涉及 Linux 内核特性（名称空间、Cgroups、能力）以及 Linux 内核模块，这些任务被包括在本章中，由于它们是由对 Linux 宿主 OS 接口进行系统调用的容器运行时执行的。本章的总体组织如下： 4 | 5 | * (a) 5.2 节讨论了涉及 Linux 的名称空间特性的配置，它们为不同资源提供隔离 6 | * (b) 5.3 节讨论了利用 Cgroups 特性的配置，它们主要用于设置资源限制，并且由此防止拒绝服务攻击 7 | * (c) 5.4 节讨论了利用能力特性的配置，它们允许最小化权限的分配 8 | * (d) 5.5 节讨论了用于设备隔离的配置，这可以通过利用 Cgroups 和内核可加载的基于标签的强制实施模块的组合来解决 9 | * (e) 5.6 节讨论了那些可以在启动容器时进行设置，而非利用上述功能预先配置的参数 10 | 11 | 在分析这些功能之前，5.1 节概述了对于容器运行时本身的配置特性的需求。 12 | 13 | ## 5.1 对于安全连接的要求 14 | 15 | 容器运行时模块利用监听 Unix 套接字并且因此允许该运行时的远程管理的守护进程而实现。在特定情况下，管理组成员有可能将 Unix 套接字替换为 TCP 套接字 \[10\]。对此 TCP 套接字的任何连接都可能允许攻击者推送并且在高权限模式下运行任何容器，由此赋予它们对于宿主的 root 访问权限。TLS 连接的安全性担保要求涉及双方（容器运行时模块以及用于远程管理的客户端工具）在建立 TLS 会话之前对此连接的加密和认证。 16 | 17 | ## 5.2 对于基于隔离的配置的要求 18 | 19 | ### 5.2.1 容器进程隔离 20 | 21 | 对于容器而言，进程隔离是一项核心安全要求，以保证运行于不同容器以及宿主中的不同应用程序的完整性。容器环境中的进程隔离机制应该满足下列要求 \[4\]： 22 | 23 | * (a) 能够将运行于不同容器中的进程彼此区分开来，以及将其同运行于宿主中的进程区分开来 24 | * (b) 限制跨容器进程可视性 25 | * (c) 防止特定类型的攻击，诸如： 26 | * (i) 运行于一个容器中的进程影响到运行于另一个容器中的进程，通过由 OS 提供的用于进程管理的接口（例如信号和中断） 27 | * (ii) 运行于一个容器中的进程直接访问属于运行于另一个容器中的进程的内存，通过特殊系统调用（例如 `ptrace()` 允许调试工具连接被调试的进程的内存） 28 | 29 | 为了提供进程隔离，用到了一项称为进程 ID（PID）名称空间的 Linux 内核特性。PID 名称空间是一种用于分组进程并且控制它们发现（例如通过 proc 伪文件系统）其他进程并且与其交互（例如发送信号）的能力的机制。PID 名称空间通过 `clone()` 或者 `unshare()` 系统调用来创建，并且与一个或者更多容器相关联。首个进程具有标识符 PID 1，后续进程的标识符按顺序增加。因此 PID 名称空间的特性还提供了 PID 虚拟化。位于不同 PID 名称空间中的两个进程可能拥有相同的 PID。 30 | 31 | ### 5.2.2 容器文件系统隔离 32 | 33 | 文件系统隔离的目标是防止从一个容器对另一个容器以及从任何容器对宿主的文件系统对象的非法访问。文件系统是一种 OS 接口，它允许进程存储和共享数据，以及在彼此之间进行交互。容器应用程序对数据的访问由它通过文件系统挂载点对文件系统的访问决定。因此，可以通过使得文件系统挂载点列表对于容器应用程序可见并且可访问来限制对数据的访问。这是通过挂载名称空间实现的。首先，一个命名的挂载名称空间随着一系列文件系统挂载点而被创建。此挂载名称空间随后与某一个只能在这些挂载点上发现并且发出诸如 `mount()` 或者 `unmount()` 的系统调用的进程相关联。它还可以操作位于该挂载名称空间中并且可通过这些挂载点访问的文件。下列内容为文件系统隔离安全性解决方案以及它们的限制： 34 | 35 | * (a) 所有基于 Linux 的 OS 虚拟化解决方案使用一个允许容器和宿主之间的挂载隔离的 _挂载名称空间_，其目的是辅助对于用户和进程可见的环境的自定义。此特性不能保证容器之间的数据隔离。容器从其上一级继承文件系统挂载视图，并且能够访问文件系统的所有部分，即使每一个容器都是在一个新的挂载名称空间中创建的 36 | * (b) 用于进程的文件系统访问封闭的典型解决方案是通过 `chroot()` 系统调用，它将某个进程绑定到文件系统层级结构中的树状子结构中，这允许容器同宿主分享资源，通过将其挂载到在容器中可见的树状子结构中。然而，此特性不能提供存在高权限进程（例如具有 `CAP_SYS_CHROOT` 权限的进程）的情况下的必要保护，这些进程可以绕过 chroot 的限制，由于 `chroot()` 系统调用只会影响路径解析这一事实 37 | * (c) 对于文件系统对象的更好的保护可通过修改容器中的进程的 root 文件系统来提供，而非只是修改 root 目录（这是 `chroot()` 系统调用所允许的）\[4\]。这是通过 `pivot_root()` 系统调用启用的，它将旧的 root 文件系统的挂载点移动到新的 root 文件系统中的某个目录下，并且将新的 root 文件系统置于其中。这提供了文件系统层级的保护，由于旧的 root 文件系统可以被卸载，如果这是在容器的挂载名称空间中执行的，因此使得宿主的 root 文件系统对于容器中的进程不可访问 38 | * (d) 另一种文件系统层级的保护策略是默认禁止某个限制区域中运行的进程挂载或者卸载文件系统，并且强制实施此权限的粒度控制，利用 `allow_mount*` 命令的选项 39 | * (e) 另一种强化文件系统隔离的机制是为每一个容器指认一个独立的用户名称空间，这会将用户和组 ID 映射到宿主 UID 和组中的具有较少权限的范围中 40 | 41 | 由于上述每一种安全性解决方案的限制，对于文件系统的整体保护的担保要求涉及包括挂载名称空间、chroot、pivot\_root 和用户名称空间的配置的组合，以用于： 42 | 43 | * 利用挂载名称空间隔离挂载点 44 | * 利用 `chroot()` 为每一个进程更改 root 目录 45 | * 利用 `pivot_root()` 为每一个进程更改 root 文件系统的可视性 46 | * 利用用户名称空间限制用户访问范围 47 | 48 | ### 5.2.3 容器 IPC 隔离 49 | 50 | 容器的进程间通信（IPC）隔离意味着一个容器中的进程必须被限制为仅可在同一容器内部通过特定的 IPC 简单信道进行通讯。IPC 对象（或者与之相关联的机制）可以是基于文件系统的 IPC 对象或者并非基于文件系统的。基于文件系统的 IPC 对象，诸如域套接字或者命名管道，可以利用挂载名称空间和 pivot\_root 特性的组合来进行隔离（见上文 5.2.2 节），由于它们阻止进程访问其自身容器以外的文件系统路径。 51 | 52 | 然而，还存在其他 IPC 对象，诸如 System V IPC 对象、信号量集合（数组）、共享内存片断，以及消息队列等。在 Linux 中，这些 IPC 对象可以借助允许创建完全不相交的 IPC 对象集合的 IPC 名称空间而被隔离开来。每一个 IPC 名称空间拥有其自身的 System V IPC 标识符集合以及自身的 POSIX 消息队列文件系统。在一个 IPC 名称空间中创建的对象对属于该名称空间的成员的所有其他进程可见，而对于其他 IPC 名称空间的进程不可见。对于某一个进程可访问的 IPC 对象可以利用 `ipcs` 命令列出，或者利用 `ipcrm` 命令移除。 53 | 54 | ### 5.2.4 容器网络隔离 55 | 56 | 容器的网络层级的隔离通过网络名称空间特性而提供。对于所创建的每一个网络名称空间，一组网络设备、IP 地址、 IP 路由表、/proc/net 目录，以及端口号可以与之相关联。每一个容器可以拥有其自身的虚拟网络设备和应用程序以绑定到每一个名称空间的端口号空间。宿主系统中的适当的路由规则可以将网络数据包指引到与某个特定容器相关联的网络设备。因此可能拥有例如同一宿主系统上的多个容器化的网络服务器，其中每一个服务器都在其（每个容器的）网络名称空间中绑定到 80 端口。 57 | 58 | 网络连接性是运行于容器中的生产级应用程序，诸如网络应用程序和多层应用程序，的核心要求。容器可以通过一种称为覆盖网络的逻辑 IP 网络连接起来。容器平台（由容器、容器运行时、宿主 OS 和物理宿主构成）的典型网络配置涉及在容器宿主上创建网桥。宿主上的每一个容器都连接到该网桥。路由器在其混合模式中从其桥接接口捕获以太网数据包，被捕获的包通过用户数据报协议（UDP）转发到运行于其他容器宿主中的路由器端。这些 UDP “连接”是双工的，可以穿透防火墙，并且可以被加密 \[12\]。每一个容器通过第 2 层（链路层）虚拟网络接口（VNI）连接到该网桥，该接口具有有效的链路层地址或者用于第 3 层连接性的网络地址转换（NAT）。Linux 的第 2 层网络隔离基于网络名称空间的概念，这允许创建若干网络栈以便提供一种完全独立于容器的视图 \[4\]。 59 | 60 | 使用第 2 层 VNI 的网络隔离的最简单配置涉及定义一对虚拟连接以太网（veth）接口，其中一个接口被指认给与容器相同的网络名称空间，而另一个被指认给宿主名称空间。这两个接口之间的虚拟连接随后被建立起来，因此将容器同物理网络连接起来。有两种选项以启用这种连接 \[4\]： 61 | 62 | * (a) 网桥设备：veth 接口和宿主物理接口通过虚拟网桥设备连接起来。在此选项中，所有容器和宿主接口被连接到同一链路层网桥，并且因此接收该网桥的所有链路层流量 63 | * (b) 路由表：另一个选项是利用路由表在（容器所被连接到的）虚拟网络接口和（驻留于宿主上的）物理网络接口之间转发流量。在此选项中，只有当显式地提供了网络路由时，容器才能进行彼此之间的通讯 64 | 65 | _安全性分析_：由这两种选项提供的网络隔离功能强制容器进程使用被指认的虚拟网段或者被指认的网络路由（例如通过 VPN 连接）。在这两种选项之间，路由表的使用相对于网桥设备解决方案提供了略高一些的安全性担保，由于后者允许容器地址对于连接到该网桥的所有容器可见。 66 | 67 | 为容器提供网络连接性的另一种方式是使用 MACVLAN 接口 \[13\]，它也允许每一个容器拥有其独立的链路层地址。虚拟以太网端口汇聚器（VEPA）是最广泛地应用于此类容器隔离选项的配置模式。然而，仅当基于名称空间的方式通过基于标签的访问控制以及同来自其他全局名称空间的进程进行隔离而得到加强时，才可能在进程层级对容器提供完整的网络隔离担保。 68 | 69 | ### 5.2.5 容器的用户和组层级的隔离 70 | 71 | 有些进程可能需要 root 权限的某个子集。用户名称空间特性可用于将某些用户 ID 的权限限制为该所需的子集。用户名称空间将用户和组 ID 号空间隔离开来。换言之，某个进程的用户和组 ID 在某个用户名称空间内外可以不同。在此，最为有趣的案例是，某个进程可以在某个用户名称空间以外拥有正常的低权限用户 ID，而同时在此名称空间内拥有用户 ID 0。这意味着此进程在此用户名称空间内拥有完整的 root 操作权限，而在此名称空间以外则只有低操作权限。 72 | 73 | 从 Linux 3.8 开始，低权限进程可以创建用户名称空间，这为应用程序的有趣的全新的可能性开辟了道路。由于在其他情况下的低权限进程现在可以在其用户名称空间内保持 root 权限，低权限应用程序现在可以拥有对于之前仅限于 root 的功能的访问权限 \[4\]。 74 | 75 | ## 5.3 对于资源限制解决方案的要求 76 | 77 | 在 Linux 容器环境中，应对拒绝服务攻击的主要保护机制是允许设置不同资源限制的 Cgroups 特性。“限制”规范特性不仅限制诸如 CPU、内存、存储等硬件资源，也适用于进程和任务。除了限制特性以外，Cgroups 允许指认一系列潜在的“资源消耗大户任务”，它们可以通过发送 SIGSTOP 信号被冻结，并且在随后发送 SIGCONT 信号而解冻 \[11\]。 78 | 79 | 除了其防止拒绝服务攻击的主要作用以外，Cgroups 特性还可以提供额外的网络层级保护，通过某种方法（利用网络分类 Cgroup）对网络数据包以某个“类标识符”的值进行标记。这随后可以被用作参数以过滤特定的包。（这个类标识符的值也可被用于基于服务质量（QoS）要求的优先级处理，尽管此特性属于性能增强而非严格属于安全性。） 80 | 81 | 下列表格提供了 Cgroups 特性能够对其设置资源限制或者访问控制的硬件资源列表： 82 | 83 | > 表 1——利用 Cgroups 的 Linux 资源限制 84 | 85 | |资源|“限制”特性或者访问控制| 86 | |----|----| 87 | |CPU|为一组进程指定 CPU 数量或者“CPU 份额”的值| 88 | |内存|用于一组进程的“硬”和“软”内存分配单元| 89 | |BLKIO|设置硬盘读写速度、每秒操作数、队列控制，以及由主要和次要数值所指认的等待时间；相对于文件系统的特定控制提供更多的粒度访问控制| 90 | |设备|创建设备白名单，基于 (a) 类型（字符设备还是块设备）或者 (b) 主要和次要数值| 91 | 92 | Cgroups 配置应该提供下列担保： 93 | 94 | * (a) 它不应该暴露容器宿主信息，诸如通过 dmesg 暴露内核环缓冲，这可能协助内核漏洞利用或者信息泄漏 95 | * (b) 它不应该允许本地硬盘访问，即使是在用户名称空间内通过原生硬盘、设备或者 make node（mknod）访问挂载受限的名称空间 \[11\] 96 | 97 | ## 5.4 对于容器的最小化权限配置的要求 98 | 99 | 如前文所提到的，Linux 的能力特性可用于分割 root 权限集合。所有容器运行时产品，诸如 LXC、Docker 以及 CoreOS Rkt，都带有默认配置文件，其中，容器的某些能力被启用而某些被禁用 \[11\]。由于运行于容器中的应用程序的权限需求，某些默认值必须被修改（即某些默认被启用的能力需要被禁用，而某些默认被禁用的能力需要被启用）。然而，对于托管于容器中的大多数应用程序，在配置 Linux 的能力特性时，下列担保要求必须被满足： 100 | 101 | * (a) 提供权限以操纵非名称空间的内核参数（例如系统时间）的能力将会拥有该参数的效果，此参数的修改不仅是对于该容器，也是对于宿主和所有其他容器的。因此这样的能力（例如 `CAP_SYS_TIME`）不应该被启用 102 | * (b) 提供几乎等同于 root 的宽泛权限集合的能力不应该被启用（例如 `CAP_SYS_ADMIN`） 103 | * (c) 无需启用能力 `CAP_SYS_MODULE`，它允许加载和卸载内核模块，由于这会导致不安全的权限提升 104 | * (d) 能力特性应该总是和用户名称空间配合使用，由于任何错误地启用某些能力而导致的进程权限提升将会被限制在名称空间内 105 | 106 | ## 5.5 对于设备隔离解决方案的要求 107 | 108 | 在 Linux 中，对设备的访问是通过设备结点实现的，设备结点是为宿主的设备驱动程序提供接口的特殊文件。设备结点同文件系统的剩余部分分隔开来，并且它们的结点被置于 /dev 目录中。这些结点对于名称空间并不警觉。设备结点的创建是通过 `udevd` 守护进程发出 `mknod` 系统调用而实现的。进程创建设备结点（用于访问块设备或者字符设备）的许可是由 `CAP_SYS_MKNOD` 能力提供的。如果对应的设备将要在容器之间或者不同容器与宿主之间共享，则容器被赋予对设备结点的访问。然而，设备结点是安全敏感的，由于它们将接口（特别是存储接口）暴露给运行于内核空间的代码，这可能被滥用以获得非法数据访问、权限提升或者挂载其他攻击。 109 | 110 | 在容器之间提供设备层级的隔离的一种可能的解决方案是使用“设备名称空间”，如果被引用的输入/输出（物理）设备是对于名称空间警觉的。不幸的是，很多 Linux 内核发行版并不支持设备名称空间特性。如果可用，此特性可用于为每一个容器创建虚拟设备，它们可以被多路传输以访问某个物理宿主设备。更进一步地，如果控制物理设备的 Linux 设备驱动程序对于名称空间并不警觉，并且这些设备假设只有一个控制它们的主控结点，对于它们的访问权限很难被安全地赋予低权限的容器，除非该设备只由单一容器专属使用。 111 | 112 | 在缺少设备名称空间的情况下，两种特性被用于控制容器对设备的访问。它们是：(a) 控制组，或者 Cgroups；以及 (b) 基于标签的访问控制。设备的 Cgroups 子系统被用于创建白名单，基于类型（即字符设备还是块设备）以及设备的主要和次要编号来针对设备格式化。通配符“all”适用于所有设备类型以及主要和次要编号，并且通常在显式地将设备列入白名单之前被用作默认的拒绝 \[11\]。 113 | 114 | 在 Linux 环境中有两种基于标签的强制执行方式：安全增强式 Linux（SELinux）和 AppArmor。在 SELinux 中，类别标签被应用于进程和数据/设备，并且进程对于资源的访问将会被拒绝，如果它不属于正确的分类。例如，某个特定的标签可以被应用于某个给定的容器 X，并且将要由该容器消费的数据被指认给相同的标签。由于指认类别过程的灵活性，SELinux 可以被用于强制实施精细粒度策略。AppArmor 是另一种基于标签的系统，它提供基于路径的访问控制（与 SELinux 中的文件系统结点相对）。对于特定应用程序、进程或者容器，限制条件可以被聚合起来以定义配置文件。所有这些基于标签的系统的共同的弱点在于，它们所提供的控制可以通过直接执行系统调用而被破坏。 115 | 116 | 因此，对于设备隔离解决方案的担保要求包括： 117 | 118 | * (a) 所有容器必须被防止创建新的设备结点，并且 `CAP_SYS_MKNOD` 能力对于它们不应该被启用 119 | * (b) 容器内的所有挂载点应该设置 nodev 标识（通过利用 `mount` 命令的 nodev 选项）以防止它们被用于创建文件以访问设备驱动程序 120 | * (c) 所有容器应该仅被允许访问下列设备的集合，由于它们被表征为安全的 \[4\]，基于下列给出的观察： 121 | * _完全虚拟设备_——诸如伪终端和虚拟网络接口；此安全担保来自这些设备为每一个容器显式地创建并且未被共享这一事实 122 | * _无状态设备_——诸如 random、null 及其他；在所有容器之间共享这些设备的同时仍然能够保持宿主安全，由于它们是无状态的 123 | * _对于用户名称空间警觉的设备_——如果此设备（通过设备驱动程序代码）支持对于对应用户名称空间中的进程的验证能力，则这样的设备可以被安全地暴露给容器，由于特定的限制条件将会被强制实施 124 | * (d) 如果 Cgroups 和基于标签的强制执行系统都被用于控制对设备的访问，应当谨慎以确保它们各自的规则不会产生冲突 125 | 126 | ## 5.6 对于容器启动选项的要求 127 | 128 | 每一种容器运行时产品都有带有众多参数的命令以启动容器。与此命令的安全使用相关联的担保要求被叙述为一组应该被避免使用的选项 \[4\]。作为最佳安全实践，容器不应该使用那些当它被启动时将会共享与容器宿主相关联的任何名称空间的选项 \[11\]。如若不然，这可能不仅允许容器查看与该名称空间相关联的资源/对象，而且允许操纵这些资源/对象，通过破坏由容器的名称空间的静态配置提供的隔离。下表提供了这样的名称空间的列表，对于它们而言，共享宿主侧的对应物不应该被用于容器启动选项。 129 | 130 | > 表 2——禁止的容器启动选项 131 | 132 | |名称空间/范例资源-对象|简述|安全威胁| 133 | |----|----|----| 134 | |Unix 分时系统（UTS）|所有容器被指认给其自身的 UTS 名称空间，因此无需获知宿主的 UTS 名称空间|容器中的进程可以看到并且操作宿主的主机名和域| 135 | |IPC/共享内存片断|应用程序模块之间的用于进程间通信的共享内存片断被设置以用于快速通讯，由于它们比 REST API 调用更快|容器中的进程可以看到并且操作宿主的 IPC 对象| 136 | |文件系统|宿主敏感的目录不应该以读写模式挂载为容器卷|赋予容器修改这些目录中的文件的能力，带有潜在破坏宿主安全的风险| 137 | |在容器启动命令中设置 `net=host`|容器的网络模式不应该被设置为等同于宿主|这将会赋予容器只有宿主才应该拥有的权限（例如关闭其自身）或者访问只有宿主才需要访问的网络服务的权限| 138 | |将容器端口公开至宿主|这被用于设置出入该容器的通讯|公开所有接口的默认选项不应该被使用；通过显式指定端口应该被绑定到的接口，出入该容器的流量被限制在给定的接口| 139 | |容器间通讯|如果存在，此选项允许任何类型的容器间通讯，它必须不能被启用；与之相反，在两个需要通讯的容器之间必须显式设置通讯信道|任何被攻击的容器可以攻击宿主上的任何其他容器| 140 | 141 | 除了涉及同宿主共享的对象的容器启动选项以外，有一些专门适用于容器的参数应该在容器启动时被设置： 142 | 143 | * (a) 容器应该总是被启动为具有一定的内存限制，以防止拒绝服务攻击，或是某些应用程序泄漏内存，以至于它最终将会消耗宿主的全部内存 144 | * (b) 容器应该总是通过指定 CPU 份额数值而启动。默认值（总 CPU 数/容器数）可能对于某些容器并不够用，导致拒绝服务。指认给某一容器的 CPU 份额数值应该使得没有容器可以导致具有默认设置的其他容器得不到足够的资源。更进一步地，如果存在这样一组容器，其在 CPU 使用上相对于其他容器占据主导地位，则较低的默认值应该被指认给该组中的容器，以保证 CPU 份额的公平分配 145 | * (c) 如果宿主 OS Linux 发行版支持某种基于标签的系统（例如 SELinux），则应该设置策略模板。容器引擎应该被启动为带有选项以识别该模板，并且容器启动 API 应该拥有选项以识别此策略模板参数，并且将其作为启动参数的一部分而包括进来 146 | * (d) 容器应该被启动为仅有“必要的”能力，通过在初始时放弃所有能力，并且随后仅添加必要的能力。下列能力通常不应该存在于容器配置中（即 `NET_ADMIN`、`SYS_ADMIN`、`SYS_MODULE`），由于它们提供了超出大多数部署所必要的权限 147 | 148 | -------------------------------------------------------------------------------- /nist_ir_8151/chapter_3.md: -------------------------------------------------------------------------------- 1 | # 第 3 章 测定和度量 2 | 3 | 本章在最宽泛的意义上处理测定、评估、度量、鉴定、判断、评价等。因此，代码审查、软件测试和其他技术在本章中具有一席之地。如同我们接下来所讨论的那样，缺少经过精确定义和严格验证的测定方法，更糟的是，大多数现存的测定方法对于我们想要在软件中确定的高级属性而言只有中等程度的预测性。甚至没有广泛和详细的数据，诸如漏洞的数量和类型，以使得测定研究可以基于它们进行。 4 | 5 | 我们有 3 个关注的领域。其一，鼓励使用测定。世界上的所有非常规测定方法如果无人使用它们，就不会带来任何帮助。同样，无人 _可以_ 采取测定行动，如果该测定方法并未被制造出来因而成为可用。美国联邦政府可以促进并且鼓励使用软件产品测定。其载体包括采购、合同、责任、保险以及标准，如同 4.3 节所解释的那样。测定带来的好处将会被放大，如果它们在受到训练的软件开发过程中被修订、解读和使用 \[Curtis16\]。确实，良好的测定方法的广泛使用是少数方式之一，这些方式具有打破崩溃——补丁的轮回以及超越攻击者的潜力 \[Grigg08\]。软件也会得益于第三方、非政府组织的程序和判据。某些可能性包括 UL 网络安全担保计划（CAP）、信息科技软件质量联盟（CISQ）的代码质量标准、Coverity 扫描、核心基础设施倡议（CII）的最佳实践徽章，以及在成熟度模型中构建安全性（BSIMM）等。这些中的很多包括进程测定，这是第二个关注的领域。 6 | 7 | 第二个领域，进程测定，包括努力的小时数、更改的数量，以及在送达的代码中没有验收测试缺陷以及验收测试缺陷密度 \[Perini16\]。这些对于漏洞数量并没有直接影响，但是其间接影响巨大。例如，如果开发者被强迫频繁超时工作以赶上某个期限，或者计划安排不允许培训，则漏洞的数量很可能会显著增加 \[Perini16\]。其他范例包括指示新的过程步骤相对于先前的实践能够带来多少帮助的测定，或者指示过程中的允许漏洞逃逸的部分的测定。这种持续改进过程的方法被发现于最高等级的成熟度模型中。它还允许小组采用或者适应于对于他们的环境最为适用的方法和测定。我们不再进一步讨论进程测定。 8 | 9 | 最后一个关注的领域是对作为产品的软件的测定，例如，关于不存在缓冲区溢出的证明、每 1000 行代码中的缺陷数量、关于规范被满足的担保，以及通过测试套件实现的路径覆盖率等。美国国家标准技术研究所（NIST）的软件质量小组组织了一次关于用于减少安全漏洞的软件测定和度量（SwMM-RSV）的研讨会以征集想法，关于美国联邦政府可以如何最好地识别、改进、打包、带来或者提升软件测定方法的使用以显著减少漏洞 \[脚注 2\]。他们召集了简短的状态报告书，随后邀请了基于所提交的 20 个状态报告中的 10 个的研讨会演示。此研讨会举行于 2016 年七月 12 日，完整的研讨会报告可以作为 NIST SP 500-320 而获得 \[Black16\]。本章的大部分内容来自于此研讨会的成果。想法通常由一人提出，由其他人讨论和详细叙述，然后由另一些人编写并且报告。因此，在大多数情况下难于将想法署名给特定的个人。我们感谢参与了此研讨会并且对报告中所注释的想法作出了贡献的所有人，无论贡献大小。 10 | 11 | > \[脚注 2\] 其网站为 [https://samate.nist.gov/SwMM-RSV2016.html](https://samate.nist.gov/SwMM-RSV2016.html)。 12 | 13 | 我们区分基本测定和导出测定。基本测定是具有明确的值的简单、基本的评估或者计数。与之相反，导出测定是“两个或者更多的基本测定的值的函数”\[ISO15939\]，或者是某个基本测定的数学变换 \[ISO25040\]。导出测定通常是那些我们想要能够测定的属性的替代品。例如，缓冲区溢出（BOF 类）\[Bojanova16\] 弱点的数量是一种具有合理地清晰的定义的基本测定。与之相反，代码安全性是一种导出测定，它只能微弱地通过 BOF 数量进行预测。缺陷的不存在并不指示着卓越的存在。 14 | 15 | ## 3.1 软件测定分类法 16 | 17 | 软件测定可以从 4 个维度来分类。第 1 个维度是该测定方法有多么“高级”。低级测定是语义之下的，诸如程序的大小、路径的数量和函数的扇入/扇出等。高级测定方法更多地处理的是程序的本意是要实现什么。第 2 个维度是静态还是动态。静态测定是那些应用于源代码或者“二进制文件”本身的测定方法。动态测定应用于程序的执行。第 3 种维度是视点。可以是外部视点，有时称为黑盒或者功能性的，或者是内部视点，在此代码被考虑，称为白盒（“清晰”或者“透明”）或者结构性的。第 4 个维度是测定的对象：bug、代码质量和一致性。 18 | 19 | 对于第 1 个维度，测定方法可以分为低级或者高级的。低级测定方法被广泛使用。与之相反，高级测定方法所处理的是作为客体的程序与作为有意识的主体的开发者或者用户之间的关系。质量在这种客体和主体的相互作用之中得到提升 \[Pirsig74\]。与低级和高级测定方法形成类比的是低级漏洞和高级漏洞。某些低级漏洞包括缓冲区溢出、整数溢出和未能提供默认的 switch 语句的 case 等。这些低级漏洞可以直接从代码中识别出来，即某人可以检视代码，或者使用某个程序来检视代码，并且确定对于给定的特定输入是否有可能出现 BOF。无需引用某种规范、要求或者安全策略来确定缓冲区溢出是否为可能。 20 | 21 | 另一方面，高级漏洞不能仅仅依靠参考代码而被识别出来。人类审查者或者静态分析器必须查询要求、规范或者策略以确定高级问题。例如，未能加密敏感信息通常不能完全通过代码检查而被识别出来。当然，启发式搜索是可能的。例如，如果某个变量被命名为“password”，静态分析器如此猜测是合理的，即该变量是某个口令并且不应该在没有保护的情况下被传输，也不应该可以被非授权用户访问。然而，不论工具还是人类都不能在不对其进行外部定义的检查的情况下确定某个被命名为“ID”的变量中的信息是否应该被加密。 22 | 23 | 拥有对于安全策略和要求文档的访问并不会使得软件质量在所有案例中被评估。要求文档通常应对的是程序的行为，以及程序特有地需要去做什么。形式化地指定该代码应该是高质量的这一点是困难的，也许完全不可能。软件架构是定义结构组成的一种方式，它将良好的、有用的软件同易出错的、难于调试的、脆弱的或者不灵活的软件区分开来。 24 | 25 | 对测定方法进行分类的第 2 个维度——静态还是动态——在测试中最为明显。测试测定在概念上有两部分：测试生成或者选择，以及测试结果评价。测试测定通常回答这样一个问题，即程序（内部）或者输入空间（外部）有多少被使用了？测试案例生成必然是静态的，而评价通常是动态的，即基于执行结果。在众多测试测定中，这两部分彼此联结。它们可能包括某个例如选择额外的测试案例以增加覆盖率的步骤。因此，动态部分会影响静态部分。测试通常被引用为动态技术，由于程序执行是测试的重要组成部分。即如果某人提出了测试案例 _但是从未运行它们_，则严格地说不会得到任何担保。当然，在大多数案例中，选择测试案例过程中的思考和检查是一种静态分析，它产出了关于程序的某些担保。ISO/IEC 25023 将静态测定引用为内部测定，而将动态测定引用为外部测定 \[ISO25023\]。 26 | 27 | 第 3 个维度是视点，可以是外部或者内部的。外部测定通常是关于规范、要求或者限制的行为一致性。它们基于软件被观测到做了什么。它们通常被引用为“黑盒”或者行为性的。这些测定方法对于验收测试以及估计用户或者任务满意度极为有用。如果程序不能满足其目的，该程序编写得多么好或者其内部结构组织得多么好几乎没有任何意义。与之相反，内部或者结构性测定主要应对的是代码的架构、实现以及精细粒度操作，或者得到关于它们的信息。内部测定基于对源代码或者可执行文件的分析。此类测定方法与质量相关，诸如可维护性、可移植性、优雅性和潜力等。例如，外部计时测试可能不足以确定算法的复杂度，而代码检查可以清楚地显示该算法的复杂度为 Θ(_n_2)，并且对于较大的输入会有性能问题。 28 | 29 | 确定多少测试才是足够的同样展示了内部和外部测定的区别。外部测定，诸如边值分析 \[Beizer90\] 和合并测试 \[Kuhn10\]，考虑行为或者规范以计算已经测试了多少，或者还有什么尚未测试。另一方面，内部测定包括区块数量计数、变化充分性 \[Okun04\] 以及覆盖率测定 \[Zhu97\] 等。这两种方式是互补的。基于外部的测试可以发现缺失的特性，基于内部的测试可以提出从要求来看并不清楚的案例，例如，当存在众多项目时由插入排序切换到快速排序。 30 | 31 | 对测定方法进行分类的第 4 个维度在概念上将其分为 3 类。第 1 类测定是存在（或者不存在）特定的弱点，诸如缓冲区溢出（BOF 类）或者注入（INJ 类）\[Bojanova16\]。注意，瑕疵的不存在并不指示例如弹性架构等。第 2 类是质量测定，其本意是确定代码或者部分代码的优秀性，然而，我们仅仅拥有“质量”的代理，例如可维护性、可移植性以及断言的存在等。即使如此，这些代理中的很多只能间接估计。前两类是关于产品质量的特征 \[ISO25010\]。第 3 类是与规范的一致性或者正确性。这第 3 种测定用于使用特征中的质量 \[ISO25010\] 并且必须具体到每一项任务。有可用的通用要求语言和检查方法。由于这 3 种类别之间的深刻差别，没有一种安全性或者漏洞测定方法可以保证优秀代码。 32 | 33 | ## 3.2 软件担保：软件测定的目标 34 | 35 | 关于软件将会按照其所应该的方式发挥功能的担保有 3 个来源。其一是开发过程，如果软件由拥有明确要求、经过良好培训并且已经被证明能够构建具有低漏洞率的良好软件的团队开发，那么我们就能够拥有关于他们所生产的软件很可能具有极少漏洞的信心或者担保。担保的第 2 个来源是我们对于软件的分析。例如，代码审查、验收测试和静态分析等可以为我们保证该软件的漏洞很可能是稀少的。我们可以牺牲这两种资源以换取担保。如果我们几乎没有任何关于开发进程的信息，或者该开发进程在过去并未产出良好的软件，我们必须进行多得多的分析和测试以获取关于软件质量的信心。与之相反，如果我们对于开发团队和开发过程拥有信心，我们只需进行最小化的测试以确保该软件能够遵循过去的经验。 36 | 37 | 软件担保的第 3 个来源是弹性执行环境。如果我们对于软件质量没有信心，那么我们可以在容器中运行它，如同 2.2.1 节所解释，给它极少的系统权限，并且让其他程序监视其执行。如果任何漏洞被触发，则它对系统的危害是受到控制的。 38 | 39 | 我们可以利用数学公式来表达我们的担保：_A_ = _f_(_p_, _s_, _e_)，其中 _A_ 为我们所拥有的担保的量，_p_ 为来自我们关于其进程的知识的担保，_s_ 为来自静态和动态分析的担保，而 _e_ 为我们通过严格执行环境所获得的担保。合并函数 _f_ 为某种加和运算，类似于 _p_ + _s_ + _e_。如同我们之前所述，如果我们没有关于进程的信息，则可以通过额外的分析工作来提升我们的总体担保。另一方面，如果我们对于开发软件的进程（和人）拥有巨大信息，则我们不需要进行那么多的分析工作。 40 | 41 | ## 3.3 软件计量学 42 | 43 | 为了拥有一种合乎逻辑的、广泛有用的测定系统，某人必须拥有坚实的理论基础，即软件测定的哲学。这种哲学必须拥有坚实的数学基础，例如，以使用合理的统计 \[Böhme08\]。本节解决了诸如这样的问题，即什么是软件计量学？它的目的是什么？相对于物理测定，测定软件过程中所特有的挑战是什么？可能的解决方案或者潜在的方法是什么？ 44 | 45 | 软件测定方法拥有众所周知的理论局限性，与物理学中的海森堡不确定性原理相类比，计算机科学拥有停机问题、莱斯定理，及其相关结果，它们展示了正确地确定 _所有_ 可能的程序的感兴趣的测定结果是不可能的。尽管这是一种提醒，这并不意味着所有有用、精确、准确的测定都是不可能的。有若干种方式以避免这些理论障碍。其一，我们可以满足于相对属性。能够确定某个程序的新版本相对于之前的版本更加安全（或者不那么安全！）可能会有所帮助。我们并不需要关于某个程序的安全性的绝对测定结果。其二，某项测定可能仅适用于拥有“合理的”结构的程序。某项测定仍然会有用，即使它不适用于那些完全由数以百万计的散布着变幻莫测的计算的条件的 go-to 语句构成的程序。无人（应该）编写这样的程序。最后，社会可以就特定应用程序作出决定，而我们只需要构建可测定的软件。民用建筑师不会被允许设计具有随意的拱门、穹顶、悬臂和正面的建筑。他们会被要求运行分析以展示该设计能够承受预期的负载和力，然后建设才能开始。当前，大多数程序员学习编写“优雅”软件，然后试图展示它能够工作。期望可能会发生更改，以使得专业人士只会编写那些能够明确满足其限制和要求的软件。 46 | 47 | 计算机程序员有时会半严肃地使用片语“这不是 bug：这是特性”。它强调了 bug 和特性是在某种意义上相互关联的实体。让我们假设某个程序可以被表征为一系列特性。（程序是一系列特性这一理念是某些大小测定的基础。例如，函数点测定试图捕获某个基本操作或者功能的理念。）称某个程序“有一个 bug”意味着它是某个“良好”程序的有 bug 的版本。良好的程序和有 bug 的程序都是程序。根据这一假设，两个程序都是一系列特性。因此，良好的程序和有 bug 的程序之间的区别在于某些特性的集合——添加、移除或者更改的特性。因此，精确的定义是：bug 是理想的特性和现存的特性之间的区别。在众多案例中，一个 bug 可能只是某个额外的特性，或者是取代另一个特性的特性。 48 | 49 | 我们可能会将软件计量学和物理计量学对立起来。在物理计量学中，挑战在于精确并且可重现地确定物理对象、事件或者体系的属性。与之相反，对于软件，大多数所谓的测定只是计数。一个恰当的案例是，ASCMM-MNT-7：模块间依赖循环拥有精确定义 \[OMG16\]。不难编写这样一个程序以精确测定实例数，在此，某个模块拥有循环回某个软件的引用。这样，差别就在于物理计量学已经明确标识出了他们想要确定的属性，例如质量、长度、时间和温度等。与之相反，软件计量学拥有一道完全不同的鸿沟。我们想要测定高级属性，诸如质量、可维护性和安全性等，但是我们并没有关于这些的精确定义。因此，我们不能直接测定它们。然而，我们可以测定与这些高级属性相关联的众多属性。 50 | 51 | 当前，计量学将实体数量计数降级为一种用于确定属性的第二类方法。这样的经过计数的 _量_ 全部被视为相同的一维的量，有时被称为无量纲量，尽管它们可能具有不同的 _类型_。 52 | 53 | ## 3.4 产品测定 54 | 55 | 如同良好的进程对于生产具有极少漏洞的代码至关重要那样，终极能力是测定代码本身。如同本章绪言所指出的那样，对软件本身的测定可以为进程改进提供信息。 56 | 57 | 安全性或者漏洞测定在其最宽泛的意义上包括测试和检查。我们需要这样的测定以确定此报告中的目标是否实现！采用此报告中给出的任何一种技术可能不会显著减少漏洞。未能实现减少漏洞可能只是由于关于技术如何使用的某些细节问题，或者可能是由于该技术就是不适用。如果采用了若干种技术，区分每一种技术的效果或者其共同效果甚至会变得更难。 58 | 59 | 这样的测定不能被留到开发的最终阶段才进行。它们必须被包括到软件开发的 _所有_ 阶段。除了像净室方式 \[Mills87\] 这样的充满雄心壮志的方法以外，此类测定不能作为门而被留到接近开发周期的结束。 60 | 61 | 有这样的可能性，即软件质量和安全性测定对于减少软件漏洞而言可能是错误的重点。某些测定可能会渐渐显露为重点，由于其他测定方法可能具有内聚性以及麦凯布循环复杂度。也可能证实最佳方式就像净室，在此，测定方法告知一种决定，以接受或者拒绝，并且不会宣称其创建了关于没有错误的绝对认证。 62 | 63 | ### 3.4.1 现存的测定方法 64 | 65 | 有数以百计的被提议的软件测定方法，诸如代码行数、类耦合性、封闭类的数量、函数点、更改密度，以及内聚性等。它们中的大多数并未经过精确定义或者严格验证。更糟的是，它们中的大多数对于软件中的我们所希望确定的高级属性只是具有中等程度的预测性。例如，代码行数（LoC）只是捕获了程序能力中的某些方差。同一规范在同一语言中的 LoC 可能相差多达 4 倍，即使所有程序员都拥有相近的技能。另一方面，LoC 与程序中的 bug 具有显著的强相关性。（这提示高级语言和领域特定语言一般会产生较少的 bug，由于它允许程序员更加精炼地表达功能。） 66 | 67 | 有些事情即使看起来就像在程序中数 bug 那样简单，其实也是令人惊讶地复杂的 \[Black11b\]。哪怕只是主观地定义什么是 bug 也很难。例如，某人可以编写一段永远不会发生整数溢出的二分搜索算法，但是该代码难于理解。除以零可能拥有良好定义的行为，得到特殊值“非数”，但是这通常不是一种有用的结果。bug 通常是若干种困难的级联反应。假设 (1) 未经检查的用户输入导致 (2) 整数溢出，进而导致 (3) 正在被分配的缓冲太小，进而导致 (4) 缓冲区溢出，最终导致 (5) 信息泄露。我们应该将此计为 1 个还是 5 个 bug？如果程序员在若干位置犯了同一个系统性的错误，例如未能在使用资源之后将其释放，这是一个问题还是若干个问题？与其说是例外，这些复杂性不如说是软件的规则 \[Okun08\]。 68 | 69 | 对于任何现实的程序，测试每一种可能的输入是不可行的。与之相反，必须选择一种测定方法以跨越整个空间。这些测定方法包括输入空间的合并覆盖 \[Kuhn13\]、变化充分性 \[Okun04\]、路径覆盖率测定 \[Zhu97\] 和边值分析 \[Beizer90\] 等。这些测定方法相互关联。例如，某些级别的（静态）合并覆盖能够制造那些产生了完整分支覆盖的测试，即一种动态测定方法 \[Kuhn15\]。 70 | 71 | 有太多的被提议的测定方法难于评估，甚至哪怕只是在这里列出来。我们可以说，如同上文所暗示，测定方法应该紧密地基于良好建立的自然科学，并且拥有合理的计量学基础，以获得最大的实用性 \[Flater16\]。 72 | 73 | ### 3.4.2 更好的代码 74 | 75 | 用于减少安全漏洞的软件测定和度量（SwMM-RSV）研讨会上的两则演示，Andrew Walenstein 的“测定软件的可分析性”和 James Kupsch 的“应对对于静态分析不透明的代码”指出了新的软件测定方法的方向。两则演示都强调代码应该能够被自动分析。两则演示都呈现了方法以定义代码能够被容易地分析这一点意味着什么、为何可分析性对减少漏洞有贡献，以及可分析性可以如何被测定和增强。 76 | 77 | 编程语言的部分子集被设计为可分析的，诸如 SPARK，或者被设计为不那么容易出错的，诸如 Less Hatton 的 SaferC。研讨会参与者普遍倾向于使用更好的语言，例如，函数式语言，诸如 F# 或者 ML。然而，对于未来并没有特别建议的 _某种_ 语言。 78 | 79 | 我们注意到，除了少数特例，诸如拥有 SPARK 的 Ada 2012 \[Barnes13\] 以外，其他新语言的工具支持欠佳。支持新工具的构建对于新语言的采用和安全使用至关重要。 80 | 81 | 尽管基于代码的测定方法是重要的，我们可以期待从对于软件的其他方面的测定中得到互补的结果。某些方面包括软件架构和设计侵蚀测定、代码的语言方面、开发者的背景，以及与软件要求相关联的测定方法等。 82 | 83 | ### 3.4.3 二进制文件和可执行文件的测定方法 84 | 85 | 某些研讨会参与者认为，存在着对于二进制文件和可执行文件的测定方法的显著需求。由于有了今天的优化编译器以及对于二进制文件中带来的众多库的依赖，仅仅检查源代码为所有类型的漏洞的出现留下了通到。 86 | 87 | ### 3.4.4 更加有用的工具输出 88 | 89 | 今天，有众多强大并且有用的软件担保工具可用。没有单一的工具能够满足所有需求。因此，用户应该使用若干种工具。这是困难的，由于工具拥有不同的输出格式，并且使用不同的术语和类。工具输出应该被标准化。即通用的命名法、呈现形式和细节越多，用户就越有可能将工具的结果和其他软件担保信息合并起来，并且选择一种对他们最为有利的工具组合。 90 | 91 | 此外，工具可以提供关于它们的分析的更多信息。工具可以指示哪部分代码已经被完整地检查，而哪部分还没有，例如由于复杂度或者启发式搜索等。这类检查信息可以被附加到代码，使其成为“随码担保”\[Woody16\]，与随码证明相类比。 92 | 93 | 参与者们感受到了对于科学地有效的研究的需求，研究内容包括工具的强度和限制、允许公开第三方对于工具的评估的机制、分享关于工具的洞察力的通用论坛，可能甚至还有关于经过验证或者认证的工具的列表。 94 | 95 | ## 3.5 延伸阅读 96 | 97 | * \[Barritt16\] Keith Barritt, “3 Lessons: FDA/FTC Enforcement Against Mobile Medical Apps,” 14 January 2016. Available: [http://www.meddeviceonline.com/doc/lessons-fda-ftc-enforcement/against-mobile-medical-apps-0001](http://www.meddeviceonline.com/doc/lessons-fda-ftc-enforcement/against-mobile-medical-apps-0001) Accessed 12 October 2016. 98 | * \[FTC16\] Federal Trade Commission, “Mobile Health App Developers: FTC Best Practices,” April 2016. Available: [http://www.ftc.gov/tips-advice/business-center/guidance/mobile-health-app-developers-ftc-best-practices](http://www.ftc.gov/tips-advice/business-center/guidance/mobile-health-app-developers-ftc-best-practices) Accessed 13 October 2016. 99 | * \[Perini16\] Barti Perini, Stephen Shook and Girish Seshagiri, “Reducing Software Vulnerabilities – The Number One Goal for Every Software Development Organization, Team, and Individual,” ISHIPI Technical Report, 22 July 2016. 100 | 101 | --------------------------------------------------------------------------------