嵌入式与物联网设备安全：设计、开发与工程实战

版权信息

书名：嵌入式与物联网设备安全：设计、开发与工程实战

ISBN：978-7-115-69824-7

本书由人民邮电出版社发行数字版。版权所有，侵权必究。

您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。

我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。

如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。

版　　权

著    [德] 多米尼克·梅利（Dominik Merli）

译    崔洪权　岳少聪

责任编辑 陈灿然

人民邮电出版社出版发行　　北京市丰台区成寿寺路11号

邮编　100164 　电子邮件　315@ptpress.com.cn

网址　http://www.ptpress.com.cn

读者服务热线：(010)81055410

反盗版热线：(010)81055315

版 权 声 明

Copyright © 2024 by Dominik Merli. Title of English-language original: Engineering Secure Devices, ISBN 9781718503489, published by No Starch Press Inc. 245 8th Street, San Francisco, California, United States 94103. The Simplified Chinese-language 1st edition Copyright © 2026 by Posts & Telecom Press Co., Ltd under license by No Starch Press Inc.

All rights reserved.

本书中文简体字版由美国No Starch出版社授权人民邮电出版社有限公司出版。未经出版者书面许可，对本书的任何部分不得以任何方式或任何手段复制或抄袭。

版权所有，侵权必究。

内 容 提 要

本书聚焦嵌入式系统安全开发的实战需求，针对当前嵌入式设备面临的安全威胁与合规要求，构建从基础到高级的完整知识体系。本书先讲解安全开发流程、密码学等基础知识，再深入剖析随机数生成器、密码实施、机密数据存储与安全内存、安全设备身份认证、通信安全等设备安全构建模块，最后阐述安全启动与系统完整性、固件更新安全、鲁棒设备架构、访问控制与管理、系统监控等高级设备安全概念，搭配基于STM32MP157F设备的案例研究，将理论转化为可落地的实践方案。

本书兼具系统性与实用性，贴合嵌入式系统资源受限的特性，适合嵌入式系统架构师、物联网开发工程师、产品测试人员，以及物联网安全研究人员、相关专业学生阅读，是构建安全嵌入式设备的实用指南。

译 者 序

当今数字化浪潮席卷全球，嵌入式系统已成为推动经济发展和社会进步的重要引擎。从智能家居到工业自动化，从交通控制到医疗设备，嵌入式系统无处不在，默默支撑着我们的日常生活和关键基础设施。然而，随着这类系统的普及，其安全性问题也日益凸显。数据泄露、远程攻击、恶意软件等不仅威胁到用户隐私，还可能导致严重的经济损失和社会危机。因此，如何构建安全的嵌入式系统已成为全球技术界亟待解决的难题。

在这一背景下，本书的出现具有重要意义。作者多米尼克·梅利（Dominik Merli）以其丰富的实践经验和深刻的研究见解，为读者提供了一本系统、全面且具有实战价值的嵌入式系统安全指南。本书不仅深入探讨安全开发的核心原则，还通过翔实的案例研究和具体的技术实现，为开发者提供从理论到实践的完整知识体系。

本书对物联网安全研究人员具有特殊意义。目前，许多物联网安全研究人员虽然在安全领域具有深厚的理论功底，但对物联网开发过程中的实际问题和挑战了解不足。而本书系统地介绍嵌入式系统和物联网设备的安全开发流程、安全设计原则以及常见的安全威胁和防护措施。通过阅读本书，物联网安全研究人员可以更好地理解开发者在保障安全性时面临的挑战，从而在未来的研究中能够更好地适应实际需求，提出更具针对性和实用性的安全解决方案。

此外，本书的受众覆盖面非常广泛。无论是嵌入式系统架构师、物联网开发工程师、产品需求工程师，还是从事嵌入式系统测试的专业人员，本书都能提供丰富的知识和实用的指导。对于学生和对嵌入式系统安全感兴趣的读者，本书更是通向这一领域的大门，能够帮助他们理解物联网产品安全设计的复杂性和重要性。

本书的独特之处在于，它不仅涵盖安全开发的基础知识，如安全开发流程、密码学，还详细探讨设备安全的构建模块，如随机数生成器、机密数据存储、通信安全等。这些内容不仅适用于高性能的物联网设备，还适用于资源受限的嵌入式系统。通过本书，读者将能够全面理解安全开发的复杂性，并学会如何在实际项目中平衡性能、成本和安全性。

值得一提的是，本书还特别强调了安全性是系统设计的重要目标，而非事后补救措施。这种理念与当前国际安全标准和法规的要求不谋而合。无论是欧盟的《网络安全法案》和《网络弹性法案》，还是NIST（美国国家标准与技术研究院）网络安全框架，本书中的指导原则都为开发者提供了符合法案规定的实践指南。

在翻译过程中，我力求忠实于原文，同时确保语言通俗易懂，便于国内读者理解和应用。我希望本书能够为我国的嵌入式系统开发者和物联网安全研究人员打下安全开发的基础，帮助他们在安全开发的道路上走得更远、更稳。

此外，我也深刻体会到，安全开发并非一蹴而就的工程，而是一项需要持续学习和实践的任务。我相信，通过阅读本书，读者不仅能够掌握嵌入式系统安全的核心知识，还能够培养起安全开发的思维方式，为构建更安全的数字世界贡献自己的力量。

崔洪权

2026年4月

推 荐 序

本书的英文名称在很大程度上解释了当前嵌入式系统的发展现状以及为何本书的主题如此重要。没有一本名为《构建不会倒塌的桥梁》的前沿著作（我已核实），因为桥梁不倒塌的目标是显而易见的。工程师们学习力量如何作用于桥梁、材料在压缩和拉伸下的行为特性，并利用这些知识来建造不会倒塌的桥梁。但人们本能地知道桥梁的目标应该是不倒塌。那么，嵌入式系统的目标是安全吗？还是说安全只是事后才考虑的事情？

嵌入式系统的复杂性在于设计师面临的广泛且常常相互冲突的目标。安全可能不是系统的首要目标，因为系统还必须易于使用、健壮、低成本、高性能、可靠、功能安全且信息安全。无论是采用小型8位微控制器的系统，还是搭载Linux或Android的32位/64位片上系统，都面临着同样的需求。

面对如此多相互冲突的需求和如此广泛的系统类型，单个工程师几乎不可能一一应对。运行在咖啡机上的嵌入式系统可能与运行在汽车安全气囊控制器上的系统类型相同，但你对两者的重视程度必然有所差异（不过我确信，对某些人来说仍然是咖啡机更重要）。嵌入式系统开发中，根本无法覆盖控制器复杂性和安全需求的每种可能组合，更不用说在一本书中全部涵盖了。因此，即使你可能没有运行嵌入式Linux系统，理解安全存储数据的基本理念对各类系统仍具有普遍意义。

建议你认真领会本书内容，即使乍看之下它们似乎与你的系统无关。例如，在进行微控制器开发时，你可能会疑惑学习Linux访问控制系统（第11章）的意义所在。但你的小型实时操作系统很可能有不同程度的用户交互任务，你不会希望暴露在不安全接口下的任务与处理敏感数据的任务共享内存。因此，虽然你的设备可能不使用Linux访问控制系统，但理解其设计目标将引导你实现更安全的设计。

本书非常具体地阐述了构建安全系统并非易事，但你可以通过许多简单步骤朝着这一目标前进。将安全确定为重要的工程目标是第一步，而你会在本书中找到许多后续步骤。我希望你拿起这本书是因为你已决定迈出第一步，我也希望某位读者将设计我下一个购买的联网设备，而多亏了多米尼克·梅利所做的引导工作，我对它的安全性将更有信心。

