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).
We saw the same rush to equate specific technologies or products 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.
Zero trust security is, at its core, a mindset from which techniques and tactics emerge and leverage specific technologies, which can then be applied to address a broad spectrum of security threats.
That mindset embraces a set of assumptions, and the uses of technologies are consequences of those assumptions.
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.
Let’s walk through a few examples that, as the title suggests, lead us to conclude that bot protection and web and API security are part of the zero trust toolbox.
- 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 that 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 nasty ware (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.
- 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 percent – 2 percent 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.
- A zero trust approach assumes change is constant. Zero trust rejects the assumption that once a user is verified and access to a resource authorised, 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.
