“一个人”的互金企业安全建设总结 – 作者:pur0

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

前言

之前的一个人安全部的77大师傅把我们拉在了一起,然后逐渐发现群里大师傅们也发了建设经验文章。好吧,这么懒得我也分享下自己的经验,也就当对这2年多来的甲方经验的总结。感谢群里的小伙伴们,感谢安全圈的各路大牛们和小伙伴们的帮助,更感谢朝夕相处的同事们的帮助。

一、概述

首先,把要说的重点总结下,时间就是金钱,剩下的都是废话围绕这些去说的。PS。本文所说的甲方安全,全部指一个或者两三个普通人的小团队,非大佬团队,非互联网航母企业)

安全一定要由上往下去推动

不制定奖惩措施的制度是很难推行落地的

外部机构的检查远远比自己找出来的问题更有影响力

作为甲方安全,你要以主人翁的角度去思考和推动,不要把开发看成敌人

不要任何事都自己造轮子,在现有的基础上加以改造

不要一直做救火队员,要推行有利于安全的流程

把安全做得有声音,最好有产出物(P神总结的)

 好了,开始废话了。

之所以把一个人加引号,是因为在甲方做安全,真的不能靠一个人来做,而是需要周围一切可以借助的资源去做,才能够做起来,否则很多事情举步难行,到头来树敌万千,工作也无法顺利进行。

接下来是我做过的事情时间点

2015年一套合规各类检查的管理体系,熟悉基础架构、初步了解业务。

2016年救火的一年,发现问题修复问题,同时规范流程(基础建设)

2017年把一些开源项目加入到环境中,弥补某些方面空缺(逐渐完善)

 今年618买了本书,《互联网企业安全高级指南》,神级的甲方建设指导的书,覆盖很全面,思路很清晰。

“一个人”的互金企业安全建设总结

三张表,1组织架构图,2产品和负责人对应表,3全网拓扑、逻辑架构、物理图、各系统间调用关系、数据关系流等,后面还有各类技术介绍,讲的很全面。

很庆幸自己没有走弯路,大体方向还对,不幸的是都是摸索的去做,会耽误时间,有些客观因素不能实现,比如团队。。。

二、2015

8月入职,一家具有支付牌照的互联网金融公司,网络运维部下。正好赶上支付牌照的认证,互金企业的监管机构太多了,等级保护,PCI DSS,ADSS,中金认证,人民银行……

于是,为了应对检测,先把现有制度熟悉了一遍,长远考虑,打算重新搞一套符合各位大爷的制度,在原有不熟悉的制度上改造不如重新做。

“一个人”的互金企业安全建设总结

管理制度制定的思路是依据ISO27001建立框架,分级制定“制度流程–操作手册–记录”。结合等级保护(许多人说等保只是应付,其实等保结合了各种标准,形成了一个安全基本要求,挺全面的)、ITIL(流程上可参考)、BS25999(业务连续性可参考)、NIST SP800-53 ISO27005(风险评估可参考),管理专业人士请教育,毕竟我也不太懂…

因为金融业的合规要求很多,仅仅27001的覆盖面是不够的,因此结合多一些完全覆盖各类合规检测。

其实我国的GB系列标准,已经引进了多个ISO标准,而且全中文看着很方便。下面是推荐参考的内容,完全足够。

ISO/IEC 27001:2013信息技术 安全技术 信息安全管理体系要求

ISO/IEC 27002:2013信息技术 安全技术 信息安全控制实用规则

GB/T 22239-2008 信息安全技术 信息系统安全等级保护基本要求

JR/T 0122-2014 非金融机构支付业务设施技术要求

GB/T 20271-2006 信息安全技术 信息系统通用安全技术要求

GB/T 18336-2008 信息技术 安全技术 信息技术安全性评估准则

GB/T 20984-2007 信息安全技术 信息安全风险评估规范

GB/T 20269-2006 信息安全技术 信息系统安全管理要求

GB/T 27910-2011 金融服务 信息安全指南

GA/T 708-2007 信息安全技术 信息系统安全等级保护体系框架

ISO 22301:2012 公共安全-业务连续性管理体系-要求

GB/T 20988—2007 信息安全技术-信息系统灾难恢复规范

GB/Z 20985-2007 信息技术 安全技术 信息安全事件管理指南

GB/Z 20986-2007 信息安全技术 信息安全事件分类分级指南

GB/T 24363-2009 信息安全技术 信息安全应急响应计划规范

制度的制定并不仅仅是应对检查,最终还是要落实,所以制度的细节一定要切合公司自身情况,尽量简单易于执行。虽然落实比较难,但流程的东西一定要落实,比如系统上线、变更要规范其安全标准化。一般安全是挂在运维下……就算不是也要和运维打好关系,把基础安全这层打牢,可以在运维推行部分流程,前面提到的4级文件形式,做过的事情要记录,记录尽量电子化,便于查阅,一是检查的时候真的有,没必要再造假了 – -!二是记录也可便于事后的总结、追溯,有一天会帮助到你的。等大家适应了流程,再一点点细化、增加,如果一口气推下去所有制度,很难落实。不想要一口吃成胖子,有了部分框架标准和流程,对于安全很重要了,你不会再浪费时间去查看对外开放端口、之前的struts漏洞新上的系统是否存在等等。