在开发过程中，了解已有的工作成果或现成工具将节省你的时间和精力，同时提高系统安全性。在我的研究工作（包含设备逆向工程）中，我研究了供应商（通常是知名公司）是如何实现固件更新的。对于大多数设备，使用本书第 9 章案例研究中使用的SWUpdate 工具会更好。即使我日常使用各类搭载嵌入式计算机的设备，每当看到说明书里写明固件更新过程不可中断，否则必须将设备寄回厂商检修时，心里总会不由一紧。这些并非设备必须面临的根本问题，而只是众多例子中的一个，遵循现有最佳实践几乎总是比尝试“重新发明轮子”更有效（即使作为工程师的我喜欢重新发明轮子）。

如果你刚刚踏入嵌入式安全领域，你可能会意识到有众多分支等待你去探索。我真诚希望你能沿着路径前进，因为你可能会发现这是一个高度跨学科的世界，新的视角往往能孕育重要成果。虽然我自己的工作集中在功耗分析和故障注入等方面，但该领域涵盖从软硬件中的高性能密码学实现到后量子密码与面向未来的密码方案，再到软硬件逆向工程，以及介于上述领域之间的所有技术领域。

因此，无论你是对嵌入式系统感兴趣的本科生，还是仍然试图节省每一字节 RAM的资深嵌入式工程师，你都将在本书中找到大量有趣且有用的信息。更重要的是，你将找到一份指南，帮助你构建安全的嵌入式设备。

科林·奥弗林（Colin O’Flynn）

ChipWhisperer项目发起人

于加拿大哈利法克斯市

致  谢

我成长于德国的一个小村庄，是我整个家族中第一个上大学的人。在我年轻时，没有人会想到我有朝一日会获得博士学位，成为一名教授，甚至用英文写书。回首过去，数百人曾给予我支持，从我的父母、兄弟姐妹、所有朋友、足球教练和老师，到同学、教授、同事和国际联系人。非常感谢你们！

与No Starch出版社合作完成这本书是一次精彩的经历，在整个过程中我学到了无数东西。我要感谢吉尔（Jill）和整个团队对我的耐心以及他们卓越的支持。同时，能有科林·奥弗林作为技术审校者是一种荣幸。我们关于实践经验的讨论为本书带来了多项改进和扩展。

感谢弗洛里安·菲舍尔（Florian Fischer）和彼得·克瑙尔（Peter Knauer），他们帮助我撰写了书中包含的案例研究，并解决了我遇到的所有工具链问题。

法比安·布莱（Fabian Bley）、弗洛里安·弗尔斯特（Florian Förster）、克劳迪娅·迈廷格（Claudia Meitinger）和伊丽莎白·施勒佩尔（Elisabeth Schröppel）慧眼如炬，发现了本书早期版本中的错误之处。谢谢你们！

最后，我要感谢我的妻子和孩子们在这个项目过程中的耐心，以及每当我遇到困难时给予我的鼓励。

前  言

互联网连接、数字商业模式和数据驱动服务、远程访问和数据分析为几乎每个行业带来了各种需求和挑战。简单来说，大多数现代电子产品需要集成计算机的某些功能。更具体地说，它们通常需要一个嵌入式系统，即包含处理单元、存储器和输入/输出接口的电子系统，这些系统被嵌入更大的机械或电子系统中。

嵌入式系统的应用领域极其广泛，用于工业自动化、交通和关键基础设施系统中的控制器、传感器和执行器。通信和网络硬件（如路由器、交换机和基站）也基于嵌入式系统。在消费市场，典型的嵌入式系统产品包括智能洗衣机、智能供暖系统和游戏机，甚至用于银行业务和门禁控制的塑料卡也可以被视为嵌入式系统。

与个人计算机和服务器系统相比，嵌入式设备通常面临各种限制，如需要降低制造成本或在计算能力较低/中等的硬件上运行，以及输入/输出能力的选择相当有限。嵌入式系统用于特定领域，通常在很少或几乎没有用户交互的情况下运行。此外，嵌入式设备采用的硬件、固件和操作系统组合千差万别，跨越不同产品、制造商和行业领域。

将安全需求纳入考量并不会使嵌入式系统工程师的工作变得更容易。为这些设备、它们特定的应用环境以及受限资源制订安全措施，对架构师和开发人员来说是极具挑战性的任务。在许多情况下，嵌入式系统还面临物理攻击者的威胁——相较于基于云或网络的远程访问攻击，物理攻击无疑是更具威胁性的攻击模式。

嵌入式系统安全现状

观察不同的应用领域和行业，可以发现嵌入式系统中的安全措施状况差异很大。例如，付费电视的智能卡解决方案早在20世纪90年代就面临欺诈威胁。如果人们能够绕过加扰算法，他们就能免费观看付费电视。此外，如果攻击者成功克隆智能卡，他们可以更低的价格出售，导致原始提供商收入受损。由于商业模式面临挑战，这些公司的安全意识相对较高，智能卡安全相关的投资和发展被优先考虑。

娱乐领域的另一类嵌入式系统——游戏机展现出类似模式。游戏机制造商的自然利益是只有原装游戏媒体才能在其设备上运行，如果攻击者成功运行克隆光盘，其商业模式就会受损。当逆向工程社区开始聚焦游戏主机分析［例如催生了安德鲁·黄（Andrew Huang）著名的Hacking the Xbox一书（No Starch出版社，2003年）］，行业以增强安全机制作为回应。结果，他们实现了嵌入式系统安全的坚实状态，攻击者需要投入大量资源，借助专业知识和复杂工具才能成功绕过保护措施。

然而，嵌入式系统在某些应用领域可能并没有如此成熟的安全措施。2016年，随着Mirai恶意软件的出现，这一点变得非常明显。该恶意软件将数十万物联网设备（主要是IP摄像头和家用路由器）变成“僵尸网络”，对网站进行大规模分布式拒绝服务攻击。此外，2020年被称为Ripple20和Amnesia:33的漏洞合集揭示了嵌入式系统TCP/IP协议栈的各种缺陷。据估计，超过1500万台设备受到影响，从医疗设备到楼宇自动化设备，再到工业控制系统。

奇怪的是，在工业自动化和关键基础设施领域，即便对鲁棒性和可靠性有着严苛要求，其设备的安全短板依然触目惊心。虽然2010年Stuxnet事件报告为工业自动化制造商敲响了警钟，但十多年后，市场仍然严重缺乏受到良好保护的设备。2022年，一组运营技术组件的漏洞以OT:ICEFALL的名称发布。我将这些安全工程缺陷称为“设计上的不安全”，因为分析的产品甚至缺少最基本的安全控制。

新兴需求、法律和标准

听起来可能很奇怪，但如果没有这些事件、漏洞和攻击，我们的安全意识可能依然不强。然而，由于我们在过去20年中目睹了许多这类问题，同时在线连接、数字服务和数据分析对企业越来越重要，网络安全“突然”成了刚性需求。

这并不意味着客户立即表现出深厚和全面的安全知识，但他们越来越多地要求风险分析、保护措施，或要求产品制造商遵循特定标准。根据我在工业领域的经验，这有时会促使客户和制造商之间进行沟通，以在安全需求与相关成本之间找到折中方案，这对双方而言可能是一种合理且富有成效的协商。

