对于当前大量企业在系统安全上面对的困境,其重要原因是软件在其开发的时候没有进行安全相关实践,从而引入的各种安全问题,比如业务分析的时候,架构设计的时候,编写代码的时候等。针对这些安全问题,应该如何有效的发现和消除它们,关键在于整个软件开发生命周期内都应使用各种正确和合理的安全实践。
现代软件开发一般包括项目计划与评估,需求获取与分析,架构设计,编码实现,验证测试,问题修复,软件交付等步骤。为了阻止和减少安全问题出现在产品系统中,需要在软件开发中实施相应的安全实践,从而缩短安全问题的反馈周期,增加其反馈途径,从而更早和更快的发现和解决安全问题。
但是由于现在的主流安全实践还是靠安全专家手工进行,导致成本非常高,所以很多企业都没有办法进行全方位的安全保障。而BSI主要是通过开发团队中已有的角色来实施安全实践,并利用大量的自动化安全扫描和安全测试技术来快速发现安全问题,从而做到真正意义上的全方位安全开发。以前一章中P2P的项目为例,来看看企业应当如何实施BSI。
项目规划
在项目开始,大多数情况下没有进行什么安全实践,但是由于这个时候中开发团队一般都是准备一些预演的工作,此时正好可以对整个团队进行安全培训,从而为后面的需求分析和开发测试工作进行准备。
由于这个P2P项目包含Web服务器端,手机应用端,服务器业务端等,所以团队中将有服务器端开发人员,手机端开发人员,Web开发人员,数据开发人员,业务分析人员等。如此多类型和数量的开发人员,只要有任何一个人在参与系统开发的时候埋下一个安全漏洞,如果在测试过程中没有发现就会进入产品环境。所以需要对他们进行安全培训,比如开发人员OWASP TOP10,Mobile TOP 10等技术类安全知识培训,对业务分析人员进行安全意识和安全业务分析的培训,比如社会工程学等安全知识培训。
需求分析
需求是软件的灵魂,需求获取和分析出了问题,就等于人的精神出了问题,就算再强壮,也一直需要医生治疗。如果需求没有考虑安全,就像一个没有设防的儿童,很容易被骗,甚至被诱拐。所以需求分析的时候一定要考虑安全问题,比如业务上存在某种安全漏洞,就需要从攻击者的角度去思考如何利用这个漏洞进行攻击,这种假设的攻击场景称之为Evil Scenario。
此P2P项目里面的认证授权和金融业务规则是非常复杂的,比如特定用户只能访问特定授权过的产品,不同的产品有不同的申请流程和使用流程等。业务人员在获取和分析业务时应该思考业务流程中的安全漏洞和如何使用这个安全漏洞的场景(Evil Scenario),比如一个用户尝试去使用未授权的产品,一个用户尝试去访问其他用户的信息等。
架构设计
软件架构与设计是非常重要的,它决定了整个软件如何实现其业务架构与数据流程。而复杂业务系统的架构和数据流是非常复杂的,很难短时间学习并理解清楚,所以也很难在短时间内发现其安全漏洞。由于架构设计人员对于软件的架构最为熟悉,所以应当在设计的时候或者开发之前分析架构中的安全漏洞与威胁,比如使用Threat Modeling等方法,快速反馈安全漏洞,把安全漏洞扼杀在摇篮中。
此P2P项目包含Android,iOS, Web Application, Web Service 以及和第三方支付系统(包括银行系统)的对接,所以架构师在设计系统架构的时候需要充分考虑各个层面上的安全威胁,比如用户使用手机登录和访问的时候如何保证其唯一性而不会被黑客欺骗,在用户重置密码的时候如何保证不被盗取重置验证码等。可以通过Threat Modeling来帮助分析安全威胁和设计安全架构,其大致步骤是:首先对架构中的每个元素进行STRIDE分析,其次使用DREAD进行风险评估,最后创建Attack Tree来模拟攻击,帮助开发和测试人员理解系统可能存在的各种攻击。
编码实现
编码与实现是一个特别注意细节的过程,大量的代码由众多的开发人员编写,而不同的开发人员由于能力参差不齐,导致代码的质量也高低不同,特别是安全这方面更是在这个过程中特别容易出现问题。由于很难保证开发人员把安全实践应用到编码中,而通过人工代码复查的方式来检查代码安全问题的时间成本非常高,困难度也非常大,因此可以采用自动化的代码安全扫描,最大程度的降低时间成本和困难度,从而增加一个反馈环来快速发现、解决代码中的安全问题。除了自动化静态代码扫描,还应该对使用到的第三方依赖库进行安全扫描和实时漏洞监控,并且对开发试用的各种工具进行安全管理和检测。
此P2P项目中代码包含Java,Objective-C,JavaScript等多种类型的代码,使用的第三方库也十分众多,比如Spring,Hibernate,Apache CXF等。面对多种类型的编程语言和大量的第三方库,基本上不可能进行人工的全面扫描,需要使用工具来对其进行自动扫描,比如使用CheckMarx或者Fortify对代码进行扫描,再使用OWASP Dependency Check或Victims对第三方依赖库进行扫描。并将这些工具集成入CI中,然后进行每次提交扫描或者每天扫描,从而可以保证在代码提交的第一时间发现安全问题,从而能快速的解决它们。
验证测试
软件功能的验证与测试最为繁琐,而且成本也非常高,所以在平时软件测试过程中,除了验证测试功能、性能和可用性等之外,很难再投入大量时间和人力进行安全测试。通常只会在软件交付之前请安全专家进行短时间的安全审查,但是正如前面所说,这样是很难找到业务相关的漏洞。所以在验证测试过程中,测试人员应该验证在需求分析和架构设计中得到的Evil Scenario和Threat,并且使用安全扫描工具对系统进行自动化的动态安全扫描和渗透测试,从而能在平时的验证和测试工作中快速发现安全问题。
此P2P项目中的业务端众多,测试是一个非常头疼的过程。但是当前大量的自动化安全扫描工具可以帮助测试人员检测比较基础的安全漏洞,其中对于Web Application和Web Service可以使用ZAP或者Burp Suite进行服务器常规安全扫描,使用SQLMap可以进行SQL注入扫描,除此之外还可以使用自动化测试框架并基于Evil Scenario来开发自动化业务安全功能测试,最后将这些自动化扫描和测试放入CI中自动运行。
软件交付
在软件开发测试完毕,业务功能交互客户使用的时候,安全也是一个容易被忽视的问题。现在很多企业在部署或者使用软件的时候,对于安全只有一些常规方法,比如购买硬件、软件防火墙,入侵检测系统,监控系统等,但是这些方法往往不能检测业务相关的漏洞和第三方依赖库的安全性。所以对于运维人员要进行系统业务安全培训,以及依赖库漏洞的实时检测报警。
最后这个P2P产品开发完成并且交付使用了,企业应当针对服务器的运维人员进行业务安全培训,这包括管理员不能随意点击用户发来的信息或邮件里面的链接,开发人员应该帮助运维人员搭建实施漏洞检测与通知系统,整个部署流程应该全程自动化等。针对Android和iOS应用的发布也要采用全自动化流程,避免在某个开发人员的机器上手动生成应用来进行发布。
通过以上的安全开发流程,可以基本保证这个P2P产品系统没有常见安全问题,极大的降低被黑客攻击的危险。
对于短迭代开发,BSI同样也是适用的,只需要在迭代开发中加入相应的安全实践就可以了,如下图:
通过在软件开发中增加各种安全实践,从而增多安全问题的反馈渠道,缩短安全问题的反馈周期,使得安全问题可以快速反馈,持续改进。