e-works数字化企业网  »  文章频道  »  基础信息化  »  网络与安全

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

2018/1/13    来源:FreeBuf    作者:佚名      
关键字:企业安全建设  网络运维  
之前的一个人安全部的77大师傅把我们拉在了一起,然后逐渐发现群里大师傅们也发了建设经验文章。我也分享下自己的经验。
    前言
 
    之前的一个人安全部的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闭环,不断完善改进。
 
    互金企业更重视结果的记录,因此在做类似系统变更、补丁修复这样的操作时候要有记录,无论纸质或者电子的。
 
    三、2016年
 
    这一年公司业务发展迅速,上线的系统也多了,起初还有时间挖挖漏洞,后来就是疲于上线扫描、定期扫描、漏洞修复,然而可怕的是同样的漏洞会再次出现,开发小伙伴们忙于进度是不会太注意安全的,立场不同。还好当时的CTO重视安全,运维领导极其重视安全,对于新公开的高危漏洞,群发邮件后,都会把各个技术负责人召集起来开会,自己评估是否影响并确定整改期限,领导的强势会有助于工作的进行。
 
    这一年与某大互联网公司合作,签了安全服务,包括培训、渗透、抗D等等。他们挖出来的漏洞会被更重视(同类型问题自己找出来不会很受重视 > <)。所以啊安全开发、上线安全检测流程是必要存在的。
 
    外部机构的检查远远比自己找出来的问题更有影响力
 
    除了救火,其实另一半的工作是把基础安全做好,不要想一口气做好所有,一步一步来,让大家有个“温水煮青蛙”的过程,渐渐的都会适应。
 
    个人感觉初期建设流程2个步骤足够了:
 
    1.发现目前不足
 
    2.针对不足加以完善
 
    不要任何事都自己造轮子,在现有的基础上加以改造 
 
    具体工作如下
 
    网络方面:
 
    1.确认开放端口,nmap或masscan扫下,然后和防火墙策略对照下。只提供必要服务的端口,SSH这样的坚决不对外提供。
 
    2.交换机路由器基线配置,比如snmp配置不能用public
 
    3.网段的重新划分,访问控制策略的重新制定(起初提过但改动太大,后来外部渗透服务,拿到内网权限后坚决整改,事件驱动)。根据重要性划分网段,网段间严格访问策略(通过路由或ACL都行,目的达到即可),可做部分mac绑定,比如网关、重要网段,办公区wifi只允许连接互联网。
 
    4.堡垒机,所有设备、服务器均通过堡垒机访问
 
    5.IPS和WAF设备的规则优化,每周的攻击日志分析

责任编辑:李欢
本文为授权转载文章,任何人未经原授权方同意,不得复制、转载、摘编等任何方式进行使用,e-works不承担由此而产生的任何法律责任! 如有异议请及时告之,以便进行及时处理。联系方式:editor@e-works.net.cn tel:027-87592219/20/21。
e-works
官方微信
掌上
信息化
编辑推荐
新闻推荐
博客推荐
视频推荐