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

前言

之前的一个人安全部的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

  1. 网段的重新划分,访问控制策略的重新制定(起初提过但改动太大,后来外部渗透服务,拿到内网权限后坚决整改,事件驱动)。根据重要性划分网段,网段间严格访问策略(通过路由或ACL都行,目的达到即可),可做部分mac绑定,比如网关、重要网段,办公区wifi只允许连接互联网。
  2. 堡垒机,所有设备、服务器均通过堡垒机访问
  3. 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神总结的)

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

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

原文发布于微信公众号 - FreeBuf(freebuf)

原文发表时间:2018-01-04

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏大数据文摘

一张图告诉你全球政府黑客的地理位置

1754
来自专栏华章科技

看上什么拿什么,拿完还不用结账?亚马逊用无人车技术开了家真超市

亚马逊前几天公布了一段视频,其内容显示它将在一个月后开放它在西雅图筹备的实体超市:一家买买买,不用付钱的超市。

922
来自专栏孟永辉

O2O公司改名:一场从一开始就注定失败的美梦?

2876
来自专栏大数据文摘

蒂姆·库克公开信:保护用户数据 FBI我们都敢拒绝

25612
来自专栏重庆的技术分享区

确保业务安全的4个基本要素

最近的网络安全漏洞和攻击使得商业和技术社区在安全性方面处于动荡状态。虽然我们可能会连续数小时谈论由技术人员、小黑客组织和非常幸运的“脚本小子”发起的攻击,但同样...

1071
来自专栏AI科技评论

业界 | AI 如何助力电网智能化?

根据The Conversation公布的最新数据,归功于风能和太阳能的大力发展,2016年英国可再生的清洁能源比重再创新高,是过去60年以来最清洁的电力结构。...

4394
来自专栏互联网数据官iCDO

iCDO一周数据:黑客称售8万个Facebook用户信息; 人人车陷数据造假事件;工信部:12家企业用户信息保护存在问题

据BBC报道,黑客称其已经窃取和公布了至少8.1万个Facebook用户账号的私人信息。黑客称,他们总共获取了1.2亿个Facebook用户账号的细节信息并试图...

791
来自专栏华章科技

揭秘:亚马逊鲜为人知的10大物流技术

亚马逊2012年7.75亿美金收购的Kiva Systems,大大提升了亚马逊的物流系统。据悉时至2015年亚马逊已经将机器人数量增至10000台,用于北美的各...

8743
来自专栏顶级程序员

现实版天眼系统,一个漏洞让小白都能追踪上亿美国人实时定位

电影中的天眼系统能够利用各种高科技追踪任何人的位置,这是美国人对于未来隐私的担忧。一家收集北美多达2亿手机用户的实时定位数据的公司,网站上出现了一个漏洞,任何人...

802
来自专栏人称T客

IBM为何不得不“另眼相看”华为服务器

以自己最优之产品,比别人入门级的产品,以凸显自己的优势,这不是值得称赞的田忌赛马之道,而是诡计也。 近日,“刀锋再起,赢刃未来”——2014 IBM新睿融合式刀...

3458

扫码关注云+社区

领取腾讯云代金券