The Next Petya Will Be Worse Unless We Change the Way Software Is Developed

DZone 's Guide to

The Next Petya Will Be Worse Unless We Change the Way Software Is Developed

While WannaCry and Peyta were by no means fun, they did highlight some changes in security implementation which desperately need fixing.

· Security Zone ·
Free Resource

Another major cyberattack hit computer networks around the globe recently, beginning in the Ukraine, when a paralyzing ransomware struck websites of government agencies, banks, transportation systems, and power plants, before spreading to Russia, the U.K., the U.S., and other nations. Coming just weeks after the 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.-based hospital and healthcare system, the Maersk shipping company in Denmark, a state-controlled bank in the Ukraine, Russian oil giant Rosnoft, and a U.K. 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 . 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 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 , rather than developed from scratch. The reliance on open-source and third-party code means that vulnerabilities in components can affect , 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 of 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 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.

security ,devsecops ,security compliance ,cybersecurity ,cyberattacks

Published at DZone with permission of John Zorabedian , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}