【安全开发系列】铸范篇：把安全渗透到软件之中

★

铸范篇：

★

剑范多用泥塑造，入窑中经火烘干，质地似陶，故称泥范或陶范。制范以铜剑的器形设计为依据，而铜剑器形是否能够达到设计要求，规整而谐调、匀称而美观，则决定于制范是否精细。 制范还要为以后的装饰打下基础，如剑体上铸出的花纹和名文，都必须预先在剑范的内壁上刻镂出阴阳相反的纹路。

01

前言

在《序章》中已经明确了做安全开发的核心思路以及一些基本的概念点：

1、团队所有人能对安全负责

2、通过一套明确的机制或者安全工程生产安全的软件

3、高效

其中的安全工程，是我们后续系列文章需要重点考虑的，但是有个问题，我还没解释——为什么选择安全规划能力、安全实现能力、安全验证能力、安全数据分析能力这四项能力作为分类的依据。

这四项能力其实就是我们一般做事方法的映射。计划怎么做一件事，实际怎么去做，怎么检验做得如何以及怎么总结和提高。如果熟悉的话，会发现这其实就是我们所说的质量管理的思想基础和方法依据——PDCA循环。

围绕质量管理基本思想来对软件的安全质量管理进行框架指导。

PS: 上文中关于DevSecOps中三团队排序，在写完重新阅读时，感觉有些武断而且会造成歧义。是不是运维以后不怎么需要做或者不重要，结果显而易见是否定的，不然会是DevSec 而非 DevSEcOps。

Ops的工作更多是由工具、脚本来替代，保证了一致性，避免偶发性人工错误，它是象征软件真正活着而非死的重要表现之一。

而Dev和Sec的工作中人工参与成分更多，不确定性更高，相较于Ops而言，人的工作量会更多。 

这仅仅是我个人对于这个概念的理解，如果大家对于这个概念有其他认识也可以，我想我们更多的是关注概念之下的本质，以及这些如何为我们所用。

本章节主要围绕其中的安全规划能力进行介绍分析，我们如何把安全渗透到软件之中。

02

概念

PDCA

PDCA循环是美国质量管理专家休哈特博士首先提出的，由戴明采纳、宣传，逐渐得到普及，所以又称戴明环。

全面质量管理的思想基础和方法依据就是PDCA循环。PDCA循环的含义是将质量管理分为四个阶段，即Plan(计划)、Do(执行)、Check(检查) 和 Act(处理)。

在质量管理活动中，要求把各项工作按照做出计划、实施计划、检查实施效果，然后将成功的步骤纳入标准，不成功的留待下一循环去解决。这一工作方法是质量管理的基本方法，也是企业管理各项工作的一般规律。

威胁、风险

威胁： 更倾向于事物的某项属性。例如：虫吃叶子，叶子上会有虫子。

风险： 在威胁的属性基础上结合了概率，可能会如何或者多大的可能性会如何。

STRIDE方法论

由微软开发的威胁建模方法。STRIDE对应了六类安全威胁，分别是Spoofing(假冒)、Tampering(篡改)、Repudiation(否认)、Information Disclosure(信息泄露)、Denial of service(拒绝服务)以及Elevation of Privilege(提升权限)。

03

安全规划能力

在具体讲安全规划能力之前，我想先把软件开发生命周期的概念放到一边。

一般来说，我们在软件开发生命周期里面去讨论安全规划，必然离不开安全需求、安全设计等一系列的具体环节，甚至需要考虑如何与原有的需求分析、软件设计结合以及前后关系，但是这些其实更多偏向于如何去组织这类规划相关的活动。

所以，这次我们暂时先搁置关于流程的探讨，聚焦到安全规划本身，尝试去回答：满足什么要求的软件，它的安全质量才是靠谱的，以及为了达到这样的要求，需要做些什么以及怎么去做。

安全威胁

我读大学时有一个说法——如果什么也不做，其实就是安全的。

如果做了些什么，那么风险就不可避免地进来了，风险能被转移或缓解，但是无法根除。然而什么都不做，几乎是不可能的，尤其是在信息化数据化越来越深入的当下。既然是因为引入了什么而带入安全风险，那么我们是否就可以对引入的东西进行分析，在实际引入之前就了解风险，从而设计和规划相应措施呢？

显然可以，正式点说，这些都叫安全威胁，是伴随事物发生的固有属性，就好比"常在河边走，哪能不湿鞋"（在河边走面临湿鞋威胁）。

