Tag: zero trust framework

Zero Trust in the Campus

* * * Posted on by Chris Crotteau * * *

Zero Trust in the Campus

Controlling Network Access

Securing Infrastructure Access

When looking at what the major risks are to the security and functionality of IT infrastructure, near the top is access to that infrastructure.  Being able to ensure that only authorized devices and users can connect to the network is one of the most effective ways of protecting your infrastructure and data.  Users who pick up malware from outside the corporate network can easily bring it in via their machines, or bad actors can attempt to place a device within the network to easily launch attacks on the infrastructure from the inside.  And it’s not just a security thing – one of the most aggravating components of ‘shadow IT’ is the random devices users bring in and attach to the network.  Printers are probably the most common, but other things like networked music players are a notable hassle.  And the worst of all is users bringing in network devices like unmanaged switches that can actually cause an outage.  Situations like this are what network access control (NAC) systems are for.

So what is a NAC system?

In a nutshell, the primary job of a NAC system is to authenticate users and devices so that they can use the organization’s network and then log those accesses.  More advanced NAC systems can also provide conditional access for devices – a device joining the network can be profiled and screened for things like an up to date OS, the presence of antimalware software, or even force an antimalware scan prior to gaining full access to the network.  The most complex NAC deployments will add network segmentation to all of the above – users are dynamically assigned to a VLAN or SSID, or have a dynamic ACL applied based on their role in the organization.

How do NAC systems function?

NAC systems, regardless of vendor, all rely on the same core technologies to function, which are RADIUS and 802.1x.  This is meant more as a short overview, not a deep dive into the intricacies of RADIUS or 802.1x.  We’ll also avoid looking at vendor-specific capabilities, such as Cisco’s Scalable Group Tags (SGTs), as those don’t see much use and rely on a single vendor environment.  First is 802.1x, the core technology for allowing or disallowing access to the network. Keep in mind that 802.1x is a function of the access device (switch port or wireless AP), not the NAC software – it’s common to see a NAC system from one vendor and access switching from another vendor in the same environment. 

NOTE: All modern OSes (Windows, Linux, MacOS) have 802.1x client (aka supplicant) functionality built in, so no 3rd party software is necessary on the client side.

Besides standard client OSes, 802.1x client functionality also exists in a number of specialty devices, including network infrastructure like routers, switches, and APs.  We’ll address that use case later.  The other thing to keep in mind about 802.1x is that it’s a layer 2 protocol – authentication information is sent even before a device can get an IP address.  That way, it’s simply not possible for unauthenticated devices to obtain an IP address in a well-designed NAC deployment. 

What if the device in question is a printer, IP phone, or other device without 802.1x awareness? 

There is a feature available called MAC Authentication Bypass (MAB) that forgoes the 802.1x process and instead, uses the device’s MAC address (learned from a single frame) as the credential to authenticate against.  Keep in mind that MAB is not very secure – spoofing MAC addresses is very easy to do, especially with wireless devices.  MAB shouldn’t be used except as a last resort, and additional security, such as network segmentation via a firewall, should always be considered when dealing with devices that must use MAB.

Further explaining the authentication process

The other part of the authentication process is the access device communicating with the NAC server.  This back-end communication is done using RADIUS.  RADIUS has a very long history as an AAA protocol, dating back to the days of dial-up Internet, and has stuck around because its capabilities are broadly useful for all manner of network access control regardless of media type.  Once an access device has received 802.1x information, it will translate that to a RADIUS request and send it on to the NAC server.  From there, the NAC server will consult its internal user and machine database or an external user database (e.g. Windows Active Directory) to determine if the device should be granted access to the network.  In the case of MAB, that will be a pre-populated list of MAC addresses that the NAC server will refer to.  RADIUS doesn’t just handle authentication, either.  RADIUS can be used to push a dynamic ACL based on user role or device type, or dynamically assign a port to a specific VLAN based on user role or device type.  This kind of dynamic segmentation is quite advanced, though, and is definitely not for a NAC beginner.

Now, let’s discuss NAC deployment

Our prior topics have generally been invisible to end users and limited to key points within the enterprise network.  Thus, even with areas that have complex security needs, like machine-to-machine security in the datacenter, there is minimal worry about messing with the end user experience or causing high-visibility problems.  NAC changes that dramatically – now we’re directly impacting end user experience if things go wrong.  To be honest, we’ll be directly impacting end user experience when things go right – remember that a NAC system is not just security, but shadow IT control. Expect user complaints when the printer they snuck in no longer works.  It still beats having people sneak in printers, in my opinion.

Deploying NAC is going to be complex

This article is not trying to build a complete guide to NAC deployment.  Rather, I want to discuss general principles and best practices to make sure that your NAC deployment doesn’t cause too much pain.  The first thing to consider is where 802.1x should be enabled.  Best practices for NAC say that any means of network access (switch ports, APs) that aren’t in a secured environment should be enabled for NAC.  That’s why APs and switches come with 802.1x supplicant capabilities – a user-accessible AP or small switch in an office could otherwise be unplugged and an unapproved device can then be attached to the network. You’ll also want to inventory network devices and determine where using MAB will be necessary. Be sure to record those MAC addresses, too.

So what’s next?

