Software Integrity

 

What can your firm learn from the unfolding Equifax hack?

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.

Lessons learned

As discussed above, breaches like this generally occur as a result of organizations not following secure software development practices. It is easiest and most cost effective to add controls early in the software development life cycle (SDLC). So performing architecture risk analysis or threat modeling early in the SDLC is critical. Many security issues can be prevented if the right architecture/design controls are added in the right places.

Developers should be trained in defensive programming so that they understand security vulnerabilities and how to prevent them. Developers and security teams should use static analysis tools that can help find implementation vulnerabilities. Code reviews and security testing should also be used to further reduce the likelihood of vulnerabilities ending up in production environments. Operations teams should keep a close eye on applications and watch for unusual behavior.

These are only a small subset of security activities that organizations should be performing. See the Building Security In Maturity Model (BSIMM) for a more comprehensive list of security activities. Also, keep in mind that you need to secure all your applications and systems.

Equifax stated, “We have found no evidence of unauthorized access to Equifax’s core consumer or commercial credit reporting databases.” This is not all that surprising. Organizations often focus on protecting their core systems but are laxer about applications/systems that they consider less critical.

Synopsys is security. Let us be your guide on your security and quality journey.

Learn more.