另外，各国政府越来越关注制定国家法律和签署国际协议，推动市场上所有产品满足基本安全要求。在欧洲，2019年通过的《网络安全法案》旨在为在欧盟销售的所有产品和服务建立安全认证框架，而2024年通过的《网络弹性法案》则规范了对具有数字元素的产品的网络安全要求。欧洲标准ETSI EN 303 645已经定义了基线安全要求，特别是针对消费类物联网产品。大西洋彼岸，拜登于2021年5月签署的第14028号行政命令采取了类似路线，旨在保障物联网设备和软件解决方案的网络安全。NIST为这些产品的网络安全标签提供了建议。

同时，各行业的联盟尝试就其领域的通用安全标准达成一致。一个突出的例子是IEC 62443标准，它针对工业控制系统和工业物联网安全。它结合了对运营商、系统集成商和组件制造商的安全要求，使工业系统能够拥有统一且相互关联的安全视图。关于安全设备工程，IEC 62443-4-1和IEC 62443-4-2最为相关：IEC 62443-4-1涵盖安全开发过程的实践，IEC 62443-4-2则涉及技术性产品安全要求。

谁应该阅读本书

如果你是嵌入式系统架构师，本书将为你提供必要的知识，使你能够与合作伙伴顺畅地交流。

如果你是负责实施安全功能的嵌入式系统工程师或物联网开发人员，想了解安全功能背后的原理和典型障碍，本书将帮助你为即将面临的挑战做好准备。

如果你是负责产品需求工程的人员或在日常工作中负责进行嵌入式系统测试，本书将帮助你理解某些安全功能的价值，以及为什么开发团队的同事可能不愿意实施它们。

如果你是一名学生，想知道为什么许多保护措施在物联网产品中不能被视为理所当然，本书将证实你拥有正确的思维方式，并且你将了解嵌入式系统安全是一项重要但有时烦琐的任务。

如果几分钟前有人对你大喊：“我们必须要实现设备安全！现在！！”请仔细阅读本书。之后，你将准备好进行一次关于“安全”的友好、客观的讨论。

本书涵盖什么内容

本书内容基于我在嵌入式系统安全领域多年的实践经验和研究见解。

第一部分　基础知识 你将学习安全开发生命周期相关的基础知识，以及如何运用密码学。

第 1 章　安全开发流程 涵盖产品开发过程中遵循安全设计原则所必需的基本要素。

第 2 章　密码学 总结与实用安全工程相关的密码学基础知识。

第二部分　设备安全构建模块 详细介绍嵌入式系统安全的基本物理和逻辑构建模块。

第 3 章　随机数生成器 深入探讨随机性，强调其对安全的重要性，并提供关于如何生成和评估随机数的实用提示。

第 4 章　密码实施 讨论密码算法的实现选项及其对性能等属性的影响。

第 5 章　机密数据存储与安全内存 专注于以安全、保密的方式存储大小不同的数据。

第 6 章　安全设备身份认证 关注嵌入式系统唯一身份的生成和管理。

第 7 章　通信安全 介绍通信通道最先进的保护措施，并回答关于在嵌入式系统上实施这些措施的常见问题。

第三部分　高级设备安全概念 关注与安全物联网设备相关的全面保护概念。

第 8 章　安全启动与系统完整性 涵盖嵌入式系统启动时敏感操作阶段的安全考虑。

第 9 章　固件更新安全 介绍如何在保证安全的前提下为产品提供软件更新。

第 10 章　鲁棒设备架构 讨论如何在遭受攻击时继续关键进程操作。

第 11 章　访问控制与管理 考虑设备上用户和进程的限制及其实际后果。

第 12 章　系统监控 探讨针对嵌入式系统异常或攻击的检测分析技术。

阅读本书时，请记住，你的目标不仅是吸收尽可能多的技术知识，还要理解设备安全措施何时以及为何有意义。

关于本书中案例研究的说明

本书多章包含案例研究。这些案例并不能在你自己的设备上轻松复现或用于生产开发。那样做超出了本书的讨论范围，相关的安全见解也会被繁杂的落地实现问题所掩盖。

有些案例研究展示了理论与混乱的现实世界之间的差距，有些案例研究则展示了不同实现选项的优势或劣势，还有一些案例研究仅提供特定的应用环境，帮助你理解介绍的思想和概念。

嵌入式系统的设备类别繁多，它们的处理器、存储器和接口也是如此。为了提供一个合理的演示设备——既不太高端，也不太小巧，我选择了一个中等性能的硬件平台：STMicroelectronics（ST）公司的STM32MP157F-DK2评估板。该平台还包括基于硬件的安全措施，可在案例研究中进行分析。（声明一下，我与ST公司没有任何关联。）

当涉及中高性能嵌入式系统的操作系统时，Linux是首选。它被用于汽车、洗碗机、可编程逻辑控制器、电视、能源监控系统，以及本书的案例研究中。具体来说，本书使用ST公司的OpenSTLinux发行版，搭配Linux 5.15内核。

资源与支持

资源获取

本书提供如下资源：

• 异步社区7天VIP会员；

• 本书思维导图。

要获得以上资源，您可以扫描右侧二维码，根据指引领取。

提交勘误信息

作者和编辑尽最大努力来确保书中内容的准确性，但难免会存在疏漏。欢迎您将发现的问题反馈给我们，帮助我们提升图书的质量。

当您发现错误时，请登录异步社区（www.epubit.com），按书名搜索，进入本书页面，单击“发表勘误”按钮，输入勘误信息，单击“提交勘误”按钮即可（见下图）。本书的作者和编辑会对您提交的勘误信息进行审核，确认并接受后，您将获赠异步社区的100积分。积分可用于在异步社区兑换优惠券、样书或奖品。

与我们联系

我们的联系邮箱是chencanran@ptpress.com.cn。

如果您对本书有任何疑问或建议，请您发邮件给我们，并请在邮件标题中注明本书书名，以便我们更高效地做出反馈。

如果您有兴趣出版图书、录制教学视频，或者参与图书翻译、技术审校等工作，可以发邮件给我们。

如果您所在的学校、培训机构或企业想批量购买本书或异步社区出版的其他图书，也可以发邮件给我们。

如果您在网上发现有针对异步社区出品图书的各种形式的盗版行为，包括对图书全部或部分内容的非授权传播，请您将怀疑有侵权行为的链接通过邮件发给我们。您的这一举动是对作者权益的保护，也是我们持续为您提供有价值的内容的动力之源。

关于异步社区和异步图书

“异步社区”是由人民邮电出版社创办的IT专业图书社区，于2015年8月上线运营，致力于优质内容的出版和分享，为读者提供高品质的学习内容，为作译者提供专业的出版服务，实现作者与读者的在线交流互动，以及传统出版与数字出版的融合发展。

“异步图书”是异步社区策划出版的精品IT图书的品牌，依托人民邮电出版社在计算机图书领域几十年的发展与积淀。异步图书面向IT行业以及各行业使用IT的用户。

第一部分　基础知识

第1章　安全开发流程

当我还是一名学生时，我认为“组织流程”是工程学中最枯燥乏味的课题之一。然而，在安全工程领域工作了十多年，并帮助企业优化其安全工作后，我不得不承认，流程远比我想象的要有趣得多，且在开发安全产品时并不是无关紧要的。

尽管产品的技术保护功能可以实现并标记为“已完成”，但安全开发流程永远不会真正完成，必须持续维护和改进。这也是安全工程流程的定性衡量标准被称为“成熟度”的原因。成熟度水平可以提高或降低，这取决于组织内支持安全产品开发活动的规律性、质量以及组织结构。

