What can your firm learn from the unfolding Equifax hack?

On Sept. 7, Equifax announced that attackers had stolen information from about 143 million people in the United States. Canadian and U.K. residents’ data was also stolen. However, Equifax has not yet revealed the number of people affected. We do not know the exact vulnerability that was exploited. Equifax stated only that “criminals exploited a U.S. website application vulnerability to gain access to certain files.” Whenever these types of events happen, it’s natural to ask questions such as what the vulnerability was, how this could have been prevented, and what lessons can be learned. Let’s try to answer some of these questions.

The vulnerability

We don’t have much information about the exact vulnerability that was exploited. However, based on Equifax’s statement, it was probably a directory traversal vulnerability, a command injection vulnerability, or an insecure direct object reference vulnerability. All these are well-known web application vulnerabilities that can be used to get unauthorized access to files.

Could this have been prevented?

These types of events are generally the result of organizations not following secure software development practices. There are many layers in which problems can often be prevented but aren't:

• Planning, architecture and design: The application architects could have put in stronger controls. Thus, protecting customer data so that a simple web application vulnerability won't result in a large number of customers’ information being compromised. They could have added strong centralized authorization checks, used input validation frameworks, etc.
• Implementation: Developers could have implemented the application such that it performed the right checks in all the right places. Without a good architecture/design in place, this is hard to do, but it’s not impossible.
• Verification (code reviews and static analysis): Static analysis tools are great at finding many web application vulnerabilities. Additionally, manual code reviews can look for issues that tools are not good at finding. These could have been used to find implementation bugs introduced by developers.
• Verification (security testing): If vulnerabilities make it all the way to a test environment, security testing tools and manual techniques can find these types of issues.
• Release and response: Operations teams should be monitoring applications for unusual activity. Although stopping attacks at this phase is not ideal, it is still critical to have the right controls in place. In this case, the breach occurred from mid-May through July 2017. This indicates that the operations team may not have had the controls in place to quickly detect and respond to web application attacks.

Equifax’s response

From a security perspective, Equifax’s response did not follow security best practices. They created a new website at https://www.equifaxsecurity2017.com/ that redirects users to https://trustedidpremier.com/eligibility/eligibility.html if they want to check whether their information was stolen. Neither website has an extended validation certificate. Users therefore have no idea whether these websites are truly affiliated with Equifax or were created by an attacker wanting to steal users’ information.

As a consumer who was curious about whether my information was stolen, I immediately noticed that these domains were not Equifax’s main domain, so I chose not to enter my personal information. Anybody can register a domain name containing “Equifax” and get a domain validation certificate for it. Organizations should not be encouraging users to enter personal information on unknown domains. Instead, it would have been much better to set up a site like https://www.equifax.com/breach so that users could clearly see that it belonged to Equifax.