应用安全

前言一般安全都属于运维部下面,和上家公司的运维总监聊过几次一些日常安全工作能不能融入到DevOps中,没多久因为各种原因离职。18年入职5月一家第三方支付公司,前半年在各种检查中度过,监管形势严峻加上大领导对安全的重视,安全被推上了峰尖浪口,所有部门19年的目标都和安全挂钩。由于支付公司需要面对各种监管机构的检查,部分基础安全做的还是很不错的,经过近一年对公司的熟悉发现应用安全方面比较薄弱。这部分业内比较好的解决方案就是SDL,和各厂商交流过之后决定自己照葫芦画瓢在公司一点一点推广。一、精简版SDL上图为标准版的SDL,由于运维采用DevOps体系,测试也使用自动化进行功能测试,版本迭代周期比较快,安全人手不足加上对SDL的威胁建模等方法也一头雾水、如果把安全在加入整个流程会严重影响交付时间。在这种情况调研了一些业内的一些做法,决定把SDL化繁为简。精简版SDL如下:二、精简版SDL落地实践1安全培训教课书式的SDL核心之一就是安全培训,所以在安全培训上我们做了安全编码、安全意识、安全知识库、安全SDK1.1安全编码:我们在网上找了一些java安全编码规范、产品安全设计及开发安全规范结合公司实际业务出了一版。因为各种监管机构对培训都有要求,借此推了一下安全培训,定期对开发和新员工入职的培训。1.2安全意识:公司有企业微信公众号,大部分员工都关注了,在公众号推广了一波。宣传完之后答题,答题满分送小礼品。因为人手不足,而功能测试和安全测试本质上有很多相通的地方,测试部门也比较配合,针对测试人员做了一些安全测试相关的培训,但是效果并不是太理想。1.3安全知识库:在漏洞修复过程中,开发很多不太了解漏洞原理、修复方案,所以我们建立了安全知识库,开发先到安全知识库查相关解决方法。找不到的再和安全人员沟通,安全人员对知识库不断更新,形成一个闭环。1.4安全SDK由于公司有架构部门,开发框架基本是架构部门提供。我们将一些常见的漏洞和架构部门沟通之后,让架构将一些漏洞修复方式用SDK实现,开发只需要导入JAR包,在配置文件中配置即可。其中也挺多坑的,需要慢慢优化。2安全需求设计公司有项目立项系统,所有的项目立项都需要通过系统来进行立项,安全为必选项,评审会安全也必须要参与。这个时候基本上项目经理会找安全人员进行沟通,copy了一份VIP的产品安全设计规范,根据需求文档和项目经理确定安全需求。确认好安全需求之后将按需求加入到需求文档,并确认安全测试时间,此流程只针对新项目,已经上线的项目的需求并未按照此流程,后续在安全测试时候会讲到这部分的项目是怎么做的。3安全测试安全测试主要分为代码审计,漏洞扫描,手工安全测试。由此衍生出来的安全产品分为3类。DAST:动态应用程序安全测试(wvs,appscan)、SAST:静态应用程序安全测试(fortify,rips)、IAST:交互式应用程序安全测试(seeker,雳鉴),这三种产品的详细介绍可以参考https://www.aqniu.com/learn/46910.html,下图为三种产品的测试结果对比。这几类产品实现了自动化可以继承到DevOps中。接下来我们将这些工具融入到开发测试阶段。IAST的实现模式较多,常见的有代理模式、VPN、流量镜像、插桩模式,本文介绍最具代表性的2种模式,代理模式和插桩模式。一些调研过的产品如下图,具体测试结果就不公布了。3.1开发阶段在对几类产品调研的时候发现IAST的插桩模式可以直接放到开发环境,开发环境和测试环境的代码区别主要还是在于application.yml配置文件,所以可以提前将该模式放到开发阶段。开发写完代码提交到gitlab部署到开发环境启动应用的时候,开发需要验证一下功能是否可用,这个时候就可以检测出是否存在漏洞。公司在测试环境使用rancher,把IAST的jar包放入到项目的gitlab,在部署的时候把代码拉到本地,通过修改Dockerfile文件把jar包添加到容器。·ADDshell/xxx.jar/home/app/xx/lib由于公司项目基本统一使用spring-boot,所有的项目都通过一个start.sh脚本来启动应用,start.sh和Dockerfile一样需要添加到项目的gitlab,同时修改start.sh脚本文件即可。-javaagent:$APP_HOME/lib/xx.jar-jar$APP_HOME/app/*.jar--spring.profiles.active=dev>$APP_HOME/logs/startup.log2>&1&测试项目如下,忽略错别字:开发访问一下正常的功能即可在是否存在漏洞。部分产品同时还会检测第三方组件包。公司使用harbor来对镜像进行当仓库镜像,项目部署完成之后会打包成一个镜像上传到harbor,harbor自带镜像扫描功能。3.2测试阶段开发完成之后进入到测试阶段。这个阶段我们进行静态代码扫描,功能测试,安全测试。3.2.1静态代码扫描利用静态代码扫描工具对代码在编译之前进行扫描,并在静态代码层面上发现各种问题,其中包括安全问题。部分工具列表:由于预算有限,静态代码扫描采用sonarQube集成,我们使用的是FindbugSecurity,精简规则,然后在持续构建过程中,进行静态代码bug,安全扫描。静态代码扫描的同时也可以扫描第三方依赖包,OWSAP的Dependency-Check就可以集成到持续构建过程中,由于IAST类产品支持该功能,不多做介绍。3.2.2功能测试功能测试方面,公司测试部门实现了自动化测试平台,前期我们并未使用agent的方式检测,一开始使用开源的gourdscan加上openrasp,利用openrasp的默认开启不拦截模式和漏洞记录功能来检测服务端无返回的漏洞。后来测试反馈扫描的脏数据太多,效果也并不是很好,就放弃了此方案。改用开发阶段的IAST的插桩方式,同样在测试环境也和开发环境一样利用agent来检测问题。功能测试完成之后。测试人员到平台查看报告和安全人员沟通哪些问题需要修复,然后将问题写入到测试报告。3.2.3安全测试

2019-12-4 66 0