一个银行信息安全人眼中的Capital One数据泄露看法


来源:微信号BRDC蓝军    作者:阿吉塔    2019-8-6 9:11

最近安全圈里出了一件大事。7月29日,美国第七大银行Capital One称客户信息遭黑客窃取,被窃取信息数量约1.06亿条,涉及信息主要为2005~2009年期间该银行的信用卡用户的各项信息。

事件一经披露,导致Capital One股价大跌,并面临法律赔偿。作为美国第五大信用卡签发方,Capital One此次信息泄露有可能成为美国历史上最大规模的银行数据泄露事件。据外媒披露,黑客可能是利用了Capital One的防火墙的错误配置,入侵到其托管在亚马逊(Amazon)的AWS云端数据库,进而实施了数据窃取。

信息防泄露一直以来就是企业安全的重中之重,商业银行作为运营关键信息系统的机构历来重视信息的防护,但是企业做安全防护是体系化建设,黑客的入侵则是单点突破,在IT技术快速迭代变化的背景下,对防护体系的不断更新、加固提出了艰巨挑战,特别是在欧盟GDPR、国内网络安全法等相继颁布的监管趋严态势下,信息泄露需要银行安全付出更多关注。从一个银行“老安全人”的视角,我也来说说此次事件中的两类风险。

一、公有云被攻击的风险

云化服务是技术趋势,是不是采购了云服务后安全责任就移交给云服务商了呢?很遗憾不是这样,云安全一般采用责任共担模式,由服务双方共同保障。安全责任主体的划分是根据提供的云服务类型来决定的。该事件中,Capital One采购了亚马逊的AWS基础数据服务,但AWS要求用户数据的安全由客户主要负责。亚马逊称,云端客户能够完全控制他们自己开发的应用程序,且没有何证据表明其基础云服务受到了损害。从已披露信息看,客户数据应该是从Capital One侧泄露出去的。这里带给我们一个启示,对于采购了公有云服务的系统,云安全的责任主体要划分清楚,不能采购了云服务就认为安全责任都归属于云服务商,哪些层面的安全由云服务商负责,哪些层面由客户自己负责,要做到心中有数。

二、数据库拖库风险

数据库数据的泄露途经一般分为外部拖库、内部泄露。此次Capital One事件当中,嫌疑人是通过互联网进行的外部拖库攻击。从这几年积累的经验来看,列举如下几条可能的攻击路径:

数据库拖库风险

1、利用网络控制不严格直接访问数据库(如数据库端口对外暴露);

2、利用应用漏洞实施拖库(例如SQL注入);

3、利用未知漏洞入侵内网后通过跳板间接访问数据库。

如前所述,在拖库攻防博弈中,防护人员需要封堵整个环境中的所有可能漏洞,而黑客只要找准一点、从系统最薄弱的点入手,层层渗透最终获得目标权限。攻击和防护是不对称的。从本次事件的角度出发,针对以上三种攻击路径,在此各提出一些传统有效的应对措施:

1、直接拖库攻击风险应对:

通过防火墙限制外部可访问端口;

部署IPS防护设备。

2、应用漏洞拖库攻击风险应对:

开展代码安全测试、上线前安全验收测试、上线后渗透测试等工作,发现应用安全漏洞并及时整改;

在互联网边界部署IPS、应用防火墙等安全防护设备,实时监测和阻断SQL注入等拖库外部攻击行为。

3、跳板拖库攻击风险应对:

DMZ区与其它业务区域严格隔离,重要数据库的网络边界设置防火墙;

部署用户集中管理系统,通过设置密码错误次数上限、用户操作行为录像等方式实现事前和事中控制;

安全补丁、操作系统补丁定期更新,各类服务器、数据库安全配置检查定期开展;

对扫描发现的漏洞及时修补,并对漏洞修补情况进行复查;

开展渗透测试、安全评估、科技检查来发现潜在安全隐患。

此外有媒体称,该事件其实自3月就开始了,嫌疑人3月发动了第1次攻击,4月发动了第2次攻击,Capital One是在7月收到提示邮件后才察觉攻击,对风险是无监控或监控失效的状态。如果该系统部署了异常流量监测、数据库用户设置了操作行为审计、针对防护设备的报警有所关注的话,还是有可能提前发现风险并修复漏洞的,不至于对风险毫无察觉。所以在日常安全运维工作当中,提高IT运维人员的安全意识,增强安全事件处理能力显得尤为重要。安全小伙伴儿们,信息泄露防护任重道远,和我们一起来探讨行之有效的解决之路吧。

关于本站联系我们手机版
Copyright © 2019 安知讯 粤ICP备11061396号-7 粤公网安备 44030602001878号