ZTNA: More Than Just an Acronym
In this blog
ZTNA is Zero Trust Network Access, and it is used to categorize technologies that limit access to specific determined use cases. This is built around a default deny strategy and allows you to whitelist rather than blacklist access. This is incredibly important as tools are being developed to grant bad actors a much easier time to cast a wide net and automate attacks on companies that would otherwise be likely to skate by through anonymity.
Discover and prioritize your assets
In this step, you want to understand your users, applications, data and services. You want to have a good understanding of what exists in your environment as well as where it exists. Palo Alto Networks uses a number of options to help with this. Using AppID (Layer7 application classification) and UserID(User mapping of IP addresses), you can get a great overview of who in your network is accessing what. These tools are part of an NGFW and provide immense value.
Questions you want to ask yourself
- Are your users local, remote, or both?
- Where does your data exist?
- Is it local or cloud-hosted?
- How sensitive is the data?
- Is it local or cloud-hosted?
- What regulations does your business need to adhere to?
- Where do your applications reside?
- Do people outside your company need to access them, or are they internal?
- What services interact with your applications and data?
- Do you have them locked down to a single service per use case?
- Are there services that access multiple applications or cross your environment needlessly?
You want to spend time here talking with your different teams about how this is being handled and not how you hope it is done. Often, one team will assume one thing but be completely unaware that it is different until a change has been made. This is a good opportunity to map out the actuals of your business so you can make the right calls as you continue through this process.
Determine interactions
Now that you have found out who and what is living in your environment and how important it is, it is time to figure out how they talk to each other. You want to get a good idea of how the network has evolved and is functioning today. This will be an involved process as this is where you will see how many hands were in the cookie jar to get you to this point—using your security tools either on your firewall or through your SOC. You can follow the logs on how each asset is being accessed. Turn on logging on everything you can to help find the complete picture.
Questions you want to ask
- Who can access your applications?
- Do you have service accounts, and if so, are they set to only one service each, or are they doing double duty?
- Are users from outside your employees accessing sensitive data
- Who should be accessing what?
Design your environment
Now that you know who and what is living in your network, who is supposed to be talking to each application, and who is accessing each application, you want to put up guardrails around this. You want to decide how you are going to regulate this access. You want to consider segmentation, how it will be applied, and how granular you can get. There are a ton of tools around this that can get you to where you want. Palo offers firewalls that can be put in between networks, at the edge of locations, virtual firewalls that can be run in your public or private cloud, and agents on your device. You can use security features from your SAAS applications, agents from SOC tools, and all kinds of solutions to help you make security enforcement. You need to keep in mind that for a tool to work, it has to see the data flow, therefore it needs to sit in line to make any enforcement. Having a firewall on the edge but a switch that moves traffic from network to network means you will be unable to use those policies to limit your interactions. You need to ensure that you have a security enforcement device in between your users, services, applications, and data.
Build your design
You have now designed how it should be for your environment and what tools you will use. This is a huge ask and lift and something that might scare you away from starting. It is important to remember that this is a journey, and you are unlikely to ever be fully finished. Every team is pulled thin in a million different directions and already has a full plate. The enemy of good is perfection; you don't want to find yourself not making needed changes because you are worried about it not being perfect. Taking small steps and moving forward one piece at a time will find you much closer to where you need to be rather than waiting for the perfect time to tackle everything. This is where something like consultants and professional services through either a partner or vendor can help you make the changes you need, but they will need guidance from you and your team to know what steps 1 and 2 are.
You want to build out policies in your firewalls or access tools. You want to make sure you are using users in these policies, not just networks or IPs. You want also to be using layer 7 applications, not port/protocols. You also have the ability to use DeviceID to determine further what devices on your network should be accessing services as well. Building a policy around the accounting team in the users' network can access accounting software in the servers' network is much better than users are able to access servers. Palo allows you to also put security tools right into this policy flow so not only are you limiting access but also running security checks against that allowed access, further decreasing your exposure.
Monitor your environment
After building your policies you want to set up logging; having logging for all of these interactions across your entire environment will allow you to ensure you are seeing what you should be seeing. Putting these logs into a SIEM or other SOC tool will help you organize and see the complete picture of how access is traversing your environment. This also allows you to take advantage of tools like automation and filtering by using something like XSIAM.
Conclusion
Going through these steps will drastically decrease data exposure if a breach does happen to you. By keeping security in mind when you are designing and implementing you will cut down on those late-night calls from your IT teams as well as not have to make changes to systems that are already deployed. Being able to sleep easier knowing that you have decreased the likelihood of a breach, as well as the amount of data that can be grabbed by any one person, is worth all the effort it takes to implement these tools in the first place. While it might feel like a large undertaking, when you look at this as a journey and not a single project, you can work little by little to make it a reality.