The recent NotPetya attacks disrupted the IT operations of many firms world wide, and as I write this, the Internet is littered with media reports of companies still struggling to return to operations nearly two weeks after the outbreak. This style of attack is not new: we saw it in the Shamoon attack on Saudi Aramco, and in the Dark Seoul attack in South Korea, and in the attack on Sony, and most recently in WannaCry and now NotPetya. I will readily admit that if you become the target of a government operation, the outcome is nearly assured no matter what you do to prepare. NotPetya, though, should highlight to us that we don’t necessarily have to become collateral damage in “cyber war” between countries if we design and operate our systems appropriately.
IT security, at its core, is a set of trade-offs, though. Some are good, some bad, the implications of some are understood, but often they are not. I guess the best way to think about it is “we don’t go to cyber war with the network we want; we go to cyber war with the network we have”. Recognizing that and the rapidly evolving techniques used by the more advanced adversaries, as well as the terrible track record those advanced adversaries have of keeping those tools and techniques secret, we need to recognize the need for cyber resilience. I recognize the term “cyber resilience” is not going over well with many of you, but I don’t currently have a better term for the concept. I believe it is important to distinguish cyber resilience from traditional disaster recovery programs. I work a lot with US-based banks and US banking regulators that are part of the FFIEC. A lot of my thinking has been shaped by the programs and guidelines the FFIEC has established in recent years regarding cyber resilience, and reflecting on that, I see many linkages between their guidance and these recent destructive attacks.
Many organizations view disasters as purely geographical events, and their programs are designed to address that. Off-site backups, hot, warm, or cold systems in remote data centers, and so on. These make good sense when the threat being mitigated is a fire, flood, tornado, or volcano. But cyber attacks happen orthogonal to location – along technology boundaries, rather than on geographic boundaries. A great example was Code Spaces, who operated their environment in AWS. Code Spaces promised a highly fault tolerant environment, replicating data across multiple AWS data centers on multiple continents. Sadly, when their AWS keys were stolen, attackers deleted all traces of Code Space’s data from all those redundant data centers. In the recent NotPetya attacks, a number of victims had their entire server environments wiped out, including replicated systems, geographically distributed fail over systems, and so on. Consider what would happen to an organization’s geographically distributed Active Directory infrastructure during a NotPetya outbreak. There is no restoration; only starting over.
Maybe starting over is good, but I’m guessing most victims impacted in that way would rather plan the project out a bit better.
That takes me back to cyber resilience. I recognize that most of us don’t see our organizations as being in the line of fire in a cyber war between Russia and the Ukraine. I am sure the three US hospitals hit by NotPetya certainly didn’t consider themselves in that firing line. It is hard to predict the future, but it seems like a safe bet that we are going to see more attacks of the Dark Seoul and NotPetya variety than less. And as time goes on, we are all becoming interconnected in ways that we may not really understand. If your organization is sensitive to IT outages in its operations, I would recommend putting some focus on the concept of cyber resilience in your strategic plans. At the risk of offending my friends in the banking industry, I’d recommend taking a look at the FFIEC’s business continuity planning material. It has some good ideas that may be helpful.