金融企业安全建设探索之四个安全建设问题

释放双眼,带上耳机,听听看~!

编者按:本文内容来自金融业企业安全建设微信群的聊天记录,来源于企业安全建设的资深前辈经验分享,干货满满,希望为有需要的人提供更全面的安全知识和技巧。由长亭科技安全志栏目团队整理,版权归属微信群全体成员,转载前请联系本公众号。


近期金融企业安全建设群的安全负责人又忙里偷闲,探讨了四个问题:Web攻击很多怎么办?企业安全部门应该管什么?公有云运维安全很好做吗?企业文件加密难,谁来背锅?听听企业安全建设的负责人怎么说。

一、Web攻击很多怎么办?




“在线等,挺急的,来自香港的扫描或者Web攻击很多怎么办?”


“习惯就好”



以上可能是安全圈很常见的自嘲式问答,段子之一。


黑客技术已经实现了质变的提升,各种硬件工具和技术软件的应用,使得针对网页端的攻击日渐频繁,又具备多样变形的特点,对安全从业人员的应对措施,提出了更高的要求。


首先要和大家探讨的是:


web攻击常见的防御手段


最通用防御手段:封IP!


这个好像并没有什么好解释的,无论从操作方法,还是实现途径上,说多了都是尴尬。


升级版防御手段:WAF部署方式


WAF的部署方式有很多,最适合的方案,才能有最佳的效果。


前辈们在这方面给出了如下的建议:


我在考虑WAF的部署方式,是否应该串行在链路上,或者有其他更好的方法?

串行没有问题,也可以旁路然后发RST阻断。


旁路的话有问题应该怎么处理?

只要不影响业务,有各种bypass就可以。


旁路的RST效率不高啊,而且感觉会漏?

GFW就是旁路的,一般会漏第一个包。串的话,有些盒子扛不住,买之前肯定有了解WAF能支持多大qps流量。

最佳实践防御手段:IPS规则库升级


很好的防御方法之一,S2-045漏洞被发现当天IPS就已经能检测了。

然而,有时难免蛋疼的是:有些防护设备升级事件库有版本依赖,设备会丢包或者重启,网络就会切换,而且,现在升级总是不及时……

紧急事件案例
以下这则是安全人员发生的真实案例。

安全情况:“IPS拦截的struts2告警,源居然是内网地址,目的是互联网地址。其他告警又正常,什么情况?”


最佳建议:

• 出问题第一步就是要查询日志。事件管理器日志,网络日志,记得马上把日志备份转移。

• 建议先从防火墙入口查询所有出去的端口是否有异常行为,基本上如果多了一个端口,就要小心了。因为,如果有入侵,日志可能第一时间被删除,这是作为一个黑客最基本的操作了。PS:只针对服务器的所有端口操作。

• 最好做下入侵测试。

• 检查服务器地址,确认服务器是否被控制,尝试挖出间谍或肉鸡。


安全大事件回顾

S2-045漏洞


数字触目惊心:

两天1万个漏洞

全网一共7万多中招


简单粗暴得令人发指:

挖St2的漏洞太容易了,小朋友都可以

St2的漏洞都谈不上挖,敲回车就好


针对未知漏洞预防,大拿解决方案:

在不需要执行本身命令的情况下,只要把Java执行本地权限的功能去掉,就可以解决很多问题,包括普通用户执行Java进程。这种方法基本上可以解决掉这一类问题,而且比较彻底。这种思路可以用来提前预防未知漏洞,可以先简单点,比如用普通用户执行Java,Java hook也不是太复杂,而且这些代码都是开源的,Java虚拟机代码是闭源的,库都是开源的。弊端:有时候,可能做起来有些麻烦,直接干掉函数,后台好多java,运维自己都不知道有多少。

二、企业安全部门应该管什么?

毋庸置疑,在一切都向线上转移的今天,企业的网络信息安全,已经成为一个不可忽视的组成部分。

 

越来越多的企业开始设置安全部门。安全从业人员的数量在增加,话语权在增多,肩上的担子也越来越重大。在各大会议、论坛沙龙、内部管理会议上,企业安全的提及率也越来越高。

 

然而,在实际的工作中,安全也难免遇到问题。正如同企业的其他部门一样,安全部门也同样需要协作和分工,也同样会面临预算有限的状况,或是人手、精力和工作量发生冲突等问题,短期内若没有更好的方法缓解,恰当的取舍则无疑成为一项必要能力。

 

在安全越来越被重视的今天,

