In the wake of one of the largest-ever cyberattacks – the fast-spreading WannaCry ransomware, which hit over 300,000 computers in 150 countries – it’s important to look at what went wrong and how to prevent it from happening again. Yet as we look for lessons from this devastating attack, it would be a mistake to see WannaCry as just a really destructive form of ransomware – it is a sign of latent weaknesses in the way the software that powers the world is developed and maintained.
WannaCry is unprecedented in some ways, as the first example of ransomware to spread itself as a computer worm. In other ways, WannaCry is merely an evolution of the crypto-ransomware that we’ve seen all too frequently since the emergence of CryptoLocker back in 2013. WannaCry also underscores the fact that we continue to struggle with the same basic security problems – cyberattackers don’t need to spend resources finding zero-day vulnerabilities, because so many organizations and users are not routinely updating their systems and software to close the security holes vendors know about.
WannaCry was so widespread because it exploited a vulnerability in almost every version of Microsoft Windows, even though Microsoft had made a security patch for the vulnerability available back in March – eight weeks ago. The convenience and efficiency of systems we collectively use, like Windows, Google apps, and other applications with big user bases, is also a common point of failure that can topple countless users like dominoes. Open source software used in thousands of applications – custom, COTS, and SaaS – is similarly vulnerable, which will inevitably lead to more situations like WannaCry.
What’s most frightening about this attack is that it demonstrates the weaknesses in how we create hardware and software that run everything from tiny drones, to medical equipment, automobiles, industrial control systems, and the internet itself. Organizations impacted by the WannaCry attacks include the UK National Health Service (NHS), the Spanish telecom Telefónica, Germany’s national transit system, and FedEx, the largest freight airline in the world. Any attack that can cripple vital infrastructure like transportation, communications, healthcare, government or banking (and all at the same time) puts more than just businesses and users at risk – it threatens economies and lives.
For too long, software development has been driven by a need for speed, not security. In today’s ultra-competitive global economy, businesses that move too slowly in bringing innovations to market will not have the opportunity to make that mistake again. And so security has become an afterthought – reactive, not proactive. Sooner or later, we will all have to pay the piper for a reactive approach to security.
It’s not just the software suppliers. Businesses that want to take advantage of the great automation and connectivity benefits of software they purchase need to also plan for the additional expenses of software. They need to vet their vendors to make sure they are building software with a security-minded development process, and they have to plan for patching as they operate the software. If the business is building its own software, it needs to be a good supplier to itself.
Application-layer attacks are now the leading cause of breaches, creating tremendous risk and cost for both the software provider and the customers who use it. It’s not going to be enough to get more efficient at applying patches, or build higher walls and deeper moats around applications and users. What we need is a fundamental shift in the way we create software, with security embedded in the development process.
What will it take for this to happen? I hope it doesn’t take another Yahoo-sized breach, another Heartbleed, or another WannaCry. We need to start treating the safety of software the same way we treat life-and-death issues like food safety or transportation safety. Government oversight can help in this regard, but application security needs to be handled by the vendors themselves, and that means it must reach the board level. Attacks like this will continue unless we see major changes in the way businesses handle risk in the software they build as well as the software they buy.
This is going to take a shift in attitudes on the level of the developer and the security practitioner, too. Developers, most of whom have never been trained in cybersecurity, must learn how to avoid introducing vulnerabilities in their code, supported by the right technologies for security testing, effective processes for sharing knowledge between development and security teams, and cultural reinforcement and training.
It’s no small task, but it’s far too important to wait for the next big vulnerability or breach to learn this lesson.
Make sure you’re delivering secure software for your business and as part of your customer offerings. Read our Ultimate Guide to Getting Started With Application Security. If you have questions about how CA Veracode can help, contact us.