Ntiva Live: Cybersecurity for the Rest of Us

What is Zero Trust Network Access (ZTNA)?

Episode Overview: Zero Trust

Join Dr. Jerry Craig for an in-depth look at Zero Trust Network Access (ZTNA). Learn how ZTNA works, see some real-world use cases, and hear some things to consider when applying Zero Trust to your organization.

Sign Up Today

Complete the form to register for the "Cybersecurity for the Rest of Us" series. You’ll get an email reminder before each livestream, plus an email with a link to the recording in case you miss any of the live events.

Zero Trust: Episode Transcript

Okay, go ahead and get started now. Thank you for everyone who's in attendance today, or anyone who might watch this after the fact. Appreciate you joining, and we're going to discuss Zero Trust.

Quick introduction for those of you that may be your first time on here. My background was an active duty Marine. Another 10 years as a DoD contractor. Six years in healthcare with CMS. I've supported a lot of defense customers as well as healthcare customers and done everything from project management engineering up through the security stack so try to be as well rounded to give you perspectives as they relate to cybersecurity, but how they also tie into our infrastructure.


Zero Trust Network Access

Today's agenda. We're really going to be talking about what is Zero Trust Network Access? No particular product or vendor, but just the concept that all vendors in this space are using. How does the Zero Trust Network Access work? Some use cases, some considerations if you're thinking about going this route, as well as whether or not it's right for your organization. Just like before, because I'm sharing my screen, I can't see any questions that you guys might be putting into the chat, but as soon as I get through the short slide deck, I will stop sharing and then go to the Q and A, so feel free to type in your questions at any time and then we'll hit them at the end, time permitting.


What is Zero Trust Network Access

What is Zero Trust Network Access? I want to split this up into two ways of looking at it. One is the technical definition that NIS and the Centers for Excellence put out, as well as some of the publications that are out there that you can download from the internet. Then really, what does it mean in layman's terms for all of us? I won't read that large block to you, but really it's saying in that first white section there, that it's a concept for workflow planning and access policies. It's going to cover anything virtual or physical so whether you're in a virtual data center, you've got a physical data center, you have an office setup, it doesn't matter. Then you're going to have operational policies that are in place for this architectural plan and that's really what this is, is an architectural plan.


What Does Zero Trust Mean?

But what does it really mean? What we're saying is never trust people or devices, always verify, and don't grant the user or the host access to your network. If you look at it from your corporate environment perspective, if I've got a user who's in this case an employee, maybe they're out at Starbucks and they're using their tablet or phone. Why would we want that individual to connect to a free wifi set up, connect to our network, have access to our hosts, our servers, our data, have the ability to ex filtrate that data, et cetera. In this model, we're really looking at how do I remove that kind of trust? How do I remove you from the network, but still grant you the ability to do your job and access all of the resources that you as an individual employee need?


How Does Zero Trust Work?

How does it work? At the core, there's basically four principles here. I've tried to go out and pull these from some major vendors so that no matter if you go to your own research or you Google it, you're going to see similar content because the major players in the space do agree on a lot of the content.

First and foremost, this is application isolation from network access. If you consider, when you sit in an office and you're connected to your internal LAN or if you VPN into your environment, you are on the network. You can see everything, you can go everywhere. Really permissions are set on the host to decide, can I access this? Once you move into zero trust, you are isolating these applications from network access so that the network is no longer accessible. In this case, it's not even visible. If I were to go do a network discovery today on my network, even my home network for example, I might find printers, other computers, other devices. When I get into a Zero Trust model, I won't see any of those, even if they are on the network, because my access and my visibility is locked down to what I should have access to.

One of the benefits for this is if you're trying to protect against an outside attacker, if they can't see your network, they don't know where they can move. They don't know what exists. They don't know what to go after. One of the things that they always do is reconnaissance to find out the types of posts, the types of devices that you have, operating systems you run because if they can enumerate that from you, they can determine what are your weaknesses or your likely weaknesses, and then target those. By removing all this visibility, they see nothing except what they're supposed to see as that user. If they've hacked or compromised an individual, they're only going to see what that individual had access to.

This also makes compromise hosts less or no concern. I hate saying they're no longer concern, although that's the consensus for this model, but if the host itself is compromised, the host is not joining into the network so they don't have access to the data to move around the network, et cetera. Now as we work from a remote environment and we talk about most employees being remote and working from home, even if they have to use their own device in a Zero Trust model, you can be less concerned about the security of their device. Obviously we want to be concerned because every day attackers find new ways of attacking us, but at least if their antivirus isn't up to date or they haven't taken security measures you take in a corporate environment, they're not on your network and making you vulnerable.

