In mid-September 2017, when Equifax announced a massive data breach had compromised nearly 150 million consumer records, criticism for the debacle was rapid and substantial. The news media and security experts immediately condemned Equifax for the breach, stating that an organization trusted by consumers to maintain confidential, personal information should have had procedures in place to guard against breaches. Adding to the noise, an array of cybersecurity firms started telling the world, “If Equifax had used our solution, this wouldn’t have happened!”
Shortly after the announcement, when it became clear that the breach was due to an Apache Struts vulnerability (CVE-2017-5638, aka “Struts Shock”) for which a patch had been released in March 2017—the drumbeat of negativity got even louder.
Amid all the furor, an important point has been overlooked, and it’s almost as concerning as the breach itself. I have yet to hear anyone mention what Equifax should have done and, most importantly, who within the organization owns the issue.
Avoiding the breach would have required management (and not just security management) to support a mature application security process. Security, Development, Quality Assurance and Operations management and their teams would all have needed to be part of the process. From what I have heard, that wasn’t happening. Even more disturbing, such a procedural and policy failure is common across a significant number of companies around the globe.
All companies store confidential data of some type, and in some quantity. Furthermore, in my experience, nearly all businesses fall prey to the same flawed decision making and lax security practices that were the downfall of Equifax. Over the past decade, despite incredible advances in security technology—and astronomical acceleration of cybercriminals’ capabilities—companies continue operating with blinders, making the same mistakes that Equifax did.
IT’S TIME FOR A REALITY CHECK
The vast majority of companies should be operating under five core principles surrounding application security. A shockingly large percentage of them are not.
#1 They should have a process for identifying which applications are running on their networks (including in the cloud).
#2 There should be a mature process for determining whether or not an application and its various components are vulnerable, including the operating system, the application server, libraries, custom code and configuration.
#3 For in-house developed or customized applications, firms should have a program for patching/fixing vulnerabilities, including regression testing to make sure fixes don’t negatively impact application functionality. (For those unfamiliar, regression testing is the process of testing application code changes to ensure the older code still works with the new changes.) Teams should be able to deploy application updates and patches to production, quickly, once the fix has been verified.
#4 Corporate management should support these principles in thought and deed, providing the resources (financial and human capital) to ensure adherence. If they cannot hire and manage the human resources, they should outsource them.
BAD CHOICES; HORRIBLE OUTCOMES
Why don’t most companies follow these principles? Several issues deter firms from making prudent choices regarding their software updates.
- Regression testing has long had a reputation for being “expensive,” making it tempting for firms on tight development budgets to skip it in an effort to reduce expenses.
- When not handled properly, regression testing can slow down release cycles, and in a world of accelerating pressure to update and release quickly, teams may give testing short shrift to get releases out the door. Ironically, proper automated regression testing will accelerate deployment timelines. It is a key part of a DevOps strategy.
- Some companies do not have proactive security or quality control systems in place, so they literally have no clue what they or their personnel should be doing.
Twenty years ago—when cybersecurity was not a household word, connected applications weren’t pivotal to most corporate operations and breaches didn’t cripple organizations—companies could get away with being lax. Today, that is simply not the case. Although following sound application security practices involves expense, that figure is almost always dwarfed by the potential cost of data breach mitigation and repair.
THE BOTTOM LINE
The hard reality is that organizations must stop thinking “We are better than Equifax,” and grow up. If a data breach in their firm hasn’t yet come to light, that doesn’t mean one hasn’t happened. (The average time to discovery is nearly 200 days.) And even if one hasn’t happened, without robust application security practices it likely will. Company decision makers and their teams must take responsibility for their applications or stop kidding themselves and accept the fallout.
If you doubt that most firms—or your firm—could be as negligent as Equifax, consider this fact. One Samsung vulnerability—CVE-2012-6422 (a Samsung processor privilege escalation vulnerability)—was discovered, and a patch was developed, in 2012. Three years later, that vulnerability was still responsible for 24% of Android exploits. Cybercriminals know that most companies are inattentive and careless.
Earlier this year, Saltworks and Orasi Software jointly released a white paper that delves deeply into application security concerns and offers practical suggestions for reducing risk. The paper’s focus is helping organizations secure their SAP customizations with sound practices and application security tools from HPE, but a considerable amount of its content applies to application development as a whole.
We invite you to download a complimentary copy, here, and start your education. Don’t miss the reference to the Struts Shock vulnerability that took down Equifax. It’s discussed on page 5.
Dennis Hurst is the founder of Saltworks Security, an organization founded to empower businesses to design, build and operate secure software applications. Its secure software development lifecycle (SDLC) tools and best practices consulting directly supports popular, rapid application development frameworks.
This straightforward, real-world approach helps clients save time and money by setting clear expectations, benchmarks, and milestones for all stakeholders—from developers to security staff to senior management.