内容简介:信用评级机构Equifax深陷全球最大数据泄露事件泥潭,美国政府官方报告称其未能实现“足够的安全措施”以保护数据。美国众议院监管与政府改革委员会的报告称,该数据泄露本是完全可以避免的,是该公司未能完整的给系统打补丁才导致的泄露。
信用评级机构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的问题出在哪里:34项控制与过程失误》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- PHP Generator相关的设计失误
- Holochain创始人总结:胜利、失误以及后续
- 【安全帮】Azure云宕机3个小时:因人为配置DNS失误
- Ryan Dahl:Node 失误太多无力回天,Deno 前景明朗
- 存储过程 – 重新编译后,存储过程运行得很快
- 面试:谈谈你对 MyBatis 执行过程之 SQL 执行过程理解
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。