你的公司安全部门是独立的吗?
事事都关安全是不是事事都要管呢?
安全部门的工作范围明确吗?

例如:终端管理要谁来管?


各家企业的答案不尽相同,诸如:

1

我们这行丢给运行了。部署和运维,可以丢出去啊,安全管结果、管审计;产品选型,肯定要关心,尽量、努力促成自己中意的。

2
我理解安全可以说终端必须要做到什么程度,实施不一定安全做。应该有终端的安全基线,终端管理很麻烦,要是多个产品客户端就更烦。如果有足够的人,作为安全部门我是希望能管的。个人期望检测类信息都能汇总到安全。
3
补丁、软件、分发、资产,肯定都要丢出去,远程协助之类的肯定给helpdesk了。产品层面差别不大,关心下实施和后续支持能力就行。我看好多行,基础管理还是要包括终端的。
4

安全应该主管方案、策略、要求、审计,以及前期落地交付,后期的三期维护。

5

我们的终端在运维,dlp在自己手上。整体策略和审计还是我们做。


安全工作的现状,何至于此?


有人说因为人贵,有人说因为人手不足(其实和人贵是一个道理),有人说负担太重(其实和人少又是一个道理)。 

1

槽点一:安全的人很贵,又难招。

2
槽点二:我们以前什么都管,但是人少效果差,今年开始改成只做管理和建设,其他都交给运维和开发。
3
槽点三:什么都搞,负担太重,团队无法建设!


可是以上这些,不是我们每个部门都会遇到的问题吗?

如何解决?

1

安全部门要定好自己的位,什么都管,能管得过来?

2
最好是多说少做,多检查少运维,多帮人家解决问题,不要提出问题不解决,检查出问题协助兄弟部门解决问题。
3
安全团队修路,大家在上面跑自己的需求,出了问题自己负责,有了需求提需求,操作各部门自己做。

安全部门负责人想要做好安全部门的定位和管理工作,不仅需具备极强的业务能力,管理能力、沟通能力、应变能力也不可或缺,这也是为什么顶尖安全人才千金难求的原因之一。

三、公有云运维安全很好做吗?

云时代来临,传统IT环境都在向云上迁移,对于大多数规模和体量不太大的用户来说,建设私有云并不现实,性价比更高的公有云显然是最好的选择,所以公有云的运维安全也越来越引起企业重视。

目前使用公有云的用户可以分为两类:

1

一开始业务就完全部署在公有云上面,主要以新兴互联网公司为主。

例如快速成长的社交媒体网站Pinterest就使用了150个AWS实例,所存储的数据目前已超过了400TB,这样一个新创企业就把自己的所有应用都放在了公有云上。


2

已经有自建的IT环境,需要向公有云上迁移。

伴随着用户IT环境从传统自建IDC向公有云环境的转变,运维工作也从内网环境迁移到公网中,这对用户来说是一个非常大的改变。


但云时代中,抱怨声也不绝于耳:

“公有云的访问控制比传统数据中心还难做,某云服务商上的安全组是单机防火墙(配策略要死要死的),另外一家的安全组类似网络防火墙,但只能命令行下做配置,没有对象复用等网络防火墙管理系统的其他功能。有公司选择针对公有云开发了安全管控平台,才能够实现灵活的访问控制。”



诚然,计算环境从本地到云端自身安全性是提高了,但云上的运维工作却面临着一些新的安全风险和挑战。公有云的运维管理工作必须通过互联网完成,和传统IT环境运维有很大不同。

常见风险来源:

1

运维流量被劫持:





公共云场景下运维最大的变化就是运维通道不在内网,而是完全通过互联网直接访问公共云上的各种运维管理接口。很容易被嗅探或被中间人劫持攻击,造成运维管理账号和凭证泄露。

2

运维管理接口暴露面增大:





原来黑客需要入侵到内网才能暴力破解运维管理接口的密码,而现在公共云上的用户一般都是将SSH、RDP或其它应用系统的管理接口直接暴露在互联网。只能依靠认证这一道防线来保证安全,黑客仅需破解密码或绕过认证机制就能直接获取管理员权限。

3

账号及权限管理困难:





多人共享系统账号密码,都使用超级管理员权限,存在账号信息泄露和越权操作风险。

4

操作记录缺失:





公共云中的资源可以通过管理控制台、API、操作系统、应用系统多个层面进行操作。如果没有操作记录,一旦出现被入侵或内部越权滥用的情况将无法追查损失和定位入侵者。


