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

2018 年 1 月 4 日 FreeBuf 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. 确认开放端口，nmap或masscan扫下，然后和防火墙策略对照下。只提供必要服务的端口，SSH这样的坚决不对外提供。

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

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

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

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个流程：

安全事件处理流程

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

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

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

四、2017

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

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

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

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

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

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

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

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

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

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

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