What is a Zero Trust Architecture (ZTA) and why it matters.

There are a number of definitions of Zero trust or zero trust architecture. Let us look at the definition given by the US National Institute of Standards and Technology (NIST):

Zero trust provides a collection of concepts and ideas designed to minimize
uncertainty in enforcing accurate, least privilege per-request access decisions in
information systems and services in the face of a network viewed as compromised.
ZTA is an enterprise’s cybersecurity plan that uses zero trust concepts and
encompasses component relationships, workflow planning, and access policies.
Therefore, a zero trust enterprise is the network infrastructure (physical and virtual)
and operational policies that are in place for an enterprise as a product of a ZTA plan.
”[1]

To put it simple, the main mantra could be described as “never trust, verify always” or always consider your services and applications to run in a potentially compromised environment. While the concept is not that new, Wikipedia refers to Stephen Paul’s doctoral thesis in 1994, where the concept of zero trust was mentioned first, it has gained a lot of momentum lately.

In a hyper connected IT landscape where organizations and businesses are using software-as-a-service from different providers, often coupled with their own on-premises servers and services. These services need to be exposed in a controlled way to users. Think about employees working from home and the office or external partners or suppliers that might need to access to your services and systems as well.

This complexity has become the new normal.

Over are the days of the Intranet/Extranet duality where everything withing the “Intranet” is considered secure and trusted and everything outside of it was not and all of it only protected by firewalls and/or a VPN access point. Imagine what would happen if the firewall software itself or the VPN access point might be compromised by an external threat actor? Which happens more than enough. “Zero trust” would help to mitigate damages caused by such incidents.

The US Cybersecurity and Infrastructure Security Agency (CISA) describes a Zero Trust Maturity Model to provide a path supporting the transition to zero trust. [1]

The model builds on five major pillars. One of those pillars is “Identity” where the goal is that users “… use enterprise-managed identities to access the applications they
use in their work. Phishing-resistant MFA protects those personnel from sophisticated
online attacks.”

Identity@ThingsRock does provide a powerful centralized identity and access management.

It allows easily to enable and rollout Multi Factor Authentication for users and or groups of users. It supports face recognition or fingerprint validation on a user’s device. Identity@ThingsRock also leverages hardware keys/tokens as well as OTP (One Time Password) apps. These distinct factors can be configured and included into different login flows and then rolled out easily to all connected services and applications or at a per service/application level. Flexibility and ease of use are important building blocks of our service.

But there is another crucial point that must not be forgotten by your IT which is managing the identity and permissions of applications/services.

Here at ThingsRock we use dozens of mostly self-build micro services and this number steadily growing. Identity@ThingsRock provides us with all what we need to manage the identity of these services and what these services are authorized to do, i.e., we use Identity@ThingsRock to secure the APIs of our services. Each of our services exposes its different authorization scopes. An authorization scope/role represents what a user or service is permitted to do, like reading the list of users or sending an email through an API. Identity@ThingsRock allows us to manage all these authorization scopes centrally at various levels, be it per user, user group or service level.

As mentioned earlier, we also use Identity@ThingsRock to protect our APIs. For instance, a user not only needs the access right (authorization scope/role) to an API, but on top of that, a user might need to authenticate with a second factor (level of authentication) for critical APIs. All these powerful options allow us to protect and secure our own services exactly the way we need it.

With Identity@ThingsRock we can support you on your journey to a Zero Trust Architecture.

If you would like to know more about Identity@ThingsRock just try it out: Register a free account or contact us: info@thingsrock.com.

1: NIST SP 800-207: Zero Trust Architecture. 2020. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf

Leave a Reply