本章的目标是让学生、工程师和开发人员认识到，流程不仅仅是创建无人阅读的文档。可靠的安全开发生命周期（Security Development Lifecycle，SDL）应深深植根于组织文化和日常行为中，它关乎如何在不断变化的条件下保持质量和安全性，也明确了每个参与产品工程流程的人如何能够持续为安全的最终产品做出贡献。

1.1　关于各种指南的讨论

关于安全开发流程的建议已经存在了一段时间。然而，根据你所处的行业不同，你的组织可能直到最近才考虑采用这种系统化的方法，或者至少没有明确地提出过这一需求。

开发操作系统和网络应用程序的公司遇到安全问题要更早一些，因此，微软公司和开放式Web应用程序安全项目（Open Web Application Security Project，OWASP）是最早开发并讨论SDL的组织之一也就不足为奇了。自国际电工委员会（International Electrotechnical Commission，IEC）发布IEC 62443-4-1以来，越来越多的工业组件（这些组件用于生产设施、关键基础设施和各种自动化应用）制造商已经意识到实施安全开发流程的必要性。

微软公司的SDL遵循12项实践，这些实践描述了公司为开发安全（软件）产品所采用的流程。这些流程涵盖从培训、需求工程、威胁建模到安全测试等环节。同样，针对软件开发社区，OWASP使用5个类别来概括其软件保证成熟度模型（Software Assurance Maturity Model，SAMM）：治理、设计、实施、验证和操作。IEC 62443-4-1旨在为工业组件制造商制定安全开发流程标准。该标准分为8个实践，每个实践包含2～13个子实践，详细说明了从安全管理、设计与实施到现场更新管理等方面的推荐活动。

尽管这些指南采用了不同的结构来解释安全开发流程的概念，但它们在核心内容上有许多重叠之处。例如，微软公司的SDL要求进行威胁建模，而OWASP则在“设计”类别中使用了“威胁评估”这一术语，IEC 62443-4-1中的SR-2（这是安全需求实践规范的一部分）也明确要求建立一套用于创建和维护产品威胁模型的流程。

此外，这三者都强调了安全知识和能力的重要性：微软公司将培训列为首要实践，OWASP则将教育纳入治理范畴，IEC 62443-4-1则在其安全管理实践中的SM-4部分要求使用“安全专业知识”一词来概括技能的识别和开发。例如，渗透测试在微软的SDL中是一个明确命名的实践，在IEC 62443-4-1标准的安全验证与确认测试实践的SVV-4条款中使用的是相同的名字——“渗透测试”，而SAMM则在验证项目下的安全测试任务中提到了这一重要内容。

在使用先进密码技术应用、第三方依赖关系澄清和漏洞处理等方面，也有类似共识。关键在于，这些指南在内容上有许多相似之处。因此，“众多可用资源中哪一个是最好的？”这一问题的答案通常是“它们的差异不大”。

微软公司在安全软件工程方面有30多年的经验。OWASP不仅提供了有价值的建议，还提供了支持流程的开源工具。IEC 62443-4-1针对的是不同于传统信息技术（Information Technology，IT）公司的工业领域和组件制造商。此外，IEC 62443的合规性可以通过独立机构进行认证，而这对微软公司和OWASP的SDL来说是不可能的，因此这一点可能是另一个决定性因素。

除了上述指南，美国国家标准与技术研究院（National Institute of Standards and Technology，NIST）的Special Publication 800-160、Building Security In Maturity Model（BSIMM）倡议以及欧盟网络安全局（European Union Agency for Cybersecurity，ENISA）的Good Practices for Security of IoT - Secure Software Development Lifecycle也提供了有价值的参考。

1.2　产品安全责任

每个产品在安全方面的成功都始于明确责任的划分。无论是初创公司的创始人、跨国公司的产品安全官（Product Security Officer，PSO），还是开发团队的成员，关键是必须有人对安全负责，且这个人需要具备完成这项工作的必要时间和资源。

安全开发流程涉及各种活动，这也意味着负责安全的人员必须参与产品开发的多个阶段，并确保“安全设计”成为产品开发文化的一部分。然而，负责安全的职位可能并不讨喜，特别是在企业并未将安全作为重点时。（产品）管理层通常更愿意讨论新技术和产品功能的潜力，故频繁强调其中的安全风险很难让你得到认可。

然而，从长远来看，这个角色将帮助消除错误、漏洞和内部误解。他们不仅能够提高设备的安全性，还能够增加产品开发团队与管理层之间的透明度。

1.3　意识与培训

几年前，我参加了一位德国安全顾问的讲座，此次讲座的内容与欧洲公司如何为即将到来的网络威胁做好准备（或没有准备）以及安全从业人员每天必须承受多少压力和挫折有关。针对管理层，他总结道：“工具和技术无法创造安全，唯有人才能创造安全！”

从需求工程到软件与硬件开发，再到漏洞处理，安全从业人员会创造性地发现产品功能被滥用的可能性，并严格遵循团队内部制定的安全编程规则，同时从第三方报告的问题中甄别出真正相关的安全隐患。

换句话说，如果你的开发团队无法设想潜在的攻击场景，将安全实践视为障碍或以愤怒、恐惧、无知的态度面对漏洞报告，那么即使你购买了最昂贵的工具许可证，产品的安全性也难有实质性提升。一个关键的问题是，“谁需要掌握哪些安全知识，才能确保每天的工作都贯彻安全设计原则。”

对大多数员工而言，基本的安全意识是必备素养，这同样适用于工程师、开发人员和设备架构师。然而，安全意识并不是在学校中能够被系统习得的内容（至少目前如此）。况且，它也不是大学或传统在职培训机构开设的必修课程。此外，随着时间的推移，安全意识可能会逐渐淡化，因此其需要被定期强化。在团队中，探讨攻击者的思维方式、意图和应对策略是非常有必要的。

基于我的经验，线上培训往往成为员工“点一下就忘”的活动，而社交聚会、研讨会和团队建设活动则能够带来更多互动、讨论以及反思（这是最重要的），并使员工将安全意识与日常工作联系起来。

除了基本的安全意识，产品工程团队中的个体还可能需要特定的技能。例如，开发人员可以从安全编程培训中获益，而测试人员则可以通过渗透测试课程提升能力。此外，加入安全工程社区也是一种常被忽视的机会，尤其是在中型企业中，为管理层和技术人员提供与其他组织交流想法、经验和教训的机会，是非常值得借鉴的做法。

同样，培训也不是一次性的活动，不断鼓励员工反思其工作和日常流程的安全性，是建立产品安全文化的关键。

1.4　资产与保护目标

想象一个阳光明媚的周一早晨，繁忙的工作周刚刚开始。此时，管理层有人向你提出了一个请求。

经理：“请把我们的产品变成一个安全的产品！”

你：“具体是什么意思？”

经理：“让它无法被破解！”

你：“这个要求是从哪里来的？”

经理：“难道你没看到新闻吗？现在什么东西都能被‘黑’！”

你：“好吧！那么，我们产品的哪个部分值得被‘黑’呢？”

经理：“我不知道。你来告诉我！”

虽然这段对话是虚构的，但你可能遇到过类似的讨论。它揭示了一个核心问题：如果不知道保护的对象是什么，就无法确保其安全性。因此，公司中的每个人都应该知道哪些对象值得保护，或者哪些对象对业务的正常运作至关重要。通常将这些对象称为“资产”。

