管理、技术、人员、考核多管齐下 解决企业SDL落地难

2018年11月1日

企业SDL的现状


      安全团队的“尬位”

在企业安全实践过程中,安全和编码是紧密结合的,因为企业自身所产生的安全漏洞都来源于企业自己的代码。但在90%的企业中安全团队是独立存在的,这就导致了研发团队只有在需要安全的时候才会想到让安全团队介入整个研发过程。

     在过往的产品研发和迭代中,研发团队最优需要达到的是产品的功能性目标,有些时候甚至会选择牺牲安全性来达到某些性能指标,因此安全容易作为迭代的阻碍而存在,不易受到研发团队快速迭代的欢迎。


     研发团队的安全“缺位”

     80%的企业研发人员并没有接受过安全编码培训,缺乏基本的安全意识,这会导致两个结果,研发人员无法写出安全的代码,研发人员对安全的介入持反感的态度,认为破坏了研发的整体秩序。

     SDL自动化程度低,流程冗长复杂会让整个迭代过程拉长,并且由于SDL工具误报高,覆盖率低导致安全产出并不明显,让研发团队对SDL失去耐心,最终逃避甚到放弃采用SDL来提高产品安全性。


管理层面可以采取的策略

     

     管理层面要解决的是文化隔阂和物理边界的问题。


1.jpg

     打破文化隔阂 建立统一的目标感

     让所有人认识到安全是大家共同的目标,每个人都要为安全负起责任,具体的落地可以通过培训、风险意识教育、绩效共担、Top-Down的方式来进行。


     团队安全价值观的打造

     企业在推行SDL的过程中,发生各种冲突是在所难免的。但每个研发团队总有价值观比较正面积极的成员,或是团队leader,或是架构师,在刚开始的阶段,安全团队通过与这类同事合作,甚至可以考虑适当让出部分业绩给对方,让对方有足够的动力去配合安全团队开展SDL的工作,之后逐步认识到并认可安全的价值,进而影响和帮助整个团队形成统一的安全价值观,最后才能把SDL更好的推广开来。


     打破物理或组织边界

     打破物理边界的最好做法,就是安排安全团队直接和研发团队坐在一起,每天实时沟通安全问题,响应研发的安全需求,让大家认识到安全与研发是捆绑在一起的,需要共同承担安全的结果,物理上的边界就会慢慢被打破。

2.jpg

     当遇到问题时,应该站在更高的角度来分析和解决问题,组织边界上的团队都需要更勇于承担安全的责任,抱着把锅甩给别人的想法不利于SDL的推广。很多时候,研发团队不是不愿意承担结果,很大程度上是没有能力承担结果或是不愿意独自承担结果,需要从组织全局观的视角来分析存在的问题,统一思想后找到各自的定位,找到解决问题的路径,而不是一味指责和甩锅,导致双方互相不认可。


技术方案层面可以采取的策略


在SDL自动化的问题上,核心目标是降低人力成本,提升检测准确率,降低召回率。 

SDL技术方案建设的部分一般有安全需求分析(威胁建模 )、代码安全检查(白盒)、黑灰盒安全测试(黑盒)、上线安全审查(SDL流程建设)、线上安全监测(逃逸SDL应用检查)。


3.jpg


威胁建模系统的自动化要求比较低,更多地是需要丰富的应用checklist,能满足企业的常见业务场景,保障安全需求分析及评审的效率,并在解决方案上具备一定的成熟度,对于新兴的业务场景能灵活调整,给出较完善的解决方案。

白盒检查需要配合好安全培训工作,把代码安全规范一开始传播给研发人员。代码安全规范不应太过于通用,应根据企业的应用特点、开发语言、安全风险类型,以及研发人员的水平制定。制定的代码安全规范应能很好的配合白盒工具制定检查策略,降低误报率,提升发现效率,同时应明确代码安全的解决方案。

白盒工具应遵从DevOps迭代要求,与代码仓库工具和集成工具能结合,研发人员能预操作,降低使用难度。白盒检测出来的问题除了使用代码修改外,更多地应依赖框架来解决,比如注入、XSS、CSRF等应更多考虑在框架层面统一解决。 

黑盒检查是预发布之前的最后一环,是准确率最高的阶段。黑灰盒工具首先要保障的就是对功能点的覆盖率,确保能从攻击者的角度发现更多的问题。保障这两点首先要结合测试的工具提升覆盖率,发现每一个功能点和输入点,尽可能尝试更多的安全测试用例对其进行测试。黑盒发现的问题应保留现场,使BUG提交后能复现问题,减少后续的沟通成本。

对于SDL流程,建议根据企业的特点设立完整的或关键性的流程。完整的流程把威胁建模与需求评审结合、白盒与集成流程结合、黑盒与测试流程结合,上线审查与预发布流程结合。关键性的流程则更多关注于测试流程和预发布流程,确保上线之前能看到应用的安全性结果。


SDL安全人员要求


