By now, almost everyone has heard of the Equifax hack that compromised the personal data of around 143 million people, or 44 percent of the US population. Equifax is one of the three main US companies that calculates credit scores, meaning that the data breach impacted everything from birth dates, addresses, and driver’s’ licenses to credit card numbers and social security numbers.
While many Americans are still reeling from the events of the Equifax hack, the one thing we can take away from this alarming event is the importance of application security testing. While this benefit might not mean much to victims of the hack, QA teams and business organizations can still learn a lot from Equifax’s shortcomings.
The following are the six biggest lessons that the Equifax hack taught us at CrossBrowserTesting:
- You never know how much a data breach will cost. Sometimes testing can fall behind on your to-do list because it’s hard to predict how much not testing could cost you or your customers. Unfortunately, Equifax found out the hard way that it’s better to be safe than sorry. It’s impossible to configure how much a bug could cost when you also consider customer loyalty and brand reputation in addition to financial losses, but implementing comprehensive QA techniques can help avoid a fatal failure, so you don’t have to find out.
- Don’t make it easy for hackers. This one should be pretty self-explanatory, but if there’s a way to make your application safer and prevent a vulnerability, you should follow it. In fact, it should be pretty high on your priority list. Equifax was aware of a method to patch the known vulnerability through the Apache Struts web application software but ignored it, which quite didn’t work out so well for them. According to The Apache Software Foundation, most breaches are caused by failure to update software components, which means a simple update could have remedied the situation.
- Let your customers know security has been compromised sooner than later. The vulnerability was learned by executives who knew as early as July, yet somehow it took until September to notify the public. It’s hard to win back customers’ trust. It’s harder if you don’t tell customers their information has been compromised as soon as you know so that they can take the measures to freeze their credit. We recommend being as transparent as possible when a security breach happens so you don’t have to suffer more reputational damage than you have to.
- Take preventative measure instead of reciprocative approaches. This way of thinking about security should be the way we think about all testing. Instead of waiting for customers to find your bugs or data to be compromised, test throughout the software development lifecycle. Testing early and often instead of waiting until after disaster strikes ensures that high-stakes errors aren’t found too little too late. If you don’t have the right internal resources to perform thorough security testing, it’s worthwhile to invest in dedicated software such as Veracode or utilize open source software like OWASP ZAP. By practicing application security testing measures such as authentication, authorization, encryption, and data validation, you can avoid a massive PR nightmare.
- Damage control should be a priority. While Equifax provided free credit monitoring for those affected by the breach, it did little to ease the worry of customers. By requiring them to enter more personal information like their SSN and not giving a definitive answer to whether or not they were affected, Equifax didn’t do much to convince customers they were any more trustworthy. When your users’ sensitive data is compromised, you have a responsibility to make things right by them. Hint: asking for more personal information is probably not the best approach to assure angry customers.
- Pinpoint where you went wrong. After the incident, Equifax released a statement saying that “Criminals exploited a US website application vulnerability to gain access to certain files,” without giving much more information on how the hack happened. Though people are upset Equifax’s lack of response and reason, hopefully, Equifax has recognized the vulnerability even if they’re not willing to share with the public so that they can prevent similar instances in the future and make internal changes to prevent repeat mistakes. This way, they can implement better testing practices in the future that are informed my data-driven decisions to avoid another accident.
- Have a process in place for worst-case situations. A hack this huge would take any company by surprise, but that doesn’t mean that organizations shouldn’t be prepared in case something like this happens. Any company handling sensitive customer information should have a procedure in place that employees can follow to immediately alleviate the situation and that stakeholders can follow to lessen the burden of the attack. Again, figuring this out before something happens is the best way to minimize the consequences.
Unfortunately, Equifax can only learn from its mistakes, but as developers and testers, it’s important for us to learn from them as well. Rather than being a second thought, penetration and application security testing should be prioritized throughout design, development, and production to avoid an irreversible error and maintain the trust of your customers.