1.4.1　识别宝贵的资产

资产可以是多种类型的，例如按需付费方案所需的加密密钥、从设备传输到云应用程序以启用预测性维护服务的测量数据、激活或禁用产品功能的配置文件、固件中用于在紧急情况下发出警报的代码或网络服务。即便是最基本的设备操作也依赖于资产。简而言之，资产就是所有重要且有价值的东西。

识别资产是启动安全开发流程的第一步，也是所有保护工作的基础。从逻辑上讲，在实施防护措施或进行渗透测试之前，必须明确要保护的资产。毕竟，如果你不清楚要保护的对象，又怎能有效实施安全防护措施并预设攻击场景呢？此外，由于大多数现代设备并非孤立存在，因此这一过程还涉及在企业内部统一认知整个系统，涵盖相关对象、数据流、人员、第三方组件、生命周期流程及其背后的业务模式。

阅读到这里，你可能会觉得信息量很大，的确如此。这些主题涵盖了从业务洞察到技术细节，再到流程和组织结构等内容。无论公司规模如何，一个人不可能独自负责所有这些任务，尤其是在开发团队内。因此，以多维方式进行分析至关重要。

与团队成员讨论网络安全的首要步骤是提供基本设备上下文概览，汇总现有的架构信息。图1-1展示了一个虚构的Wi-Fi控制工业通风机的基本设备上下文概览示例。

图1-1　基本设备上下文概览示例

这个初步的概览应该尽量简洁，但在必要时要足够详细。在随后的研讨会或讨论过程中，这个概览可能会随着更多信息的出现而不断被丰富和完善。例如，最初的概览中可能没有明显提到的数据流、此前未知的与第三方的关系，以及只有每天实际操作这些流程的人才能知道的隐含步骤等，都会被添加进来。

在所有人都对系统整体的细节和准确度感到满意之后，资产识别的实际工作将从这个问题开始：系统的哪些部分对我们的业务模式和组织至关重要？

1.4.2　相关保护需求

在确定需要保护的资产时，不仅要明确哪些内容是重要的，还要深入理解为什么这些内容值得保护。只有弄清楚这两点，才能更好地定义保护目标，并确保采取的安全措施切实有效。每个资产都应至少有一个保护目标，否则该资产可能不需要特别保护（从安全角度来看）。下文将从著名的CIA三要素（保密性、完整性、可用性）出发，列出常见的保护目标，并定义哪些资产属性是值得保护的。然而，如果发现某个特定保护需求不符合这里的标准目标，可以自行定义保护目标并记录。

保密性（Confidentiality，C）

这一保护目标可能是最广为人知的。可以简单地说，一个相关的资产必须保持“机密”才能被视为“安全”。更正式地说，这意味着除非经过授权，否则任何人都不应有读取特定资产的权限。尽管这是大多数人在谈论安全时首先想到的目标，但并非所有资产都需要保密。需要保密的典型资产有存储的加密密钥、包含知识产权的可执行文件等。

完整性（Integrity，I）

只有被授权的人或系统才能更改特定对象或数据，并且如果未经授权的更改已发生，必须能够检测到这种更改。常见的完整性应用场景包括用于计费的单调计数器、通过通信通道发送的控制命令。

此外，完整性保护目标还适用于整个设备或机器。例如，如果系统的某些部分可以被替换，那么确保系统的完整性就显得尤为重要。需要注意的是，“完整性”在安全领域和在可靠性领域的定义有所不同。在可靠性领域，循环冗余校验（Cyclic Redundancy Check，CRC）常常被视为“完整性保护”，这并不适用于安全领域；在安全领域，一个活跃的攻击者可以很容易地伪造一个CRC。

可用性（Availability，A）

设备的大部分功能应正常运行，如果攻击者可能中断或延迟对设备端或后端某些数据或服务的访问，可用性便成为关键保护目标。相应的资产包括提供实时数据的网络服务、设备主处理器中的随机数据流，以及服务器系统中的备份等。特别是在汽车和工业应用场景中，硬实时通信也有类似的要求。在这种场景下，当前信息（例如来自安全传感器或刹车控制器的信号）必须在指定截止时间前可用。

真实性（Authenticity，Au）

真实性可以被视为完整性的延伸。除了确保数据没有被篡改外，还必须能够明确验证数据的来源。真实性对于必须为“原装”的设备部件尤为重要，例如备用零件、闪存中的固件或许可证文件。

不可抵赖性（Nonrepudiation，Nr）

不可抵赖性与真实性密切相关，它指的是某个实体不能合理地否认其已执行的某项操作。通常，这一要求适用于涉及合同的设备或用户活动，例如在设备上直接订购打印机补充墨水或付费使用产品。

隐私（Privacy，Pr）、假名（Pseudonymity，Ps）和匿名（Anonymity，An）

2018年，欧盟《通用数据保护条例》（General Data Protection Regulation，GDPR）出台，自此隐私和数据保护问题日益受到重视。如果你的设备处理个人数据（例如医疗设备），你可能需要为这些数据指定保护目标。典型的目标包括假名，即数据可以追溯到别名但无法关联到真实身份；或者匿名，即处理/收集的数据无法关联到真实身份或别名。

最终，你可能会得到一张资产及其相应保护目标的表格，如表1-1所示。注意：如果你希望为所选的保护目标提供更多背景信息，“注释”栏可能会非常有用。

表1-1　资产及其相应保护目标

在处理了大量信息之后，人们通常会对设备安全与产品开发和操作各个领域之间的紧密关系感到惊讶。然而，他们通常也会感到满意，因为迈出了确保设备安全的第一步，并且学到了有关自认为熟悉产品的新知识。

1.5　攻击者、威胁和风险

在建立了对设备资产及其环境的理解后，接下来的任务就是分析相关用例中的威胁与风险。第二阶段的目标是定义一组场景（代表当前的威胁状况），并根据其发生的可能性及其对业务和组织的潜在影响进行评级。

一个典型的威胁场景通常包括攻击者（实施攻击的主体）、潜在漏洞（设备中可利用的弱点）、攻击向量（攻击的路径或方法），以及对之前确定的至少一项资产的影响。这个阶段旨在预测设备未来可能面临的威胁，即使该设备尚未被开发或生产。

当然，不可能以 100% 的准确率预测所有威胁。这个过程充满创造性，要求参与者从攻击者的角度想象如何实现恶意目标。是的，定义威胁场景的过程对技术人员而言可能显得有些混乱，且可能会出现意外结果，最终结果也并非一成不变。如果日后发现了新的威胁，你将需要更新这些场景。

1.5.1　潜在攻击者

一个好的起点通常是想象潜在的攻击者，他们的动机、机会和资源各不相同。以下是基本例子。

脚本小子

这类攻击者不一定是青少年，但他们往往出于好奇或消遣来分析设备和服务。他们通常资源匮乏（除了时间充裕以外），使用互联网上提供的标准工具，并通过观看视频或自学掌握基本技能。

安全研究人员

这些人通常具有专业知识，并拥有强大的设备，通常在大学或研究机构工作。他们的行为通常不涉及经济利益，他们的目标是公开发现的漏洞并准备相应的修复措施。与其他类型的攻击者不同，他们通常愿意与公司合作，帮助改善产品安全。

网络犯罪分子

这类攻击者通常以经济利益为驱动力，有组织地犯罪，每天都在攻击IT产品。无论这类攻击者是专注于勒索软件、拒绝服务（Denial of Service，DoS）攻击，还是出售个人数据，他们至少拥有中等资源，并主动监控各个行业，能够根据新的环境调整工具。

