为数字化企业注入安全基因

 

企业面临的安全挑战已经发生改变

如今,越来越多的企业选择部署移动技术和数字化来强化自己的业务,传统的业务模式在新的技术革命中面临新的安全问题和挑战。这些挑战集中体现在如下几个方面:

第一,固守网络边界安全难以达到预期的效果。传统的安全思路是,在网络边界实行严格的访问控制、部署网络防火墙、入侵检测以及入侵防御系统等,企业以为这么做足以高枕无忧,但实则是被安全的假象所包围。近年来,黑客渗透进入企业内网,绕过网络防火墙,通过IT系统漏洞获取最高执行权限、下载敏感数据,种植木马病毒等攻击事件层出不穷。

更何况,随着云技术的快速发展和大量使用,传统的企业网络边界正变得越来越模糊,这势必给固守边界安全这种方式带来更大的挑战。

第二,应用防火墙存在天花板效应。和网络防火墙侧重在网络层做防御有所不同,应用防火墙则是在应用层入手,扮演门卫的角色以保护IT应用。但随着企业在数字化道路上的不断前行,企业IT应用数量和业务复杂度都在持续增长,这使得管理维护应用防火墙安全规则的难度也在不断加大。当这种难度大到难以掌控的时候,应用防火墙便遇到了天花板,例如谁也不知道某条安全规则为何存在,谁也不敢轻易去修改安全规则,谁也不敢添加新的安全规则,因为有可能会对正常访问造成误杀等等。此时本来是为企业安全保驾护航的应用防火墙,反而成了企业数字发展的瓶颈。

除了安全规则的管理维护难度大之外,无论是网络防火墙还是应用防火墙,都无法彻底解决漏报和误报的问题。误报对用户体验是种伤害,然而更为严重的是,由于安全的特殊性,一次漏报就有可能造成后续的安全事件。

第三,在提倡持续交付、DevOps以及通过MVP基于市场反馈进行快速改进的开发部门面前,偏好实施安全控制和审计的传统安全部门无法跟上开发部门的快速开发节奏。随着敏捷精益、持续交付、DevOps等理念和技术的发展,开发部门可以做到一天之内数次发布产品。例如,早在2014年的时候,亚马逊平均每秒就有一次以上的产品部署,每天如此。在这种情况下,安全部门如何跟上开发团队的速度?如何在快速变化当中了解即将发布的IT应用的安全情况?

这些挑战使得安全成为了企业数字化转型中“最薄弱的一环”,在日益复杂的未来环境中面临严重风险。大部分企业认为自己有能力抵御网络攻击,可实际情况是,企业安全问题已经迫在眉睫,很多安全公司对企业安全是持悲观态度的。

安全领域的资源投入出现了严重错位

根据企业规模和行业的不同,安全在IT投资中的占比也不同。一般而言安全投资的比例会占到5%-8%,金融行业略有不同。大部分的资源被投入到了IT基础设施安全(例如,网络、服务器、数据安全)。而安全风险越来越突出的应用安全方面,却存在着严重的不足。

伴随投入占比失衡的问题,更加突出的是安全技术的变化,现在的安全威胁已经由传统的病毒木马、系统漏洞、缓冲区溢出攻击转变为虚拟机安全,激动安全,APT攻击,DDoS攻击等。这些攻击带来的安全风险和威胁也随之加剧。比如携程网信用卡泄露事件,从表面上看是Web页面上的漏洞所致,漏洞的产生主要是由于产品在其App端调试的过程中便开发了整个目录的遍历,由于开发过程中安全控制不足,上线后黑客能够巧妙的绕过服务器的权限访问到文件系统的其他部分。此次安全漏洞可导致用户个人信息、银行卡信息等泄露。由于发现及时,最后得以控制和限制。但这件事给越来越多的成长中的企业以警示。使得更多的企业在面临数字化创新、求新求变的同时,将安全放在重中之重的地位。

金融行业是安全风险和攻击出现的重灾区,以银行行业为例,银行为了更多地吸引客户和方便客户,开通了网上银行业务,由于任何用户都可以通过互联网访问业务系统,因此网上银行系统存在来自互联网各种攻击的安全风险,这种风险在P2P行业盛行的中国尤为突出。

图1:安全风险和对应的投资呈现出严重错位

企业中的绝大多数数据访问都是通过应用程序进行访问的 。根据Gartner统计,现有的攻击中80%的网络攻击也是发生在应用层。面对新的安全形势,企业若不采取有效措施加以应对,应用程序中的安全漏洞一旦被公之于众,必将对业务造成破坏性影响,使企业陷入竞争不利的局面。一般应对此类安全问题的措施是采用应用层防火墙做一些基础性的防护,系统性地测试和扫描所有应用,通过特征库来区分安全威胁和风险,这种控制的方式存在误报率高、问题发现不彻底的缺陷。要解决应用层安全的问题,最佳的方式是在软件开发的过程中,根据软件和应用的特性,在应用开发的过程中解决安全风险。

另外一个普遍的现象是,虽然有不少常见的安全措施可以采纳,但其实大多数企业依然是在依靠防火墙来阻挡攻击,用渗透测试来暴露安全漏洞。随着安全挑战的变化,这些传统措施的抵御力越来越低。

防火墙的主要职责是阻挡攻击,为开发团队争取修复漏洞的时间,而并非取代漏洞的修复工作。换言之,只要应用中导致安全问题的代码没有被修复,漏洞就会一直存在,一旦防火墙规则被绕过,或者配置不当,反而会将应用置于更高的安全风险当中。此外,误报和漏报始终是防火墙无法彻底解决的问题。

