No Zero Trust Network without strong authentication

The Cybersecurity Tech Accord, throughout Cybersecurity Awareness Month in October, broke down the core elements of “Zero Trust” architecture in a blog series – Never Trust, Always Verify. The series featured expert voices from across Cybersecurity Tech Accord signatories analyzing what Zero Trust is, what is isn’t, and how to have an informed conversation to ensure your organization is employing best practices for security.

Szilárd Pfeiffer, Security Engineer & Evangelist at Balasys, wrote about Zero Trust and strong authentication.

What is Zero Trust and why is it important?

Traditional cybersecurity approaches focus on establishing a sound perimeter to keep malicious actors outside a network. This assumes that all users and resources inside the perimeter are trustworthy. In today’s world, however, resources are increasingly hybrid in their structure, and data are spread across an innumerable combination of devices, services, applications, and people. This makes security more complicated than simply keeping bad actors outside a network; good security means knowing more about who’s inside as well. According to the Zero Trust Architecture’s principle guideline – never trust, always verify – no resource should be accessed until successful authentication and authorization have been achieved.

While the Zero Trust security Model was first introduced in the 1990’s, it’s only become widely known and used in the past few years because, like many things, it is far easier said than done. But one thing is for sure: the improved security environment is worth the effort, and it begins with strong authentication. The Zero Trust security model is an approach to the design and implementation of information technology systems. The main concept behind the architecture is de-perimeterization, which refers to the removal of a boundary between an organization and the outside world.

The seven tenets of Zero Trust

The United States’ Cybersecurity and Infrastructure Security Agency (CISA) has outlined the following principles in its Zero Trust Maturity Model:

1. All data sources and computing services are considered resources.

Even if the network is composed of multiple classes of devices, this tenant does not allow exceptions. In practice, there should be at least one policy enforcement point in the network where all the traffic goes through and where the policy can be enforced.

2. All communication is secured regardless of network location.

Secure communication and providing trust are no longer based on the location of an asset.

3. Access to individual enterprise resources is granted on a per-session basis.

An evaluation should be made before giving access to a resource independently of whether the resource was previously permitted or not.

4. Access to resources is determined by dynamic policy.

The policies should be generated as real time as possible and should always be appropriate to the attributes.

5. The enterprise monitors and measures the integrity and security posture of all owned and associated assets.

No asset should inherently be trusted, and data integrity should be maintained at all times.

6. All resource authentications and authorizations are dynamic and strictly enforced before access is allowed.

Authentication and authorization should always be rigorously checked at each access request before access is granted to a resource.

7. The enterprise collects as much information as possible about the current state of assets, network infrastructure, and communications, and uses this information to improve its security posture.

Maintaining and improving security posture is a never-ending circle: collecting and analyzing data are essential to the process.

While there is no one definition for Zero Trust architecture, the major tenets of the approach, as described by CISA, make clear that strong authentication is at its foundation. And strong authentication needs to be a priority for all security architecture, as password issues are responsible for more than 80 percent of data breaches. And strong passwords alone are not enough. Organizations today require more robust protections to defend themselves against the latest threats. Though more and more companies are investing in various strong/multifactor authentication methods, it has proven easier to purchase a solution than to effectively implement and introduce it across an organization. So how should organizations start to actually follow through in adopting strong authentication practices?

ALWAYS ENCRYPT AND ALWAYS ENCRYPT WELL

The ‘zeroth’ step in implementing strong authentication is reliable encryption. Zero Trust requires that enterprises never consider their private network as an implicit zone of trust. Assets on a network should always be handled as if an attacker was persistent on the system. As a result, access to resources should be granted in the most secure manner available. This entails not just authenticating all connections, but also encrypting all the traffic. Attackers are smart, and capable enough to eavesdrop on a network, analyze any unencrypted traffic to capture credentials to perform a well-structured attack later.

In the case of a private network or service, it is good practice to allow only the most secure cryptographic algorithms that provides forward secrecy, such as ECDHE and authenticated encryption, such as Poly1305. Attacker toolchains – such as other software systems – often contain legacy parts that do not support the most modern mechanisms. This means that an exploit used against a service that can be accessed solely via encrypted channels, using the most modern algorithms, will fail before it can really begin, even if the attacker can access the system and has valid credentials, as the initiation of the encrypted connection will fail. This approach also has other indirect benefits. Using state-of-the-art encryption increases security as connection failure events can be reported as suspicious behaviors as part of “real-time monitoring,” another requirement of Zero Trust. Beyond this, advanced encryption also helps us identify our own legacy or “shadow” systems that cannot support the most modern forms of encryption, meaning they should either be accessed through a middleware device or be sunset altogether.

AUTHENTICATION IS ABOUT IDENTITY, NOT METHODS

Just like there is no reliable authentication without encryption, there is no authorization without reliable authentication. Zero Trust requires strictly enforced authentication and authorization before resource access. Unfortunately, security experts sometimes focus on methods instead of identity. Passwords, certificates, tokens, or biometrics are just methods, they are not the identity itself.

