Three Reasons Adopting Zero Trust Leads to Bot Protection and Web and API Security

Today, zero trust is the hot new trend everyone wants to be attached to. It is one of the top three “most exciting” trends identified by our State of Application Strategy 2022 report and has consistently scored high in interest per Google Trends over the past twelve months.

The result is that zero trust is one of the most talked about—and misunderstood—approaches to security since “shift left” entered the room. Too often, zero trust is equated with a specific technology, like software-defined perimeter (SDP), or a market segment, like identity and access management (IDAM).

This is not really surprising. We saw the same rush to equate specific technologies or products with the “hot new trend” when cloud computing was introduced. Cloud washing was a thing that happened regularly and was often used as a derogatory observation on the actually “cloudiness” of some new product.

So, it behooves me to start with a definition of zero trust. I’m going to do that by quoting my colleagues, Ken Arora and Mudit Tyagi, who already published a great guide on this topic:

This is an important point, and so I will repeat it again: zero trust security is, at its core, a mindset.

That mindset embraces a set of assumptions, and the uses of technologies are consequences of those assumptions.

That means implementing a technology like SDP or API security does not mean you’ve adopted zero trust. There’s no single product you put in place that suddenly means you’re “zero trust compliant” and therefore immune to attacks, breaches, or exploits.

What is true is that SDP and API security may, in fact, be an appropriate tactical response to adopting a zero trust approach. But to get there you need to start with some core assumptions and then decide what the best tools and technologies are that logically flow from them.

To flesh this out, let’s walk through a few examples that, as the title says, leads us to conclude that bot protection and web and API security are part of the “zero trust” toolbox.

1. A zero trust approach assumes compromise. Legitimate users with authorized access may, in fact, be compromised and, therefore, an unintentional—and very costly—threat. Attackers understand it’s usually easier to gain entry through windows (users) than the front door (corporate network). Users are constantly under threat of being compromised, and thus the assumption that they are already compromised is the safest course possible. The range of potential actions from a compromised corporate laptop or mobile phone are many and include launching attacks against websites and apps that attempt to share nastyware (that includes malware, ransomware, and whatever-comes-next-ware) or exploit vulnerabilities to gain access. Because APIs are increasing “the way” mobile and web-based apps access corporate apps and systems, it becomes important to inspect content coming from even legitimate, authenticated users to determine whether or not it is malicious. That makes web and API security a logical choice to implement protection against this risk.
   
   
2. A zero trust approach assumes credentials are not enough. Whether a user is human, machine, or software, a zero trust approach assumes that even if legitimate credentials are presented, the actual user may not be legitimate. Credential stuffing, after all, is an ongoing concern that leverages legitimate but stolen credentials. It’s well known that, on average, one million usernames and passwords are reported spilled or stolen every day. Analysis from F5 concludes that 0.5%–2% of any breached credential list will be valid on a targeted website or mobile app. Therefore, a zero trust approach should take steps to verify not just credentials, but the very identity of the user. This includes uncovering bots masquerading as legitimate users. Tactically, this leads to bot protection—which can also be called bot detection—playing an important role in a zero trust approach.
   
   
3. A zero trust approach assumes change is constant. Zero trust rejects the assumption that once a user is verified and access to a resource authorized, there is no risk. Every transaction is considered risky and evaluated with respect to the content it carries and the user who is sending it. Session hijacking is a real attack method, after all. Constant vigilance is (or should be) the motto of zero trust, which implies constantly being on the lookout for malicious content. This makes web and API security along with bot detection critical components of a zero trust approach.

Now, this approach also leads to other tools and technologies, like SDP and identity and access control, network firewalls and CASB, and a host of other solutions that mitigate known risks that flow naturally from those assumptions. But you can’t implement just one of them and call your zero trust initiative done. That’s like taking a Tylenol to treat a broken leg instead of visiting a doctor. Yeah, it helps the pain, but it does nothing to actually address the rest of the problem.

Adopting zero trust as a shift in mindset that leads to mitigation isn’t perfect—no method is—but it will get you further down the road of being more adaptable and able to address new and emerging attacks faster and with greater success.

Be safe out there.

You can learn more about modernizing security with a zero trust approach in Chapter 5 of our book, Enterprise Architecture for Digital Business.