一般来说,专注于威胁建模的人员应该有一定的业务理解能力和丰富的安全攻防经验。如果没有一定的业务理解能力,则无法从业务的角度思考安全风险,而丰富的安全攻防经验则可以帮助产品经理更好的理解并验证安全风险问题。

制定代码安全规范和打造白盒工具的人员首先需要具备一定的代码能力,在架构层面能和研发人员或架构师讨论最优的安全问题解决方案,在培训研发人员的时候能从企业的实际情况出发,而不是完全站在安全人员的视角。

开发黑灰盒工具的人员需要了解测试过程,对安全漏洞攻防有深入的了解,能将二者结合起来在测试过程中完美的融入安全测试用例。


SDL的考核和量化机制


     安全工作容易落入自我证明的陷阱,相较于线上安全运维来说,SDL是比较好考核和证明的,一般来说主要有几个指标:


4.jpg

     上线前检测出漏洞数和上线后发现的漏洞数

     这个指标更多要采用环比来进行比较,来验证SDL工作的有效性。

     SDL的实施效率,即进行SDL安全环节的时间

     通过观察安全测试的效率,安全漏洞修复时间来判断SDL对整体研发效率的影响,或可提升SDL工具的自动化程度。

     项目组SDL问题检出数

     通过横向评比,可评估不同项目组和研发部门设施安全培训、代码规范,以及安全需求评审的效果,判断需要向哪些项目倾斜SDL资源。


默安科技“平台+工具+服务”一体化SDL解决方案

      银行业在数字化转型的过程中,应用的功能、体验和安全性成为用户选择的关键因素,为了丰富产品功能和用户体验,银行产品类型越来越丰富,数量越来越多,项目周期越来越短,但是安全人手的短缺导致很多应用上线前未能经过充分的安全测试,多数银行的对客应用系统在上线前仅仅做一次人工安全测试,测试的广度和深度难以控制。如何有效地保障其安全性已然变得至关重要。

      为了更好地帮助银行从根源解决应用系统安全问题,默安科技推出了基于“平台+工具+服务”的一体化可落地的安全开发生命周期解决方案——MoreSec SDL。


5.jpg

MoreSec SDL解决方案流程图


      MoreSec SDL解决方案由默安科技的资深安全专家倾力打造,依托默安科技自主研发的雳鉴软件开发流程安全框架,并结合了大量金融行业的实际落地经验,致力于帮助企业的SDL体系更有效的落地。方案的优势主要表现在:

银行业可落地的SDL流程体系

默安科技SDL解决方案区别于传统的SDL安全咨询服务,不只是交付一套SDL流程、制度和实施指南,还有雳鉴黑白盒安全检测平台和更细层面SDL流程执行配套的的表单工具,如:《安全需求分析清单》、《安全设计清单》和《安全功能测试用例》等。

默安科技SDL流程表单工具由默安科技安全技术专家在实际金融行业SDL项目实施过程中进行不断总结和沉淀形成,覆盖了大量常见的业务系统场景下的威胁模型,针对银行、证券、保险等各种企业的实际情况,针对性优化SDL流程,为金融行业SDL体系的建立和落地奠定了坚实基础。


6.jpg


SDL流程管理闭环

针对有SDL轻量化落地需求的客户,默安科技SDL解决方案可支持定制基于雳鉴黑白盒检测平台和上线安全检测服务的轻量化落地SDL体系和流程,并且根据项目中的问题,实时反馈调整SDL流程在特定银行中的落地策略,以满足多元化的金融行业研发安全需求。

专业多元化的SDL安全赋能

默安科技SDL解决方案通过“产品+工具+服务”的方式对企业开发流程中相关员工进行多元化的安全赋能。针对外包人员占比较大,安全能力较差,沟通成本高的行业特点,专业化的雳鉴SAST和IAST安全产品将应用程序静态安全测试能力和交互式安全测试能力赋能给研发和测试人员。基于海量威胁模型定制的表单工具赋能给安全和测试人员。通过培训服务进行SDL流程管理和SDL流程各阶段的实施的赋能,如:安全需求分析、安全设计、安全编码、安全功能测试和安全应急响应等。

DevSecOps安全检测自动化

默安科技全面开放雳鉴黑白盒检测平台API,可与银行系统内部CI/CD开发平台集成,协同开发、测试、运营和安全团队共同努力将安全和合规作为属性嵌入软件DevOps流程,形成DevSecOps体系,使安全检测工作自动化,解决传统SDL实施大量依赖人工参与,无法在敏捷开发模式下落地的问题。

漏洞平台化管理解决沟通成本

     从漏洞发现,漏洞详情,漏洞确认,漏洞修复,到漏洞重新检测,覆盖漏洞从产生到被正确修复的各个阶段,保证安全问题完全闭环。


7.jpg


     同时提供漏洞描述,漏洞危害,修复建议,缺陷代码示例,正确代码示例,数据流调用关系,漏洞代码详情等漏洞详细信息,帮助开发人员更快的理解漏洞和修复漏洞,减少安全人员与开发人员的沟通成本。