资料显示,如今不少云服务商针对以上风险都提供了相应的解决方案。

但有时最大的风险却是来自于云服务厂商本身:


案例一:2015年,某云服务商出现大规模宕机情况,多款APP、以及多家使用其服务的网站出现无响应的情况。

案例二:某云服务商发生服务中断事故,全部28个数据中心中有26个受到影响。所影响区域的用户无法创建、更新和删除数据资源。

案例三:某云服务商机房内网发生故障,大量互联网公司业务受到影响,客户正常文件被误隔离,所有基本命令都不能运行。

案例四:今年年初,某云服务商突然发生重大故障,事故持续时间超过4小时,部分客户损失惨重。


种种停机事件和服务中断事故说明,现阶段公有云在可靠性上存在很大问题。为了使公有云能更好服务大众,公有云服务商应该不断从技术手段做出改进,而用户也要重新审视什么样的业务才适合公有云。

公有云的运维安全到底该怎么做?

1
公有云并不适合于所有组织
也并不适合于一个组织内的所有应用。一般来说,适合于公有云的企业应用都没有很严格的安全要求。在网站、应用开发、测试、在线产品目录和产品文档等案例中,大多数云服务提供商(CSP)所提供的默认安全足以应付此类应用的安全需求。
2
企业安全部门要评估并强化安全策略。
CSP所提供的公有云安全千差万别,有厂商的产品还增加了身份验证层,这里需要权衡:是需要更好的公有云安全还是需要降低可能增加的网络延迟成本、性能退化以及额外故障点。
3
数据库风险感知:大多数公有云泄漏事件的攻击目标直指核心数据库资产,安全漏洞攻击、SQL注入、病毒感染等常用手段正在不断演变攻击形态。通过数据库审计对应用侧和运维侧进行的数据库行为采集,能够帮助我们形成完善的语句结构模型,确保威胁发生的第一时间准确感知来自外部或内部的安全风险。
4
数据库数据加密:
数据库加密技术是整个公有云安全防护思路的关键点,当威胁渗透至核心数据库,对数据库加密是底线防守的终极武器。在确保企业对密钥可控的同时,按需采用灵活合理的数据加密技术保护核心数据库是关键。
5

采用多家、冗余的CSP分散风险:从多家厂商购买连接数据中心的高带宽,是一种常见的做法,这是因为企业希望将风险在多家提供商之间分散。如果一家CSP宕机,其他厂商依然可以正常运行。目前,有不少云配置工具都已集成在了领先CSP的服务中。如果采用这种方式,再发生厂商服务中断事件就不会对企业的应用造成不利影响了。



权衡公有云的安全与性能


虽然安全是很多企业在使用公有云作为IaaS时的首要关注问题,但是也有不少方法可以有效地解决这一问题。最简单的方法就是只将最不敏感的应用和数据迁移到公有云中。

如果企业决定把关键任务应用迁移到云中,则需要在CSP所提供的安全措施之外再增加一些安全措施。不过在增加公有云安全层时总是需要进行一番权衡的,因为这样做有可能增加故障点或导致应用运行得更慢。在安全和性能之间寻找恰当的平衡点可能是困难的,但努力实现这种平衡则会让企业感到安心。


越来越多的企业加入了公有云的队伍,这也意味着越来越多的用户信息被迁移到了云上,能否做好公有云的运维安全必将成为决定企业未来能走多远的关键因素。

四、企业文件加密难,谁来背锅?

企业内部文件,一旦被黑客窃取,其损失不堪设想。所以企业中,对文件进行加密处理成为一种共识。

为什么要文件加密?

互联网上进行文件传输、电子邮件商务往来等活动,存在着许多不安全因素,而且这种不安全性是互联网存在的基础——TCP/IP协议所固有的,包括一些基于TCP/IP的服务。所以为了保证安全,我们必须给文件加密。

加密我们可能这样做

   首先想到的可能就是用WinRAR进行加密。
最大的优点是简单易用,而且使用AES加密算法,文件的安全基本能得到保证。但用此法的安全程度也依旧受到口令长度、复杂程度的影响。且WinRAR无法针对大范围的分区进行整体加密,无法满足企业对于内部机密文件加密的需求。

   
使用某些免费的文件加密软件

随便检索一下“文件加密软件”,会出现各种所谓免费的加密软件。介绍中它们会把自己包装成无所不能的“高手”,不仅能保障文件安全,而且宣称加密速度快、适配各种系统等等。然而,世间并没有此等“天上掉馅饼”的好事。因为使用这些免费的加密软件而导致重要资料丢失、被盗的事件数不胜数。



