嵌入式开发:DevSecOps为嵌入式安全带来深度防御

更新时间: 2021-11-24 10:25:31来源: 粤嵌教育浏览量:992

  虽然安全的应用程序代码本身不能在不安全的环境中提供足够的保护,但它确实在考虑安全性的系统中发挥着关键作用。无论首选的开发生命周期是什么,这都是正确的。因此,嵌入式开发团队越来越接受DevOps原则,而其他人则更喜欢传统上与功能安全标准相关的V型,如航空航天的DO-178C、汽车的ISO 26262和医疗设备的IEC 62304。


  从DevOps到DevSecOps进行纵深防御


  DevOps方法集成了开发和运营团队,专门用于应对不断变化的环境。DevOps为许多嵌入式应用程序带来了明显的好处。例如,通过更加集成的产品开发,可以更快地满足新的市场需求,也许最重要的是,应用程序补丁和更新(如汽车软件的空中传送(OTA)安全性)可以比其他方法更快地应用。


  DevSecOps代表开发安全操作,它以DevOps原则为基础,采用“左移”原则进行扩展,在每次软件迭代中尽早并持续地设计和测试安全性。


  纵深防御与过程模型


  传统上,安全嵌入式代码验证的实践在很大程度上是被动的。代码是根据相对宽松的指导原则开发的,然后进行性能、渗透、负载和功能测试,以识别漏洞。


  更主动的方法可以确保代码在设计上是安全的,这意味着一个系统化的嵌入式开发过程,在这个过程中,代码是按照安全编码标准编写的,可追溯到安全需求,并经过测试,以证明在开发过程中符合这些需求。


  这种主动式方法的一种解释是将安全相关的最佳实践集成到V型软件开发生命周期中,这是功能安全领域的开发人员所熟悉的。由此产生的安全软件开发生命周期(SSDLC)代表了专注于安全的应用程序开发人员的一个转变,确保漏洞是在系统之外设计的。




  左移:这意味着什么


  任何开发安全关键应用程序的人都应该熟悉“左移”原则背后的概念,因为多年来,功能安全标准要求采用类似的方法。因此,以下在功能安全领域得到验证的最佳实践也适用于安全关键应用:


  从一开始就确定需求


  未记录的需求会导致各方沟通错误,并造成返工、更改、错误修复和安全漏洞。为确保嵌入式开发顺利进行,所有团队成员必须以同样的方式了解产品的所有部分及其开发过程。明确定义的功能和安全需求有助于确保它们做到这一点。


  这些需求很可能为V-model开发人员定义一个完整的系统,而仅仅是应用DevSecOps的开发人员的一个迭代。然而,原则仍然是一样的。这并不是说软件永远不能用作“智能建模粘土”来创建概念验证,但此类实验的最终结果应该是明确定义的需求和适当开发的生产代码,以满足这些需求。


  提供双向可追溯性


  双向可追溯性意味着可追溯性路径可以向前和向后维护,而自动化使其在不断变化的项目环境中更易于维护。


  正向可追溯性表明,所有需求都反映在嵌入式开发过程的每个阶段,包括实现和测试。通过应用影响分析,可以评估变更需求或失败测试用例的后果。然后可以重新测试修改后的实施,以提供继续遵守双向可追溯性原则的证据。


  反向可追溯性同样重要,它强调了不满足任何特定需求的代码。否则,疏忽、错误的逻辑、功能爬行和恶意后门方法的插入可能会引入安全漏洞或错误。


  安全嵌入式应用程序的任何妥协都需要一个更改的或新的需求,并且需要对源代码开发工程师很长时间没有接触到的内容立即做出响应。在这种情况下,自动跟踪可以隔离所需的内容,并仅对受影响的功能进行自动测试。




  使用安全的语言子集


  对于C或C++的开发,研究表明大约80%的软件缺陷源于错误的使用语言的大约20%。为了解决这个问题,开发人员可以使用通过禁止有问题的构造来提高安全性和安全性的语言子集。


  两个常见的子集是MISRA C和卡内基梅隆软件工程研究所(SEI)CERT C,它们都帮助嵌入式开发人员生成安全代码。这两个标准的目标相似,但实施方式不同。


  一般来说,使用MISRA C开发新代码会导致更少的编码错误,因为它具有更严格、更可判定的规则,这些规则是根据第一原则定义的。参考MISRA C编码标准快速方便地分析软件的能力可以提高代码质量和一致性,并缩短部署时间。相反,当开发人员需要对代码追溯应用规则时,CERT C可能是一个实用的选择。针对CERT C分析代码可以识别大多数软件安全攻击背后的常见编程错误。


  应用MISRA C或CERT C都会产生更安全的代码。在任何规模的代码库上手动执行此类标准都是不现实的,因此需要一个静态分析工具。


  遵守以安全为中心的流程标准


  在安全关键部门,适当的标准经常补充那些注重功能安全的标准。如果需要,可以将自动化开发工具集成到安全关键系统的嵌入式开发人员工作流中,并同时满足功能安全需求。


  自动化SAST(静态)和DAST(动态)测试过程


  静态分析是涉及源代码自动检查的测试机制的总称。相反,动态分析涉及部分或全部源代码的执行。这些技术对安全问题的关注分别导致了静态应用程序安全测试(SAST)和动态分析安全测试(DAST)。


  在这些分组中有很大的差异。例如,渗透测试、功能测试和模糊测试都是黑盒DAST测试,不需要访问源代码来实现其功能。黑盒DAST测试是对白盒DAST测试的补充,白盒DAST测试包括单元测试、集成测试和系统测试,以通过动态分析揭示应用程序源代码中的漏洞。




  早测多测


  所描述的所有安全相关工具、测试和技术在每个生命周期模型中都占有一席之地。在V模型中,它们在很大程度上类似于通常与功能安全应用程序开发相关的过程,并与之互补。


  对于V模型,需求可追溯性在整个嵌入式开发过程中保持,对于DevSecOps模型,需求可追溯性在每个开发迭代中保持。


  一些SAST工具用于确认遵守编码标准,确保复杂性保持在最低限度,并检查代码是否可维护。另一些用于检查安全漏洞,但仅限于在没有执行环境上下文的情况下对源代码进行此类检查。


  白盒DAST使编译和执行的代码能够在开发环境中进行测试,或者更好地在目标硬件上进行测试。代码覆盖有助于确认代码满足了所有安全性和其他要求,并且所有代码都满足了一个或多个要求。如果系统的关键性需要,这些检查甚至可以进入目标代码级别。


  健壮性测试可以在单元测试环境中使用,以帮助证明特定功能是有弹性的,无论是在隔离环境中还是在其调用树的上下文中。传统的模糊和穿透黑箱DAST测试技术仍然是有价值的,但在这一背景下被用来证实和证明系统的健壮性和安全性。


  为自动化工具的安全性铺平道路


  在开始软件开发过程之前,嵌入式开发人员应该能够使用自动化工具,例如测试软件,以加快开发、认证和批准过程。使用这些工具在整个生命周期中支持他们的工作,同时遵循与“左移,尽早测试”方法相关的最佳实践,有助于提高连接嵌入式系统的安全性,这些系统将继续为行业带来如此重大的变化。

免费预约试听课

推荐阅读