小型互联网企业安全建设的管窥之见

2018-10-19 442015人围观 ,发现 10 个不明物体 企业安全

*本文原创作者:si1ence,本文属于FreeBuf原创奖励计划,未经许可禁止转载

0×0 背景

最近发现大家都在讨论一个人的安全部这个话题,两年前在某A轮互联网公司(80人左右的研发团队)做过一段一个人的安全部的经验就简单分享自己的经验。之前也在FreeBuf看到过很多关于这方面的规划设计的方案,私下觉得这样的规划是建立一些标准的信息安全体系之上的比较全面,真正的落地起来往往需要大量的人力物力和财力,很多一个人的安全部往往没有这么多预算只希望以最小的代价做好安全工作。

一点个人经验之谈,大佬们不喜勿喷。 

0×1 工作环境

往往也就是自己一个人做安全,通常就放在了测试部门或者运维部门或者开发部门,你的直属上级可能是一个经验丰富的开发大佬、运维大佬、或者有着PMP管理经验的项目经理,他们对于安全的理解并没有那么深刻。

目标就只有一个:安全还是很重要。你来了,安全方面的事情就交给你了,尽量不要再出安全事件了。

由于互联网公司往往提倡扁平化管理,公司的Boss对你也是有一定期待的:大家都说安全很重要,你要做好尽量少花钱。

51.jpg

0×2 工作计划

 主要系统产品可能包括手机APP包括安卓端与IOS端、几个对外的网站系统、几个对内的网站系统,涉及几十台主机系统。也许还被wooyun提交过一些较为严重的安全漏洞,所以当务之急是尽快发现未知的安全漏洞,先救火再治理分5步走。

图片1.png0×3 安全漏洞修复

首先需要确认范围从同事们手里拿到当前最新的应用系统清单与开发的同事确认一下使用了怎么样的技术组件等,顺便熟悉一下相关的一些业务流程与功能。

需要治理的安全漏洞主要简单的分为4类:

1.传统的web安全风险,如常见的sql盲注、cookies注入、多种xss、代码注入、CSRF、敏感数据泄漏、命令执行漏洞,文件包含、文件上传绕过、弱密码、任意文件下载等;

2.业务相关的安全风险,比如短信借口过滤不严格、越权查询、配置文件合理、校验不严格、验证码爆破、明文传输密码、任意用户密码重置等;

3.组件框架类安全风险,比如Struct2命令执行、Weblogic组件漏洞、jboss漏洞、ImageMagick命令执行、网页编辑器漏洞、Apace解析漏洞、Nginx解析漏洞、心脏出血等;

4.操作系统类风险,比如windows 338弱口令、MS08-067、http.sys命令执行 数据库的弱漏洞、Sqlserver的配置风险等。

为了梳理逻辑方面就简单画了个思维导图方面查看:

图片2.png

剩下的工作就是对每一个系统和应用进行测试、当然也许要借助一些成熟的安全工具进行测试。当时也想到一些不错的idea可以偷懒比如Burpsuit联动Sqlmap跑接口参数对测试sql注入与xss就能省下不少工作量、比如使用wvs的web端设置任务列表可以半夜扫描、检查linux配置项可以自己写shell、github找poc批量测试组件漏洞等等。

图片3.png其实还是一个比较费时间的工作,一个应用系统差不多一周到二周就测试完毕,毕竟996的工作模式。将发现的安全问题截图保存并梳理成excel表格提交给领导,并跟进后续的整改工作,后来发现常见的安全问题基本都有,比如一些参数遍历可以导致系统所有的订单数据被脱裤、还有短信验证码就4位又没有次数限制的情况也是很普遍的,想想还是觉得很可怕比较还是有不少个人数据。

0×4 应用加固

安全加固就是相对比较容易一些了,但是风险也是比较大的因为不清楚可能会造成什么样的影响,所以这个事情之前一定要给领导们说清楚先慢慢测试最后实施的时候出一个整体的方案。

主要包含Linux主机的加固、Windows主机的加固、数据库的策略优化、应用加固,其实google一下还是能搜到不少相关资料具体的流程还是要结合业务流程,内容大同小异。

图片4.png