产品盗版者

对嵌入式系统来说，克隆设备是一个主要问题。产品盗版者这类攻击者装备精良，能够复制硬件设计和软件组件，并以更低的价格提供假冒产品，从而利用原始设备制造商的研发投资获利。

明确攻击者类型有助于识别整体风险，但通常情况下，设备及其应用会有更具体的攻击者，让你可以将威胁场景具体化，并帮助你识别组织的个别风险。例如，在汽车和摩托车领域，发动机调校可能是特定攻击者群体的目标，他们的目的是规避保护措施，以应用其自定义性能设置。甚至客户本身也可能有兴趣操纵他们的设备。纵观农业物联网（Internet of Things，IoT）系统，环保和动物保护积极分子可能是相当现实的攻击者，他们有自己的目标、资源和方法。最后，不要忘记内部人员也可能是攻击者，因为他们对内部文档、数据和流程有独特的了解和访问权限。当然，大多数员工可能是值得信赖的，但在这一阶段，考虑一下他们心怀不轨时会怎么做还是很有价值的。

表1-2列出了表1-1所列资产的攻击者及其相应属性的示例。

表1-2　资产的攻击者及其相应属性的示例

在生成这份清单时，人们有时会想起曾经发生过的有关盗窃、破坏或盗版的真实案例。这些信息对优化未来的保护工作非常有帮助。

1.5.2　潜在的负面影响

一方面，我们有对业务至关重要的资产；另一方面，有伺机攻击这些资产的潜在攻击者。接下来的问题是：这些可能的恶意行为者会如何对资产产生影响？

构建攻击向量并想象系统中的潜在漏洞可能会产生无数的威胁场景，这些场景可能会相互重叠，增加处理工作量，但仍无法涵盖所有内容。应对这一问题的一个实用方法是，逐一查看你的资产列表，并应用由微软公司提出的STRIDE方法论中建议的相关威胁。

表1-3通过解释STRIDE各字母的含义，展示了6种常见威胁，并引用了它们针对的目标以及主持人可以向所有参与者提出的示例问题。对于表1-1中的AS01——一个具有完整性和真实性保护目标的固件镜像——任务是创造性地思考如何篡改它，或者伪造镜像原始制造商的身份。

表1-3　STRIDE威胁清单

如果其他STRIDE威胁似乎适用，请将其添加到你的讨论中。例如，在固件案例中，你可能拥有尚未被考虑的机密知识产权。最后，将任何额外的威胁与你的攻击者列表相匹配，并讨论谁是该威胁的合适攻击者。

除了设备和软件共同面临的威胁之外，物理产品还面临一个问题：它们可以受到物理攻击。在一些情况下，这可能并不严重，因为如果人们能够物理访问设备，他们也可以破坏机器或系统的其他部分。不过，物理可访问性至少在以下两种情况下会产生影响。

• 攻击前设备分析。在许多情况下，攻击者可以购买设备，并在其控制的环境中分析设备的漏洞、加密密钥以及相关行为。物理访问允许攻击者提取设备固件，并进行详细的逆向工程，或者通过监听印制电路板（Printed-Circuit Board，PCB）上的通信信号来获取可能泄露的机密数据。

• 隐蔽的操控。使用物理工具（如锤子）对机器进行非正常操作时，通常会产生噪声和造成可见的破坏，这些异常情况容易被人类感知。然而，任何可以更改设备或系统参数的物理访问或近距离接触行为，如果不进行深入的分析，可能无法察觉。这种攻击可能会产生持久的影响。

对所有资产重复这一过程需要时间。不过，这些讨论通常需要多个领域的专家共同参与，因此在实践中通常只需要一天到几天的时间。在对资产进行全面分析后，你将获得一套适用于产品的威胁场景。表1-4所示为一个研讨会威胁情景示例结果中的前几行。

表1-4　一个研讨会威胁情景示例结果中的前几行

这些场景将帮助你说明所识别的问题，并在公司内部进行沟通或向管理层反映。

1.5.3　没有风险，就没有优先级

到目前为止，所有潜在的攻击载体和漏洞都被收集起来了，没有忽略任何“无关紧要”的内容。然而，列表可能相当长，而处理这些问题的资源通常有限。现在是时候通过对每个威胁场景的两个属性进行评级来对其优先级进行划分了：一是发生的概率；二是如果发生，可能的影响等级。

在安全领域，几乎每个事故发生的概率都可以用一个数字来描述。如果你的跨学科研讨会中有功能安全专家，他们可能会提供这种方法，并认为概率必须用数字表示。然而，对人类攻击者来说，很难将其行为转化为有意义的百分比，因此最好采用定性的低、中、高评级方法。

对于影响等级，采用同样简单的低、中、高评级方法。然而，定义这些术语在每次分析中的具体含义是非常重要的，具体取决于产品、公司规模及业务场景。例如，你的团队可以商定将影响等级与损失值挂钩，如表1-5所示。

表1-5　影响等级示例

为了获得每个威胁场景的最终风险评分，有最后一个要点要说明：发生概率和影响等级的低、中、高分别对应数值1、2和3。将特定场景下的两个数值相乘即可得到相应的风险评分。

在对所有威胁场景进行评级后，你将得到一份类似表1-6的列表。为评级添加解释有助于更好地理解和推理，特别是在研讨会结束几周后，参会人员可能已经忘记了讨论的具体细节。

表1-6　威胁场景评级示例

在编制了威胁场景评级列表后，可以根据风险评分对其进行排序，或者通过二维风险矩阵展示出来。矩阵的两个维度分别是发生概率和影响等级。这种方法可以帮助设备架构师和产品经理更好地确定风险的优先级，因为资源永远不足以实施所有的缓解措施并防御所有可能的威胁。

1.6　安全需求和安全架构

威胁建模和风险分析对于分离设备的必要保护需求和“锦上添花”的保护需求至关重要。然而，重要的是要理解你的组织并不是唯一的利益相关者——客户、认证机构和政府部门可能会对你的产品提出额外的安全要求。

一些要求可能与你的利益一致，而另一些可能与你的利益相悖。你要确保处理好已识别的高优先级风险，但也要考虑外部要求，例如法律义务、客户需求和行业标准。

如果你的目标是产品认证，那么此时你应该仔细查看与目标产品认证相关的详细要求。例如，工业组件制造商可以根据IEC 62443-4-2中的保护功能来调整其设备的安全要求。即便没有明确的认证目标，像ARM的平台安全架构（Platform Security Architecture，PSA）1级问卷这样的文档也可以为特定产品创建鲁棒的安全需求提供指导和启发。

此外，安全需求总是与其他需求（例如设备性能、向后兼容性和降低成本等）相竞争。因此，你需要在早期阶段考虑各项需求之间可能产生的相互干扰。

在识别安全需求时，往往会忽略对整个产品生命周期的考虑——从开发、生产、现场使用到退役。每个阶段都有其独特的需求和依赖性。然而，如果从未考虑过设备的所有者可能更换，或者设备上的机密数据必须在报废前被销毁等问题，那么可能会导致后期出现麻烦。

1.6.1　风险处理

在定义安全架构时，之前所有关于威胁、风险和需求的分析工作需要整合成一套技术、保护措施和组织安排，以确保最终实现产品安全的目标。你可以通过多种方式应对风险。

降低风险