现有加密软件,大牛们的体验如何?

   某软件,加密利器,可以和outlook等邮箱工具无缝集成。收费和开源,两者互通。

   某老牌软件,十几年前的初代产品,数据防渗漏、源代码加密,用户体验极差。现在有几种方式有突破:一种是进程伪造,一种是用白名单伪造exchange的证书,一种是至今未解决的漏洞可以通过micro的云服务,把文件不加密保存在云端。

   种种DLP我都测试过,说句得罪人多话,不太满意。


我们知道,信息安全要上个台阶,加密或者防泄密不可少。但各种软件的效果着实令人左右为难。

  有人说:

文件加密就是个投入巨大,又没有什么成效的无效方案,必定会失败。

  有人说:

网络安全是找保安,数据安全是找保镖。信任机制,投入,授权完全不一样。


各大公司针对文档加密做过哪些措施?

  措施1:

重要的文档和普通的分开处理。

  措施2:

个人觉得做dlp比做加密靠谱点。文档加密麻烦的是秘钥管理和过度加密问题,dlp的问题是规则和漏误报的问题,不过dlp误报没关系,安全增加点工作而已;漏报也没关系,起码有审计嘛!

  措施3:

关于文档传输几种途径:邮件、网页、共享、USB,首先得审计,其次是控制。

  措施4:

我们这样的公司,没有办法强势加密方案,需要综合的治理方案,文件共享的方式,各种技术措施的选择和应用,如文件网关,edlp,ndlp,mdm,业务应用系统内置安全机制……员工的管理和教育,客户的教育和风控,要考虑的地方和场景复杂,没有哪种技术措施可以全面hold住这样的体系。当然,畏难和不作为是不行的,还是要不断前行。

  措施5:

我司现在的情况,前人任性地上了文档加密,现在看,文档泄露问题还是没有根本解决,而带来的各种兼容性问题很是呵呵。但是,已有的制度和投资,撤下来又有很大难度,骑虎难下了。

  措施6:

除非上层有强制要求,不建议做文档加密给自己刨坑。


文件加密,真的没有彻底解决方法吗?

dlp这招好使吗?

没有数据的分类分级,dlp就是镜中花水中月。

其实,加密要看需求和场景,通用解决方案没有,也不会有。管研发人员源码和管办公人员文档、外部审计人员调资料查阅、事后追踪和溯源,这些就是不同场景和需求,解决办法是不同的。企业里面泄密的很多源头不是你管住的那些好人。

如果只想着用某一种方案而得以一劳永逸,很多时候便会使安全运维工作陷入僵局:

  熟悉的场景?

一套安全解决方案,不调研实际情况,不摸清真实需求,将矛盾上交,由决策层拍板上,实施起来一刀切,搞得鸡飞狗跳,又没有解决实际问题,最后归结于这届员工不行,找解决方案厂商背锅了事,然后抱怨安全难做。

其实自己才是最大的问题。日拱一卒,每天都解决一点点,才是正道。

具体措施

多层治理机制


– 在外部审计调阅资料或封闭场景,使用透明加解密。

– 在办公环境下,重点投入事后追踪和溯源,保持良好的用户体验。

– 在IT部门内部,管理尽可能严格,严格的措施大家都能想到。

– 在交易区,注意敏感数据源的防护。

—————–我是分界线———————


 

人生最美好的莫过于各种经历和难忘的体验,过程比较痛苦的,结果都还比较好。如果大家和我一样,在企业做安全中遇到各种颇为“痛苦”的体历,过后你一定会感谢和怀念这份体历的。

 

 

附注:

  • 聂君,信息安全从业人员,十余年金融行业信息安全从业经历,默默无闻。好读书,不求甚解。性格开朗,爱好足球。

  • 本订阅号文章是个人对工作生活的一些体验和经历分享,站在不同角度和立场解读会有偏差,见仁见智,不求正确统一,但求真、善、美。



想加入金融业企业安全建设群请联系微信公众号“君哥的体历”,后台留言,微信号+公司名称,验证身份后入群,为保障群质量,不保证都能通过验证。


长按识别二维码,和我交流。


本文源自微信公众号:君哥的体历

人已赞赏
安全工具

我的CISSP之路

2019-10-16 13:52:02

安全工具

安全从业者存在的意义

2019-10-16 13:52:13

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索