WannaCrypt/WannaCry got a lot of people up in arms for a variety of reasons – some legitimate, some less so. The least important of which was, in my opinion, the ransomware itself. Ransomware is not interesting however, it is annoying and problematic which makes it, by definition, important for security/threat researchers, analysts, incident responders, forensics analysts, vendors, service providers, law enforcement, the media, the victims... you get the picture. And because ransomware is, under 'normal' circumstances, worrisome for many people around the world, one can certainly understand why something like WannaCrypt/WannaCry concerned so many more people and reached an almost 'celebrity' status within the media. There's been a great deal of analysis conducted on the WannaCry attack and the iterations observed after May 12, 2017.

I think there are a few points worth noting regarding the WannaCry attack and what it has shown us as an industry and community:

The Complexities of Attribution and Leading Theories on the Attackers behind WannaCry

There's a lot of conjecture and debate, along with varying degrees of agreement, in regards to the attribution of the actors behind the WannaCrypt/WannaCry attacks that began on May 12, 2017. Many well known (and some lessor known) threat research organizations and researchers have weighed in publicly and privately during and after the attack (and continue to do so as recently as the recent report released by Group-IB regarding the Lazarus Group's alleged involvement in this recent activity and other historical activity including the SWIFT network attacks in Bangladesh from 2015-2016 which had been noted in the Operation Blockbuster report lead by Novetta a few years back).

Whether you elect to believe the reports being generated by Symantec, Kaspersky Labs, Novetta and its coalition, Group-IB, etc. is entirely up to you. The authors are presenting information that they have acquired and corroborated (in many cases) and are applying their analysis to that information. Time will tell whether or not that analysis is accurate. For now, I'll table this by simply stating: proving unequivocal, irrefutable attribution is no small feat. And though it's easy to be skeptical of such work and the resulting findings and conclusions, one should keep an open mind regarding these efforts. Additionally, the application of Heuer's ACH is, in and of itself, not enough in the modern world of cyber threats, criminality, espionage, and warfare.

Use of Stolen NSA Exploits to Propagate

Tools developed by a team within the NSA (referred to by Kaspersky Labs as 'Equation Group') were stolen, allegedly with the help of an insider, dating back to 2013 by a group known as the ShadowBrokers. Some of these tools were integrated into the WannaCrypt code base yielding WannaCry. The first tool of note was ETERNALBLUE, an exploit that took advantage of vulnerability in Microsoft's implementation of Server Message Block (SMB) protocol v1. And though Microsoft had released a critical patch for this vulnerability, exploitation took place globally due in large part to the propagation made possible via ETERNALBLUE.

The second tool of note in the WannaCrypt/WannaCry attacks was DOUBLEPULSAR. The incorporation and use of this tool, in addition to ETERNALBLUE, are what caught my eye; not due to the fact that there was code reuse (that's rather common in the world of malware and weaponized code), rather due to the sophistication and historic allegations of attribution related to the authors of these tools.

Patch Management Issues Prevail and Leave Thousands Vulnerable to Compromise

Unpatched Microsoft systems were the victims. You can read for yourself above about the operating systems that were vulnerable to exploitation due to unpatched MS17-010. According to the team at Kaspersky Labs, most of the systems affected were running Windows 7 – not Windows XP, which was (at least for a little while) being suggested. Regardless, some 10,000 organizations and at least 200,000 individuals in over 150 countries were impacted. What's troublesome to me is that so many individuals were impacted given that Microsoft has, for many, many years, made it very easy to auto-update patches on one's operating system. This is an important lesson to be learned (I'm afraid in a rather harsh manner) for many individual users.

Regarding the systems that were infected within the 10,000 organizations around the world, I would say only this: I understand that patch management (as a part of good IT hygiene) is not always easy and/or possible (I'm thinking specifically of cases wherein an organization might have had systems impacted which are connected to its enterprise network yet managed and maintained by a third party – think medical devices for example). And though I understand that this is a reality for many organizations, that leads me to conclude the following: First, patch management in some organizations is not perceived as being a priority that has a direct impact on the risk posture of an organization and thus its ability to conduct its business, whatever that business may be. Second, organizations (rightly or wrongly) are not or have not been able to hold the vendors or third party technologies which reside on their enterprise networks accountable for the timely maintenance and upkeep of those systems. Third, there is or presumably was either an absence or failure of compensating controls (either on the network or on the hosts themselves) which would have allowed for the prevention of the exploitation of MS17-010, if it were not possible to patch within the organizations that were victimized.

Don’t Blame the Victims

Victim blaming – rightly or wrongly – continues and though I understand there are some cases where negligence might be proven, that is simply not applicable in all cases and thus uncalled for. Shaming victims for the mistakes that left them vulnerable is never the most effective way to get them to understand the importance of good security hygiene.

Protecting Against Future Attacks

So what do we do now that we have all of this information in our hands (thanks to the work of threat research organizations and researchers the world over) regarding WannaCry and the patch management issues which led to this noteworthy event?

We need to have some hard conversations.

First, as consumers (individuals or organizations) we need to demand that our vendors code with security in mind at all times. Many initiatives have been spun up over the years which have pointed out the failure of true secure coding practices in traditional SDLC processes; some more successfully than others. For many information security professionals, this has been a constant theme for more than two decades; yet here we are, talking once more about the value, the importance, the fact that in 2017 and beyond coding without security in mind is a non-starter. And it ought to be noted that I am not writing this solely with Microsoft in mind, but rather any organization which releases commercial (for profit) code and software products as consumables by individuals and/or organizations small and large. How we achieve this may require some significant thought. I'd like to think that due to the fact that we are now – more so than ever before – connected globally, that the need to do so would be obvious, however I am lead to believe that unless consumers vote with their checkbooks and/or releasing insecure code is made punishable by law, little will change. For the record I am not advocating even more government oversight than is already present in our society today but rather suggesting that there ought to be greater costs to those who profit and benefit from the sale of software if it is found to be vulnerable and that vulnerability results in global exploitation such as that which was observed in the WannaCry attacks.

Second, we as consumers need to reiterate the value in aggressively testing patches when they are made available and disseminating them in the most effective manner possible in order to ensure that the business of doing business remains a possibility.

Third, we need to have deeper conversations with organizational stakeholders regarding the realities faced by their organizations if things like patch management are not pursued aggressively.

Fourth, we need to hold the vendors of third party devices and systems accountable for the timely analysis and patching of their platforms when those platforms are maintained in a vacuum while residing on our enterprise networks.

Fifth, we need to ensure that our organizations have compensating controls in place which possess the capability of providing protection against the exploitation of vulnerabilities such as MS17-010 if a patch has not or cannot be deployed in a timely fashion.

So how can we as information security professionals working either for organizations (small, medium, enterprise businesses, non-for-profits, government organizations, etc.), for service providers, for vendors, or as independent consultants help facilitate the necessary dialogues in order to prevent the next WannaCry? I think we know how to have the conversations and what to say. I am even inclined to believe that now, more so than ever before, we are positioned to receive the message and take action (and many organizations around the world have done just that!), and yet, for many others, the reality is less positive. Less compelling. Less optimal. And as a result the struggle remains quite real. Yet, we must continue to push ourselves, our partners, our employees, our consumers, and our vendors to strive toward a state where the opportunity for exploitation such as was seen in the case of WannaCry is even less common with the end game being prevention through thoughtful design, architecture, and coding.