Zero Trust Architecture
Intent
Zero Trust, meaning “never trust, always verify” (Samaniego & Deters, 2018, p. 89), is an approach to secure digital assets by eliminating implicit trust and requiring strict verification when trying to access resources.
No user or application is trusted by default from inside or outside the network, and verification is always required from everyone trying to gain access to resources on the network. This added layer of security has been shown to prevent data breaches. IBM Studies have shown that the average cost of a single data breach is over $3 million.
Zero Trust Security was first established at large internet firms such as Google and CloudFlare, and it is starting to gain traction with the rest of industries and corporations.
Zero Trust Architecture (ZTA) is designed to protect modern environments and enable digital transformation by using strong authentication methods.
Motivations
There are a number of internal reasons why ZTA has become increasingly critical in the modern environment besides financial and legal implications in wake of a potential breach.
Inherent Trust
The traditional security models operate on the outdated assumption that every service or people inside an organisation’s network should be implicitly trusted, hence gaining access to everything within the network. It is common to see attackers gain access to a network, including thread actors and malicious insiders, are free to move laterally and access or exfiltrate sensitive data due to a lack of granular security controls.
ZTA challenges that conventional ethos by removing inherent trust from the internal network.
Cloud Movement
With cloud adaptation picking up pace, and systems and applications are more distributed than they ever have been, the concept of traditional network perimeter starts to disappear and dissolve.
ZTA provides a mechanism that enables companies to operate securely in the new world.
Principles
There are three key principles to ensure the success of ZTA.
Grant the Least Amount of Privileges
As the foundation of ZTA, the idea is to grant the least amount of privilege and access as possible without impeding a system or individual's ability to complete their tasks. The access is granted on a case-by-case basis to exactly what is needed and nothing more.
Never Trust, Always Verify
No action, system or user should be trusted by default, every new entry into a system or request to access resources must come with authentication to verify its authenticity.
Monitor, Monitor, Monitor
With least privilege and authentication being the backbone of ZTA, it will massively undermine the value and effectiveness of ZTA without sufficient or even increased levels of monitoring capability. The enhanced monitoring will unlock abilities to gain insights into system/user behaviour, data movements, network changes, data alterations and more.
Considerations
There are a sequence of steps to take before getting to the summit. This is not necessarily an exhaustive list of actions, also even though highly recommended, you should decide for yourselves which are more applicable considering the specific scenario and context.
Figure 1. Zero Trust Architecture
Visibility and Critical Asset Identification
Just like Rome wasn't built in a day, we need to start somewhere. The first and foremost step to get to ZTA is to identify the most critical and important data, assets, applications and services within the network.
This helps:
set the priority on where the work should start,
enables the creation of Zero Trust Security Policies (refer to sections below),
begins to protect these assets as part of the ZTA journey.
Zero Trust Network Access (ZTNA)
The conventional wisdom of the perimeter of traffic being inside or outside the border has the following assumptions:
Traffic from outside of the network is untrusted, hence should be validated and restricted
Traffic from inside the network is trusted by default
Identity of a system or user is never compromised
This broad definition often creates oversights that only one system is affected in the event of a breach rather than all systems being under threat. This approach is “verify, then trust” by requests passing a number of checks, such as firewalls, VPNs, IPS, etc.
Whereas the Zero Trust Network requires a granular definition of perimeter, i.e. micro-perimeter, and implements micro-segmentation to ensure the assets within micro-perimeters.
Micro-segmentation
Micro-segmentation is the practice of breaking up a security perimeter into small zones to maintain separate access for separate parts of the network. For instance, there may be several secure zones within a network using micro-segmentation, and sensitive data is stored in a single data centre in one of the zones. Systems or users with access to any zones other than the one with a data centre will not be able to access the data, without separate authorisation.
There are a number of benefits with the micro-segmentation approach:
with lateral network mobility risk eliminated, it massively improves breach containment. In other words, if two systems do not need to talk to each other across the network, they shouldn’t be allowed to, even if these systems happen to live within the same network,
which will in turn reduce the attack surface, particularly the ones that could lead to sensitive data;
a simplified consistent security policy can be used to protect the systems,
which reinforces the effectiveness of resource access governance,
and better supports compliance and auditing by creating perimeters around certain types of sensitive data.
Identity and Access Management (IAM)
Building on top of ZTNA is access control in the application layer, which is a challenging topic on its own. Even though it has been done many times in many ways with many modern technologies, frameworks and off-the-shell products, in essence, IAM is a means of managing a given set of users’ digital identities, and the privileges associated with each identity.
There are many data points on which security decisions can be made, and here is a non-exhaustive list, starting with identity, location, device (address, health), resource, data classification and anomalies.
Authentication & Authorisation
A contemporary approach to authentication that works well is tokenisation.
This requires incoming requests to present a token when trying to access the target system.
The token will then be verified by the target system itself, if it were the issuer, and have the token correctly configured;
alternatively, the target system will send the token presented to a token verification service for authentication.
The token will remain valid during the communication, but should expire after a pre-configured amount of time, a so-called temporary credential.
As part of the token verification process, it is likely that the underlying credential associated with the token would have predefined security policies specifying granular access.
Use Case: JSON Web Token (JWT)
JWT, pronounced “jot”, is a special form of auth token. It is an open standard.
JWT is issued by the server. The data is created and verified with a digital signature, the encryption can keep it safe even over HTTP. A JWT token is made up of three parts: header, payload, and signature, where the payload contains a set of claims which specifies the permissions associated with the token, hence the underlying account.
Figure 2. Client Credential Grant Flow
A finished product:
allows for safe and secure communication between systems,
with the ability to specify what the token holder can access,
how long the permission lasts;
and the token size is relatively tiny.
Use Case: Kafka Security
Kafka security follows the same trait. Network segmentation restricts access to ZooKeeper, whereas Kafka brokers can be set up to be accessed through the private network, public internet or via a proxy.
Figure 3. Producer / Consumer, Broker Interaction
There are three key components to secure Kafka:
Data encryption during transmission using SSL;
Authentication via SSL or SASL;
Authorisation via Access Control Lists (ACLs).
Least Privilege Access
To complement the whole picture, security policy is at the core of the capability, and needs to be defined and configured carefully. As opposed to a policy granting access to every single system in the connected network by default, Least Privilege Access means giving systems only as much access as they need to perform their job. This minimises each system’s exposure to sensitive data using carefully crafted security policies.
Context-Based Policies
In Addition to Least Privilege Access, security policies should also be adaptive when the context changes, so the systems’ access privileges are continually reassessed and updated. The context change can include identity, device, location, type of content, access per request, etc.
Security Policy Governance
Strong governance directly contributes to the success and performance of ZTA. Therefore, Zero Trust is an organisational strategy rather than a local one. Organisations with advanced strategies verify business security assertions by regularly validating technical security assertions, an example of that would be asking “is the data confidential?”
Governance should first ensure the integrity of data, followed by continuous assessment and adjustment, to foster best practices, continuous improvement and innovation.
Assume breach
Rather than burying heads in the sand, realising and recognising hacking is a reality and an imminent risk will help better prepare the teams mentally and physically for when it actually happens, limiting the blast radius to the minimum and disruption to the organisation.
Assuming micro-segmentation is done, end-to-end encryption, automatic threat detection and response are in place, it is half way there to secure the systems, apart from the fact that we do need to know when an incident (PEN testing or real attack) actually occurs and being alerted through continuous monitoring.
Real-time Monitoring
ZTA requires each system to monitor how many other systems or services are trying to access its network, ensure the requests are authorised, and report on any anomalies of behaviour.
Moreover, real-time monitoring is critical for mitigating damage when preventative measures fail. It allows a system to contain the breach while giving valuable breakout time to secure teams to respond to an intrusion.
This will further minimise the attack surface area of the network, provide both full visibility and control over a growing number of demands in the distributed cloud environment.
Challenges
With great capability comes great liability, ZTA is not only a technical or logistic challenge, but an organisational challenge.
Time
Everything takes time, ZTA adaptation is no different from the others, in fact, more so. Just to give you an idea: Google, one of the pioneers in this space, spent some six years moving away from its VPN and privileged network access model to BeyondCorp, its own version of a zero trust environment. Along the way, the company had to redefine and restructure job roles and classifications, build an entirely new master inventory service for keeping track of devices, enable better visibility over its apps, and overhaul user authentication and access control policies. Pulling off the effort required support from the board level down.
Therefore, it is good to be clear about the commitment and expectation upfront.
People
Another challenging factor is people’s mindset, even business may feel uncomfortable with the change in the beginning.
As the implementation details kick in, engineering teams may soon find themselves out of depth and in desperate need of some necessary skills to implement the vision of ZTA.
Legacy Integration & Migration
A lot of legacy or even essential systems or applications may be proven difficult to readjust to ZTA, one of the examples is the HR system, it is needed for the daily functioning of business but are typically left out of the ZTA. As a chain is only as strong as the weakest link, these systems can present a weak link in the security system and diminish the advantages of switching to ZTA. Therefore, it is worth evaluating the impact of whether or not to rework or replace these systems, and the associated costs.
Commitment
Access control and security policies need to be monitored and updated regularly. Either a central committee or team should take the responsibility or new roles need to be created in order to maintain these. Moreover, a company needs to have a comprehensive view of all identities, security requirements and policies, and can make changes immediately.
Any delay in updating access control or security policies could lead to potential devastation.
Comments
Post a Comment