Skip to main content
Petya Ransomware Attack
June 28, 2017

The Next Petya Will Be Worse – Why Software Development Must Change

Another major cyberattack hit computer networks around the globe on Tuesday, beginning in the Ukraine, when a paralyzing ransomware struck websites of government agencies, banks, transportation, and power plants, before spreading to Russia, the UK, U.S., and other nations. Coming just weeks after the WannaCry ransomware wreaked havoc, this new attack – initially believed to be a strain of the Petya ransomware – has many similarities to WannaCry, and some alarming differences.

Organizations affected include the U.S. pharmaceutical manufacturer Merck, a U.S. hospital and healthcare system, the Maersk shipping company in Denmark, a state-controlled bank in the Ukraine, Russian oil giant Rosnoft, and a UK advertising company. With the ransomware continuing to spread, no industry is immune. Enterprise organizations may prove to be more vulnerable due to their larger attack surface and the difficult task of patching many systems, including those that need to remain online.

The details of the attack are still hazy. Is this a new and improved version of Petya? Or something we’ve never seen before? Who was behind the attacks? There has been speculation that the intention of the ransomware was not to extort businesses, but to disrupt them and sow chaos. It’s also not entirely clear what the original attack vectors were. Some evidence points to the ransomware spreading via the same vulnerability as WannaCry – a vulnerability known as EternalBlue in a file-sharing protocol in Microsoft Windows – yet computers that were patched against that vulnerability have also been infected.

Security firms will continue to conduct forensic analysis of the ransomware over the coming days and weeks, and understanding the source of the attack and the attacker’s motivation will hopefully help us prevent similar attacks. Yet, as our economy and infrastructure increasingly depend on software applications, shared across millions of computers and users, the risks and consequences of this kind of cyberattack will continue to worsen unless we change the way software is developed, updated, and accessed.

Veracode scans of thousands of applications and more than a trillion lines of code over the last decade have shown conclusively that the security of the software businesses develop and purchase from third parties is a massive liability for those organizations, their customers, and the economy as a whole. Our scans routinely find that applications fail the most basic standards that have been in place for a long time. And software produced by vendors is even less secure than applications developed in-house.

There is also systemic risk in software because of the way applications are assembled from components, rather than developed from scratch. The reliance on open source and third-party code means that vulnerabilities in components can affect thousands of other applications, and those vulnerabilities can be difficult for security teams to track down and patch when new vulnerabilities are disclosed.

As the WannaCry and Petya attacks make clear, the cost of failure to secure software is high. Vulnerable software can harm individual businesses and entire nations. Destructive attacks on critical infrastructure threaten lives and economies. Because the stakes are so high, it is incumbent upon software vendors and organizations that develop their own software to ensure their security.

So, what is the best path forward? Simply put, software needs to be designed with security in mind – it can no longer be an afterthought. High walls and sturdy locks are not enough to protect vulnerable software from being exploited. Security needs to be built into software with rigorous testing for flaws in the code.

The burden for responsibility should not fall on security teams alone. That responsibility should be shared across the organization, from the board level down to the developers who write the code. Unfortunately, there isn’t a silver bullet to prevent vulnerabilities. Development, security, and operations teams need a combination of software testing techniques to find flaws in proprietary code and third-party components.

If we have any hope of preventing new and more dangerous attacks from exploiting vulnerable software, it will be in educating our software developers in secure coding best practices. Every computer science course should include cybersecurity. And as new languages, frameworks, and platforms take hold, organizations must train their developers to keep security at the forefront.

The digital transformation of the way we work, communicate, and consume goods and services, is a wonderful thing. Applications enable individuals, businesses, governments, and organizations of all sizes to thrive, and better serve customers. But this transformation comes with considerable risk. If we make the security of software our top priority, the potential for innovation is limited only by our imaginations. If we don’t make security an essential part of the way we create software, we are putting people and progress in harm’s way. We understand the risks. Not doing anything about them would be negligence of the worst sort.

Learn how to reduce application risk – download our Ultimate Guide to Getting Started With Application Security.

John Zorabedian is a blogger, content marketer, and research editor. He has a background in marketing and journalism, writing about IT security, technology, business, politics and culture. He lives and works in the Boston area.

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.