Equifax的问题出在哪里:34项控制与过程失误
作者:星期一, 十二月 17, 20180

信用评级机构Equifax深陷全球最大数据泄露事件泥潭,美国政府官方报告称其未能实现“足够的安全措施”以保护数据。

美国众议院监管与政府改革委员会的报告称,该数据泄露本是完全可以避免的,是该公司未能完整的给系统打补丁才导致的泄露。

Equifax没能完全理解并缓解其网络安全风险。

该报告还证实,Equifax安全人员未能发现数据渗漏是因为他们用于监视网络流量的设备在19个月前就因安全证书过期而不工作了。

直到该安全证书最终得到更新,从该公司消费者自动采访系统(ACIS)流往某中国IP地址的可疑流量才被发现。

报告中称:Equifax注意到一个二级IP地址上有额外的可疑流量,该IP地址属于某德国ISP,但却租给了中国提供商。这一警报促使Equifax关闭了ACIS网页门户进行紧急维修。ACIS一下线,该网络攻击也就停止了。

缺乏领导和问责令过程失灵,使工具疏于维护,让策略形同虚设。

7月31日,证书更新后两天,该公司首席信息官 David Webb 向首席执行官 Richard Smith通告了此事,但直到9月才向公众披露该数据泄露事件。之后8天,Webb和Smith被解雇。

监管与政府改革委员会这份长达96页的报告总结道:Equifax没能完全理解并缓解其网络安全风险。但凡该公司此前曾采取措施解决其显而易见的安全问题,数据泄露事件都可以被避免。

ACIS是承自1970年代的老旧系统了,最初的攻击途径就是作为ACIS前端的 Apache Struts Web 服务器上一个未修复的漏洞。

Equifax没检测到数据渗漏,因为用于监视ACIS网络流量的设备因安全证书过期已经19个月没启动了。2017年7月29日,Equifax更新了该证书,立即注意到了可疑网络流量。

——Adrian Sanabria (@sawaba) 2018年12月11日

渗透测试公司NopSec策略副总裁 Adrian Sanabria 列出了Equifax的各种IT安全失误:

Equifax的全球威胁与漏洞管理团队(GTVM)向400多名内部员工推送了Struts警报。就像很多公司所做的一样,Equifax也就该漏洞召开了内部会议。警报邮件在该漏洞被披露2天后就发出了,并指示该漏洞应在48小时内打上补丁,但会议是在邮件发出后一周才召开。

警报邮件都在那儿了,为什么要在修复时限过去5天以后才开会商讨修复事宜?因为他们清楚根本没人会去修复。

无论如何,他们没有测试这一规则,所以攻击中也没有触发。测试你的控制措施!太多安全控制措施都是只部署不测试了,这很令人惊悚。

即便如此,该公司还是花了2个多月才最终打上补丁,但那个时候其系统已经被完全渗透,尤其是攻击者找到一个含有公司48个数据库明文用户名及口令的老文件之后。

为什么Equifax不通报该渗漏情况?老实说,大多数公司都没有设置线上数据渗漏检测。

但是,19个月,这也太夸张了。这是因为没人正式负责内部证书管理工作。对一个拥有1.7万个可路由IP的公司而言,或许内部证书管理责任是块烫手山芋吧。

还不仅仅是证书过期问题。数据泄露发生当时,Equifax还有至少324个SSL证书是过期的。

他们可能有做一些SSL检查,所以证书很重要。但他们不应该仅仅依赖包检测技术。

即使不解密流量,他们也应该注意到有大量数据流向了中国和德国的服务器,而且是从平时不会往这些目的地址发送大量数据的源发出的。仅仅网络流量这一条就应引起注意了。

总之,证书更新后,Equifax立即注意到了攻击,证明他们确实拥有可以检测的工具。

纵观整份Equifax数据泄露报告,可以总结出3点:

1. 员工注意到了缺陷;

2. 存在恰当的过程、工具和策略;

3. 缺乏领导和问责令过程失灵,使工具疏于维护,让策略形同虚设。

虽然Equifax的安全人员使用了扫描器来探测其 Apache Struts 的漏洞,该工具却配置错误,未能有效发现漏洞。且仅仅扫描根目录和异常检测是不够的,安全人员没有测试他们的措施和对策。

Equifax总共犯了34个控制与过程错误导致数据泄露。可能只需其中5个控制措施和过程做对了就能避免这场数据泄露。其他29个左右可以尽早检测到数据泄露情况,留出时间加以阻止。

Equifax报告:

https://oversight.house.gov/wp-content/uploads/2018/12/Equifax-Report.pdf

相关阅读

Equifax的教训:如何建立正确的网络安全事件响应计划

Equifax黑客事件的经验教训:供应链合作伙伴太重要了!

 

申明:本文系厂商投稿收录,所涉观点不代表安全牛立场!


相关文章