SDL-开篇明义

 已发表于freebuf原创 https://www.freebuf.com/articles/es/232252.html,格式跟这里略有不同

 

SDL只是方法论，忌为SDL而SDL

1、sdl是什么 

sdl是安全研发生命周期 ,一个方法论, 理念是安全左移, 通过各种方法、工具、流程设计和交付更安全的软件,以期望降低安全成本,最终还是为了保护企业和用户的资产

一图胜千言,简化版sdl (偷个懒,太多了,概念性的东西不多说了,我就默认看的都是做过至少了解过sdl的;)

 

2、为什么要sdl

成本:应急成本、修复成本、法律成本......

越来越多的安全事件、漏洞、法规要求, 这些成本也愈加明显,安全左移的需求也愈发迫切

一言以蔽之,设计和交付更安全的软件,将安全左移动,尽早的发现安全可能的风险以处理、缓解;

从传统应用安全(注重线上漏洞应急、安全测试)到SDL(全链路)其实也代表软件行业对安全的需求和了解越发深入,从一个“必须解决的问题之一”发展到“应满足的最低要求之一”,

在欧美这个历程大概花了10-12年,在我国,可能还需要3-5年左右时间,(也许更快,从这个角度看(应用)安全应该还是在黄金时代初期);

这里放一张sdl的发展历程,from 微软官网https://www.microsoft.com/en-us/securityengineering/sdl/about

这张图里的信息量还是比较大的,感兴趣的可以去了解下,包括TwC(microsoft-trustworthy-computing)、微软、思科和adobe在sdl方面的协作共同领导等等;

 

 无论怎么看,SDL的最终目的还是为了解决应用安全的问题,这一点不能忘记,

也就是说,如果你在做SDL的时候,做的事情不能为这个目的服务,那是没有意义的

 

3、实际建设中sdl的误区及痛

SDL 过程图示

这里说一下SDL建设中常见的几种误解、误区,以及带来的痛;

1、领导对sdl的“误解”,如:

  • “灵丹妙药”:觉得sdl一上,应用安全能一下子缓解,不再是老大难
  • 投入少:觉得sdl很容易就能实现,招一两个安全工程师就能落地,最多再搞搞自动化(一个人的sdl,甚至一个人的安全部)
  • 实现快:从哪里听到看到SDL的这一套流程、工具和效果,就想照搬过来,直接复用,快速实现
  • ......

总的来说就是“期望过高+资源很少”

2、其它部门对SDL的感受或“误解”,比如

  • 找事的,因为需要相关同学给到配合,信息同步、做出相应action,举几个例子:
    • 需求对应产品,要同步需求信息、评审会议信息、填写checlist或问答表、根据安全建议修改需求业务逻辑(或流程图)、上线要满足安全要求才能上线
    • 开发对应研发:要同步代码提交信息给代码审计、要按照安全标准进行开发、要更新升级存在漏洞的三方包、要修复安全测试出的漏洞
    • 集成发布对应研发及应用运维:要添加三方包检测(Nday及版权)、对接白盒扫描、对接自动化测试(IAST、DAST、SAST)
    • 测试对应QA:同步测试进度、同步测试用例评审会信息、测试数据环境账号等等
  • pmo:每个环节都要管,都要参与,你们是不是pmo啊
  • ......

3、安全人员对sdl的实施误区

  • 完全照搬:比如上面的sdl过程图示,各种规范、自动化上来就整一堆,推给各部门团队
  • 心急:没摸清公司安全状况,没理清背景、需求就上马
  • 拿来主义,生搬硬套,而不是因地制宜:举个例子,在上家公司经过两年摸索、建设,结合devops做成了一些安全自动化的东西,到新公司想在半年内就把原来的这套搭建起来,但这家公司没有相应的devops、IT能力支持,业务场景、产品类型也不同,结果费了大力做出来却效果不理想;更甚者,直接网上找来一些就去推广,自然被产品、研发怼的鼻青脸肿,后续工作也不好开展;
  • 没有自己的节奏,尤其是遇到上面描述的情形和领导时,容易被牵着走,结果也很不好
  • 软性能力不足,受环境影响过大:在好的环境下有好的同事配合可以干好,而遇到自己不喜欢的环境、同事,就干不好

这些感受或“误解”、“误区”,加上工作或环境中的问题, 会带来SDL推行、落地时的各种困难,比如:

  • 领导的要求不现实
  • 被领导牵着鼻子走,乱了步子
  • 同步信息不及时、忘了甚至不愿同步
  • 问卷填写随意填,不一定真实正确
  • 漏洞没修复就要上线,带伤上阵
  • 修复时间一拖再拖,要跟在后面催
  • 只要安全没卡点,就可以不用care
  • ......

这样下来,搞得自己和大家都很累,也没成果,最终黯然离场或混吃等死...

 

4、应该怎么做

SDL只是方法论，忌为SDL而SDL

为什么会有上面那些误解、误区,

  • 投入与预期   “既要马儿跑得快,还不给马儿吃草”
  • 首先理解偏差,且太强调SDL,一定成度上将其“神话”了不同的人知识储备、能力、“屁股”都不相同,有理解偏差很正常,但要避免“神话”、“过分超出预期”;
  • 其次,工作开展方式问题,这个不能说是谁的问题,只能说结果不好,我们要去改进;
  • 另外还有就是我们的软能力(如沟通、协调协作、管理、价值观等等)不足,需要加强,安全从业者多数是技术出身,这个问题也是技术同学的通病,但企业安全建设,尤其是sdl需要跨部门、沟通协作的地方格外多,那么出问题时不足也凸显了;

