Guide to Zero Trust: 4 Things You Need to Know

Best practice is to operate from the perspective that an attacker is on your network, servers, laptops, mobile media, and databases. In other words, the traditional way of thinking that your internal networks and environments are “safe” and all users can be “trusted” is no longer true. Read on to learn about Zero Trust and how to effectively and proactively implement it into your organization.

Implementing Zero Trust simply means introducing less trust into your organization’s environment in the short term, but you can consider increasing those efforts down the road. Zero Trust scales. So, no matter the size of your organization, security team, or budget, you can find ways to start implementing less trust today. 

There are four key areas of implementation your organization should focus on when introducing Zero Trust into your environment.

• Detection Capabilities
• Traffic Analysis
• Least Privilege 
• Access Control

1. Detection Capabilities: Identify What You Have

How are you going to find the attacker on your network and in your systems? How are you going to know where they’re hiding, what they’re doing, and what they’ve already stolen from you? In order to start answering these questions, you must have the following solid detection capabilities in place.

Know Your Data, Devices, Applications

 Solid detection capabilities means first having insight into what sensitive data you have, what devices you have, and what software you have. In other words, you must know what your sensitive data is, where it is located, and what systems use it. The adversary inside your environment is looking for your sensitive data, so you better know where it is before they do. This means having a data classification scheme that is in place and actively utilized by your employees and staff members. It also means knowing which systems access, process, transmit, and/or store your sensitive data. Keeping an active inventory of all hardware and software, classified and categorized by Impact and Risk, will keep you organized and ready to act. 

Set Up Centralized Logging

Once you have a comprehensive knowledge of your data and systems, you need to understand what normal network activity on these systems looks like so any abnormal activity can be identified. Centralized logging means you identify what activities using your sensitive data are so important to your organization’s mission and daily processes that you need to have a firm understanding of how those activities function under normal, i.e. productive, circumstances. After all, knowing what is normal will help you identify what is abnormal or looks like potential attacker activity. 

Understand Threat Intelligence and IOCs

“But wait… we’re working from the mindset that I’m already compromised, so how am I going to determine what is normal if I’ve already been compromised?” 

This is where threat intelligence enters the picture. In order to know what activity should be taking place, your information security team needs to know what activity should not be happening. Attackers have certain patterns of behavior that can be identified. Even when using a botnet to perform reconnaissance or a DoS attack, these botnets have been programmed by humans to act a certain way from certain ports, IP addresses, protocols, or IoT devices. In other words, you need to understand the IOCs (Indicators of Compromise) for those threats and attack patterns most common to your organization’s industry. The MITRE ATT&CK framework is a knowledge base of adversary tactics and techniques for modern day threats relevant to private sector verticals as well as government organizations. Couple this intelligence with your comprehensive knowledge of your network, sensitive data, and critical systems and you are on your way to detecting the threat that is living inside. 

2. Traffic Analysis: Start Scrutinizing Outbound

Once you’ve been compromised, it’s just a matter of time before the attacker does what they really came to do: exfiltrate your most sensitive, valuable data. Thus, in order to detect the adversary inside your systems before they have a chance to do this, you must have visibility into the movement of your data, the movement to and from your networks, movement to and from your cloud systems, and the movement to and from your endpoints.

Analyze Both Inbound and Outbound Traffic

A traditional security model - based in Trust - only monitors inbound traffic (because only inbound traffic was thought to be malicious since attackers were thought to come only from outside an organization) and is no longer sufficient. Today, you must monitor outbound traffic. Zero Trust operates from the mindset that all traffic - inbound and outbound - must be secured and monitored because an adversary can still come from the outside but, now, the adversary is also moving around inside your network. Remember, that may or may not really be your CEO connecting via RDP. 

Continuously Monitor