安全一定要由上往下去推动

不制定奖惩措施的制度是很难推行落地的

这是两条制度落地的关键,说多了都是泪,自己体会吧。最理想的状态是形成PDCA闭环,不断完善改进。

ps,互金企业更重视结果的记录,因此在做类似系统变更、补丁修复这样的操作时候要有记录,无论纸质或者电子的。

三、2016

这一年公司业务发展迅速,上线的系统也多了,起初还有时间挖挖漏洞,后来就是疲于上线扫描、定期扫描、漏洞修复,然而可怕的是同样的漏洞会再次出现,开发小伙伴们忙于进度是不会太注意安全的,立场不同。还好当时的CTO重视安全,运维领导极其重视安全,对于新公开的高危漏洞,群发邮件后,都会把各个技术负责人召集起来开会,自己评估是否影响并确定整改期限,领导的强势会有助于工作的进行。

这一年与某大互联网公司合作,签了安全服务,包括培训、渗透、抗D等等。他们挖出来的漏洞会被更重视(同类型问题自己找出来不会很受重视 > <)。所以啊安全开发、上线安全检测流程是必要存在的。

外部机构的检查远远比自己找出来的问题更有影响力

除了救火,其实另一半的工作是把基础安全做好,不要想一口气做好所有,一步一步来,让大家有个“温水煮青蛙”的过程,渐渐的都会适应。

个人感觉初期建设流程2个步骤足够了:

1.      发现目前不足

2.      针对不足加以完善

不要任何事都自己造轮子,在现有的基础上加以改造 

具体工作如下

网络方面:

1.      确认开放端口,nmap或masscan扫下,然后和防火墙策略对照下。只提供必要服务的端口,SSH这样的坚决不对外提供。

2.      交换机路由器基线配置,比如snmp配置不能用public

3.      网段的重新划分,访问控制策略的重新制定(起初提过但改动太大,后来外部渗透服务,拿到内网权限后坚决整改,事件驱动)。根据重要性划分网段,网段间严格访问策略(通过路由或ACL都行,目的达到即可),可做部分mac绑定,比如网关、重要网段,办公区wifi只允许连接互联网。

4.      堡垒机,所有设备、服务器均通过堡垒机访问

5.      IPS和WAF设备的规则优化,每周的攻击日志分析

系统方面:

其实运维团队基本都会有自己的一套标准,包括自动化部署、监控、日志收集等。因此要做的就是熟悉现有方法,加以完善。

如果在没有任何监控、安全措施的环境下,可以自己搭建一套SIEM,但是拿我们的环境来说,目前已经有了nagios、cacti监控网络、性能、进程,服务器文件完整性检测、puppet配置同步,定制的加固过的系统镜像,时间同步、日志收集措施,我觉得覆盖面已经足够了,不如在现有基础上进行优化。

欢迎大佬指教还欠缺哪些方面。

实现安全目标的方式有很多种,只要达到目的,最切合企业自身利益便好。

数据库真心不太懂,而且我们有oracle、mysql、SQLserver、mongoDB,核查下安全基线关注下漏洞动态…比如启动数据库的账号权限,数据库内的默认账号,生产库账号限制,访问权限限制。数据库审计我见到的基本没人开的,影响效率。但是对于数据安全,互金企业对其要求极高,数据的存储、加密、传输、备份恢复都有严格要求,按照监管机构的要求去做就好了╮(╯▽╰)╭

ps,作为互金企业,对灾备切换极其重视,因此每年的灾备演练要确实去做。

应用安全,其实本质还是要提高代码安全,请了外部培训、外部渗透测试,也没有搞好这方面,这也是甲方安全的一个痛点。其实人与人之间的交流都一样的,与开发交流,要用“咱们”,不要挑开发的问题,要说成那些讨厌的人会不正常的去输入内容,绕过web界面直接修改数据包等等,原则上是找共同利益点,多赞美,人性所在啊。换个角度去想,作为开发任务挺紧的,实现功能、赶进度、改bug,突然来了个人和我说你的代码不安全,这样不行,WTF,你丫哪根葱你来写啊。所以互相理解吧。

1. 作为甲方安全,你要以主人翁的角度去思考和推动,不要把开发看成敌人

题目是带引号的一个人,因此我们要借助可以利用的各种资源去做安全。比如DDOS防御,我们是把服务器托管到IDC机房,对于DDOS防御肯定要借助外部力量,机房的流量清洗以及安全公司提供的抗D服务。再比如我们自己的DNS服务器,每天很多的攻击流量,于是采用外部的DNS服务,自己不再做DNS解析。

把自己无法做到的事情和非关键业务又浪费精力资源的事情,转交给专业的外部服务团队,性价比更高。

2. 作为甲方安全,其实起初在技术深度上下功夫,并不能给整体企业安全带来太多显著提升,反而流程上安全优化会有显著提升。先做纬度,再做深度。

