Securing IT environments and especially the topic of cloud computing platforms are on the minds of many companies these days. Common sense: IT security is considered more important than ever. In recent years, the term zero trust has appeared more and more often in discussions about architectures and security. But what exactly is behind this term and how is Zero Trust relevant for your company? We would like to shed some light on the subject and briefly provide you with all the relevant information on Zero Trust.
In the classic IT architecture world, the so-called perimeter approach was considered the standard for a long time when it came to IT security architecture. To explain the term as simply as possible, one usually uses the image of a castle and its moat ("castle-and-moat"). As in the classic image of a castle, attackers from the outside are made as difficult as possible to enter the castle in order to conquer it. On the other hand, people inside the castle are given almost unrestricted freedom of movement. If we transfer this example to the IT world, it is made as difficult as possible for people outside the local network to access private resources (within the network), e.g. through the use of firewalls. People inside the network are treated differently. They are given the benefit of the doubt and usually also more or less unrestricted access since they are in the trusted area.
In the meantime, however, things have changed in IT. Companies are relying more and more on applications from the cloud. And employees are increasingly using the option of working from their home offices. These examples already show that the IT landscape is changing. This paradigm shift is also accompanied by changed requirements for IT security as well as the associated architecture: the origin of the Zero Trust approach was developed. It is a tool to meet the new requirements.
With the changed requirements, it is of course not advisable to stick to the old approach. If an attacker is already in the network (e.g. internal threat), it is correspondingly easy for him to attack other systems in the network. A clear "castle wall" cannot really be built, as more and more external service providers, cloud platforms and digital collaboration possibilities are becoming relevant for companies. These external services or parties are partly used for processing data (Microsoft 365) or also for providing storage space (Microsoft Azure).
You can see for yourself: a mere security barrier (castle wall), as applied in the perimeter approach, leaves you defenseless. And this is where Zero Trust comes into play.
The zero-trust approach is essentially based on the already known least privilege approach, which refers to all entities (users, devices, systems, etc.) within a company. As the name of the approach already indicates, the zero-trust approach means that there is no implicit trust placed in these entities. To obtain the desired access, each entity must fulfil certain requirements, which are defined by the respective company.
The definition clearly shows that the Zero Trust approach is much more about guiding principles that look different for each company and can have an influence on processes, communications, and far-reaching IT decisions.
The implementation of this approach can go much further, depending on the claim. Renowned institutes, such as NIST or Forrester, have already dealt with the Zero Trust approach at an early stage and developed various concept papers. In Germany, the BSI recently took a stand on the topic of Zero Trust. In essence, it clearly addresses the NIST concept, which represents the status quo.
In the Zero Trust approach, we talk about the fact that entities must gain trust first. Each entity can independently define what its requirements are for gaining temporary trust. If an entity then makes a request for access to a resource of a company (e.g. OneDrive), this entity is checked. More precisely, it is checked whether the entity fulfils the requirements. If it meets the requirements, the entity is granted (temporary) access. If it does not meet the requirements, the request is denied. After such access has been "released/allowed", this access and the state of the accessing system is continuously monitored. If there is a need/violation of the requirements, the access permission can be withdrawn.
This is the core of the Zero Trust approach. However, there are many more recommendations that go hand in hand with the approach, such as logging, authorization concepts and automation in the context of Zero Trust. Zero Trust in the context of cloud computing.
Now looking at the topic of Zero Trust in the context of cloud computing and going into more detail on an example in the Microsoft context. Logically, this topic is also relevant for other manufacturers.
If we look at the Microsoft cloud world, it is noticeable that many companies are increasingly obtaining various services from Azure, Microsoft 365, or Dynamics. Thus, these services contribute more and more to the company's success. For this reason, they need to be looked at more closely in the context of IT security. Let's take Azure as an example. For prescribed services to be administered there, it is necessary for administrators to have access to the portal, for example. With this access, it is also possible to retrieve data from a storage service, for example. You are probably asking yourself: How can I approach the issue of zero trust in this context?
As already mentioned, Zero Trust is not a project with an end date. It is an initiative that will accompany you continuously, as the requirements must always be checked, updated, and renewed. Using the example of access to a Microsoft platform such as Azure, the "Conditional Access" function represents one of the most important technical implementation points. Within the service, you can define the requirements for an entity. This service then checks the access requirements of the entities and subsequently decides whether an entity is granted access or whether it is denied access. This is also illustrated in the following graphic.
In our example, you could define that an administrator who wants to log on to the Azure Portal can only do so from a company device. If this is the case, he can access the Azure Portal and carry out his activities there. However, if he uses a device that is not known to the company, he must perform the MFA confirmation. Otherwise, his access attempt will be rejected.
This example makes it clear that these specifications/requirements can be more or less freely defined. The important thing is that nowadays you can secure a huge range of applications/services and platforms via Conditional Access. These only need to be connected to Entra ID (formerly Azure AD).
All in all, even just the rough overview of the Zero Trust topic complex makes it clear that it is much more than simply introducing a new way of thinking. From my own experience I can report that there are many myths surrounding the implementation of a Zero Trust initiative and many companies hope for a golden approach that fits all companies. However, this golden approach does not exist. Each company must find its own way of dealing with the issue and design its own approach, processes and requirements based on this. If you have questions about the development of a Zero Trust strategy or you are interested in how the Zero Trust model can be applied in your IT landscape: Don't be afraid to get in touch with us.Our training center offers training courses in the area of Microsoft Security, which also cover precisely this highly relevant topic (English courses are also available).
Our training center offers training courses in the area of Microsoft Security, which also cover precisely this highly relevant topic (English courses are also available).