It's an outbound only connection model, so you are not getting in, you're making a request and the connections are being made outward. IP addressing is hidden so folks don't know your subnet scheme. They don't know how you've labeled things, how you've IPD things. They can't do scans against the entire subnet, et cetera. There's application segmentation, where it's one to one access. Again this is where I'm saying, you get access to a particular host or a particular application that you need, not the entire network.

It's this application centric approach versus the network centric approach. We want users to connect to applications and not a network, which in turn, turns your internet into the network. So it's, how do I get to whatever I need? And I can get to whatever that is, regardless of where it's located. I may have, if I'm a global company, servers and applications in different time zones and different countries, continents, et cetera, but me as the end user, I can get access to the services that I need wherever they're located and I only have access to that service. If I've got networks and offices in multiple locations, I'm not getting access to that entire network. So from a security stand point, this is a major leap in reducing the amount of potential harm that can be done to an organization.


Zero Trust Network Access (ZTNA) Common Use Cases

Some of the most common use cases, I put four up here. You could probably make an argument that there's many more. These probably make up 90 plus percent of all the reasons why any organization would even consider going to a Zero Trust model. The first and most prevalent would be a replacement or alternative to VPN. Just as I said before, a VPN grants you access to your entire corporate network. You want to get rid of that. Why? Because, maybe going through VPN is slow. Maybe the applications don't respond very quickly. It's costly to set up this VPN model and the bandwidth that's required, the appliances that are required.

It's also easier to secure the appliances, devices, the applications, et cetera, by getting out of VPN. It reduces that security administration component, which does two things. One, you don't necessarily need a skillset in your personnel to manage VPN. By having fewer things to do or less timely requirements, you can cut down on the cost for your personnel. Makes it a lot easier obviously for you to transition folks from one technology to another and not have to go out and find new employees or personnel to manage the solutions. Securing cloud multi-cloud access. This again prevents the need from connecting to multiple clouds or granting VPN access into a cloud. This is where I was stating a couple minutes ago about how you can go anywhere in the world, access the resources that you need, but again, you're not in that cloud environment. You're not connecting from one and cloud to another so you're cutting down the amount of traffic and access in visibility.

The third is to reduce third party vendor and contractor risk. You'll see this a lot coming up in the DoD side as a big concern. I think it starts in DoD and then propagates out throughout the federal government and then into the private sector. But now that we have third party vendors, we've got contractors and subcontractors that are accessing our data, providing services to us, maybe from a supply chain perspective, manufacturing perspective. If we can keep them off of our network, but still allow them to access the organizational resources that they need, we're more secure.

Good example there might be if I'm producing a product and I've got to work through multiple vendors to get the raw materials that are needed. I can still place quotes and orders and things like that, and fulfill all of these orders and grant them access to my service board, to my inventory, et cetera, but I'm not giving them access to my network. This becomes really important when you talk about the fact that there's a lot of times high turnover with these third party organizations. You've got people leaving that you don't necessarily even know they left. You have no idea what's going on with their credentials, their devices, et cetera. If we can limit that, then to some extent, we can almost say, we don't care what they do. That's on them and their security posture.

It also accelerates mergers and acquisitions processes. One of the big delays when you go through mergers and acquisitions is you have two different organizations who have their own processes, procedures, and technologies, and all of a sudden, we're going to slam them together and say, how do we play nicely moving forward? There's delays in getting the technology set up and working properly. There's also a lot of times a struggle as to who should be deciding what those technologies are. If we have a simple model like Zero Trust, where everybody is on Zero Trust, and it doesn't matter what they do, we eliminate virtually all of these delays. We just grant people the access they need. Your time is really spent just making sure you set up their access appropriately.

Some of the considerations for Zero Trust, and I call these potential roadblocks, because before you go to deploy something like this, or even quote out a product like this, you're probably going to want to start going through these questions and asking yourself one, how are we going to address it? Because when you go to get a quote, a vendor's going to start asking questions no matter who that is. They're going to need to learn about your environment, your processes, your procedures, what your end goal, before they can adequately scope the project. Choose the right product with the right feature sets and then quote it.

If you don't know these things and if you don't have these policies and procedures in place, and you don't know the questions to ask, it could delay it, it could become more costly, something could be overlooked. You may engage in the project and then find out that it was supposed to wrap up in six months but now it's turned into a year, the quote doubled due to of products that were needed, et cetera. A lot of this happens when you're dealing with legacy applications. Some of the questions here I would be asking would be can my own devices, the BYOD aspect be managed? Some products can be applied to more end user devices than others so do you intend to include things like cell phones, tablets, et cetera. Will the endpoints require agent installations? In some cases, that's not a problem if you have to deploy an agent. In others, it could be very problematic. Will the agents be communicating back to a cloud offering and what goes into that? That's the second from last bullet there.

