Transcript
by only allowing verified clients access to resources which they are authorized to use. In doing so, not only do we limit the attack vectors to the device, but in the event it becomes compromised, we can greatly reduce the blast radius. It all sounds great, but you're no stranger to the game. Challenges lay ahead. Hi, welcome to Forefront. I'm Nixon Kada, an engineer at Forescout. In this episode, we'll be going over five steps to aid in the planning, design, and deployment of your microsegmentation policies for the campus. Let's do it. We start with Discover and Identify, where we essentially want to account for all the players on the field. In order to design policies which provide only necessary communication based on role, we need to understand what devices, users, and applications are actually out there. Without that information, we can't possibly have the confidence needed to design the correct policies. First up are devices, since they are the direct touchpoint to the network. Just as users, devices need access to resources, so it's important that we understand their identity in order to make informed decisions about what access they need. A key part of a device's identity is its function or role, whether it be a mobile phone, workstation, IP camera, or any one of the growing number of network-connected devices out there. Next up is the operating system, which can not only help shed light on the role of a device, but also help us better understand the requirements. For example, a Windows client will access a different patch management server than your macOS clients. Lastly, devices from different vendors, especially IoT and OT devices, will have different requirements that you need to consider. Let's move on to the posture of a device. This can act as a condition for access to resources, if healthy. If not, it can lead to a response which restricts or removes that access entirely. There are three key factors in deciding a device's security posture. One is the method it used to authorize to the network. This can be either 802.1X, device enrollment and management solutions, device fingerprinting, or even a simple MAC address bypass list. Next is whether or not it adheres to your compliance policies. Are your security agents installed? Are all your patches applied? Lastly is the risk the device poses to the organization. This can be from exposed vulnerabilities, malicious behavior, or threat detections. So whereas identity is the mostly static information that helps decide what resources a device should access, posture is the dynamic information which decides if that access should even be granted at all. Now gathering this information is no easy task. Identity can usually be helped by having discovery tools or network access control solutions. Posture usually falls to a range of security tools. Whatever the case, all this information needs to flow up to your policy decision point, where it can be used to help decide access. Next up are users, where we're going to look to apply the same concepts of least privilege access. To do that, there's some information we'll need to gather in order to make those decisions. We'll begin with user entitlements. These will help us build the base rule sets needed. Some common items which fall under entitlement are business units. These can be thought of as a high-level grouping for common services that all members need. For example, corporate employees having access to the HR system or IT support to the ticketing system. Job function will help decide based on the role of the user. For example, the physical security team having access to the surveillance system. And for sensitive resources, the clearance level of the user might also factor in. We might also want to consider some of the more dynamic contexts around the user, such as which authentication method is being used, if any, which lets us know how trustworthy the session is. And just like devices, users can have a risk score associated with them as well. This might reflect on user behavior or any detected threat events. So how do we get this information? Well, identity access management brokers or authenticated session details are pretty good at providing the user account name. Now to associate a user to a device, we might need to have manageability of that device in order to query and find out who the logged in user is. Regardless of the method, once we have that user account name, we usually have to query some sort of database, such as Active Directory or the personnel system, in order to get the entitlement information. The final piece for us to discover are applications or workloads. Now since we're focused on micro segmentation in the campus, we're going to keep it simple and treat applications as resources that clients will access. Given that, there's just three simple things we'll need to know. One is which host the apps are running on. Two is which ports they're being accessed over. And three are the different protocols in use. Now you can make some pretty reliable guesses as to which applications are out there if you have visibility of the traffic, especially at the application layer. Additionally, if you know the host's identity, you might be able to find out which services are running on it. Next up is mapping the data flows, where we want to evaluate what is currently in use so we may better understand what the potential access requirements might be. This data often comes from monitoring network traffic, whether that be the raw packets seen through a switch or analyzing flow data. It's important to not only just capture the north-south traffic, but also the lateral east-west movement as well. Additionally, your capture period should be long enough to account for monthly or quarterly scheduled workloads. Now once you have those communication flows, they should be enriched by mapping the data from the previous section of Discover and Identify. So what does this look like? Well, we start with our basic record of a source, destination, and a port, which doesn't really tell us much. However, once we overlay the data, we see that the source is actually a Windows PC logged in by Bob Hodges, and he's from accounting. And the destination he's trying to reach is actually a database server over SSH, which leads us to the question, does Bob from accounting really need SSH access to the database server? Being able to consolidate this information into a single record is immensely helpful in the investigative process. Having insight into which devices and users are accessing which services and where will not only help with building the correct policies, but will help audit their effectiveness down the road. Time to get started on what we came here to do, policy design. We did our homework, so now let's put it all together and figure out what are the requirements each device and user needs to do their job, and only that. So we'll be assuming that these rules will go against the backdrop of an implicit deny-all. So how do we figure out our policy requirements? We'll be consulting all the information we gathered so far, as well as doing some investigative work. We'll be aided by those enriched data flows, which gives us a current baseline. Now again, that doesn't mean that traffic is absolutely required, but it does mean that it should be considered. We then have documentation, which can specifically state network service requirements for things like IoT and OT devices. Although it can be time intensive, surveying your teams for a list of resources they use can help cover your grounds. Lastly, review existing ACL and firewall rules in your environment. They might certainly need amendments, but they'll help make sure that important production workflows don't fall through the cracks. Now that we have our requirements, we just need to figure out where are the enforcement points in our network. This, of course, will depend greatly on which technologies are in play, as well as how the traffic traverses through your network. Some common points might be client firewalls, the edge, distribution, or core layers, or the many firewalls dispersed throughout your network. In truth, there's a lot to unpack, and every environment will be unique, but there are some common things we can consider. Software-based controls can work well on managed IT clients. However, you might want to consider how to apply policies to IoT and OT devices. Enforcement closest to the edge is ideal. However, can your switches handle the TCAM loads, or do they have other modern blocking capabilities? Are your enforcement points device context aware so that they know which policies to apply? If not, is there some other system which can inform them? Lastly, a layering strategy might be needed, which has different policy enforcement points for lateral, cross-zone, or outbound traffic. Now that we have our policy proposals, we do the responsible thing and test them, not only to validate their effectiveness, but also make sure they don't block important production workflows. You can do this by having your policy enforcement points set to log-only mode, wherever they may be, whether it's at the switch level, client-side firewall, or at the core distribution layers. Aggregate all those logs and make sure that nothing is being blocked which shouldn't. If you have the resources, you can also consider a test environment. Here, you might be mirroring your production traffic from your firewalls or from your core switches to a clone device, which has your policy proposals enabled. Keep in mind, having a holistic view of the entire network throughout this process is a lot more effective than only looking at specific enforcement points. During this simulation phase, it might be time to start thinking about the more not-so-fun stuff, like the more operational aspects of your deployment. Things like having rollback processes just in case something critical is being blocked, or trying to figure out how this new design fits into your change control procedures. Once you're satisfied with the effect your policies have in simulated mode, it's time to gradually deploy them into production. IoT devices are great candidates to start with, as their requirements are generally pretty straightforward. They can really help your teams build confidence and get into their groove. In any event, you've probably been down this road before. Take the gradual approach and any problems will be more manageable. It's a good idea that once your policies are rolled out, to review your denied traffic logs every now and then. Just because a problem isn't being brought to your attention, doesn't mean it isn't lurking in the background. Requirements will likely to have been missed, and that's okay. Have a good process around reviewing and allowing for exceptions, and your policies will remain tidy and effective in the long term. And that wraps up our five steps to help guide you in designing your zero-trust micro-segmentation policies for the campus. We began with discovering and identifying all devices, users, and applications to be accounted for. Also, this allows us to dynamically apply policies later on. We then mapped the data flows with that enriched context, so that we can better understand the access requirements. Next, we got into policy design, where we took all that information into consideration, as well as planning for our policy enforcement points. Next, we tested and simulated our policy deployment, to give us the confidence to avoid any unforeseen impacts to production. And in the end, we gradually deployed all our rules and monitored them for effectiveness. We hope you found this guide useful, and wish you success in the road ahead. Thank you. If you're interested in seeing how Forescout can help with these steps, check out the link in the comment below.
