Equifax的问题出在哪里：34项控制与过程失误

信用评级机构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