一、概述
首先，把要说的重点总结下，时间就是金钱，剩下的都是废话围绕这些去说的。（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神总结的）
甲方安全的痛点，在于话语权，公司是以业务为重，安全只是个辅助。因此前面提到的从根本上提高代码安全，推行制度落地流程，都是一个长期的缓慢工作。大的互联网公司安全都很强势，安全不达标系统不能上线，漏洞未按时修复直接影响绩效考核，但有能力做到流程化的基础安全后，才有精力去做业务安全，总之感觉路还很长……