常见的风险应对方式是降低风险。通过适当地集成保护措施，可以降低某种威胁场景发生的可能性，或者减少其可能造成的损失。这两种策略都能降低风险。

消除风险

有时，删除软件组件、接口或产品功能可以完全消除某个风险。从安全角度来看，这无疑是最理想的策略，但从业务和市场角度来看，这通常是一个艰难的决定。

转移风险

你可以将安全风险从公司转移给供应商，或者从制造商转移给产品用户。通常，这种风险转移需要适当的文档和/或法律协议，它有助于提高合作伙伴与客户之间的透明度和安全意识。

接受风险

公司内部的负责人可以选择接受某些风险。如果某项风险的缓解成本高于实际发生安全事件时的处理成本，这可能是一个合理的选择。

1.6.2　安全开发原则

虽然本书的第二、第三部分旨在帮助架构师决定是否采用某些技术安全功能，但在开发安全架构时，你还应牢记一些概念性原则。

实施纵深防御

每项保护措施都有可能失效，这可能是由于攻击者的高超技术或特殊情况。安全架构应该实施多层保护，如果一层保护失效，剩下的一层或多层仍然能够保障安全或至少能减少潜在的损失。

使用经过验证的安全技术或组件

有些公司不愿意使用外部提供的现有技术和组件，即便这些技术和组件质量很高。在某些情况下，选择从头开始开发安全组件是合理的。但这样做可能需要漫长的时间，并伴随着许多失败。如果没有充分的理由说明必须这样做，最好使用已经被证明鲁棒、安全的技术和组件。

实行最小权限原则

一个鲁棒的安全架构应明确记录所有相关的角色和权限。在授予或拒绝权限时，特定角色应只被授予完成其任务所需的最小权限。这种做法还有助于减少内部攻击的潜在威胁。

保持简单

复杂性和不透明性是安全的天敌，因为它们使风险分析、攻击路径识别和有效的对策实施变得更加困难。保持设备和安全架构的简洁性有助于确保实际安全工作达成定义的保护目标。

减少攻击面

可以通过“减法”来增强安全性，这在涉及产品的攻击面时非常实用。无线接口不存在，就无法被攻击；从PCB上移除的调试端口也不会成为物理攻击者的切入点。删除所有不必要的功能、接口、硬件和软件组件，或者至少从即将进入市场的最终产品设计中移除它们。

1.7　安全实施和安全测试

前几节侧重于“做正确的事”，本节则专注于“正确地做事”。硬件和软件开发人员自然希望开发一个功能齐全、可正常运行的产品。然而，如果每个人都不关注安全问题（甚至完全忽视安全问题），那么最终你可能会得到一个功能齐全但存在若干问题的产品。而这些问题可能会在产品上市后被网络犯罪分子、研究人员或客户发现。

1.7.1　左移策略

避免这种情况的一种策略是“左移”，意思是尽早（尽可能向左靠近开发流程的开始阶段）发现和修正实施中的错误。这样不仅能加快反馈循环，还能降低错误检测和修正的成本。

在实施阶段初期，当团队需要做出可能对安全产生重大影响的关键决策时［例如选择中央硬件组件、操作系统（Operating System，OS）以及安全编程规则等］，这些考量就显得尤为重要。让我们来看以下两个例子。

硬件组件选择

物理产品的硬件开发通常比软件开发开始得早。在某个时间点，项目会达到一个称为“硬件冻结”的阶段，此时你将无法再更改设备的硬件组件。在这一时间点之后检测到硬件安全问题，可能会导致临时修复、昂贵的重新设计，或者设备安全性问题。

在为设备选择基本硬件组件时，务必考虑安全需求。如果组件成本不是关键因素，选择具有更多安全功能的组件，而不是安全功能较少的组件，这或许能在开发后期为你节省大量的时间和金钱。

编程语言选择

问10个人哪种编程语言最适合特定任务，你可能会得到11种答案。然而，特别是在嵌入式系统和物联网设备领域，我们发现，C语言可能带来大量内存安全问题，这些问题最终导致了安全漏洞。根据安卓、Chromium和微软的统计，70%～90%的常见漏洞与暴露（Common Vulnerabilities and Exposures，CVE）都可以追溯到内存管理问题。想象一下，如果代码分析工具、代码审查以及与内存管理问题相关的事件处理都不再必要，你能节省多少时间和精力。

Rust语言近年来在嵌入式、系统级和高性能软件开发社区中越来越受关注，因为它提供了解决由C或C++带来的安全问题的方案。

1.7.2　持续测试和分析

当然，初期的设计决策无法预见可能出现的所有安全问题。安全实施的第二个重要环节是建立强大的自动化流程，用于构建、测试和审查。特别是在软件开发过程中，开发人员必须在发现代码漏洞和潜在问题后立即得到反馈。虽然自动化和持续集成（Continuous Integration，CI）并不是专门为安全设计的，但它们有助于提高质量并减少人为错误，而这些错误通常是安全漏洞的根源。

从安全的角度来看，在自动化安全开发生命周期，请确保涵盖以下领域（其中有些是软件特定的，但大多数也适用于硬件开发过程）。

第三方组件透明度

在硬件设计中，生成物料清单（Bill of Materials，BOM）是日常工作，但某些产品对软件物料清单（Software Bill of Materials，SBOM）的需求正在增长。虽然两者的主要目的并非关于安全，但它们对于跟踪第三方依赖（包括软件库、微控制器和操作系统）中的安全漏洞至关重要。

静态安全测试

在软件开发中，使用静态应用程序安全测试（Static Application Security Testing，SAST）进行漏洞检测是重要环节。这类工具可以帮助你识别C语言中的不安全函数，例如它们可能检测到需要在发布前移除的硬编码机密信息，并突出显示容易受到常见安全风险（如OWASP Top 10）影响的代码部分。这些静态代码分析工具可以无缝集成到CI管道中，为开发人员及时提供反馈。

动态安全测试

静态安全测试无法检测到某些漏洞，因为这些漏洞可能源于软件或设备的不安全操作行为，所以需要进行动态安全测试。你可以在一定程度上采用自动化测试，例如将CI管道中构建的软件部署到测试设备，并使用测试用例来进行验证。然而，由于测试范围广泛，且动态应用程序安全测试（Dynamic Application Security Testing，DAST）需要特定的运行环境，因此这一测试通常需要比静态安全测试投入更多的精力。

实施情况审查

通常将“代码审查”一词用于软件开发流程，但同样可以对设备硬件设计进行审查，以发现实施中的缺陷、使用被禁止的组件或不良的设计模式，这些模式可能助长物理攻击。虽然这是一项需要人工参与的任务，但自动化工具可以帮助安排审查或在关键硬件/软件部分发生更改时自动触发审查。

1.7.3　攻击者即服务

上述所有技术都旨在验证和确认安全需求和保护功能，或者避免可能削弱设备安全性的实施缺陷。然而，尽管安全实施和安全测试逐渐融合为一个渐进和敏捷的开发过程，但有一种安全测试通常是手动完成的，并且是在CI环境之外进行的，那就是渗透测试。

在渗透测试中，内部或外部的安全专家会扮演攻击者的角色。通过模拟对设备的攻击，他们尝试触发最坏情况，以展示被攻击的可行性、涉及的工作量和可能的攻击路径。反过来，这种测试可以帮助制造商重新设计相关产品部分，并发现更多潜在问题。

由于渗透测试通常是一项限时服务，因此有效利用测试时间非常重要。如果你为设备安排了一场渗透测试，请务必明确以下3点：测试范围、最坏情况以及你希望进行的是黑盒、灰盒还是白盒测试。