Do you manage non-company furnished equipment? Obviously we don't manage it, but how do we manage that? That really becomes a question you need to ask, because again, if you're going to allow folks to use non-company furnished equipment, ideally there should be some security measures in place. It could be as simple as policy within your organization that you can hold folks accountable for if they're found to have violated it, or there might be software. You may want to say to your employees, I'll allow you to use your device but I'm going to install this agent on your machine because we need to track X, Y, and Z. If they're willing to do it and that gives you a reasonable expectation for security and their posture, fine. If they don't want to do that, then you might be looking at do I have to pay for company furnished equipment? Now, in my opinion, company furnished equipment is always the best way to do it because obviously you can lock it down better, you can control it, manage it, push out policy, clean up things, install agents on the endpoints, et cetera. But for some organizations, that may not be financially feasible coming out of the gate until they're larger.

Does the product support all of your legacy applications? If you don't know what your applications are, you probably don't want to go engage in a quote. How do you know it's going to work? How do you know what will break and what won't break? There's going to be a certain amount of user testing that takes place throughout a project so that's not something you can answer 100% before you start, but if you at least know which major applications need to be supported, the vendor can tell you whether they have a solution for it. They can tell you if it's in a development phase, if it's a request they've put in but their organization hasn't developed it yet, et cetera.

Then do they offer on-prem or cloud only solutions? Depending on the organization that you work for, the customer base that you have, some may require on-prem. They may not want their data going out into a SaaS environment. Even if the vendor comes back and says we're only storing X, Y, and Z logs. A lot of customers, especially in the federal government, just won't allow that. If they have an on-prem offering, but you're in the cloud, do they have a cloud offering? Vice versa. It's really about matching the vendor and their product suite to your environment and your organization. You obviously want to know if you're planning to move to the cloud over the next two years, because if you implement the solution, you want to make sure they have a cloud offering available so that you can forecast for the future and migrate.

How well does it work? There are some products across any technology where the vendor has been always in an on-prem environment. Maybe they've just recently moved to the cloud and the product offering is not the same in the cloud, as it is on-prem, or it lacks certain feature sets. These are all things that you want to talk about, and you want to be open with the vendors in advance of taking on any type of project like this.

What authentication standards are included? What do they offer you? What are you using? Does this match up with what your organization's doing? Is it going to require you to change your processes? Will you have to make additional procurements? From a budgeting perspective, you want to know what the product costs, but you also want to know what impact it's going to have in your environment. Will you incur additional cost by changing platforms? Will you incur cost by spinning up solutions in say your cloud offering to host their products? None of that is going to be quoted as part of the vendors quote. It's going to be simply the service or the technology that they're providing. If you get with a good vendor, obviously the vendor's going to ask these types of questions, maybe not all of them, but start the ball rolling. You ask questions, and they're going to put together data sheets to say, if you're going to deploy our solution, here's what's going to be expected in your environment. You can get that in advance and you can go out and price that and see is this feasible? Does it work? Can I afford it, et cetera, because that is an additional cost.

The big one here, the last slide is really, is Zero Trust right for your organization? I try to put up as many common questions as I'm used to seeing. There's many more, but I think this is a good starting point that everybody should be asking because you really need to know, is it right for my organization? This is not a technology question. This is more of a business question. I think from a technology standpoint, anything that secures our environment and increases our security posture while reducing risk is good for any organization. However, the hurdles to sometimes overcome may not be, and this is where the business comes in.

Going through this list, do you have the talent or skillsets implement and manage the solution? You may pay for a professional service engagement with the vendor when it's being implemented, but once that's over, who's managing it? Who's managing the connections? Who's managing the access? Who decides who's going to grant what access, and then who actually carries that out? How is a reconciliation done? How are we auditing? How are we making sure over time as people change roles in the organization, the organization grows. People come and go, that the right access is still being granted?

What's appropriate today may not be appropriate two years from now. These skill sets, especially when technologies are newer, are more difficult to find. There are fewer people who have worked in organizations with the technologies. There's fewer people who have implemented it. That's something that you're going to have to go through when you're interviewing potential candidates for positions is really drilling down and honing in on their experience. Did they sit in an environment where it was already deployed when they got there and they did basic day to day administration, or were they there when the product was bought and they helped implement it? Depending on where you are in your path or your roadmap, that's going to be very important when you go to hire an employee. The last thing you would want to do is hire the employee and they say "I only supported this once everything was completely done and I had the advantage of a professional services engagement to link back to, or we paid for a support model that you're not paying for here that allowed me to get an engineer on the phone whenever I needed it."

