The purpose of this guide is to provide a high level overview of my thoughts on zero trust and not a complete security architecture. It is a work in progress that will be updated.
Zero Trust this Zero Trust that, blah, blah. Everyone says everyone should do it. Even the United States Department of Defense has a 104 page guideline, https://dodcio.defense.gov/Portals/0/Documents/Library/(U)ZT_RA_v2.0(U)_Sep22.pdf.
The National Institute of Standards and Technology has this special publication, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf.
However no one tells you what technology to use or how to configure/deploy it. I’m changing that! This a guide on how it works with configuration guides/links and very few if any acronyms so you can do it yourself!
First here is how Forrester defines Zero Trust: https://www.forrester.com/blogs/the-definition-of-modern-zero-trust/ I’m not going to retype what they wrote. But here are the concepts that are important:
- Deny all traffic and only allow traffic that is required (least privileged).
- Continuous monitoring for threats
- Continuous verification of user access
Just so you don't have to read everything to get the answer, I’m going to give it to you now. Palo Alto firewall configured with:
Why Palo Alto, because they are the only company that I have found that can do it at the deepest level with the least amount of additional hardware.
- They also have a cloud version if you prefer called Prisma. However it requires hundreds of licenses to get started, so not really for a small business or home user.
- You can run a virtual Palo Alto on a hosted service such as Google Cloud and achieve this as well.
You might think I’m crazy because Virtual Private Network is old technology and you should instead buy some new sexy next generation product cloud based phenom that will eat your budget (don't do this). Yes it's been around and it still works, it's not difficult to setup can be used with multi factor authentication, or even utilize passwordless authentication (using the credentials of the windows machine you logged onto and/or certificates), Just dont forget multi factor authentication. The other great thing about the VPN client is that it provides posture validation so you know only authorized systems can connect. Fasten your seat belts and let's get to it.
Architecture:
The Palo Alto must be the center, conceptually and routing wise, of your network. Meaning that all traffic must flow through the firewall so the proper policies can be applied (referring to the three Forrester bullet points above) (in large networks there can/will be many firewalls). I cannot show every scenario due to many different factors in network design, etc., so I’m going to just show how this can be done for a small doctors office, we’ll call him Doctor SKRZ.
Remember that you define the boundary of Zero Trust, being a group of servers or a single laptop.
The Palo Alto:
So the basic firewall config can be found on the Palo Alto Live Community Site.
https://live.paloaltonetworks.com/t5/general-articles/secure-day-one-configuration-not-for-the-faint-of-heart/ta-p/435501, careful with it, you have been warned. It is a strict configuration but has a lot of best practices from both Palo Alto and DISA prebuilt into it. Some features/functions still have to be configured or modified since they cannot be added into a base config.
The Global Protect setup can be found here:
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClfXCAS
Since configs change etc, I’m not going to restate them.
OK what about the rest of the network? There should be a few vlans (virtual local area network video here https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000PMuTCAW) that are required for this small office and all terminate at the Palo Alto. What I mean by terminate is that the Palo Alto holds the gateway so traffic can exit out of the vlan. The Palo Alto can then be used to apply policies to allow only the required traffic.
What are VLAN’s?:
- Side note on vlan numbering. First, do not use vlan 1, it's usually the default vlan and can provide access that was unintended. Also if you have requirements for configurations such as Security Technical Implementation Guides (STIGs), vlan 1 must be disabled. Check vendor documentation on the highest vlan number you can use, yes there are limits. Use the 5’s, 10’s methodology, ie vlan 5, 10, 15 ,etc. Or vlan 10, 20,30, etc. This will be handy in the future if you need a vlan in between them.
- I’m not going to suggest a switch brand because all you need is the ability to vlan and maybe trunking if you're adventurous, even inexpensive switches have this and with phones you might need power over ethernet, etc. Trunks may not be needed depending on the amount of ports the Palo Alto has, even a PA-440, entry level unit, has 8 ports. But trunking will reduce the amount of ports consumed/used and still maintain zero trust. The switches should be in a secured location to limit who has access to them physically. Unused ports should be shutdown and on a vlan that does not route. Same with wall ports, if not in use, dont cross connect them.
- Palo Alto sizing is done by throughput and depends on several factors. For assistance on this contact your sales team or go onto the live community and post a question, https://live.paloaltonetworks.com/ there are lots of super smart and helpful people there.
Since this is a small doctor's office, we’ll use the 10’s methodology. Why, because why not, honestly its just random anyway. So we’ll make the users vlan number 10, servers vlan20, printers vlan30, and Internet of things (Supervisory Control and Data Acquisition. SCADA) and other items etc vlan40. payment system(s) vlan50, Medical equipment vlan60, phones vlan70, and internet side vlan666. Why not a flatter network? Remember that not all of these devices can utilize VPN technology and must have their network traffic be separated. Yes some things can live on the same network, it depends on your resources, access to someone who can make changes to switch ports, etc. The idea is to keep like type equipment together and the firewall to maintain separation and who/what can talk to what equipment..
Choosing subnet addresses:
- I also ‘try’ to make the 3rd octet in the IP address the vlan number, helps with ease of troubleshooting, etc. and the second octet as the building/floor number or something else logical for growth potential i.e. for a small network, 10.<floor/building>.<vlanID>.0/24, so users would be 10.12.10.0/24, 10.12.20.0/24 servers, and so on. This doctor only has one office and is on the second floor, hence the 12 as the second octet and its the only one so no biggie. I use the /24 class ‘c’ so subnetting is easy, 255.255.255.0. For the gateway, we’ll use the ‘.1’, you can use any IP within the subnet but keeping it simple helps keep your sanity and its going to be assigned by a dynamic host configuration protocol, DHCP, server probably, anyway. The internet, ‘public’, IP will be provided by your Internet service provider, you can still use vlan 666 as long as it's not tagged, it's just a vlan number, no other real use.
DHCP notes:
- DHCP lease time, Microsoft default of 8 days is fine. Dont leave it too long or too short, obviously depending on your use case, but it can come back to bite you. The way I look at it is, I basically have 4 days to bring that scope back online before clients start to potentially have issues. The client will request an extension of its lease at 50% of the lease time, so if the lease is 8 days, every 4 days the client (if connected and online the entire time) will request a new lease. The DHCP server will lease it the same IP since its an extension and just bump the expiration out to 8 days.
- I usually leave a ‘reserved’ space at the beginning and end, just in case (lessons learned the hard way, full scopes, dhcp offline, etc.). So 1-10 and 240-254 are not assigned by DHCP.