测试范围

如果你没有为渗透测试设置明确的测试范围，测试人员可能会寻找进入设备的最简单方法。例如拆解设备，这与你预期的攻击模型可能相去甚远。

明确你的期望，包括物理攻击是否在范围内；哪些接口应该被测试，哪些应排除在外；是否允许对设备固件进行篡改。

明确测试范围并不是为了缩小测试范围以获得积极的测试结果，而是为了确保测试结果能够以最佳方式支持你的防护工作。

最坏情况

通常，你的设备会承载一些关键资产，一旦泄露，就会导致严重的损失。你最关心的是那些对这些资产有影响的攻击。最理想的情况是，你在早期的风险分析中已经识别了这些资产。如果你不明确这些关键资产，渗透测试人员可能会耗费数天时间尝试找到操纵图形用户界面（Graphical User Interface，GUI）的方法，而这一界面可能只用于内部系统。

黑盒/灰盒/白盒测试

黑盒测试假设攻击者对设备一无所知，这种测试在你想了解攻击者可以在短时间内收集到哪些产品信息时是有意义的。然而，进行数周的黑盒测试并不必要，因为这可能意味着你实际上是在为渗透测试人员支付费用，让他们对你已经知道的信息进行逆向工程。

提高效率的一种方法是分阶段进行测试。在黑盒测试几天后，测试人员可以提交初步结果，并提出可能的下一个步骤（如逆向工程）。此时，制造商可以提供有关协议、硬件和/或软件的信息，使测试人员能够继续进行渗透测试，而无须进行实际的设备逆向工程测试。你可以多次重复此过程，这不仅能节省时间，还有可能发现有价值的安全问题。

最后，不要忘记，对于像物联网设备这样的实体产品，其实施操作不是在开发团队的办公室里，而是在工厂的生产过程中进行的。选择安全的生产环境，保障设备在转移到生产现场过程中的安全，以及执行生产后测试以验证保护功能是否正确激活，这些环节都是确保设备安全运行的关键。

1.8　漏洞监测和响应

无论公司规模大小，无论你在组织安全开发流程方面投入了多少精力或你的工程团队有多么机敏，设备中隐藏漏洞的可能性始终存在。

有些漏洞可能是由开发过程中人为的失误导致的，有些可能源自第三方组件，还有一些漏洞可能是随着攻击工具和方法的进步而出现的，这些工具和方法是你难以预见的。如果你承认这一事实，那么最好的做法就是为以下阶段的有序运行做好准备。

1.8.1　漏洞报告

一些客户、渗透测试人员和安全研究人员会负责任地将他们发现的漏洞报告给制造商。然而，如果你的公司网站上没有列出安全联系信息，这些人可能难以将他们的发现汇报给关心安全问题的相关人员。他们可能会使用info@company.com联系，但这类邮箱通常收到大量邮件，安全问题相关的邮件可能会被忽视，导致你错过重要的漏洞报告。

在某些情况下，漏洞发现者可能会转向国家或国际安全组织，甚至媒体，以引起更多的关注，这可能并不是你希望看到的情况。为此，建议在网站上提供简单、可见的安全联系方式。此外，有些人可能会跳过联系制造商的步骤，直接将漏洞报告发布到邮件列表或漏洞数据库中。因此，监控这些来源对于早期识别和了解漏洞至关重要。

1.8.2　审查和评估脆弱性报告

漏洞报告可以是简短的电子邮件，也可以是详细的分析文档。在收到报告后，首先要审查它是否确实是一个安全问题，或者是否是设备的预期行为，抑或是研究人员可能犯了错误。如果你的产品确实存在漏洞，接下来的任务就是弄清楚漏洞存在的根本原因，建立对当前漏洞的内部认知，并进行风险评估。

1.8.3　修复或解决问题

如果问题来自可以更新的软件，你可以开发一个补丁，目标是尽可能彻底地消除漏洞，同时确保不影响设备的其他功能或特性。此外，你可以考虑通过重新配置设备来减轻漏洞的影响，甚至可以让客户自行完成这种配置。在某些情况下，硬件或无法更新的软件是安全问题的出处。这类问题处理起来非常棘手，可能需要物理访问设备，在极端情况下甚至可能需要召回产品。

1.8.4　测试

无论解决方案是软件补丁、物理返修还是配置变通方案，都必须在推广到所有现场设备之前进行测试。在某些情况下，更新可能会影响设备性能；在其他情况下，软件更改可能会将问题转移到设备的其他部分，从而产生新的漏洞。确保你的解决方案能够准确实现预期的修复效果。

1.8.5　公开解决方案

最终，你的解决方案需要发布给客户。根据行业标准、问题的严重性以及处理漏洞的效率，解决方案可能会在初次报告后的一周或一年内发布。然而，即便到了这一阶段，外界可能仍然不了解详细情况。确保你的解决方案附有详细的解释，清楚地向客户、管理员或操作人员说明需要采取的行动。如果你的产品涉及公众利益，你还应准备好应对媒体的提问。

1.8.6　避免今后出现问题

安全开发流程是一个持续改进的循环过程。每次发现的漏洞都应引发讨论，以便为开发流程寻找可能的改进方法，避免未来发生类似问题。

1.8.7　建立信任

与那些发现并报告漏洞的人建立信任关系对制造商大有裨益。这些人实际上是在支持你的安全开发流程，而他们并不在你的工资单上。定期清晰地沟通漏洞处理流程的状态至关重要。

根据发现的漏洞的严重程度和影响范围，你可以考虑通过奖励或安全漏洞赏金计划来表达感谢。但即便你认为报告的漏洞微不足道，表示感谢仍然是值得的，这样可以肯定报告者的努力，并鼓励他们未来发现更多关键的安全漏洞。

如果你仍然认为“我们的设备不会有漏洞被发现”，请考虑某人确实发现了漏洞时的后果。如果你没有准备好漏洞处理流程，可能会出现两种情况之一：设备漏洞可能得不到足够重视，因为没有人关心或承担责任，这可能会导致设备被攻击和造成客户损失；漏洞报告可能会导致团队中的每个人四处奔波，漏洞响应混乱无序，消耗精力和资源，最终也无法修复漏洞。

1.9　总结

本章总结了开发安全产品时，组织应了解的一些关键活动和流程。开篇我解释了，你可以从多个内容相似的指南中进行选择。微软公司和OWASP的建议主要针对软件产品，而IEC 62443-4则明确适用于可以被认证的工业组件。

所有安全开发流程的基本要求是，人们需要具备风险意识，并接受安全培训以应对日常工作中的安全需求。创建安全产品的关键是对资产、相应的保护目标、可能的攻击者、威胁以及相关的风险进行全面分析。通过结构化的方法，你可以实现透明化的流程、明确的信任评估与风险决策，并形成清晰可追溯的文档体系。

基于这些前期工作，你可以随后实施满足特定产品安全需求的工作，并设计个性化的安全架构。培养开发人员和工程师的安全实施习惯（如安全编程），并通过定期的安全测试检查实施效果。漏洞监测以及高效的漏洞响应流程将完善高质量产品的安全开发生命周期。

如果你有兴趣深入研究安全开发流程及相关方法论，可以参考洛伦·科恩费尔德（Loren Kohnfelder）的《软件开发安全之道概念、设计与实施》（Designing Secure Software）以及亚当·肖斯塔克（Adam Shostack）的Threat Modeling: Designing for Security。