应该怎么做

  1. 也是前提,定好安全的战略目标(长期目标):要做成什么样的安全,实现什么样的效果,可以不用那么明确,大致期望即可,也是要跟领导传达安全需要时间,需要资源,是个长期投入、长期建设的事情;
  2. 同样也是前提,定出中短期的安全工作,根据风险评估(安全现状)来制定
  3. 摸索出适合这家企业的打法节奏,要根据业务、团队、IT能力、同事等等因素来定,需要有个摸索过程,不同阶段、相应的项目or工具或平台;摸索的过程靠自己,共通之处可以借鉴(后面有机会展开~)
  4. 应用安全的合理性,开展的背景要明确(问boss、问leader、问自己),有答案了再做后面的事情,且要通晒同步对齐;
  5. 有些弯路是必须要走的:摸索的过程,找出合适的方法,同时也是给相关部门、团队、人一个了解接受的时间,这个过程绕不过去也有必要;
  6. 跟直属领导常沟通、常同步,方式很多:开会、主动讨论、周报(如周报 描述重点项目、解决什么问题、遇到什么问题和困难,需要什么协助;不用太细)
  7. 定期安全情况报告,可以分环节分对象来,比如漏洞管理情况、比如某业务的迭代需求及测试用例评审、安全测试结果;体现价值,涮存在感,获得认同;
  8. 提升软能力,建议根据冰山模型+学习提升管理能力

另外在公司安全建设战略甚至战术层面,不要过分强调“要做SDL”,个人认为沿用“应用安全”这个词会好很多,包括减少不必的沟通成本和超预期的情况,尤其是在资源不足,“一个人SDL”、甚至“一个人安全部”的情况下,好好把基础的东西做起来, 用能争取到资源,解决主要的风险,就一个字“稳”;

 徐徐图之, 其他的留给时间(拿多少钱办多少事,话糙理不糙);如果时间不能解决,那....该干嘛干嘛吧  (基操勿6)

各方面也都是再向成熟趋势走的,包括技术、整体IT能力、公司管理,对安全的投入等等, 安全治理 工作是要基于这些因素来开展的;

理清楚做SDL的目的,找到背景,顺理成章开展;不忘来路,始知归处; 

 

总结&后续:

SDL只是一个方法论,只是一种手段，而不是目的，目的是让我们的产品更安全:设计与交付更安全的软件,来保护公司及用户资产;

如果盲目为了SDL而SDL,完全follow SDL ,结果必然是悲惨的,就算你能完全实现,那最直接的就是没业务了,公司就搞安全了... 因地制宜,适合自己的才是最好的,我们做SDL其实真正花时间去思考解决的就是找到合适的方法将SDL方法论落地来达到目标,这个顺序我们要明确,通俗一点说:有些弯路是必须要走的;

 

方法论是一种以解决问题为目标的理论体系或系统，通常涉及对问题阶段、任务、工具、方法技巧的论述。方法论会对一系列具体的方法进行分析研究、系统总结并最终提出较为一般性的原则。

当然有许多工具、经验是就在那里,也值得我们去借鉴的,涉及对问题阶段、任务、工具、方法技巧,都能够提炼到一些共通的东西,这些后面具体展开,这里先说一下大致的思路;

 

 

 

首先确定我们的产品是有安全问题的，以前有过(比如外部白帽测试)，现在也有，以后也会有，这个跟bug是一个道理.

那么怎么就能更安全，目前就是在做测试,我们在测试SDL这个方法是否可行，类似我们要采购某个产品工具，我们要先测，测功能，测性能，测效果;分步骤在进行.

试点，是一个很常用的手段,(在流程、工具、效果、不同业务线适用度都需要做试点),在一家企业要做sdl时,第一个试点就是测试sdl流程能否在这家企业跑通，能否工作运转起来；同时也会测效果，能否提升安全，但这块后续还会有试点项目来进行验证；第一个试点建议找比较稳定的项目，来测流程是比较合适的。试点过程中会发现很多问题,不仅是流程或安全知识技能、工具,还有公司环境、人等方面的,这些不同企业所特有的问题是更需要思考去解决的; 总结出问题、尝试解决方法、(比如沟通成本高,能否有方便沟通双方的方法,工具?比如覆盖率低,比如不配合等等,详见上面的困难)

那如果测试结果发现SDL不管用，不能跑通，或者不能使我们更安全，(当然不太可能，毕竟这个是业界比认可的，但不同场景公司是有自己的特殊性，就不适用通用别人公司的方法)，或者遇到各种问题, 效果没我们想象中的好，那我们就换一种方法，或者参考/添加一些方法、元素，比如SAMM，比如以前的测试修复模式，比如BSIMM,比如事件驱动，比如威胁建模等等，或者取这些方法的优点，来做一个适合自己的东西出来，当然 我们也可以继续把这个东西叫做SDL，只要结果是对的就好，是能提升我们产品安全性即可。

 

当然 这些话没必要对老板去讲，老板只要结果。

我们在过程中去做去改进即可去拿到结果。实在要说，就一句话：我们在不断改进，得到更适合我们自己的方法来进行。

 

那么目前看来，阔以提取到的通用元素的是什么(设计交付更安全的软件的要素),比如：

  • 流程(阔以借鉴PMP，项目管理方面知识)
  • 工具化自动化
  • 人员及能力
  • 威胁建模(安全分析设计能力)
  • ......

接下来就是如何将这些元素在自己的公司里/场景下实现、串联、运转到落地应用

这些元素在不同企业里落地时的共通点,以及涉及的软能力提升

后续一个一个展开,先挖坑,待填(但愿不会太监)

 

posted @ 2020-04-21 10:58  指尖的乐律  阅读(733)  评论(0)  编辑  收藏  举报