The zero trust strategy aims to effectively stop hackers and prevent data leaks. The underlying principle: no connected devices and persons can be trusted until authenticated definitively and reliably. In return, they are only ever granted the authorisations that they actually require. In the first part of our blog post about zero trust, we looked at what companies need to consider before implementing this type of security strategy. In this second part, we turn our attention to the actual implementation.
Having completed the first planning step, which involved compiling an inventory of the internal data that requires protection, the data streams within the company, and the necessary protection classes, we must now define the access rules that will apply in the future. The previously acquired knowledge serves as a basis: Who are the users? What data, applications and other resources are they using? And which devices and connections – the intranet or a VPN server – do they use to access company data?
PDP with PEP
The zero trust principle is applied when resources within the network are to be accessed. As a rule, this type of data exchange can only take place if it is classified as permissible according to a set of rules and has been added to a whitelist. In practical terms, these rules must satisfy two key conditions:
- All components of the network must send incoming and outgoing requests for data exchange to a central decision point – also known as the policy decision point (PDP). The PDP determines whether or not requests are approved based on the available information, the attributes, as well as the applicable security guidelines.
- In order to implement the access rules, the PDP must be able to activate all existing security components – the policy enforcement points (PEP) – via appropriate interfaces. Multi-factor authentication (MFA), web application firewalls (WAF), host-based network segmentation, and numerous other solutions can function as PEPs. Which of these is used will depend on the previously determined initial situation in the company.
Getting started: making the change
Since the zero trust strategy is a dynamic process that cannot be rolled out from one day to the next, it’s important not to overlook anything during the implementation. On the contrary, a prudent approach will even pay off. The specified guidelines determine the way forward for the zero trust implementation. However, the speed at which this takes place and the tools required may be decided by higher-level business criteria:
- Are new procurements or replacement investments planned anyway? For example, are licences for existing security products about to expire? Or is a switch from on-premise to cloud storage planned? If so, IT executives should ensure that new hardware and software are compatible with the zero trust objective and are integrated into the new security architecture.
- In which area do new zero trust components offer the greatest boost to security? Can a rapid return on investment (RoI) be achieved there? It is now time to start laying solid foundations for its further development.
- Increasing security is not an end in itself and often comes at a significant cost. However, it can be priced into many projects as a logical addition: For instance, if a new customer management solution is being set up anyway, the chosen solution must also cover the key zero trust security factors – such as multi-factor or passwordless authentication.
In a nutshell: although zero trust requires a degree of perseverance, the necessary investments can be spread over a longer period. This means they do not unnecessarily reduce operating profits – yet still contribute to the ongoing rollout of a future-proof zero trust architecture.
