物联网（IoT）应用在将外围传感器、网关和云资源结合起来的同时，也将遭到前所未有的攻击，因为这会引入大量潜在的攻击面和安全漏洞。随着IoT应用与企业基础设施的关联愈发紧密，这就需要对这些威胁、所引发的可能性及影响有一个清楚的了解。通过有条不紊的对威胁和风险进行评估，开发团队可以在必要时加强安全性，或者对可接受的风险做出明智的决策。
连接系统中广泛存在的安全漏洞已被频频报道。即使是快速浏览新闻头条，也可以看出攻击范围之大，从公开的大规模分布式拒绝服务（DDoS）攻击到极为隐蔽的高级持久性威胁（APT），这些威胁会驻留并悄悄地提取有价值的数据，或为更极端的攻击做准备。
这些耸人听闻的攻击让我们意识到，使用安全机制和创建安全系统不是一回事。黑客能成功侵入各种安全机制构建的系统，即使是最注重安全性的开发团队也可能会在设计中不知不觉地留下开放式攻击面。
事实上，当今设计的复杂性导致可利用的开放式攻击面增加，特别是诸如IoT应用的多层连接系统。当大量不同类型的可编程设备连接到云时，端到端的安全性就更像是一种统计概率问题，而不是绝对的确定性。在这样一个相互关联的系统体系中，每个元件不仅可提供特定功能，还会引入一组安全漏洞。
通过充分了解每个漏洞如何对整个应用造成威胁，企业可以判断出该漏洞所来的风险是否超出了可承受范围，以及是否需要进行后续缓解。
这种预测风险的能力所具有的战略价值是难以尽述的。同时，通过将安全漏洞与风险评估相结合，开发团队可以设计出一个战略路线图，开发一种实用的方法来帮助连接系统应对几乎源源不断的威胁。事实上，如果没有通过威胁和风险评估获得较高的认知，即使是最有经验的开发团队也不敢完全保证系统和应用的安全。然而，要获得这些知识，首先要构建一个有据可查的威胁模型，以便清楚地了解系统所面临的潜在威胁。
威胁模型可以捕获与系统设计相关的特定安全漏洞。从理论上看，创建威胁模型可以说是很简单，比如，开发人员通过分析设计，就能识别与每个底层组件相关的安全漏洞。然而，我们会发现在实践中，威胁建模所涉及的工作、研究和策略远远超出了最初的想法，而且还会带来一系列技术安全问题。在广泛应用后，威胁建模还可以识别与物联网应用相关的生命周期和总体安全策略中的漏洞。最后，可接受威胁模型的内容可能会随着它们所服务的物联网应用和组织的不同而变化。即便如此，不同的威胁模型也有某些共同的特点，任何威胁建模方法都会遵循一些共同的步骤。
威胁建模
威胁建模首先是对系统的准确描述，即所谓的评估目标（TOE），与特定的用例相关，例如公用水表的操作。如果说威胁模型描绘出了系统漏洞的画面，那么TOE描述就是画布。通过扩大或缩小TOE范围，威胁建模团队可以在威胁识别过程中扩大或缩小关注点。例如，Arm最近发布的智能水表威胁模型严格地限制了它的TOE，只关注系统核心（图1）。
当然，将TOE限制在更大、更复杂的系统或应用的一个子系统中，意味着识别威胁、评估风险和构建有效缓解计划的能力就会受到限制。对于物联网应用等复杂系统，经验丰富的威胁建模师可能会创建一系列威胁模型，从对整个系统非常的抽象描述到对组织具有特殊意义或需要关注的子系统日益详细的描述。
无论采用何种方法，都不会对TOE描述的详细程度提出绝对要求。旨在提供每个组件详尽细节的建模方法可能会耗尽流程参与者的所有精力。另一方面，过于抽象的模型可能会隐藏微妙的漏洞，或阻止识别深深隐藏在依赖关系链或第三方软件库中的漏洞。
一种有效的折中方法就是只收集所需的详细信息，以捕获在系统的特定独立区域之间跨“信任边界”的所有交互（图2）。
例如，物联网应用可以包含多个与云资源、网关、物联网终端设备和用户链接的区域。跨信任边界操作的事务特别容易受到一系列针对传输数据、安全凭证或协议的异常攻击。即使是看似无安全问题的跨信任边界的通信尝试，也会为“指纹”攻击创造一条路径，黑客会利用系统响应中包含的已知指示器来确定系统的底层组件，为更直接的攻击做好准备。
当然，如果其中一些组件来自第三方，那么理解每个区域底层组件之间的交互就变得尤为重要。例如，使用第三方传感器驱动程序的物联网设备，会受到驱动程序边界的威胁（图3）。
虽然适当的详细描述对于威胁建模是必不可少的，但却无法识别与这些详细信息相关的特定威胁。在Arm的水表威胁模型中，建模者提供了与每个资产相关的威胁简表，如固件、测量数据以及与可能触及TOE的外部实体（如用户、管理员和攻击者）的交互信息。
对于固件来说，该模型可以描述特定威胁，包括安装受损固件、修改用于验证固件更新、克隆等的相关安全证书所带来的威胁。开发团队可以根据资产和已识别漏洞列表，列出一组相应的安全目标和缓解方法。例如，Arm的水表模型最后列出了一系列包括针对固件的安全需求，例如需要安全引导、固件验证、对验证失败的响应等。
可用资源
在识别潜在威胁时，很少有开发组织能够实时识别其TOE描述中的详细资产和流程可能会面临的每一个潜在威胁。然而工程师可以利用一些公开的资源来完成这部分操作。开发人员可以利用公共资源，如通用攻击模式枚举和分类（CAPEC）列表，自上而下地审查最可能的攻击类型。然后，自下而上地识别公共弱点枚举（CWE）列表中列出的可能攻击目标，该列表描述了系统设计方法中固有的缺陷，例如使用硬编码凭据时。设计人员在确定其设计中使用的特定硬件或软件组件时，可以求助于通用漏洞披露（CVE）列表，该列表列出了可用硬件或软件组件中的特定软件缺陷或潜在漏洞。
对于风险评估，通用脆弱性评分系统（CVSS）等资源为评估与特定脆弱性相关的风险提供了一致的方法。虽然风险与特定漏洞的性质有关，但它也包括其他因素，例如用于执行攻击的途径（向量）、利用漏洞所需的攻击复杂性等。例如，通过网络执行的攻击比物理访问攻击带来的风险要大得多。同样，简单的攻击比高度复杂的攻击具有更大的风险。使用CVSS计算器，工程师可以快速计算出这些不同的影响因素，得出与特定威胁或威胁类别相关的风险等级的分数值。对于Arm水表，CVSS计算器计算出固件攻击所涉及的因素具有9.0的临界风险值（图4）。
由于广泛的需求和技术问题，带动了各种自动化工具的出现，如开源Web应用程序安全项目（OWASP）Threat Dragon项目、Mozilla的SeaSponge和Microsoft的威胁建模工具，以帮助开发人员借助于建模工作。每种工具都采用不同的威胁建模方法，从Threat Dragon项目和SeaSponge中的系统图到Microsoft的详细STRIDE（即“欺骗”、“篡改”、“拒绝”、“信息披露”、“拒绝服务”和“特权提升”）。尽管这些工具已经有好几年的历史，而且通常是为企业软件系统构建，但是威胁建模是一个广泛适用的持久过程，更多地依赖于当前的攻击向量、弱点和漏洞列表，而不是特定的方法论。尽管如此，还是一直有新的工具不断涌现，有望在系统描述和威胁识别之间建立更紧密的联系。然而，尽管深度学习技术在快速占领其他领域，但在将这些技术应用于自动威胁和风险评估方面仍然存在重大挑战。即便如此，智能建模和评估工具仍将很快被广泛应用。
同时，开发人员还可以找到包含安全弱点、漏洞和攻击模式的各种列表，以至于信息量过于庞大，特别是对于那些刚刚开始进行威胁建模的人来说。事实上，过于复杂也是不进行威胁建模的常用借口之一。工程师们可以利用较为温和的方法，专注于最常见的威胁，而不是深入到细节。截至本文撰写之时，OWASP仍在回顾其2018年的10大物联网安全漏洞，而其之前的10大物联网安全漏洞列表也非常有用。也就是说，开发人员只需在他们常用的资讯网站上找到这些漏洞和攻击的现成目录即可。
然而，对于能够快速突破基础攻击的组织来说，也可以将这些方法用于解决物联网设计中的安全相关问题。例如，机器控制回路中使用的系统通常面临与功能安全相关的任务关键型需求。在这类系统中，防护和功能安全交织在一起，因此威胁模型可能需要考虑到防护或安全方面的漏洞会造成人身安全风险的情况。同样，防护和隐私也在许多方面有重叠之处，任何一方的漏洞都可能导致个人身份信息泄漏。
结论
威胁建模和风险评估在复杂系统中的有效应用远远超出了可用选项和技术的任何简单列表。与每个特定系统一样，每个开发组织都拥有自己独特的约束机制和能力。在满足某个系统或组织的需求的同时，可能会完全忽略另一个系统或组织的需求。唯一共同的要求可能是需要先进行威胁和风险评估。即便如此，企业是否应该尝试创建一个“完整”的威胁模型和风险评估呢？答案是否定的，因为这种尝试并不能得到一个完美的结果。
世界自然混乱的进程，系统漏洞缓解与黑客利用之间的抗衡，最终使任何追求完美的尝试都无法实现。但如果不根据威胁模型和风险评估建立安全路线图，将无法避免导致常见安全漏洞的一些陷阱和弯路。
在电子行业有20多年的写作经验，涉及广泛的主题，包括硬件、软件、系统和物联网等应用。他获得了神经网络神经科学博士学位，并在航空航天行业从事大规模分布式安全系统和算法加速方法的研究。目前，他在写技术和工程方面的文章的闲暇之时，还在研究深度学习在识别和推荐系统中的应用。
该发布文章为独家原创文章，转载请注明来源。对于未经许可的复制和不符合要求的转载我们将保留依法追究法律责任的权利。
