I have been reading the Zero Trust Architecture (ZTA) publication from the NIST for quite some time now. You can find the document here: https://csrc.nist.gov/publications/detail/sp/800-207/final. This 41 page document is dense and full of advanced architecture patterns. It took me a while to read and understand.
The original post of this article was on www.tristandostaler.com on January 11, 2021.
By designing a network using the ZTA, you can make sure that if an attacker is able to get a foothold in the internal network, he doesn’t have access to anything. Of course, if the attacker stole credentials, he would still have access to what the user he impersonate has access to. But with a ZTA, there is a dynamic and constant evaluation of the global risk and current status of the whole enterprise assets, meaning that an access that was given to a user could be removed at any point based on many criteria.
For example, if the global risk of the enterprises reaches a critical point when a new CVE with a 9.9/10 CVSS score appears within it’s assets, the algorithm could block access to sensitive information to users until the CVE is patched, or could enforce MFA verification to get access to the data where there would normally be only a single factor.
Another interesting example is that an access could be denied if it’s discovered that some credentials of the user trying to get access were leaked recently (for example by using https://haveibeenpwned.com/).
This model significantly reduces the risk that an attacker could escalate it’s privileges or maintain an access for a long period and it makes it harder to use elevated privileges when they are available to the attacker (for example: through phishing).
The whole principle of the architecture is summarized in the section 3 of the document at page 9: Logical components of Zero Trust Architecture. Without going to much in the details, we can get a pretty good idea of what’s going on with this picture:
In this graph, we can see many components:
Subject: The subject is the user using the System (a computer) to get access to some Enterprise Resource (some piece of information)
System: This is simply the computer, or something similar, being used by the Subject (user) to get access to something.
Policy Enforcement Point: This is one of the core components of a ZTA. It’s purpose is to receive access requests from Systems (users) and ask the Policy Decision Point if an access is granted. It is important to note that the access can be revoked at any moment as everything goes through it, even once an access is granted. A Policy Enforcement Point can be a single system, but can also be split in 2: the Client (like a computer) and the Resource (like a website allowing access to the user).
Policy Decision Point: This is a logical component encompassing the other 2 main components of a ZTA: the Policy Engine and the Policy Administrator.
Policy Administrator: This is the component that handles all the session information, like the authentication token. It is also responsible of allowing or stopping the communication between the System and the Resource depending on the Policy Engines decision.
Policy Engine: This is the component that makes the ultimate access decision based on the policies defined by the enterprise. When the Policy Enforcement Point asks if a System is allowed to communicate to a resource, the Policy Administrator communicates with the Policy Engine. The Policy Engine makes a decision using multiple decision points (including external resources like Threat Intelligence) and the policy for the resource. The Policy Administrator will then execute the decision by creating the token for the sessions and other related things. If at any point the Policy Engine decides that the communication should be stopped, the Policy Administrator will revoke the validity of the token and the communication between the System and the Resource won’t be allowed anymore.
So, to summarize the flow, the Subject (user) using a System (computer) will try to connect to a Resource. To establish the connection, the System will ask access to the Policy Enforcement Point. The Policy Enforcement Point will ask how to proceed to the Policy Administrator which validates with the Policy Engine if the access should be allowed or denied. If access is granted, the Policy Administrator generated all the required information for the session to be authenticated and authorized and returns the session details to the Policy Enforcement Point which grants access to the System to the Resource.
If you’re in a Windows environment, the best way is to follow the guidelines and steps provided by Microsoft: https://docs.microsoft.com/en-us/security/compass/privileged-access-strategy
If you’re in a Linux environment, there are some providers that can help implement this strategy, one of them being Okta: https://www.okta.com/resources/datasheet-advanced-server-access-a-zero-trust-approach-to-linux-and-windows-server-access-via-ssh-and-rdp/
In an ideal world, everyone would implement a ZTA. That would make most enterprise really resilient to attacks and reduce the number of successful hacks we see weeks after weeks. But like it is for everyone, budgets are limited and technical human resources that can make these changes are scarce.
The main problem is that, like most secure features, it is not enabled by default. This implies that we need to assign a skilled resources fulltime for a significant amount of time on this project, slowing us on all the other important things we need to do.
If you go to the link for Microsoft Windows, you’ll quickly realize that this architecture is no simple task. And if you know Microsoft, you know everything won’t be perfectly documented and some feature won’t work like you think it should, meaning you’ll have to do some trial and error to make it work.
Sources
The original post of this article was on www.tristandostaler.com on January 11, 2021.
What is a Zero Trust Architecture
A Zero Trust Architecture (ZTA) is an Information Security architecture based on the idea that a network shouldn’t have inherent trust on the internal boundary. Many enterprise networks are designed like an egg where they have a rather strong and robust external shell, but once inside the shell, everything is lax; it needs only a little needle that is able to break through the shell to wreak havoc inside.By designing a network using the ZTA, you can make sure that if an attacker is able to get a foothold in the internal network, he doesn’t have access to anything. Of course, if the attacker stole credentials, he would still have access to what the user he impersonate has access to. But with a ZTA, there is a dynamic and constant evaluation of the global risk and current status of the whole enterprise assets, meaning that an access that was given to a user could be removed at any point based on many criteria.
For example, if the global risk of the enterprises reaches a critical point when a new CVE with a 9.9/10 CVSS score appears within it’s assets, the algorithm could block access to sensitive information to users until the CVE is patched, or could enforce MFA verification to get access to the data where there would normally be only a single factor.
Another interesting example is that an access could be denied if it’s discovered that some credentials of the user trying to get access were leaked recently (for example by using https://haveibeenpwned.com/).
Why it matters
A Zero Trust Architecture is a key element in modern architecture, cloud or not. For example, it is one of the main elements of the new architecture recommendation by Microsoft: https://docs.microsoft.com/en-us/security/compass/privileged-access-strategy.This model significantly reduces the risk that an attacker could escalate it’s privileges or maintain an access for a long period and it makes it harder to use elevated privileges when they are available to the attacker (for example: through phishing).
How is a Zero Trust Architecture implemented
As I explained, the official documentation is dense so I won’t be able to summarize how to design and implement a ZTA here. For that, I would recommend you read the official document. But I will try to make the intent of the architecture clear enough so that you can decide if it’s something you should do in your enterprise.The whole principle of the architecture is summarized in the section 3 of the document at page 9: Logical components of Zero Trust Architecture. Without going to much in the details, we can get a pretty good idea of what’s going on with this picture:
In this graph, we can see many components:
Subject: The subject is the user using the System (a computer) to get access to some Enterprise Resource (some piece of information)
System: This is simply the computer, or something similar, being used by the Subject (user) to get access to something.
Policy Enforcement Point: This is one of the core components of a ZTA. It’s purpose is to receive access requests from Systems (users) and ask the Policy Decision Point if an access is granted. It is important to note that the access can be revoked at any moment as everything goes through it, even once an access is granted. A Policy Enforcement Point can be a single system, but can also be split in 2: the Client (like a computer) and the Resource (like a website allowing access to the user).
Policy Decision Point: This is a logical component encompassing the other 2 main components of a ZTA: the Policy Engine and the Policy Administrator.
Policy Administrator: This is the component that handles all the session information, like the authentication token. It is also responsible of allowing or stopping the communication between the System and the Resource depending on the Policy Engines decision.
Policy Engine: This is the component that makes the ultimate access decision based on the policies defined by the enterprise. When the Policy Enforcement Point asks if a System is allowed to communicate to a resource, the Policy Administrator communicates with the Policy Engine. The Policy Engine makes a decision using multiple decision points (including external resources like Threat Intelligence) and the policy for the resource. The Policy Administrator will then execute the decision by creating the token for the sessions and other related things. If at any point the Policy Engine decides that the communication should be stopped, the Policy Administrator will revoke the validity of the token and the communication between the System and the Resource won’t be allowed anymore.
So, to summarize the flow, the Subject (user) using a System (computer) will try to connect to a Resource. To establish the connection, the System will ask access to the Policy Enforcement Point. The Policy Enforcement Point will ask how to proceed to the Policy Administrator which validates with the Policy Engine if the access should be allowed or denied. If access is granted, the Policy Administrator generated all the required information for the session to be authenticated and authorized and returns the session details to the Policy Enforcement Point which grants access to the System to the Resource.
How can we implement a ZTA
The previous section explains, in an architectural concept, how a ZTA can be implemented but it doesn’t explain how to actually install and use it. Because of the complexity of the architecture, I won’t go into the details on how this can be achieved, but I’ll direct you towards great resources.If you’re in a Windows environment, the best way is to follow the guidelines and steps provided by Microsoft: https://docs.microsoft.com/en-us/security/compass/privileged-access-strategy
If you’re in a Linux environment, there are some providers that can help implement this strategy, one of them being Okta: https://www.okta.com/resources/datasheet-advanced-server-access-a-zero-trust-approach-to-linux-and-windows-server-access-via-ssh-and-rdp/
What I think of the ZTA
Because of the current context with the COVID-19 and the fact that a lot of enterprises now have to support people working from home, the idea of a ZTA starts to get traction. Since I started reading about it, I have seen more and more blog posts talking about it.In an ideal world, everyone would implement a ZTA. That would make most enterprise really resilient to attacks and reduce the number of successful hacks we see weeks after weeks. But like it is for everyone, budgets are limited and technical human resources that can make these changes are scarce.
The main problem is that, like most secure features, it is not enabled by default. This implies that we need to assign a skilled resources fulltime for a significant amount of time on this project, slowing us on all the other important things we need to do.
If you go to the link for Microsoft Windows, you’ll quickly realize that this architecture is no simple task. And if you know Microsoft, you know everything won’t be perfectly documented and some feature won’t work like you think it should, meaning you’ll have to do some trial and error to make it work.
Conclusion
I think a ZTA should be applied in all enterprises, but because of the effort needed, it will be applied mostly by some medium and large enterprises that value Security as a core business need.Sources
- https://csrc.nist.gov/publications/detail/sp/800-207/final
- https://docs.microsoft.com/en-us/security/compass/privileged-access-strategy
- https://docs.microsoft.com/en-us/security/zero-trust/identity
- https://docs.microsoft.com/en-us/security/compass/esae-retirement
- https://www.techrepublic.com/article/zero-trust-security-a-cheat-sheet/
- https://www.helpnetsecurity.com/2020/03/02/building-zero-trust/
- https://www.okta.com/resources/datasheet-advanced-server-access-a-zero-trust-approach-to-linux-and-windows-server-access-via-ssh-and-rdp/