测试和分析工具有助于验证和实施军事系统的安全性

作者：CHRIS TAPP，JAY THOMAS

经过适当测试和验证的安全编码实践有助于确保军事系统的可靠和安全运行。组织应从头开始，结合使用静态和动态分析、单元和集成测试以及需求可追溯性。

军事系统中的安全漏洞可能是毁灭性的。具有严重后果的安全中断的一个例子是据称在2011年由中央情报局在伊朗上空捕获的美国RQ-170无人机（UAV）。据伊朗称，该飞船被伊朗网络战部队安全降落，并设法接管了它。断言是，无人机是通过干扰卫星和陆地控制信号捕获的，随后是GPS欺骗攻击，该攻击向无人机提供虚假的GPS数据，使其降落在伊朗，无人机认为是其在阿富汗的大本营。

虽然实际细节可能永远不清楚，但似乎无人机确实受到了损害，以至于它可以安全地降落在伊朗境内，并被敌人拥有以进行可能的逆向工程。该无人机软件中的某些内容允许访问系统的至少一部分，这显然打开了对其重要内部的访问。

保护嵌入式系统

嵌入式系统现在渗透到军队中，从车辆控制、通信、武器控制和制导到自主和半自主系统，包括无人机和类似飞行器。这些设备现在相互连接，用于控制和协调目的。为了人员安全、完成任务的能力以及通常的国家安全，这些设备必须对其操作员安全且操作可靠。此外，它们必须免受未经授权的访问和攻击。如果它们不安全，则不能认为它们是安全或可靠的。因此，对安全性、可靠性和安全性的要求是不可分割和相互依存的。

这些要求不能是事后的想法，而必须从头开始构建。它们还经常要求软件遵守某些编码准则，如MISRA或CERT C，并且必须遵循工业或政府规定的标准，如DO-178C。随着这些系统越来越受到认证要求的约束，必须证明和记录编码和功能的正确性。

尽管有许多策略可用于实现安全性，但仍有必要确保这些策略也正确编码 - 无论是在编码标准方面还是在整个应用程序中的正确功能方面。传输层安全性 （TSL） 等传输协议 – 这是对安全套接字层 （SSL）、安全文件传输协议 （SFTP） 和其他协议的改进 – 现在被广泛使用，但通常从组织外部获取。其他策略可能包括使用安全设备驱动程序、远程实施安全和加密固件升级的过程，以及个人验证协议，如密码、视网膜扫描和射频识别 （RFID） 芯片，以确保访问安全。其他分层安全策略仅允许对系统部分进行选定访问，但这些策略也可能引入漏洞，如果未检测到，这些漏洞可能会被利用。

过去，组织可能已经能够通过手动代码审查和软件演练来检查其代码。然而，当今关键程序的规模和复杂性使得使用这种方法和手段无法确保完整的分析。需要一套新的测试和分析工具及方法来满足当今的安全要求。

建立和实施安全性

当今全面的工具套件在单个开发环境中集成了用于测试、分析和验证的工具。使用工具环境还可以帮助在组织内建立一种规范的方法，该方法可以帮助团队协作，即使他们可能在不同的位置工作。

为了满足认证或资格要求，实现双向需求可追溯性的工具（从需求和设计到实施、验证活动和工件）可以使组织与竞争对手区分开来，并确保获得设备批准的最短路径。需求管理工具允许团队处理单个活动，并将代码和验证工件链接回更高级别的目标。

需要基于需求文档的双向可追溯性，以确保一个或多个低级别需求涵盖每个高级需求，并且每个低级别需求都可以追溯到高级需求。

除此之外，还需要这些工具来执行基于静态分析、动态覆盖分析和单元/集成测试的广泛基础测试。这些结果有助于确保安全性、功能安全性和符合编码标准，以及跟踪需求并通过广泛测试确保它们是否实际按预期运行的能力。

静态和动态分析：安全合作伙伴

在确保安全方面，两个主要问题是数据和控制。设计人员必须考虑谁有权访问数据、谁可以从数据中读取/写入、数据如何流动以及不同级别的访问和控制。为了解决这些问题，静态和动态分析必须同时进行。

在静态分析方面，这些工具使用未编译的源代码来检查代码与所选规则，这些规则可以是支持的标准以及开发人员或公司可能指定的任何自定义规则和要求的任意组合。这些工具还可以查找可能危及安全性的软件结构，检查内存保护以确定谁有权访问内存的哪些部分，以及跟踪可能遍历内存位置的指针。为了获得最佳结果，信息应以图形屏幕显示，以便于评估，以确保符合编码标准。