The key word here is “monitor.” This gets back at the foundation for detection - having a data classification scheme, asset inventory, and centralized logging also provides you with the capability to monitor the movement of what data — and how much of it — leaves your network from which systems. If your CFO starts downloading 1 terabyte of credit card information from the PCI database at 3 a.m. in the morning to an IP address in a country you know she does not live in (nor does your company do any business there), that should be an event that is detected immediately and investigated asap. 

Include Cloud and Mobile Devices

Monitoring traffic is not just from the perspective of direction, either. Monitoring traffic must include all key systems and endpoints, including cloud applications and mobile devices. This is not to say that you should monitor and log every single transmission and event that occurs on every single thing. Instead, it is about monitoring those systems, including IaaS, PaaS, Saas, laptops, smartphones, IoT, and ICS that are important to your organization’s mission and business processes in order to identify the threats currently living in your environment. Attackers want to be on those systems.

3. Least Privilege: Revamped for Everyone

Attackers will be actively looking for the most sensitive data, which includes trying their best to elevate their privileges in order to gain access to that sensitive data if initial spear phishing attacks weren’t successful. This attacker may or may not be able to escalate their privileges, but they are certainly trying to do so. The problem is “may or may not” is too great a risk for your organization to take. Therefore, you should rethink how you implement the principle of least privilege. 

Think “Need to Know” for Access

The principle of least privilege must be revamped to provide only those users with a “need to know” access to only those devices, laptops, servers that have only the specific applications and data on them that those users are allowed to access. If Bob in HR does not have a need to know your patient’s data on a daily basis in order to perform his job duties, then Bob in HR has no business having access to your EMR. This way, if Bob were ever to fall for a phishing attack and his credentials are used by an attacker to gain access into his accounts, one of those accounts compromised would not be in your EMR system. 

Apply to Everyone

Many organizations understand how to implement a Zero Trust model for contractors or third-party personnel who may need to perform maintenance on a device or in a system. A contractor would only be given access to the system that needs updating or patching. And the contractor would only be allowed to access certain data on that system only using a certain application — or list of approved applications — on that system. In other words, the contractor would not be trusted and their access would be restricted to the least privilege needed to perform the job. This mindset needs to be applied to everyone in your organization, including the CEO, not just your contractors.

4. Access Control: Conditions, Conditions, Conditions

So just how easy is it for an attacker inside your network to gain access to a PCI database, EMR system, or another database housing your most sensitive data? Just because someone compromises your username and password, should they be allowed access into all your accounts and applications? And should the same access controls be implemented universally for every employee in your organization or should there be stricter controls for those individuals with more privileged access? In a Zero Trust environment, the answers to these questions are easy: access should be controlled by a series of conditions based on who the user is as well as the device. 

Apply Several Conditions 

Taking the above example of the CFO, we could detect very odd activity based on a list of conditions: who the user was, the amount of data being downloaded, the type of data involved, the time of day the download was taking place, and the location of the device. These same types of conditions used for detecting suspicious activity can also be applied to access controls. Conditions for access control can include device, location, time, MFA, as well as confirmation of a device having a certain operating system version or anti-virus updates. Applying conditional access controls such as these helps to ensure that only the people who should be using those devices, systems, applications — and the sensitive data on them — are given access. 

Use More Stringent Conditions for Privileged Users

And, yes, those conditions are more stringent for those users with more privileged access. What if Bob and Jane were required to log in using only the laptops that were issued to each of them, only from the cities in which they lived and worked, using not just their username and password but also phishing resistant MFA, and only during the hours of 7 a.m. to 6 p.m. in their respective timezones? Their devices may also have to undergo a post-authentication check for updated anti-virus signatures and applied patches before being allowed to connect to the network. For Jane, she may be required to provide biometrics as part of her identification and authentication process. Her device may undergo additional post-authentication security checks before she is allowed access to the network. She and her device may require even more security checks or use of a jump box or VDI if she’s accessing certain systems, such as the PCI database. In other words, verify that a user is who they appear to be by using a group of conditions relative to each user before granting access. Once that access has been granted, continue to limit user access to sensitive data based on conditions.