围绕安全威胁进行分析，相当于从外面的角度来看，我们面临哪些摧毁我们自己的可能情况，从而针对这些可能性进行响应，了解到我们到底应该做些什么以避免被摧毁。

当然，除了安全威胁以外，法律方面的安全威胁同样重要，但是在整个操作和实现上与安全威胁区别不大，关键在于对法律和规范条文的解读，所以下文不再单独区分安全威胁和法律方面的威胁，进行统一处理。

威胁分析

在这条思路上，我们可以首先看到以下几个对象需要进行梳理：

1、可能性情况有哪些，即安全威胁有哪些？

2、与威胁绑定的事物有哪些？

从事物出发推导威胁，从威胁出发反向推导事物，就是构建威胁分析的主要途径。

STRIDE

前者主要象征了一系列的威胁建模分析的方法论（也包括攻击面的分析方法），而这类方法论中又以微软提出的STRIDE最为知名。

STRIDE从某种程度来说，实际上是对安全威胁进行分类，从对系统的最终影响方面划分为假冒、篡改、否认、信息泄露、拒绝服务和权限提升，所以与我们一般而言的安全威胁，诸如SQL注入、盗号等有所不同。其根本目的是为了帮助我们系统地分析某个事物所面临的安全风险，结合某个具体的业务场景，就形成了更具体的威胁，例如信息泄露这类威胁在系统通信过程中可能表达为窃听。

严谨地分析过程固然不错，但是在实际使用这项技术时，如果对每个事物都进行如此详尽繁复的分析势必会导致投入过大。另外应用一项方法论分析事物，也不是那么轻松容易的事情，在推进上必然会面临来自资源（时间、精力）和人才两个方面的阻力，更何况里面包括大量重复性工作。

这并不符合我们高效、高复用的理想，如何有效积累这些已经完成的模型和降低分析的难度都是我们要解决的问题，而这两点基本上可以基于知识库和二次封装解决。通过这两项的积累，分析工作更多会变成如何组装和扩展工具，这与现代软件系统研发有异曲同工之妙，通过框架和组件快速完成业务系统开发，甚至可以依托产品线更快更好地完成研发任务。

PS: 攻击面分析也可能纳入到这个部分，就是知识的集合。

误用分析/反向测试/攻击分析

后者更多的考虑是反向思路——遗漏了什么。从事物出发推导威胁，更多是从整个面出发，全面性毋庸置疑，但是难免在细节上会有遗漏，而积累这些误用的例子（或者说被遗漏的威胁）对于整个面补充是十分必要的，也是从60分走向80分乃至满分的关键。

后者更多的考虑是反向思路——遗漏了什么。从事物出发推导威胁，更多是从整个面出发，全面性毋庸置疑，但是难免在细节上会有遗漏，而积累这些误用的例子（或者说被遗漏的威胁）对于整个面补充是十分必要的，也是从60分走向80分乃至满分的关键。

事物

具体分析的事物，可能最终决定了我们最终输出的成果是什么样的。如果仅针对系统进行分析，我们能够提供的便只是系统层面的结果，如果我们能够深入业务，那么就能够提供业务层面的威胁情况，系统层面的威胁情况可以通过业务层面的组成被还原出来。

从信息量的角度可以说，颗粒度越小，能够组装的东西就越多，能够提供的信息就越多，缺点就是细节信息过多，需要对信息进行归纳和总结，同时颗粒度变小，说明需要分析的事物就越多，分析的工作量也会变大。也有一个比较关键的好处就是，有了初期工作铺垫以后，可以快速组成得出其他结果。

通过上述的一系列方法，理论上来说，我们其实已经知道了到底面临哪些外部威胁，只需要针对这些威胁逐条构建风险转移和风险降低措施即可，也就得到了第一个问题——我们应该做些什么而免于被毁灭的答案。

威胁处置实践

既然已经了解了到底要做成什么样，那我们又该如何把这些要求折现融入到软件中呢？

融入过程实际上就是实现需求的过程，而软件研发过程本就是实现需求的过程，那意味着我们完全可以通过研发管道来实现安全的要求。当然融入管道自然需要符合研发管道原来的特征，所以安全的要求需要与一般的业务研发需求在颗粒度方面保持一致，对于一些粗颗粒度，我们可能需要人工介入进一步拆分，使其形成更加具体的结果，例如针对某个具体业务功能或者接口。