Are you ready to perform intense user testing? This is one of those solutions where you cannot just drop it into an environment, flip a switch, and then expect it to work. There's a lot of testing that's involved. There's a lot of configuration. Ideally, you're wanting to test it from a role perspective. If I have a finance department, maybe I'm going to set up and test with one or two finance folks. If I think I've got it right, I can roll it out to the entire finance team. Same thing from a system administration or an engineer perspective or a security team perspective, but you're not going to get away from the training and the testing.

I don't think I put training on there, but that's something that's going to follow after that, which is once you test, this is a new technology users, users may be able to work, but won't know how to necessarily work. They're going to have questions, particularly if they had a lot of access prior to zero trust, and now their access is restricted. If they were able to do everything on the network yesterday and today they can see a host, they're going to come to you with questions. They're going to come with complaints. You can expect to see a lot of, I can't do my job because, and you're going to have to drill down into, well, what is it you can't do? Can you do your job and you just aren't happy with the new model, or are we really preventing you from getting work done?

That kind of rolls into the third bullet, which is, is your culture amenable to change? There's going to be a lot of change. Will everyone deal with that? How will they adapt? Will senior leadership back that once the complaints potentially start rolling in? How much of this communication you do in advance, how much planning and testing you do will have a big effect on whether it's a positive or negative outcome for your deployment, but you still have to see how your culture of your organization deals with change in particular.

Do you have the policies and procedures in place ahead of time? If a user, for example, is working a Zero Trust model, and you have the ability to send all of their internet traffic through your environment where your security tools are, or you have the option to split it to say, you can work in our environment to do your job, but then if you want to go to YouTube or social media or whatever the case is, you go out through your own internet provider and it doesn't traverse our network. These are decisions that have to be made. These are corporate business decisions with the help of security, providing guidance and recommendations, but you probably need to think about all of these and create these policies or the shells of these policies in advance because as you go to buy the products and as you go to set them up and implement them, these questions are going to come up and you need to know what the impact will be on your user base.

If you allow folks to split their traffic, do you create the potential where someone could ex filtrate data from your corporate environment to the host because they're using the connection to the corporation and then have a second connection set up where it goes from their host out to the internet to some other device? So now if their device was compromised, the potential exists that two communication paths exist at the same time and the data could be ex filtrated. Or do you say, for security purposes, when you're connected to corporate, everything else stops working because everything is being funneled through our corporate environment? That may be a more secure way of doing it and the preferred way, but your business may come back and say, well, if you do that, it breaks X, Y, and Z. It would be nice to know that it's going to break something prior to you implementing this solution and specifically the way you've implemented the solution.

That kind of touches on the next one. What impact have on exfil trading data? I think I've covered that one. How long will this implementation configuration and testing take? I think this is very similar to building a house and someone tells you it's going to be done in a certain amount of time or renovating a house. As you watch, HGTV and other shows, you find that when someone estimates two months, it turns out to be four or five, six months. They estimate a 40,000 budget and it turns out to be a 60,000 budget. This is something you're going to have to look at because while you're going to hire professional services in most cases, and they'll come in and give you a statement at work, they're basing it on if everything works great. Everyone's network is different. Everyone has business challenges and it rarely if ever goes as planned. You need to consider that. Do you have deadlines? Do you have audits? Can you get this stuff done before those things take place? What's your budget look like for the year? Is it going to spill over into another year, et cetera.

What is the cost versus your current solution? In some cases, the cost of this new product may be comparable, but with all the training, the user testing, the professional services engagements, et cetera, the total bill for this new solution could be astronomical compared to your current solution. Again, this is where it becomes a business decision. How do you balance security work versus the cost? Do I double my budget to get X percentage better security? One of the things that'll normally be asked is how much better is this? How much more secure are we or will we be? That is a very difficult, if not sometimes impossible thing to quantify. Don't just look at it as, my current solution costs me $1,000,000 a year, and this solution is 1,000,001. It's basically the same, no problem, and then forget that you had $1,000,000 in other costs that were upfront during implementation.

On that note, I appreciate everyone's time. Thank you for joining.

About the Ntiva Cybersecurity for the Rest of Us Livestream

Ntiva’s Dr. Jerry Craig hosts the Cybersecurity for the Rest of Us livestream every other Thursday from 12:00 to 12:30pm ET. These live events, presented by the Ntiva team of cybersecurity experts, are sharply focused, easily digestible, and cover topics surrounding cyber security in today's modern workplace. We take questions from the audience and share what's working for us and others in the industry.