If you haven’t heard of the Zero Trust model before, I would defiantly recommend reading: Zero Trust Networks by Evan Gilman and Doug Barth or Googles BeyondCorp case study.
Now right off the bat you might think that Zero Trust is basically a concept of not trusting anything at all, but you would be wrong. It’s more around having the ability to issue/validate trust for systems and users that interact on your network. This is because you accept the fact that your internal network is not secure.
In my own opinion, here are a few guidelines:
- You must assume that activity on the network is untrusted until the user and device has been authenticated, authorised and secured.
- You must accept the castle and moat concept is becoming less affective. Your WAN is not safe just because you built the network yourself. Threats do sit inside the network.
- Utilize network segmentation. Network isolation can help control network flow and limit exposure when dealing with Worms/Trojans. Strong designs targeted at each level such as local, network and site level.
- You must have a strong inventory and audit trail.
- The design needs to have to be dynamic and adapt to different circumstances. Automation is key for success.
- It is accepting that you can’t implement a single solution to achieve a Zero Trust model. You need multiple technologies, processes and policies in place as well as the acceptance of the culture change.
The model essentially aims to fill in the holes in which traditional security methods don’t cover. A few years back, the perimeter model was the preferred choice. The idea that all the threats sit outside of your network, so simply build a wall to keep them out. The problem with this design is that it doesn’t account for insider threats and you blindly start to trust everything that sits inside of the network.
There isn’t anything wrong with the model at all, but it was designed when the internet wasn’t as vast as it is today, and malicious code back then was very static. Threats nowadays have become more advanced and have the capability to subvert several security systems. Just think of recent threats such as the ransomware Wannacry.
Wannacry was successful in spreading through the network because it used the Eternal Blue exploit: https://ctrlaltdel.blog/2019/06/06/metasploit-eternalblue-exploit/
Using it’s worm capabilities and the SMB vulnerability, Wannacry managed to spread from client to client, server to server. This worm was spreading through networks due to a lack of patching and open firewall rules inside of the network.
With all this going on and malicious parties getting smarter and smarter, what can you do?
Replicating what Google did will most likely be a no go for most. Transforming your entire infrastructure and network would take a huge amount of resource, time and effort, let alone the change in culture. There is also no fancy appliance that you can buy to implement this model quickly. Instead you must focus on transforming and tweaking your current model and thought process.
The thought process and culture change are important as without them, the model falls apart. Your users, especially IT will need to understand why you are doing this. This is because they are the ones working on your network day to day. If your IT staff, start to have the mindset of Zero Trust, they will start to incorporate it into their work/designs and any future solutions.
This may still take time and money but may benefit you massively in the long run. Not doing it however may cost you.
According to the 2018 Cost of Data Breach Study, the average cost of a data breach is $3.86 million (around £2.95 million), with an average cost per lost or stolen record of $148 (Annabelle Graham/IT Governance 2018).
Below are a few ideas and designs in which you can follow to start implementing solutions around the Zero Trust model. They are mainly around having the ability to issue trust as this is the foundation of the model.
Saying that you don’t trust internal traffic, and that you are going to place firewalls everywhere may seem like a good idea, but it isn’t. Overtime, you will have to accommodate user and application traffic so eventually, they will be letting internal traffic pass unchallenged. Sure, you can have IPS scanning everything, but do you really want to increase admin time and costs whilst affecting the users experience? Instead, isolate, segment and start to challenge your own network, users and devices more. Just because they are yours doesn’t make them safe.
Trusting your users
Something they know:
Passwords and security questions
Something they have:
MFA, 2FA or OTP token. Remember that SMS is less secure as it’s exposed during transit. It can also be intercepted or social engineered.
Something they are:
Biometrics; Fingerprint or retina.
As you know, most of us access our systems using either SSO or the traditional method of username and password. A while back this was enough however times have changed. We need to start asking ourselves the question of “How do we know it’s really them?”. Credentials can be leaked, and devices stolen, so how can you be sure user 1 is in fact user 1?
You can do this by enforcing additional steps such as 2FA/MFA when your users have to authenticate themselves. To do this, you will most likely have to setup or purchase an idP (Identify service provider). An example of this would be Microsoft Azure. Azure, lets you sync your active directory and password hashes up into the cloud. This can then be used for things like single sign on requests. What it also gives you is a way for third parties to authenticate your users.
In purple you can see the traditional method of the third-party application having LDAP/s access to your domain controller. This is so it can authenticate your users. This requires you to allow the third parties system access to your network and this will be most likely from the internet.
In the Blue shows how a SAML2 request works using your idP. With this in place, you are in control of your identities. There is no need to have them stored on the their end or you having to provision them with network access. Instead they can communicate with your idP and allow it to handle the authentication for them. Once the idP is happy, the application can grant the user access.
Now looping back to the MFA. Your idP should allow you to ask your users for additional authentication steps such as a MFA token. Using Azure as an example, this can be done through conditional access policies. With this in place, we can ask the question “Is this really user 1?”. If this person has entered the password correctly and they have approved/passed the MFA challenge, then we can trust that it is actually user 1.
Trusting Devices
Trusting users and devices go hand in hand. Devices are what your users use to interact with your network. This could be a desktop, tablet, phone or laptop. Each one will need to have some level of trust if it is to sit or interact with the network.
Mobile devices can be easily controlled by an MDM solution. This will allow you to set security policies as well as keep an inventory. This will help keep those devices secure whilst still allowing the user to move freely. Most people simply accept that mobile devices don’t need an antivirus solution or any hard restraints as they are just phones right? Wrong. Although mobile devices such as the iPhone are designed with security and privacy in mind, they still have weaknesses; humans. Humans are vulnerable to social engineering and Phishing attacks and therefore can be exploited. Not to forget that we can also “misplace” these devices or be a victim of theft. Because these devices have access to your company emails and data, you might want to add your own security layer on top. This can be the form of a pin complexity rule that stops users setting it to 1234. This is important as even if they have their fingerprint setup, there will still be a pin set on the device. A hacker might not be able to crack the biometrics but if the back method is a PIN set to 0000, they would just focus on this.
MDMs also give you a way of wiping data should the device be stolen. In terms of trust, some of the latest MDM solutions help integrate with O365. With this you can start setting trust requirements before they can access their emails. This could be a simply rule of, you must have the MDM solution installed before you can access your emails or that you must be on a certain OS version. Having this will allow you to issue trust to your mobile devices.
Having the ability to trust laptops is crucial. These devices are portable and will be constantly accessing the several networks including your own. They are forever changing from the original build due to each user’s requirements. This makes life difficult as not all devices will have the same configuration. Some will have applications installed that other won’t. These applications could be vulnerable to certain exploits and could be the hackers way onto the network. The good news is that there are a lot of options out there and not all of them will break the bank.
At your company you will most likely have a ‘build image’. This build image is basically the companies standard of what a secure laptop looks like. Everything will be up to date and have all its policies applied. It will also have only approved applications installed and be free of unnecessary access. The problem is, the longer the user has their laptop, the further it moves away from this ‘perfectly secure image’. This is unpreventable though as they user must use it in order to do their job.
What you can do however is set a ‘refresh’ schedule to restore some trust. If you are a large organisation this might be harder to do but is still possible. You could set a process where each couple of years, you refresh and re-image your devices. It might be a pain, but it would be worth it as it wipes the slate clean and allows you to trust that device again.
Application management systems can also help keep the trust of the devices. If you only allow applications to come from your management system such as SCCM, you can have a clear inventory of what’s out there. Then if a vulnerability is announced about an application you deploy, you can help track and remediate the threat. This will then in turn help you to trust your devices more as only approved applications can be installed. One thing to note is that if you deploy one of these, you will have to ensure extra security layers are in place. Remember, you need to be able to trust the applications are genuine and that the system hasn’t been compromised. This can be a hard thing to do but having stronger policies enforce on the box should help. A review every couple of months should also be done to check that no malicious parties has compromised the system. If they have, they might be able to distribute malware as this system is trusted.
PKI certificates are another way in order to issue trust. Any device which doesn’t have your PKI certificate present should not be trusted. This can be enforced on your security stack so that devices that don’t have a certificate cannot join the network. Most companies have their own PKI infrastructure already setup and can therefore implement this easily. Automation can be applied and the computer certificates should be enrolled once the system has joined the domain. Again, much like the application management system, you will have to review this often. This is because this is automatically issuing trust to your devices.
AV solutions that have the Host/Device Integrity feature set are another way of automating trust. Much like the build image, you will have a defined set of standards you require your devices to meet. If they don’t, you need a way to remediate or quarantine the risk. MDMs such as intune can handle this but using your antivirus solutions such as Symantec and ESET might be better. The reason being is that the AV solutions often have stronger remediation controls and more flexibility. If the device meets the requirements you can join the network, if not, you cannot access the company network, end of.
Trusting the Network
This is the big one. Remember, the idea of Zero Trust is that you don’t blindly trust your network just because it’s yours. Threats can live on the other side of the firewall and therefore your own internal network should not be trusted. Because you can’t trust your own network, you are screwed right?
Well no. The ideas above are aimed at authenticating and authorizing each system which sits on this untrusted network. Because we can’t trust this network, the best we can do is limited exposure and secure it best we can. In order to do this, we need to be segmenting the network, encrypting the traffic and applying least privilege access.
What this means is that you don’t place all your production servers on one VLAN. This is because they will most likely not pass the firewall when talking to each other which could allow worms to easily spread. Instead, what you can do is start carving the network out and segmenting the risk. The user VLAN should not have free rein on your network. Users should only be able to speak to servers on required application ports. They don’t need an ‘all’ rule or to be directly remoting (RDP/SSH) onto each.
If you want to remotely manage your infrastructure, you should have a jump (bastion) server in place or a PASM which we will talk about later. Using these servers can help restrict the flow of traffic and help mitigate RDP attacks such as BlueKeep.
This could be enforced using group policy. You could push out a Windows Firewall polices that only allows inbound 3389 traffic from your dedicated remote management servers. This is simple enough and could be a quick and easy way of managing this. Then when you expand your remote management systems such as a new PASM, you could just add the source IP into the list. This can also be achieved on your Linux machines if you have a management system in place.
Another point of entry onto your network is your VPN setup. VPN setups are secure method of allow your remote users to join your network and access your internal systems. This prevents the need to publish them onto the internet as your users can simply VPN in. The problem with VPN solutions is that it is based on IP, therefore you will often find yourself lifting the firewall based on the whole subnet. This is because you can’t be sure which IP a user will be given once they connect. What this leaves you with is a problem. Below is a common scenario in which all your remote users inherit another privilege.
Now you may have lowered this risk by requiring several requirements on your VPN connection such as MFA or host/device integrity, but it will still be an issue. Remember, insider threats are a thing and all that hard work could be undone If a user has fell short to a Phishing attack or is simply disgruntled and wants to cause trouble.
You could, carve out a few VLANs and land users onto them based on their role. Below is an example of this:
Below is an example of this. Because the IT users’ needs to remotely manage their DCs, the security team have lifted the firewall from VLAN 2. This VLAN is dedicated to IT users only. No other users require this access, so it is simply not lifted from the other two.
This could be enough to better secure your remote connections. The problem is, these rules will slowly build and how long before VLAN 2 becomes unsecure again. The other issue is auditing. You need strong audit logs from multiple sources. If you don’t have a SIEM or these logs to hand, you will find it very difficult to identify and prove who patient zero or an attacker was during a breach.
This is where Software-Defined Perimeters (SDPs) come in. SDPs aimed to fix the security holes in traditional VPN solutions. SDP providers such as Zscaler ZPA or Peremiter81 incorporate Zero Trust into their products. An example below shows how Zscaler ZPA works.
Notice that technically the users are never on the network. They are also proxied through Zscalers ZPA and only have outbound traffic. This is because the device establishing the internal connections is the ZPA connector and not the device itself. What this gives you is a way to present your internal systems to your users without them ever having to be on the network.
The other focus for SDPs is that all this access is granted to the user and not an IP address. This allows you to provide least privileged access and set targeted rules. You don’t care about, which IP the devices get, you just care about the user accessing them.
If you are curious about deploying SDPs, another thing to focus on is the device posture capabilities. Remember the focus of Zero trust is to have the ability to authorize and authenticate everything as we are no longer issuing trust blindly. Device posture allows you to set a few ground rules before your users can access your systems. Things like, is the Firewall enabled, the disk encrypted, AV up to date and enabled (Handled via registry key) or do they have your PKI certificate installed. You want these devices to conform to your standards before touching your systems.
The last benefit I will mention is having the ability to separate out access and timeout rules. Timeouts allow you to force your users to reauthenticate themselves at certain checkpoints. Now if you user is accessing simple harmless applications, you might want them to only authenticate once. If they suddenly attempting to RDP to a domain controller, you might want to double check it’s them and force them to reauthenticate. This is something that access, and timeout policies can help you achieve.
Trusting Third Parties
Sometimes we have to provide third parties access to our systems. This might be to help troubleshoot an issue or to simply manage and support their product. The two common methods are to provide them access is through a VPN connection or to grant them access through a PASM. The latter is really the preferred solution as this will give you tighter controls and help you restrict access based on user. Most PASM will also have stronger audit level and even session recording in case of a breach.
If you look around the market today, you will notice that most PASM solutions such as Centrify are advertising that their designs are based on Zero Trust. This is because a PASM is handling all your third parties access and is often available 24/7. It is also an entry point into your network as you have to trust the PASM otherwise, it simply can’t function. So, what can you do?
Aim for a PASM that has its own local account management, can broker credentials without having to share them, has strong audit capabilities, has a workflow and has some sort of automation around access control (Most do). All of these will really help you to better secure your outside > In traffic.
The local account management feature is important as it allows them to solely manage the account they use. They shouldn’t require any level of access into your network such as a password reset solution. That means if they are compromised, it can only get you through the door of the PASM and not into your whole network. If it was a Windows AD account for example, it might be granted access by default. This could be access to published web applications or VPN due to it being in ‘domain users’ group. Having a way to enforce 2FA will just add to the security of your design and help to issue trust.
The PASM having the ability to broker credentials is another important one. Often, we share credentials to the third-party vendors and pray they don’t just save them in notepad. Solutions such as Centrify will allow you to attach a user account to remote access and therefore all the user will have to do is open the session and they are in. This means they get the access they require without ever having to know the credentials you are using. Having this will also help you rotate their passwords as they will be stored in one place. This might not be possible in all cases but certainly can be achieved for most.
The automation part is another key part of Zero trust. You need solutions that can automate and issue trust by themselves based on certain situations. You cannot be expected to be monitoring your PASM 24/7, watching each account and verifying it is them. Below is an example of this. If the user is coming from an unusual source the PASM can challenge the user differently.
Hopefully the points I have raised above will help you to incorporate Zero Trust into your designs or to simply get you talking about the model. This was certainly the aim, as it’s good to get people talking. The more the model develops, the stronger it becomes. I will leave you with a few more points in which you need to focus on.
Keeping an inventory of your environment
If you don’t know what you have, how can you secure it and trust it? Answer; you can’t. If you aren’t keeping an eye on your systems, you won’t be able to enforce your policies and secure your devices. Now you might say, CMDB but this is not what I mean. CMDBs often require user input and all it takes is one person to forget and the thing is wrong. What I mean is Inventory tools such as Lansweeper, SCCM, Solarwinds and Spiceworks. Anything that can help you to identify what is sitting on your network.
Audit everything
You might have space issues but when you can, audit everything. Nothing is more important during a breach then logs. Audit trails will help you identify what went on and why. Feeding this all into a SIEM will also help you in the long run as this will create a centralized platform in order to query all logs.
Automate when you can
Security is hard work and keeping your environment secure is a struggle. There are constant changes happening and you will never have the resource to manage it all. This is where automation can help. Having tools in which can adapt, and issue trust based on requirements and situations will help you keep afloat. It might take a lot of work to get it up and running but it will be all worth it in the end.
Review and refresh
Since reading this, things would have most likely changed. Therefore, it is always good to renew and refresh your designs and policies in order to keep up with the modern world. The security measures you implemented at the start of the year, may now be obsolete. Reviewing these on occasion will help you to implement the best solution possible.
And that’s it for now. I just wanted to end with a cool thing I heard from The Defenders trailer which I think really sums up the job we do. I apologies that I don’t know the person’s name.
“To be a hacker you have to be right one time, to be a defender you have to be 100% accurate, 100% of the time or you have lost”
amoran.io 
Leave a Reply