不过这一点对于实施人员的能力要求也很高，他需要懂安全威胁，更需要懂安全威胁到底从何而来。我想可能正是由于人才资源和需求拆解的矛盾难以调和，才导致很多人怀疑SDL方法无法满足软件对于安全的需求。

另外还有一点是我在接触很多客户时发现的一个误区:

最终安全需求的条目数越多越好。

其实不是这样的，应该是在满足我们对于软件安全质量要求的前提下，尽可能减少安全需求的条目数量。只有足够少的数量才足够明确，方便落地，就好像石头剪刀布一类的游戏一般，规则简单粗暴，不需要投入太多的沟通成本，简单一句话——石头赢剪刀，剪刀赢布，布赢石头，就轻易构成了游戏的规范。

04

安全规划能力产品/工具

上文已经从理论层面上探讨了我们可以如何做，但是现实面对的问题是哪怕我们能够无限投入，也没有办法拥有如此多的复合人才，也没有办法让这些人才拥有无限精力，更没有办法让这些人才像机器一样的工作。

无论是将凡人塑造成天才，还是提升效率，我们都需要工具！

对于工具而言，除了整合相关的安全知识以外，更重要的是能否运用知识。

微软 Threat Modeling Tool / Owasp Threat dragon

无论是微软的Threat Modeling还是OWASP Threat Dragon，都是通过绘制类似于以数据流图的方式，分析所需要执行的安全需求，图例如下：

通过绘图明确了组件与组件的关系后，即可匹配知识库，获取我们想要的结论。

不过既然是辅助工具，必然有一定的门槛，它对于使用者是有一定要求的——熟悉整体软件系统架构、软件部署运行以及辅助工具的工作机制。

同时工具内置的模板和组件，更多的是针对整个软件应用系统进行分析建模，即分析事物选择了系统，通过这类建模工具，我们可以在系统层面上获知所要达到的安全目标。

但是系统层面到落地实践，还有许许多多的路要走，这两款工具也提供很多自定义模板和组件的功能，通过调整深入到软件内部在技术上还是可以实现的，不过局限性也在的，它更多是在架构层面进行分析，有点难以深入业务和研发工作，需要在后续研发流程中慢慢细化。

从个人感觉上，它更适合做一些自研成分比较高，规模比较大的系统，而且可能更多适应于一些基础设施系统分析，而非业务系统分析。

安恒安全开发一体化平台天璇子平台

这是公司自研的一款产品，属于安全开发一体化平台的一部分，在技术选型上没有走架构分析方向，而是选择了业务分析方向。

避开了架构分析，实际上就避开了绘图方面的高门槛，天璇工具以业务功能为切入点，通过常规技术业务重组成了具体的某个功能业务，从而获得该功能的分析结果。

这样的方式将技术门槛迅速降低，与本身的业务实现分析工作相融合，大大提升了效率。另外将事物的颗粒度下沉到了业务功能以及技术业务，提升了实施环节任务的精细层面，当然伴随着的副作用，是全局性视角的弱化，虽然通过组合所有业务功能在系统层面重新还原出系统层级的要求，但是对于架构方面分析的缺失还是难以弥补的。

个人感觉上，它会更适合去做一些业务系统分析，快速形成业务功能的安全要求，分发到各个业务功能的责任人，责任人推进在业务功能下的相关要求。

难点

这类辅助工具的另一个难点，而是在于如何管理威胁的知识，对于这些知识做维护和管理，同时这些知识又如何能与我们企业自身的现状完全匹配，过犹不及！

05

总结

本章节主要就是为了介绍如何明确软件需要达到的安全性目标的方法和工具，从另一方面也想表达威胁建模知识库也好、STRIDE也好都是中间的工具和方法，我们不能被工具所限制了，为了使用什么技术方法而使用，更多的应该关注在我们想要什么。这样，我们的思路可能会更加宽广，本文也算是抛砖引玉，至少我觉得未来在这个方面能做的还很多，或者说在整个安全开发方面能做的还很多。

06

预告

安全开发系列-安全实现能力（烧刃篇） 

在想明白我们要做哪些事情以后， 具体如何去实现才决定了我们最终看到的成品质量以及我们能否顺利的推进。

纸上得来终觉浅,绝知此事要躬行！

往期精选

围观

热文

热文