There’s an old chestnut in the security world: if you make yourself a hard enough target, in many cases an attacker will go find an easier target and leave you alone. Plants with thorns, critters with spines or spikes, and trees that secrete toxins all embody this principle: making an attacker pay a price for every attack will both stop but also deter attacks. Of course, trees, critters, and plants don’t have to deal with criminal gangs or nation-states, so this principle doesn’t hold universally—but it’s pretty much true for cybersecurity. Let’s see what “imposing cost” means to the Microsoft 365 administrator.

What Costs Are We Talking About?

Let’s start with the obvious: when I say “imposing cost” that does not mean “paying security vendors more money.” Instead, I mean imposing a cost on the attacker. There are three basic categories of cost you can impose on an attacker:

  • You can increase the risk that they’ll get caught.
  • You can force them to spend more time (or other resources) on attacking you
  • You can cost them money

These three categories often inter-relate; breaking into a bank vault takes longer than breaking into a residential garage, and the extra time required exposes the thief to more risk of getting caught.

In the physical world, defenders can come up with security measures that require expensive tools or materials to defeat, but in our world, it’s hard to come up with good ways to impose a financial cost on an attacker. Various attempts have been made; for example, the Hashcash anti-spam system that forced senders to solve a small cryptographic puzzle and send the results as a header in email messages, thus forcing spammers to pay a small (but measurable) amount for each message they sent, in the same way that postal spammers have to pay for postage. It didn’t work, but it was a good idea. Let’s leave aside the direct-financial-cost category and instead focus on the two other categories.

Imposing a Time Cost

Each year we see more and more automated, high-volume attacks. You might remember when password cracking was a laborious brute-force process… but not anymore, since rainbow tables and commodity GPUs have lowered the bar for successfully automating this attack. However, there are still places where you can successfully impose a time-based cost to attackers. Think of the kill chain that an attacker has to execute to compromise your tenant: they have to get initial access, poke around to look for other vulnerabilities inside your network, try to figure out what’s valuable or vulnerable, and then exploit it (whether that’s by deploying ransomware, exfiltrating data, or moving into another network). One of my favorite techniques is to purposely leave fake data in a lightly protected space; you can then watch your logs for attempts to access AdministratorPasswords-Aug-2024.xlsx or whatever.  Better still, you can create badly routed network segments, intentionally-very-slow servers, or other time traps to impose additional discovery costs on the attackers. Of course, these time-wasting measures don’t necessarily work against high-volume attacks. For that, you need to take a different tack.

Imposing Risk on the Attacker

Attackers don’t want to get caught. They don’t want attention from law enforcement or intelligence agencies, threat-hunting teams, Microsoft, or anyone else because that attention makes it harder for them to work. Forcing an attacker to spend extra time getting in or getting data out raises their risk profile, as does using sentinels (like the honeypot technique I just mentioned), and so does having better detection tooling and threat intelligence. As a Microsoft 365 customer, you’re already getting some degree of this protection for free. For example, the recent attacks against the US presidential campaigns of two candidates were first detected by Microsoft, which notified the campaigns that they’d been attacked. Even if Microsoft doesn’t detect an attack against you, they often detect other attacks and publish information about the attacker’s tactics and signatures, which you can use to improve your own detection capability.

There’s a hidden part of imposing attacker risk that lots of people skip over. If you catch an attacker, of course one of your first steps (if not the first) is to block their continued access. Another very important early step is to tell someone, whether it’s your threat intelligence vendor, the FBI, an industry-specific standards body, MSRC, or the local TV station (but probably not the latter). Notifying the appropriate people that you detected an attack, and sharing what you know about the attacker’s profile and tactics, helps protect others but also allows entities with a broader view of the landscape (like MSRC, your EDR vendor, or CERT) to correlate “your” attack with other attacks to get a fuller picture of what the attacker’s doing… leading to a higher chance that they’ll get caught.

Risk vs Reward

In some cases, the potential reward for the attacker is so great that they’ll have a very high risk tolerance. For example, the Chinese government (or their sponsored organizations) has continued to mount attacks against Microsoft and other large cloud vendors, apparently because they believe the US government won’t take any action against them that outweighs the value of the access or data they get. I’d like to see a new US government policy: if you attack a public infrastructure service, like an airport or hospital, the US will put its full might into finding out where you are and then drone-striking you. Failing that, the best you can do is to combine the hardening and protection measures you should already be taking with some additional measures intended to make you the equivalent of a spiny cactus—something that a potential attacker will evaluate and then reject as a target in favor of something with more flavor and less potential to cause damage.

About the Author

Paul Robichaux

Paul Robichaux, an Office Apps and Services MVP since 2002, works as the senior director of product management at Keepit, spending his time helping to make awesome data protection solutions for the multi-cloud world we’re all living in. Paul's unique background includes stints writing Space Shuttle payload software in FORTRAN, developing cryptographic software for the US National Security Agency, helping giant companies deploy Office 365 to their worldwide users, and writing about and presenting on Microsoft’s software and server products. Paul’s an avid (but slow) triathlete, an instrument-rated private pilot, and an occasional blogger (at http://www.paulrobichaux.com) and Tweeter (@paulrobichaux).

Leave a Reply