图片5.png网站应用的防护既然不想花钱买waf就只有找开源的了,由于大量基于nginx的服务器当时主要在nginx+lua来实现WAF和nginx modsecurity之间选择纠结过,后期还是选择了lua方式。

连接如下:

https://github.com/SpiderLabs/ModSecurity

https://github.com/unixhot/waf

图片6.png

运维安全也是要有才行,既然不花钱买设备就使用开源的JumpServer,现在都已经支持docker部署了,当时我搭建这个还是花了一些时间,有需要的还可以做二次开发。

https://github.com/jumpserver/jumpserver

图片7.png

接口安全,由于一个应用有很多客户端比如IOS、安卓端、微信端等多种平台一套统一的API就显得格外重要了。由于接口很多参数的条件过滤不严格、权限控制不严格存在较大的安全隐患、整改起来工作量较大,于是想了一个简单的办法,对http提交的安全进行加密,主要采用AES加密保证了完整性和保密性,性能消耗也在毫秒级可以忽略不计。

图片8.png

由于有前车之鉴,对图片上传的控制就更加严格一些,最开始只是准备采用数据流的方式加上白名单进行校验,领导居然还觉得不够。于是就将所有的图片重名之后保存在另外的服务器,数据库当中只关联相关的访问的路径。

图片9.png

0×5 安全开发

开发的各位都是大佬们,当然不能得罪只能小心伺候着。但是安全也还是要做,那就只能提需求了,这里较多的参考了OWASP 指南,与各类编程语言的安全编码规范,但是又不能说别人代码有问题,只能说代码可以这样优化一下会更好。

代码审计的设备还是比较贵的、什么Fortify,Checkmarx就想都不要想了,还好有一些开源的代码审计工具可以用用。

RIPS:

https://sourceforge.net/projects/rips-scanner/

VCG(VisualCodeGrepper):

http://sourceforge.net/projects/visualcodegrepp/

对于编码完成之后的项目,都可以去跑一下但是涉及到的误报也是相当的多,所以静态扫描一般就只解决高中风险的问题,自己还要配合开发大佬们一起看看是不是问题还要说一下要怎么优化会更好,开发大佬是得罪不起的。

图片10.png

0×6 安全测试

在中小型企业推SDL落地其实就有点扯淡了,谈ISO27001之类的安全体系也没有那么精力支撑。对上线前的应用系统主要进行安全测试,主要还是部署漏扫工具,主要没有什么大问题其他都好说。

比如在Kali下面就集成了ZAP、openvas和github上也能找到一些扫描工具重点关注一些高位漏洞风险大的问题,有预算的可以考虑买了个Appscan或者WVS的商业版也不是特别贵,pojie版不推荐如果不怕版权也无所谓。

大版本有较多新代码的版本就自己手动测试一下,不过还好频率也不是特别频繁,发现的问题及时修正可以在内部jira这种缺陷管理工具注册一个帐号专门来提安全Bug。

图片11.png

0×7 安全运营

运营工作工作主要分成三个部分:

第一,将日常发现的安全问题、被各大SRC披露的安全问题及时响应并跟进修复,形成案例库定期给开发大佬们交流经验根本不敢说是培训。

第二,及时跟进一些最新的安全漏洞、最新的攻击手法督促开发大佬修补。

第三,总结工作内容,日常给领导汇报体现价值。

0×8 总结

一个人的安全部有时候压力还是很大的,要和很多对安全不是很了解大佬们一起工作总会被嫌弃,感觉是亲妈不要后娘不爱的感觉。领导们的想法也很简单,只要不出特别大的安全事件不花太多钱工作自由度还是比较高的,累了乏了的时候刷刷乌云逛逛freebuf,对个人的整体的安全能力建设还是很有帮助的。

当然一个人的安全部也可以很欢乐,同事们都比较好相处很友善也没有那么多条条框框。当初s2-032漏洞刚刚出来的时候wooyun都被刷屏了大家连夜修复的漏洞之后一起坐在成都的路边撸串,感觉也是过的很巴适。

50.jpg*本文原创作者:si1ence,本文属于FreeBuf原创奖励计划,未经许可禁止转载

这些评论亮了

  • 西门吹牛 回复
    安全没有和业务挂钩,在甲方公司一般都低人一等
    )8( 亮了
发表评论

已有 10 条评论

取消
Loading...
css.php