动态分析测试编译的代码，该代码使用编译器生成的符号数据链接回源代码。动态分析，尤其是代码覆盖率分析，需要大量的测试。开发人员可能能够手动生成和管理自己的测试用例（生成测试用例的典型方法），从需求文档开始工作，该过程可能会以不同程度的有效性刺激和监视应用程序的各个部分。然而，鉴于当今代码的大小和复杂性，这种方法通常不足以获得某些必需的认证。

图1：LDRA 工具套件的动态分析功能可生成基于当前测试运行的变量和参数使用情况报告。该报告突出显示了文件中使用该变量的文件和位置，并使用自定义筛选器进行了更精细的测试。

安全性需要对功能漏洞进行严格而彻底的测试，以及遵守正在运行的应用程序中的编码规则和指令。如果覆盖率分析要求包括语句或分支/决策覆盖率、过程/函数调用覆盖率，或者在更严格的环境中，修改条件/决策覆盖率 （MC/DC） — 则这些通常需要源代码和目标代码分析。它还可能需要自动生成测试，作为衡量测试有效性的一种手段（图 1）。

自动测试生成基于代码的静态分析，并在动态分析期间使用此信息来确定对应用程序中软件组件的适当激励。基本边界值测试的这一支柱可以通过从需求文档手动创建的功能测试轻松扩展。这些应包括任何功能安全测试，例如模拟尝试访问控制设备或向其提供会改变其任务的错误数据。此外，基于创建的测试的功能测试应包括稳健性，例如测试不允许的输入和异常条件的结果。

深入了解代码

发现安全漏洞可能涉及更微妙的问题。例如，存在与“死”代码区域相关的危险，这些代码可能被黑客激活或系统中的模糊事件用于恶意目的。尽管从头开始实现安全性是理想的，但大多数项目都包含预先存在的代码，这些代码可能没有经过与当前项目相同的严格测试。静态和动态分析一起使用可以揭示死代码区域，这些区域可能是危险源或可能占用所需空间。

区分真正死代码和很少使用的代码的能力是双向需求可追溯性很重要的另一个原因;为了能够检查应用程序中的代码是否满足需求，还可以从实际代码中将代码追溯到实际需求。如果这些路由都没有显示连接，则代码肯定不属于那里。

因此，静态分析的功能是分析源代码以获得正确的编程实践，还可以帮助为覆盖率测试、功能测试、控制和数据流分析设置动态分析。后者对于突出和纠正潜在的问题领域并产生软件质量指标至关重要。

为满足机载或作战系统的严格安全要求而开发的公司可能需要展示对数据流和控制流的分析，以进行软件认证。在根据DO-178C认证机载软件和系统的情况下，需要在对象级别进行验证。这涉及将源代码级别的代码覆盖率与目标代码级别的代码覆盖率相关联的能力。在某些情况下，可能还需要提供在汇编程序级别扩展代码覆盖率的机制。此扩展对于 DO-178C A 级认证特别有用，其中软件故障可能导致飞机损失和/或生命损失。

从单元测试开始并发展项目

除非可以从头开始进行测试，否则从头开始考虑和开发安全性没有多大帮助 - 这包括在目标硬件可用之前在主机开发系统上进行测试。在这个阶段，没有人在谈论项目接近完成的阶段，因此通常可以进行早期单元测试，然后进行集成测试，因为任务来自不同团队或开发人员。

此方法也适用于可能从头开始编写、从其他项目引入、作为商业产品购买或作为开源获得的代码部分。即使是内部代码也需要检查，因为它最初可能没有经过相同的分析。使用单元测试工具的决定归结为商业决策：产品开发中发现缺陷的时间越晚，修复成本就越高（图 2）。

图2：在开发周期的后期，修复缺陷的成本急剧增加。

可以在不考虑硬件时序的情况下完成主机上的功能测试，在某些情况下，可以在具有模拟连接的外围设备的基于主机的虚拟目标上执行。在主机上执行的相同测试也必须在目标硬件上执行，以确保正确的功能测试。

将全面的测试和分析框架应用于组织的开发过程，可以大大提高安全措施的彻底性和准确性，以保护重要系统。

审核编辑：郭婷