Joey on SQL Server

Mossad/Not-Mossad: Preparing for Nation-State Cyber Threats

As geopolitical tensions escalate and nation-state cyberattacks increase, organizations must adopt an "assume breach" mindset and strengthen disaster recovery planning -- including preparing for physical threats to cloud infrastructure.

• By Joey D'Antoni
• 03/16/2026

There is an excellent 2014 security paper called "This World of Ours" that purports a security theory called "Mossad/not-Mossad." If you are not familiar with Mossad, they are Israel's national intelligence agency. The Mossad/not-Mossad theory posits that, with well-implemented security controls, an organization can protect itself from "script kiddies" and even criminal enterprises trying to hack it, but that no one can protect themselves from a dedicated nation-state-sponsored team of threat actors.

When I started writing this column, it was because AWS datacenters in both the United Arab Emirates (UAE) and Bahrain were hit by "objects" that impacted their availability. It was widely reported that these datacenters were hit by drone strikes. While I have designed many disaster recovery plans, I have never planned for missile strikes.

We will talk more about datacenters later, but shortly after this attack, Iran reportedly threatened several US-based hyperscalers and software companies. While the nature of these threats was oriented around physical sites, this week an Iran-affiliated hacking group called Handala launched a data destruction and theft attack against the US medical device company Stryker. Security expert Kevin Beaumont suggested that the attackers gained access to Stryker's Active Directory infrastructure and used Microsoft Intune to wipe the devices. (To bring a bit of levity to this grave matter, I did see several Intune admins on Reddit asking how the hackers were able to get Intune, which is known for its latency, to immediately wipe approximately 20k devices.)

Iran is not new to nation-state hacking operations; along with North Korea, Russia and China, it is listed on the US government's Cybersecurity and Infrastructure Security Agency's short list of Advanced Persistent Threat (APT) actors. While these teams of threat actors are not necessarily government employees, they are state-sponsored and can operate in the shadows without concern for prosecution, with access to top-notch technology teams and hardware. Back to our Mossad theory of security: these are the attackers who will breach you, no matter what you do.

How do you handle a nation-state threat actor breaching your environment? One of the foundational tenets of zero-trust security is assume breach. While some parts of zero-trust seem too gimmicky or even complex to implement in many organizations, assume breach is more of an organizational mindset that allows you to build more robust defenses. Assume breach means you aim to minimize the blast radius of any single attack by segmenting networks and data, using end-to-end encryption to protect data within your security boundaries. Backups, the most important part of any DR strategy, should immediately be sent into a separate, secure, immutable environment. Having auditing and data loss prevention tools will help you identify any data that is captured by attackers.

While configuring network segregation and using just-in-time admin access are mainly modern best-practice security measures, many organizations still struggle to achieve that level of security. In tense times like these, more firms may be targets of APTs than they realize. Stryker is a good example; they mainly make plates and screws to fix broken bones (I used to work in this industry). While these firms do usually have defense contracts, which led Handela to attack it, along with Stryker's connection to an Israeli firm it acquired in 2019. This means your company does not have to be making missiles or fighter jets to be a target of a group like Handela.

Datacenter Drone Strikes
What exactly can you do if your cloud provider gets hit by "objects"? I have been wanting to write about this for a long time, but while tools like Zerto and Azure Site Recovery are really good at doing test failovers, and even recovering from your own disasters, I really question the amount of capacity AWS, Azure and GCP have in the event of a major disaster at one of their datacenters. There are various reasons for this, including:

• Some regions have a ton of datacenter capacity spread across a wide area and may be less vulnerable to attacks or disasters.
• There is no clear definition of what a "region" is and how much capacity it has.
• The continued investment in AI over "regular" cloud capacity limits overall capacity.
• It benefits the cloud provider's margins to run tighter on capacity.

I brought this up on our webinar last month, but I tried to do a DR test with a client on Cyber Monday (the Monday after the Thanksgiving holiday in the US). We ultimately had to postpone the test because we could not get the VMs we needed in our target DR region. While we were successful a couple of weeks later, this was just another data point in addition to what I have heard from other Azure community members about overall capacity. If a major datacenter in a key region is lost completely for an extended period, I am not sure where the rest of those workloads could go.

What can you do about this datacenter threat? If I were in the Middle East and had in-country data sovereignty requirements, I would probably look toward smaller in-region datacenters -- if I had a workload that could support it. For example, if your workload is mostly VMs or containers, you can probably move easily to another hosting provider, which might not be as much of a target as a very large datacenter owned by a large American company. Additionally, if I had critical workloads that were cloud-specific -- say Azure SQL Database -- I would look to set up live DR in a second region outside your geographical area if that worked with my regulatory framework. This costs money, yes, but it also lets you get ahead of everyone else who would be trying to fail out of your region after an incident happened.

Drone strikes and nation-state threat actor attacks were not what I thought I would be writing about when I started writing this column many moons ago. Sadly, that represents the current state of the world. Hopefully things will be better soon, but take the opportunity to evaluate your security posture (you should really be doing this quarterly) and evaluate your DR plan (you have a DR plan, right?) with the possible consideration of impacts to your cloud providers and the possible loss of a region. While I, too, am tired of living in unprecedented times, protecting our workloads is part of the technologist's job.