至于上线后的渗透测试,它确实能发现安全漏洞,但是也存在着明显的不足。通常而言,渗透测试会被安排在应用上线发布之前进行,此时如果检查出安全漏洞,企业反而会面临两难的境地:修复安全漏洞之后再发布应用可能导致项目延期,错失市场机会;如果强行发布含有安全漏洞的应用,又将提高被黑客攻击利用的风险。

数字化企业,需要注入安全基因

为了更好的应对新的安全挑战,做好应用的安全防护势在必行。不过,在介绍具体做法之前,让我们先看看为何企业采纳了众多安全措施,可开发出来的应用中依然存在不少安全漏洞,就像顽疾一样无法彻底根除。

应用中的安全漏洞是在开发过程中由于各种原因被引入的,然而回顾现有的安全措施就会发现,许多措施并没有被作用于开发过程中。例如防火墙、安全监控发生在应用上线之后,渗透测试需要在开发完毕后才能进行,而安全培训、安全规范只能起到预防作用。正因如此,安全问题从引入到被发现,间隔很长,使得安全问题不能被及时的反馈给开发团队。

建议的做法是,在开发团队中建立起一个高效的安全反馈机制,在开发过程中引入安全活动,尽早开始收集安全反馈信息,加快获取安全反馈的速度,在整个开发过程中持续关注应用的安全性,与此同时团队成员共同来承担安全职责。ThoughtWorks将这些在实践中总结出来的经验命名为©Build Security In DnA(下文简称BSI,http://www.buildsecurityin.net),从源头上尽早、尽快、持续性的、以团队共同协作的方式发现并解决安全问题。

图2:Build Security In 内检安全基因

越早获取到安全反馈信息,越有利于开发团队以更低的成本将其修复。与其依赖于项目后期的渗透测试,不如在开发过程当中引入一些适当的安全实践,比如在分析业务需求的同时主动分析安全需求,将其作为质量验收标准在团队内明确出来,再比如,对代码进行安全评审、测试人员在测试业务功能的同时还对安全性进行验证。通过这种方式,使得团队能够尽快的知应用的安全状况,而不必依赖于很晚才能提供安全反馈的渗透测试。

图3:在开发过程当中引入安全实践

对于常规的安全测试完全可以借助工具以自动化的方式进行,不仅能够以更快的速度得到安全性反馈,还能在一定程度上弥补由于人员安全技能不足所造成的安全测试不够全面的问题。此外,自动化带来的另外的好处是,它可以集成入CI服务器,从而让开发团队可以利用CI流水线在第一时间发现应用的常规安全问题并及时修复。

收集安全反馈不是一次性的活动,高效的安全反馈机制和持续集成秉持相同的理念:除了尽早集成、尽快集成之外,很重要的一点就是让集成活动能够持续性的发生。类似的,对于建立高效的安全反馈机制而言,在能够尽早、快速的获取安全反馈的同时,还需要让这个反馈循机制在应用开发过程中持续地运行下去。

图4:对安全保持持续性的关注

实施BSI的挑战

我们将BSI在多个大型金融企业里进行了实践探索,而在实施BSI的过程中,我们遇到了各种各样的挑战,其中比较典型的三个如下:

挑战一:安全活动排不上高优先级

企业完全认同IT应用的安全性是数字化战略中不可或缺的一部分,但是具体到BSI实施落地层面,却发现安全活动排不上高优先级,总是会被各种原因不断的往后延期。其中一个常见的说法是,开发团队面临着很大的交付压力,要在规定的发布日期到来前完成计划中的业务功能已经实属不易,没有充足的时间执行安全活动。

出现这样的情况并非是因为开发团队不清楚安全的重要性,这背后潜藏的原因是,某些传统安全活动给开发团队留下了一些不太好的印象,比如说,需要耗费开发团队比较多的时间,或者某些传统安全活动过程繁琐、流于形式,难以产生实际有效价值。再加上实现业务功能永远是开发团队的第一优先级,因此安全活动难以推进执行也是必然的结果。

从我们的实战经验来看,要解决这一挑战,企业可以精心挑选一个试点团队,将其打造成BSI的样板工程,以成功案例的方式让更多的开发团队进一步了解BSI,明白它能够最大限度的借助自动化,提高开发团队在安全活动上的投入产出比,用相对而言更少的时间,更有效的提高IT应用的安全性。

挑战二:传统安全团队的焦虑

传统的IT应用安全运作模式是,每次IT应用在发布上线前,开发团队将其交给安全团队做扫描,安全团队将扫描结果汇总成安全报告并提供给开发团队做修复。在这一模式中,安全团队报告的安全漏洞数量越多,严重性越高,越能体现出自身的价值。

而在实施了BSI后,开发团队承担了更多的安全职责,将原本由安全团队才有能力报告的安全漏洞及时发现并修复了,这使得传统安全团队感到一丝焦虑。想象一下,如果某次安全扫描后,没有在IT应用中发现任何安全漏洞,安全团队到底是应该欢喜雀跃,还是黯然神伤?

BSI是IT应用安全发展的必然趋势,在这个大趋势下,安全团队需要重新思考和调整自己的定位,将关注点从安全漏洞数量,转移到为开发团队提供自动化、自助化的安全服务上来。

挑战三:安全活动如何可视化?

在实施BSI的过程中,我们经常被开发团队问到的一个问题是:我们做了这么多安全活动,仅仅只是我们自己知道它非常有帮助是不够的,如何才能把它可视化出来?

BSI中的每个安全活动都有着明确的产出物,我们可以通过收集整理这些产出物,将其作为基础,通过图表的方式进行可视化。比如,威胁建模会产出一系列安全需求,它们会随着开发的进行逐个被实现。在这一过程中,开发团队可以将当前已完成的安全需求、未完成的安全需求的数量以燃尽图的形式展示出来。再比如,开发团队可以持续统计通过自动化安全测试发现的安全漏洞数量,依然以图表的形式进行可视化。

通过BSI安全成熟度模型来对企业或者某个开发团队的安全实践进行评估,并且将其结果可视化出来也是一个不错的选择。不仅如此,企业还能通过这个办法,从中识别出当前面临的安全短板,为开发团队设立安全改进目标提供帮助。

在数字化革命面前,金融企业业务的正常运转必然将高度依赖于IT应用的可靠运行,IT应用的安全性将对企业产生重大影响。企业有必要通过BSI这种内建安全的方式,尽早发现安全问题,利用自动化的优势缩短安全问题的反馈周期,持续的、以共同协作的方式主动预知并化解安全问题。

 

作者介绍:

马伟:ThoughtWorks高级咨询师、企业应用安全高级咨询顾问,BSI的实践者。

杨璐:ThoughtWorks首席咨询师,曾服务于IBM和埃森哲咨询部门,为多家跨国公司和机构提供过安全咨询服务。

 

Share

别再依赖安全扫描了

本文中的“安全扫描”是指开发团队在距离产品上线日期比较近的时候,通过公司里的安全团队或者外部第三方安全公司对产品进行安全扫描,团队基于安全扫描报告,对产品中存在的安全漏洞进行修复的过程。不同的公司,不同的开发团队对它的称呼可能不一样,有人把它叫做渗透测试,也有人把它叫做安全审查、安全评估、安全检查等等。

如果不做安全扫描会怎样?

想象一下,你所在的开发团队正在开发一款互联网金融产品,所有的核心业务功能基本开发完毕。此时此刻,离计划中的上线日期只有不到三周时间。通常而言,这时候安全扫描就会介入进来,扫出一堆问题扔给团队修复。

safe

不过这次不一样,如果我提议,不必给产品做安全扫描,就这样直接上线可好?我想,绝大多数人的反应会是下面这样的:

“神马?!不做安全扫描?那我怎么知道产品安不安全?万一出问题了怎么办?”

“我知道我们产品中一定会有安全问题,安全扫描正好可以帮助我们把这些问题暴露出来,将其修复之后再上线才是万无一失的选择。”

“虽然每次安全扫描都会扫出一堆问题来,搞得团队压力山大,但如果不做扫描,我们到是轻松了,可产品的安全性却又是个问题。”

“安全扫描可是我们安全团队的杀手锏,不让我们给开发团队做扫描,那我们的价值怎么体现出来?”

“公司规范里说了,不做安全扫描不准上线。”

“年少轻狂的年轻人,我以过来人的经验告诉你,这么做是要付出代价的。”

反应越是激烈,说明团队越是依赖安全扫描。甚至可以说,安全扫描在你的团队里,是保证产品安全的最后一道屏障,也是唯一的手段。

安全扫描是陈旧落后的手段

有人会说,最后一道屏障又怎样,唯一的手段又如何,不管红猫黑猫,抓到耗子的都是好猫。

1123-b

先不谈这样做是好是坏,我们先来换个角度思考一下,如果把“安全问题”这几个字换成“功能缺陷”或者“Bug”,你还会认同这种在临近产品上线之前做一次性的、运动式的大检查,然后期待着开发团队在所剩无几的时间里快速修复掉所有Bug,还不能引入新Bug的做法吗?

答案显然是否定的。大家都明白,功能缺陷越早发现越好,否则修复成本将会非常高,越往后拖越对团队不利。

现如今,还有哪个开发团队敢说,在开发过程中不需要对软件做测试,等到最后上线前做一次集中式的测试就够了?开发团队也是极尽所能的快速响应软件质量问题,例如进行测试驱动开发,编写大量的自动化测试并且通过CI持续的对软件质量进行监控。

安全问题是如此的重要,它也是软件质量的一部分,只不过换了个名字,变了种表现形式而已,而我们却用如此落后的方式来对待它,显然不合理。

提前做安全扫描可能是空中楼阁

foam

又有人说,安全扫描不就是太晚了一点嘛,我们把扫描时间点往前提一些不就好了吗?

思路是对的,但很可惜,要做到这一点却几乎是不可能的。因为安全扫描有一定前提条件,它只能对已经开发完成了的功能进行扫描,这也就意味着,那些还处于开发过程中的功能是覆盖不到的。而且随着开发的进行,软件功能会有所调整,之前做过的安全扫描很可能会失去意义,最终还是得等到所有功能都开发完毕了,在上线之前再做一次最终的安全扫描。于是这又回到了上面那个问题。

安全扫描的短板不止一处

安全扫描除了上面讲到的时间太晚的问题之外,还有不少短板。首当其冲的就是速度太慢,跟不上开发团队的节奏。尽管有自动化工具的帮助,但是一次全面、细致、深入的安全扫描,往往需要好几天,甚至更长时间。在如今追求快速开发上线,迅速调整以响应市场变化的环境下,开发团队没有这么多时间和耐心来等待扫描结果。

某些采用敏捷或者精益开发方式的团队,每个迭代甚至每天都有新功能上线和旧功能调整、问题修复等等,而等到几天甚至几周后,团队拿到安全扫描报告的时候,被扫描的功能可能早就被废弃了,这么做简直是在浪费资源。

sgonot_bloombergfinal_15_2048

其次,留给安全扫描的时间窗口十分有限,它往往只能在产品功能完成之后,最终上线之前才能进行,在这种情况下,往往只有一次机会进行扫描,也只能给团队提供一次性的安全反馈。但实际情况却是,业务需求在不断发展和变化,开发团队也在持续对产品功能做出调整,除非每次产品功能发生变化之后立即进行一次安全扫描,否则以现有的模式,是没有办法及时给开发团队提供安全性反馈的。

最后,安全扫描的成本也是不得不考虑的因素。购买外部安全公司的安全扫描服务到是很方便,可是动不动就是几十万的支出不是任何团队都能承受得起的。通过自有安全团队做安全扫描看上去可能更加经济实惠,毕竟是公司内部资源,但是别忘了,自建安全团队也是有成本的,而且要招到杰出的安全工程师也不是件容易的事情。

既然安全扫描有这么多缺点,那为什么还有如此多的团队在用它?

抛开安全问题暴露出来之后,解决起来是如何痛苦这件事情不谈,其实安全扫描也并非一无是处。

尽管安全扫描在时间上晚了一些,速度上慢了一点,还不可持续,但由于软件开发本身是个复杂的过程,开发团队在产品安全性上总有疏忽大意的时候,只要进行安全扫描,大多数时候都会有所“收获”。这样的话,一方面安全扫描帮开发团队发现了问题,另一方面安全团队也体现出了自身价值,正是在这样的背景下,安全扫描无论是对于开发团队还是安全团队而言,都具有难以抗拒的诱惑力。

此外,有时候做安全扫描也是一种无奈之举,因为有些开发团队不见黄河不死心,除非你把安全问题明确的摆在他们面前,否则他们意识不到问题的严重性,不会轻易的主动去关注安全问题。

除了安全扫描,还有别的什么办法?

既然安全问题这么重要,安全扫描又是如此的低效,那我们该怎么做才能更好的解决这个问题呢?答案其实早就摆在眼前了,软件的安全性是软件质量的一部分,为何不尝试一下把它和功能需求一样,都当做头等公民来看待呢?那些用于保证软件质量的最佳实践对于软件安全性同样适用。

更具效率的做法是,在产品开发的全生命周期里,直接植入安全最佳实践,我们把它叫做Build Security In(简称BSI)。例如,在分析业务需求的时候,主动去分析安全需求,给用户故事建立安全验收标准;在开发过程中时刻关注安全,通过自动化的安全测试持续性的关注产品安全;在测试过程中,不仅测试产品看其是否满足了业务需求,还基于安全验收标准设计并执行安全测试用例。

1-bsi

传统的安全扫描是从后外前推,倒逼着开发团队做改变,而BSI的做法则是从前往后梳理,融入到日常的开发过程中。正是因为提前并且持续性的关注产品安全,所以在后续的开发中,团队才会有意识的去做安全防御,使得最后开发出来的软件默认就已经具备了不错的安全性,给团队带来的冲击和压力也是最小的。

迈出改变的第一步

安全扫描已经深深的烙在了很多开发团队的骨髓里,突然之间要改变这一切势必不容易,但是我们还是可以做很多尝试来逐渐改变这个现状。在这里我推荐一些比较好的切入点,开发团队可以作为参考,迈出改变的第一步。

每当在创建用户故事的时候,多问几个和安全相关的问题,比如:

  • 这个业务需求面临着哪些威胁?
  • 和这个业务需求相关联的安全需求是什么?
  • 有没有什么东西是应该被保护起来的?
  • 应该提前做些什么以应对可能的黑客攻击?

然后,团队共同给这个用户故事设定安全相关的验收标准。

开发人员在每日代码审查的时候,多问一下:“这样设计,或者代码这么写,有没有什么安全风险?安全验收标准满足了吗?”

每当测试人员拿到一张用户故事对其进行测试的时候,也问问自己:“除了测试产品看其是否正确实现了业务需求之外,还需要基于安全验收标准设计并执行哪些安全测试用例?”

上面这些提问看似简单,但是当你在团队里问出这些问题的时候,你一定会惊讶于它们带来的影响力。试试呗。

Share

让安全实践在敏捷团队落地

随着安全得到越来越多的关注,一些跟安全相关的理论(比如BSI)脱颖而出,尽管这些理论提出来已经有一段时间,却很少看到其在开发团队被成功地应用。我们知道微软曾在十多年前就提出了SDL,却没能在业界推广开来,并不是人们不认可微软这种“从软件生命周期保障安全”的理念,而是考虑到其落地实施的难度,很多企业知难而退,那么这些安全理论对我们的软件安全真的有帮助吗?安全实践能落地吗?

很幸运地,我有机会在一个成熟的敏捷开发交付小组中经历了“从完全没有安全实践到BSI”的过程,我们也曾遇到过很多困难,但最终得到了客户的认可,并成功把安全实践推广到了整个团队,所以想跟大家分享一下我们是如何将安全在敏捷团队落地的,希望能给大家一些帮助。文中会拿Web系统举例,但一些落地的实践同样适用于非Web系统。

为什么安全理论很难落地?

结合对一些团队的了解,原因大多来自以下三个方面:

  1. 认为安全不重要
  2. 认为安全太难,需要很广很深的领域知识,只有专业人员才能做到
  3. 不知道应该用什么样的流程来做安全

那么针对第一点,因为我本身也是交付团队的一员,我观察到的大多数软件开发团队,不管是业务分析师、开发人员、测试人员、体验设计师还是项目经理,都很少有人真正把“安全”作为非常重要的一件事情,尤其是在交付压力比较大的情况下,我们都会舍弃对于安全的投入,而花时间在更容易可视化出来的用户功能上。安全,很多时候就像灭火器,如果不发生火灾,我们甚至都感觉不到它的存在。那么,安全,真的重要吗?

换位思考一下,如果我们是用户,面对以下两种选择,我们会选择哪一种?

  • 系统A:设计非常完美,功能缺陷几乎没有,性能也很棒,但是没有做任何跟安全相关的防护,用户的敏感信息很容易泄露;
  • 系统B:设计比较差,有一些功能缺陷,性能也差一点点,但是采取了特别多的安全措施,能够保障用户的数据安全性;

相信几乎所有人都会毫不犹豫选择B系统,除非这是一个完全没有用户敏感数据、完全不需要安全保障的系统(那这样的系统又有什么用?),所以只要我们把自己放在产品使用者的角度,而不是产品制造者的角度,就能很容易地理解和认可安全对于软件系统来说是比功能更重要的一个因素,安全是软件的灵魂。

那么对于很多已经深刻认识到安全重要性的团队,为什么依然很难将安全理论落地呢?原因大多来自前面提到的第二点和第三点,一是从技术上认为安全是一个很难的领域,需要专业的安全人士;二是从流程上不知道该如何开展;从这两个角度出发,“安全”需要巨大的投入,所以很多团队望而却步。那么安全真的这么难落地吗? 接下来我会简单介绍一些Web安全知识,然后通过我所在团队的落地过程给大家一个答案。

如何让安全在敏捷团队落地

什么是Web安全?

所谓Web安全问题,就是攻击者可以通过非正常的手段,获得Web系统访问权限,从而破坏网站行为,盗取甚至修改用户数据的一系列问题。

那么为什么攻击者可以获得Web系统权限呢?这种几率到底有多大呢?如果可能性非常小,我们是不是不必花费太多精力在安全上面呢?

我们来看一下Web系统的组成,一个最简单的系统都至少有这么几个部分:

如上图,浏览器发送请求到服务器,服务器给浏览器响应,服务器会查询数据库,数据库返回结果。在这个过程中,我们开发的Web程序不可避免的存在安全漏洞,甚至我们开发系统所使用的编程语言也会有安全问题。在开发时,我们常常会引用一些第三方的工具、组件,而第三方的安全性也没有办法保障,甚至数据传输过程中使用的协议、操作系统本身也会有安全问题。所以可以想象一下,如果我们不做任何的安全防范,那么每一个软件都是一个非常脆弱的系统,很容易出现安全问题。

常见的Web安全问题

既然这么多环节都有潜在的安全风险,那么该如何着手呢?可以参考OWASP TOP 10,以便对最严重的Web应用程序安全问题有个大致的了解。

敏捷开发模式现状

我们是一个已经实施敏捷开发七年的团队,一共有五十多人,划分成不同的Feature小组进行日常的工作,其敏捷开发模式已经非常成熟,我所在的Feature小组有6个开发人员,1个业务分析师,1个QA,我们每个小组的交付模式都是这样的:

如上图,以用户故事为单元,所有的用户故事都会经历一个从分析到最后给客户演示的生命周期,多个用户故事组成一个Feature,然后我们会进行Feature的功能测试,给客户展示整个功能,最后在发布之前,客户会邀请第三方的专业安全公司做渗透测试,然后找我们的开发团队修复安全缺陷。

那么这种方式有什么问题呢?

  1. 守门员模式,安全测试非常滞后
  2. 安全问题的修复时间非常有限
  3. 只有少数人关注和了解安全
  4. 依赖独立的渗透测试

所谓守门员模式,指的就是把所有的问题和风险都留在最后,靠少数人来保障,在当时的开发模式下,第三方的安全公司就是我们系统的安全守门员,可想而知,如果我们的团队对安全没有任何了解,在用户故事的开发阶段引入的安全问题要等到发布之前才能够被发现,安全测试是非常滞后的,反馈周期特别长。

另外当第三方的安全公司发现问题,留给我们团队修复问题的时间特别有限,因为渗透测试是发布前的最后一个阶段,长时间的修复又会导致发布延期,所以经常会导致安全修复以补丁的方式发布。

而且除了少数修复过安全缺陷的开发人员对安全有一点点了解之外,团队内是没有人关心安全的。

最大的问题是,所有的安全防范都依赖于最后的独立渗透测试。虽然因为执行渗透测试的是专业的第三方安全公司,他们有专业的安全知识,可以发现很多公共的安全问题,也可以提供专业的极具权威性的安全报告,但这种方式的渗透测试有个致命的弱点,他们对业务知识了解不够,很难发现跟业务相关的安全问题,而这一类的安全问题又占了相当大的比重。

可以看到,这种敏捷开发模式的现状就是:试图将安全注入一个已经成型的系统中。

安全落地尝试

那么了解了之前开发模式存在的问题,安全又这么重要,客户和团队都希望可以改变这种现状,提高安全质量,减少补丁,让每一个人都关心安全,但是我们都担心安全需要巨大的投入,会影响功能的发布,所以我们决定选择一个Feature小组做为安全试点,目标周期为一个月(我们的发布周期),观察投入产出比,然后决定是否要在整个团队实行。

首先我们小组开始学习BSI,我们认为它所传递的是这样一些理念:

  1. 将安全融入整个软件开发过程中
  2. 所有团队成员一起为安全负责
  3. 安全的设计和实施一个持续进行的过程

那么在一个几乎没有安全知识储备的团队中,如何将以上理念在团队应用呢?我们遇到了很多的困难,比如:

  1. 不知道怎么把安全和日常开发结合起来
  2. 不知道如何编写安全需求,怎么做安全测试
  3. 接受了很多安全培训,不知道如何下手
  4. 对安全缺乏专业的认知,对安全开发和测试没有信心
  5. 不知道如何满足客户期望

分析这些困难,我们开始迈出了艰难的第一步。

首先,召集团队的核心成员(包括了业务分析师,开发人员,测试人员,技术主管),同时我们邀请了公司的一位安全专家帮我们解答难题,大家头脑风暴,参考OWASP TOP 10, 结合曾经项目上出现过的安全问题以及对于业务领域的深入了解,尝试总结属于我们自己的安全问题项目并且和OWASP TOP 10进行关联,比如我们讨论后的成果是这样的:

可以看到,我们总结出来的这十项并不是将OWASP TOP 10调换顺序这么简单,我们是针对业务需求,有针对性地进行了重新整理和组织,比如其中的Sensitive Data Exposure,我们就结合项目将它划分成了四类(1.Authentication,2.Error Handling,3.Code Leak,4.Cookie Management),之所以会划分的这么具体,是因为我们自己的TOP10更贴近实现。另外我们还针对每一项添加了项目上的例子作为参考,让团队每一个人都清楚地知道我们自己的TOP 10都是什么样的以及业务场景下可能出现的安全问题。

然后我们将项目专属TOP 10作为模板加入到了每个用户故事中,这么做有两个好处:

  • 第一,业务分析师在写用户故事的时候,可以将其作为参考来编写安全验收标准;
  • 第二,如果业务分析师在缺乏安全知识的情况下很难编写安全需求,我们可以将其直接作为安全需求以防遗漏。

当然这还远远不够,更理想的情况是在需求分析阶段、业务分析师和客户在讨论需求的过程中尽量参考一些基本的原则,比如最小权限原则,来确定和编写更加准确的安全验收标准。如下图。还可以让更多的人参与到需求分析阶段,通过威胁建模等手段分析出更全面的安全需求。当然这就需要我们的业务分析师增加安全相关的知识储备,我们也在向这个方向努力。

然后在用户故事的启动阶段,业务分析师、QA和开发人员会一起针对用户故事模板中我们自己的TOP 10进行筛选,将和用户故事相关的内容标识出来作为安全验收标准。如果在故事分析阶段,业务分析师已经遵循一些原则细化了安全验收标准,在这个阶段,也可以多个角色针对这些安全验收标准进行探讨,确保大家理解一致。

到了用户故事的开发阶段,通常开发人员都会按照验收标准来编写代码和测试,基于我们已经有了足够的安全验收标准,相应地,开发人员也会编码来实现这些安全条件并且添加相应的自动化测试保障,当然,除了满足安全验收标准之外,我们也会做一些静态代码的扫描和第三方依赖的扫描,双重保障。

用户故事的验收阶段非常重要,因为如果在这个阶段发现缺陷可以快速修复,我们一般是QA、开发人员和业务分析师一起,逐个验收我们之前制定的安全验收标准。当然,除了简单地从前端进行验证,针对安全验收我们需要借助一些工具(如Burp Suite),绕过前端修改请求,检查是否后端接口也作了相应的防范,如果发现安全问题,会在这个阶段及时修复并且增加相关的测试保障。

07

到了用户故事的测试阶段,QA会做跟安全相关的探索性测试,在这个阶段,需要QA从一个全新的视角来做测试,之前我们的模式是从正常用户的角度来测试功能,而针对安全的探索性测试则截然不同,我们要用攻击者的角度来思考问题,尝试各种看似不可能的手段,寻找安全漏洞。另外,在这个阶段,我们也会借助一些自动扫描工具(比如ZAP),来检测是否有一些通用的安全问题。

08

安全的演示阶段比较有挑战性,前面提到过,它不像功能需求那么可见,所以我们采用了一种全新的方式去展示,通常功能演示我们是给客户展示用户界面,如何使用系统等,而对于安全,我们尝试了展示安全缺陷以及我们的缺陷分布分析。比如在这一个月里,我们发现了六个安全问题,其中两个是通过ZAP扫描出来的共通的安全问题,另外四个是和业务强相关的安全问题(比如账户A可以通过特殊手段修改其本来没有权限的数据,属于我们自己的TOP 10的Authentication那一类)。

回顾整个过程,其实我们在用户故事的每个阶段都增加了和安全相关的实践,并且让团队所有人员都参与了进去,将安全融入到日常的工作中,不断改进,持续关注,而这些正是BSI所传达的理念。

客户看到我们的安全成果展示后非常满意,进而在我们整个团队开展了这样的安全实践。

在维持这样的安全模式几个发布周期之后,我惊喜地发现我们的开发人员开始有了安全的意识,比如前不久我们有一个用户故事需要实现一个邮件模板,系统要求能够接受用户定制化的html,功能实现非常简单,可是开发人员一筹莫展,接到用户故事后马上找到我,探讨如何让我们的系统允许接受html后还可以避免script攻击,这让我深刻感受到,BSI(Build Security in our DNA)这个理念的精确含义,我们不是为了让大家遵循实践而去实践,而是让每个人都有安全的意识,每当我们接触到一个新的功能,马上会想到可能有哪些安全问题,而不是急于实现功能,长此以往,安全就真的进入了团队的DNA。

总结

回想之前我们想要开始在团队实施安全时的恐惧以及止步不前,到最后我们成功将安全实践落地并且推广,这个过程让我体会到,从一个小组开始尝试,观察投入产出比,再推广到整个大的团队是个很好的实践。

另外,不要期望一步到位、迅速成为安全专家,安全的设计和实施是一个持续进行的过程,可以从日常工作中的点滴做起,从保障每一个安全需求做起,想象一下,如果我们每一个用户故事都注入了和安全相关的实践,那么feature就会是这些安全的用户故事的结合,系统就会变成一个充满安全投入的整体。

和之前“靠最后的渗透测试来补救安全问题”的方式相比,这种从源头就将安全渗透进软件系统的方式更能保障我们软件的安全。


更多精彩洞见,请关注微信公众号:ThoughtWorks

Share

內建安全的软件开发

文章作者/配图来自ThoughtWorks:马伟,未经允许,谢绝转载。

1. 传统安全实践面临着严峻的挑战

随着互联网应用、移动应用爆发式的增长,伴随而来的黑客攻击事件也是层出不穷。仅在过去的2015年里,被公开报道的数据泄露安全事件就有约3930起,将近7.36亿条数据被泄漏。显而易见的是,如果某家企业被爆出安全问题,对企业造成的影响不仅仅只是名誉、财务上的损失,还会遭受法律诉讼,陷入竞争不利的局面。安全已经是企业不可忽视的问题。

近年来,黑客攻击的趋势已经发生了显著的改变,由最初的针对网络、操作系统以及服务器的攻击,已经转变为针对应用程序的攻击。根据Garnter的调研报告显示,有将近80%的安全漏洞发生在应用层。为了应对新的安全威胁,企业也做出了各种尝试,例如为员工提供安全培训、设立安全规范文档、部署Web应用防火墙、建立安全监控中心、利用安全渗透测试寻找安全漏洞等等。经过一些列的努力,取得的成果也是比较显著的,例如老生常谈的SQL注入攻击,其全球范围内的漏洞数量呈现出了非常显著的下降趋势,如图1-1所示。

image_0

图 1-1 SQL 注入漏洞数量趋势

然而并不是所有发生在应用程序中的安全漏洞的数量都得到了有效抑制,例如跨站脚本攻击漏洞的数量似乎并不受安全措施数量的影响,如图1-2所示。

image_1

图 1-2 XSS 漏洞数量趋势

一个现象是,企业为应对应用安全问题采取了各种措施,虽然有一定成效但是也有或多或少的问题,如图1-3所示,随着安全措施数量的增加,应用中的安全漏洞的数量不再显著减少。似乎无论如何努力,开发出来的应用中始终有安全漏洞。

image_2

图 1-3 安全措施和安全漏洞数量的关系

除此之外,企业还面临着更多的困境:

  • 安全漏洞总是很晚才被发现出来,造成的结果是安全漏洞的修复成本高昂。
  • 未能检查出隐藏在应用中的安全漏洞,含有安全缺陷的应用被发布到生产环境中,这将增加企业面临的安全风险。
  • 某些安全措施容易被误解为是团队的负担
  • 开发团队人员安全技能有所缺失,应用的安全性过度依赖于应用安全团队

2. 为何安全漏洞如此难以消除?

为消除安全漏洞,企业采取了不少措施,然而一个不争的事实是,企业主要依赖于Web应用防火墙(Web Application Firewall,下文简称WAF)和渗透测试(或安全审计)。然而问题在于,这两种措施固然有效,但是也存在着明显的不足。

2.1 WAF是把双刃剑

WAF主要的职责是阻挡攻击,为开发团队争取修复漏洞的时间。换言之,只要应用中存在安全问题的代码没有被修复,漏洞就会一直存在,一旦WAF规则被绕过,或者配置不当,反而会将应用置于更高的安全风险当中。此外,误报和漏报始终是WAF无法彻底解决的问题,与此同时,随着应用规模的扩大,业务逻辑复杂度的增加,对于WAF的管理维护难度也在不断增加。

2.2 渗透测试让企业面临两难的境地

渗透测试确实能发现安全漏洞,但是也存在着明显的不足。首先是太晚才能得到安全问题的反馈,因为通常而言,渗透测试会被安排在产品上线发布之前进行,此时如果检查出安全漏洞,企业反而会面临两难的境地:修复安全漏洞之后再发布产品,或者强行发布包含安全漏洞的产品。同修复业务缺陷一样,修复安全漏洞也是越晚修复成本越高,开发团队需要投入更多的时间和人力,而这可能导致产品推迟发布,错失市场机会;如果强行发布含有安全漏洞的产品,又将增加被黑客攻击利用的风险。

2.3 抛开现象看本质,问题的根源在于缺乏高效的安全反馈机制

应用中的安全漏洞是在开发过程当中由于各种原因被引入的,然而回顾现有的安全措施就会发现,其中大量的措施发生在应用程序开发过程之外,例如WAF、安全监控发生在产品上线之后,渗透测试需要等待开发完毕后才能进行,而安全培训、安全规范只能起到预防作用。尽管各种安全措施都能为开发团队提供不同程度的安全反馈信息,然而问题在于,大量的安全措施都发生在开发过程之外,距离安全问题被引入的时间点之间有很长的距离,因此安全问题不能及时的反馈给开发团队。

此外,由于不少安全措施的成本高、耗时长,因此难以持续性的为开发团队提供安全反馈。例如聘请第三方安全公司对应用进行安全渗透测试的价格较高,且往往需要几天甚至更多时间才能收到安全报告。

3. 更好的解决安全问题

安全漏洞本质上是软件质量缺陷,安全性是软件质量的重要组成部分,而现如今应用安全面临的问题和多年以前软件测试面临的问题极其相似。当时人们在开发软件的时候,采取的做法往往是在软件开发临近结束之时集中性的进行测试,修复发现的质量缺陷,结果是当时的软件质量普遍不高,不少项目因此失败。

为了提高软件质量,开发团队采取了一些措施,例如将测试介入的时间点提前,尽早进行测试,甚至是先写测试后写实现代码,与此同时也大量采用自动化测试来加快测试执行速度,采用构建流水线持续关注软件质量,并且每位团队成员都对软件质量负责,而不再认为只是测试人员的职责。这些措施之所以能够显著提高软件质量,关键在于它们能够更加高效的为开发团队提供软件质量相关的反馈信息,使得开发团队能够基于反馈结果迅速进行改进。

同理,要更好的解决安全问题,开发团队应当建立起一个高效的安全反馈机制,在开发过程中引入一些安全活动,尽早开始收集安全反馈信息,加快获取安全反馈的速度,在整个开发过程中持续性的关注应用的安全性,与此同时团队成员共同来承担安全职责。我们将这些在实践中总结出来的经验命名为内建安全的软件开发方式(Build Security In DnA,下文简称BSI),从源头上尽早、尽快、持续性的,以团队共同协作的方式发现并解决安全问题。

image_3

图 3-1 内建安全的软件开发方式 (Build Security In)

3.1 尽早获取安全反馈

越早获取到安全反馈信息,越有利于开发团队以更低的成本将其修复。一个反面例子是,安全问题在早期就已经引入了,但是只能通过后期的渗透测试才能暴露出来,安全反馈信息经历了很长一段时间才能反馈给开发团队。与其依赖于后期的渗透测试,不如在开发过程当中引入一些适当的安全实践,比如在分析业务需求的同时主动分析安全需求,将其作为质量验收标准在团队内明确出来,再比如,针对每次代码提交都对其进行安全评审、测试人员在测试业务功能的同时还对安全性进行验证。通过这种方式,使得团队能够尽快得知应用的安全状况,而不必依赖于很晚才能提供安全反馈的渗透测试。

image_4

图 3-2 在开发过程当中引入安全实践

3.2 通过自动化加速获取安全反馈的速度

从安全角度对代码进行的评审,以及测试人员主动进行安全测试等等手段都能更早的产出安全性的反馈信息,但是传统的安全测试、渗透测试主要是以手动的方式进行,造成的结果是需要耗费许多时间才能收集到安全反馈信息。更好的做法是,对于常规的安全测试可以借助工具以自动化的方式进行,不仅能够以更快的速度得到安全性反馈,还能在一定程度上弥补由于人员安全技能不足所造成的安全测试不够全面的问题。自动化带来的另外的好处是,它可以集成入CI服务器,从而让开发团队可以在CI流水线完成之后第一时间发现应用的常规安全问题,而不必等到上线前由安全专家来发现安全问题。

例如,应用通常依赖于各种第三方组件,这些组件可能含有已知的安全漏洞,手工对每个组件进行安全检查是行不通的,更好的做法是利用自动化的检查工具如OWASP Dependency Check,以更快的速度对组件进行安全检查并且生成结果报告。这一过程是完全自动化的,开发团队只需定期检查报告即可,使得开发团队获取反馈的速度得到极大的提升。

3.3 在开发过程中持续性的关注安全

收集安全反馈不是一次性的活动,高效的安全反馈机制和持续集成秉持相同的理念:除了尽早集成、尽快集成之外,很重要的一点就是让集成活动能够持续性的发生。类似的,对于建立高效的安全反馈机制而言,在能够尽早、快速的获取安全反馈的同时,还需要让这个反馈循机制在应用开发过程中持续的运行下去。

自动化使得开发团队能够更容易的做到对安全的持续关注。例如,将自动化的代码安全扫描和持续集成服务器结合起来,这样在每次代码提交后都能得到一份安全报告,从而可以立刻着手进行相应的修复。此外,对于那些不适合自动化运行的安全实践而言,开发团队依然有必要持续性的去做。例如,每当应用的功能发生变更之时都应该进行一次威胁建模以分析安全威胁,明确安全需求,每当新的功能被开发出来,测试人员都要对其安全性进行验证。

image_5

图 3-3 对安全保持持续性的关注

3.4 团队成员共同承担安全职责

大多数人认为团队中的测试人员应该对产品的安全负责,理由是他们要进行各种测试,安全测试理应包含在内。如果有专门的安全团队,则更多的人会认为安全团队应该主导产品的安全性,毕竟,在他们眼里这是安全团队天生的职责。

但这是一种误解,只要人们认为安全应该由团队中的某个角色或者某个独立的团队负责,就容易形成消极的氛围:既然有专门的人在负责产品安全,那就说明安全不是自己的职责,等发现安全问题了再说。这种氛围会带来很多负面影响,例如:安全问题难以及早发现并解决,人员安全技能得不到锻炼,安全改进在团队内难以推动,等等。

和传统的高度依赖于某个角色或者安全团队来保证产品安全的做法不同,BSI则是把安全职责拆分到团队中的每个角色身上,让所有人都参与进来,共同协作解决安全问题。每个人都肩负着维护产品安全性的责任,主动为此付出努力。

业务分析人员在分析业务需求的同时把产品的安全性纳入考虑的范围之内,如果他们没有相关的安全技能,则可以和技术人员合作共同来完成这一任务,与此同时,开发人员在编码的过程中有意识的去避开安全风险,并协助测试人员对产品进行安全测试。在产品交给安全团队进行安全审查之前,一些安全漏洞已经被发现并修复了,甚至在需求分析之时就已经被规避了。此时的产品已经具备了一定的安全性,也为安全团队争取到了更多的时间,使得他们可以把更多的精力放在检测深层次安全漏洞上面。

通过这种共同分担职责的方式,开发团队在应对安全问题上的内部凝聚力会得到增强,团队成员会更有意愿和动力去提升自己的安全能力。更重要的是,这种做法可以使得团队成员以及安全团队能更好的进行协作,从而逐渐形成良性循环。

image_6

图 3-4 共同承担安全职责

4. 总结

安全,是每个企业都需要做到的,在互联网时代更是重中之重。企业正面临着全新的安全挑战,然而现有的一些传统安全措施却并不能高效的解决这些问题,主要的原因在于过度依赖WAF、渗透测试等被动防御手段,往往是在比较晚的时候才获取的安全反馈,导致安全问题修复成本高昂,甚至使企业陷入进退两难的局面。

为了提高应用的安全性,并且弥补传统安全措施的不足,Build Security In应运而生:在软件开发过程中引入合适的安全实践以尽早发现安全问题,利用自动化的优势缩短安全问题的反馈周期,持续的、以共同协作的方式主动预知并化解安全问题。在减轻开发团队和安全团队负担的同时,提高发现、解决安全问题的效率。

安全不是绝对的,所以BSI对于安全的保证也是相对的,但是对于业务越来越复杂,规模越来越庞大的软件系统,BSI这种内建安全的软件开发方式必将从源头上减少安全风险,降低被黑客攻击的可能,从而显著减少系统在上线使用后因安全问题造成的损失,使其在互联网的大潮中生存下来。

Share