For instance, spyware can collect login credentials by harvesting from the databases of pawned sites, especially when users use their company email addresses for private purposes. Meanwhile, simpler passwords can be brute-forced to be discovered. If security is compromised, the password can no longer prove identity. You might think that a more modern and sophisticated method – such as a digital certificate – could solve the issue of simple passwords, but at the end of the day the strength of the certificates depends on the strength of the password that protects the certificate’s private key. If an attacker can compromise a protecting password, the authentication based on the certificate is also compromised.

Multi-factor authentication (MFA, or 2FA) has not become so popular for nothing, and security experts today encourage both individuals and companies to use at least a second factor in authentication. However, MFA also has weak points in addition to its significant benefits. A typical time-based, one-time password (TOTP) either expires after a minute or is used as part of successful authentication. This means that even if an attacker acquires the actual value, it cannot be used for subsequent authentications. Unfortunately, this does not protect against website spoofing, which can prompt a user to provide both their password and the TOTP on the spoofed authentication form. Using the intercepted credentials, the attacker can then authenticate in the name of the victim.

A more convenient, but less secure, second factor in MFA is “push-based” authentication where, following a successful password-based authentication, the user confirms the login by clicking “Yes, it was me” in a push notification received on their mobile device. However, if an attacker can compromise the password, several login attempts can be made that cause several push notifications on the mobile device of the victim. Just one confirmation in error that occurs either accidentally or through getting tired of the spoofing (MFA fatigue attack) is enough for the attacker to get into the system. It is also important to remember that a mobile-based second factor cannot be any more secure than the protection of the mobile device itself. If the mobile device isn’t locked, we risk the sense of the second factor, and this is the case if confirmation can be done without unlocking, or the locking pattern is simple, predictable, or vulnerable to smudge attack.

To make a long story short: MFA is an essential best practice, but no matter how perfect a solution may seem, security awareness is still essential.

AUTHENTICATION IS NECESSARY, BUT NOT SUFFICIENT

Zero Trust Network Architecture requires both encryption and authentication, but these are means, not an end in and of themselves. According to the National Institute of Standards and Technology (NIST) in a special publication on Zero Trust architecture, both authentication and authorization should be strictly enforced every time before access is granted to any resources inside or outside of the private network, in line with the principle of least privilege. This means that the classification of a resource should also vary the conditions of the resource access. Depending on the observable state of client identity, the requesting assets, or other behavioral and environmental attributes, various levels of access can be granted for a resource.

The principle of least privilege (PoLP), also known as the principle of minimal privilege (PoMP) or the principle of least authority (PoLA), requires that in a particular abstraction layer of a computing environment, every module (such as a process, a user, or a program, depending on the subject) must be able to access only the information and resources that are necessary for its legitimate purpose.

For instance, under certain circumstances, strictly “read-only” access may be granted to a particular resource, but upon further authentication “read-write” access can be provided as well. The situation reflects approaches to physical security, where entering physical environments with higher classification requires additional authentication. In terms of network and data security, access to data should mirror physical security considerations and authentication requirements for access to a location. In this dynamic, authentication is not just a single step – pass through the doors and you’re in – but rather a repeatedly executed task of the policy enforcement process based on what is being accessed and how.

The first tenet of Zero Trust says that all computing services are considered resources. Authentication services should be considered as resources, meaning that access should be granted taking the least privilege principle into account. It means that the number of authentication requests, including successful and unsuccessful, should not exceed a certain number. Rate limiting unsuccessful authentication requests helps to prevent brute-force attacks against the first factor of the authentication, such as a password. However, this does not diminish the importance of choosing properly secure passwords. Rate limiting successful authentication requests helps to avoid the compromise of the second factor after the first factor has already been compromised. For instance, an MFA fatigue attack is hardly feasible if the number of successful authentication requests is limited. Zero Trust requires monitoring and measuring the security posture of all owned and associated assets, meaning that exceeding the rate limit should be monitored and could trigger the deactivation of a user account that is suspected to be compromised. This is how identity handling becomes dynamic, something which is required at the optimal level of maturity in the Zero Trust Maturity Model.

HUMAN FACTOR IS UNAVOIDABLE IN AUTHENTICATION

While trying to achieve the higher and higher levels of Zero Trust maturity, we should not forget about the weakest link in all security system chains: humans. Security is often contrary to comfort, yet discomfort is usually also contrary to security. Even the trendiest, most cutting-edge , methods can have weak points that attackers can successfully exploit while the most traditional methods might work effectively under such circumstances. Not surprisingly, users tend to bypass security systems if the discomfort they experience exceeds a certain level. Bothering users with frequent password changes is a particularly good example of this. Users who are forced to frequently change their passwords often fall into two kinds of bad habits for security when trying to remember their passwords. The first is writing it down where others can see it, and therefore steal it. The second is that making memorable but predictable alterations to their existing password to fulfill the password policy requirements.

A conventional authentication method such as a password can be secure, but its security level does not depend on the expiry period. – rather, it depends on the entropy. The easier it is for a user to remember a strong password, the likelier it is they will use it. Security is about minimizing risks that cannot be taken without cooperation. High security requirements are good, but followable security rules that are in line with the risk are the best.

This article was originally published on the Cybersecurity Tech Accord blog.