比如你的开发同学将源码传到git上公开…

不要一直做救火队员,要推行有利于安全的流程

于是在频频救火的过程中,即使领导再重视,你依旧处于救火中。流程制定好,处理事情有条理,整体的企业安全会有显著提高。

最关心的流程我觉得就是安全事件,那么安全事件发生后第一时间得知,就需要一个监控汇上报过程,包括技术上的监控系统,非技术层面的运营人员发现系统故障。向谁上报,上报哪些内容,如何处理,由谁处理,处理优先级,处理方法,总结积累。

从这个流程可以看到,我们需要业务连续性分析(处理优先级),应急手册(处理方法),可能这些东西太虚,但起码你要了解自己公司的哪些业务重要,遇到不同安全事件如何处理,需要外部资源联系谁。

每一年可以集中对这些事件进行分析总结,然后根据结果进一步优化代码也好,架构也好,进一步提升安全能力。

“一个人”的互金企业安全建设总结

总之,我觉得重要的2个流程:

1.      安全事件处理流程

2.      系统上下线流程(资产信息变更、基线确认、安全测试等,最有效的把系统安全提升到及格分数)

这一年还确定了安全预警流程、漏洞修复流程以及下图中运维相关的流程。

制定流程要切合实际,便于落地执行,精简。至于是否完全合理,在今后的工作中逐渐微调,总之先有一个流程先让大家适应。其次,要把权限责任分散出去,流程可以是自己制定或者和同事一起,但至于流程的执行负责人分开管理,让大家知道谁负责哪些,该有什么流程,既起到了规范作用,又减少了出现坑的机率了。

“一个人”的互金企业安全建设总结

四、2017

这一年,日常的安全日志分析、漏洞预警、季度扫描、上线测试、漏洞修复、安全事件处理、合规检查已经轻车熟路了,再在原有基础上优化流程,就可以腾出来时间搞些开源的东西。当年做计划的时候写了威胁感知,那时候概念很火,后来给了自己一个大嘴巴,没有大数据根本搞不了这玩意。

目前环境中,没有源代码扫描、日志分析系统,ips和waf都是商业化产品,有时发现一些细节问题无法定制化,资产的管理系统是人工录入,存在延迟更新、失误导致的错误数据风险。于是应用了下面这些开源项目

1.      巡风扫描,感觉最好用的是资产管理,可以查看哪些IP开放了什么端口,开放了某端口有哪些IP…可以比我们的监控系统更简单更全面搜索(毕竟服务器多了人为操作难免会有遗漏加监控等等),还可以自己尝试写写漏洞检测脚本。

2.      Nginx-lua-waf,很实用,基于openresty,可以自己写规则防御某些有针对性的攻击,然而总是与时代慢了一步,AI联动waf的时代已经来临了,尤其兜哥出了AI安全三部曲以后…

3.      Yasca,源代码扫描,几年前的东西了,支持Java, C/C++, HTML, JavaScript, ASP, ColdFusion, PHP, COBOL, .NET…支持挺多的还免费…而且集成了PMD,JLint等很多常用源代码检测工具,建议在git下载,版本较新。如果是PHP大神还可以定制更改。

4.      ELK,日志分析,后来公司买了套类似产品…然后我就不再花费精力研究这个了。

推荐些常用的吧,小伙伴们都说好的,很多我都没用过。

网络入侵检测snort的时代过去了,现在基本用suricata。主机入侵检测ossec。Siem产品ossim,跳板机jumpserver,蜜罐t-pot、Awesome Honeypots。

还有个安全思维导图大全:https://github.com/SecWiki/sec-chart?files=1

当基础安全做好,纬度够了,接下来就是要做深度的事情了。

安全开发知识库:对应各类威胁,不断积累的一个代码库。

蜜罐系统:知己知彼,百战不殆。

AI:先看书学习吧 > <

业务安全:互金行业对业务的功能要求蛮多的,而作为互金企业,风控是一个重点工作,我不清楚大的互联网公司风控和业务安全是如何归属,但是业务安全做得好,防止企业利益受损,是看的见的收益。

五、总结

产出物这个问题,很多人总要搭建一个乌云知识库,一个XSS平台等等,我心想有哪个公司的开发会有时间去玩他,乌云知识库网上有,公司资源紧张我没必要再搞了。现在我终于清楚为什么要搭建了。

把安全做得有声音,最好有产出物(P神总结的)

甲方安全的痛点,在于话语权,公司是以业务为重,安全只是个辅助。因此前面提到的从根本上提高代码安全,推行制度落地流程,都是一个长期的缓慢工作。大的互联网公司安全都很强势,安全不达标系统不能上线,漏洞未按时修复直接影响绩效考核,但有能力做到流程化的基础安全后,才有精力去做业务安全,总之感觉路还很长……

烦请各位大佬指点,灰常感谢。新年快乐~

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

来源:freebuf.com 2018-01-04 09:00:17 by: pur0

© 版权声明
THE END
喜欢就支持一下吧
点赞0
分享
评论 抢沙发

请登录后发表评论