The initial deployment is the next step. Build the NAC servers, integrate with any external resources like AD, and start with a small test deployment.  The IT department always makes for a good guinea pig.  This test deployment should start in open mode – network access is always allowed, but all 802.1x and RADIUS exchanges are logged.  Review the logs and address any errors, then move to closed mode, where network access is now conditional on successful authentication.   There will likely be some issues that weren’t caught or only appear in closed mode.  Make note of anything particularly troublesome for when the wider deployment is carried out.

Next, prepare for the general rollout

Since this involves client machines, make sure the helpdesk team is in the loop and is trained in how to deal with the inevitable issues that will surface and work closely with the desktop team to make the needed changes to enable 802.1x (for a Windows shop, traditional GPOs or InTune can be used to do this).  Procedures will also need to be updated – don’t forget that.  It’s way too easy for NAC to turn into an unmanageable mess without good procedures.  Above all, communicate with the users about the process well in advance.  Be sure to have a good answer as it relates to things like printers and other devices brought in by users.  Just cutting them off causes more problems than it solves, no matter how satisfying it may be.  This is, honestly, the hardest part of a NAC deployment and the biggest cause of failures.  Nothing sinks a project faster than agitated users and their managers.  Now is also the time to remediate any potential issues that have been found in the pilot deployment if they appear to be widespread.

You’re done prepping, its time to deploy

Now that the preparatory work has been done, it’s time to move on to the large-scale deployment.  Feel free to split this up further for large deployments or if there are lots of remote sites.  Just like the pilot, start with everything in open mode and log errors or failed authentications.  Remedy those issues as appropriate.  Once the technical issues have been resolved and any ruffled feathers have been un-ruffled, it’s time to move to closed mode.  Once again, communications from IT to the rest of the organization is key.  I can’t state enough how important it is, really.  No matter how much work is done prior to this step, there will be issues.  Address the users with respect and courtesy, and always be flexible.  It’s not uncommon for some devices to just plain refuse to work with 802.1x no matter what, short of a full reimage. 

Some final thoughts

NAC systems are a powerful tool in your journey towards zero trust, but the user impact should always be top of mind.  This is definitely one of those projects where a good services partner can have a big impact – a team that’s done dozens of NAC deployments has seen numerous ways things can go wrong and can streamline the NAC deployment dramatically.

By Chris Crotteau

What is a Zero Trust Philosophy?

* * * Posted on by Chris Crotteau * * *
Zero Trust: Its a philosophy, not a plan

The Mindset

One of the current trends in IT security that gets a lot of press and discussion is the idea of zero trust.  Zero trust, however, is really a philosophy, not a plan of action.  Specifically, zero trust is the philosophy that all IT resources, whether internal or external, should be treated as untrusted or even potentially compromised.  While this philosophy is simple, applying it to a live environment can be anything but simple!  Adopting a zero trust mindset requires a holistic approach to security and good cooperation between all stakeholders in the organization in order to execute on this philosophy.  This even extends beyond the technology infrastructure and onto the employees and even organizational policies themselves. 

It’s important to keep in mind that the threat landscape is always changing – what may have been good practice five years ago may not be so today. This is what drove us at Crossconnect to develop a series of posts laying out how to adopt a zero trust philosophy in your organization.

Getting Started

This series will explore various aspects of technology infrastructure with an eye towards how things are built when done so with a zero trust mindset.  Before we get into those details, it’s always best to take some time to think about the big picture questions – many of the areas of security that we’ll talk about will have options that range from ‘very simple’ to ‘year-long project.’ Being able to figure out where effort needs to be made will go a long way towards creating an effective security infrastructure for your organization. 

Foundations of Zero Trust Philosophy

The first step in planning is to think about the capabilities of your organization and the threats you’re likely to face.  Many threats are industry or organization specific, but there are some that are universal.  First, of course, is ransomware – probably the biggest general threat most organizations will face.  Fraud and theft also rank high in terms of general threats.  Sometimes, the organization’s data itself is the target – there are plenty of groups out there who want confidential information for any number of reasons, even just to leak to the public.  And finally, compromising your organization may be done so that the bad actors can gain access to a 3rd party’s network via yours – think contractors and other service providers.

Next, look at your internal capabilities.  Security is, unfortunately, time-consuming to manage.  As such, it gets hard to manage some solutions with limited staff and budget.  Consider what your organization is capable of managing and monitoring when looking at security products and services – a simple but well-managed system is going to be more effective than a very capable, yet complex and maintenance-intensive system that gets neglected.

Once you have a good understanding of what your threats and capabilities are, then it’s time to build a plan.  The core of a security plan is to look at the applications in use, files/information that needs access, and the infrastructure that they run on, then figure out who/what needs access.  The goal is to limit access for any device, user, or application to only the resources it needs. 

Zero Trust Philosophy Index

This series will explore the areas of security that need to be addressed in order to make your plan a reality and to discuss specific areas of focus on how to apply a zero trust mindset.  

  • Datacenter
  • Route/switch
    • Features that ensure integrity of network operations
  • Wireless
    • Capabilities for detection and mitigation of RF based attacks
  • Endpoint
    • Network Access Control (NAC) – Ensuring that endpoint activity is controlled and that security threats are detected and mitigated before an exploit can occur
  • Network Security
    • Ensuring that all traffic through the network is controlled and monitored for malicious activity
  • Cloud Security
    • Ensuring that user to cloud access is controlled and that cloud resources are appropriately provisioned and accounted for.
  • The Human Factor
    • Ensuring that end users are aware of security issues and responsible for their security choices.