Supporting any computing – which we have defined as access to your critical information from anywhere, at any time, on any device – requires organizations to restrict access to specific communities of users/devices, based on organizational policies. In order to do this, you need to integrate with your existing installed base of security and networking technologies, ensuring management leverage and reducing complexity. No easy task, for sure. So let’s discuss how you can implement network access control to play nicely in the larger sandbox.

Authentication

When an endpoint/mobile device joins the network, you can start with either a specific authentication or network-based detection of the device, via passive monitoring of the network traffic or the MAC address of the connecting device. The choice of how strong an authentication comes down to whether building policies based on device and/or location will be granular enough. If you want to take into account who is driving the device into the policies, then you’ll need to know the identity of the user. Although there are techniques to identify users passively, we prefer stronger methods to determine identity; these require integration with an authoritative source for identity information. The integrated directory might be Active Directory, LDAP, or RADIUS. Authentication is either via a persistent agent, a connection portal (provided as part of the NAC solution), or a protocol such as 802.1X.

Keep in mind that identity is a dynamic beast, and users & groups are constantly changing. So it’s not sufficient to provide a one-time dump of the directory. You’ll want to check for user/group moves, adds, and changes, on an ongoing basis.

At authentication time you need to figure out what’s going on with the device, which involves inspecting it to understand its security posture.

Endpoint/Mobile Device Integration

The first decision is how deeply to scrutinize endpoints/mobiles when they connect. Obviously there is a time factor to scanning and checking security posture, which can cause user grumpiness. Though most organizations want to make sure devices are properly configured upon access, many aren’t ready to react to the answers they may get. Do you block access when a device violates policy? Even when the user has a legitimate and business critical need to be on the network? As we discussed briefly in the post on policies, you may want to define policies based on the security controls in place on the endpoints/mobiles.

Compromising your security by providing access to compromised devices makes no sense, so what remediation should happen? Do you patch the device? That requires the ability to integrate with the patch management product. Do you reconfigure the device? Or update the endpoint protection platform? It depends on the nature of the policy violation and which information that user can access, but you want options for how to remediate. And each option requires support from your NAC vendor. You could just ignore the details and block users with devices which don’t comply with policy, but this tends to end with your rainmaker calling the CEO because she can’t get into the ordering system to book that critical deal. Which presumably won’t work out very well for you.

Another consideration is that devices may be compromised after connecting. Detecting a compromised device involves both re-authenticating devices periodically (to ensure a man in the middle hasn’t happened), as well as assessing the security posture of the endpoint/mobile device every so often. Another tactic is to detect compromised devices by their behavior – which requires continuously checking devices for anomalous behavior. Most NAC devices are already monitoring the network anyway to detect new devices, so this anomaly detection capability is frequently available.

Now that you know the posture of the endpoint/mobile, you can determine the appropriate level of access it, enforcing that policy at the network layer via integration with other infrastructure.

Network Integration

There are plenty of ways to enforce network access policies using your switches and firewalls. Let’s take a look at the major techniques:

1. Inline device: Obviously an option for enforcing access policies is to be in the middle of the connection and able to block unauthorized devices as needed. Networking infrastructure players who offer NAC can provide multipurpose boxes that act as inline enforcement points. There isn’t much more to say about it, but this approach has a dramatic impact on network design.
2. CLI: The good old command line is still one of the more popular methods of enforcing access control. This involves the NAC equipment establishing a secure, authenticated session (typically using SSH or SSL) with a switch or firewall and making an appropriate change. That might mean moving a user onto a guest VLAN or blocking their IP from access a protected network. Obviously this requires specific integration between vendors, but given that a handful of vendors control the switch and firewall markets, this isn’t too daunting. That being said, there may be delays in compatibility when network/security gear is upgraded, so make sure to check for NAC support before any upgrades.
3. 802.1X: The standard 802.1X protocol is typically used for authentication on connect (as described above), for which it is well suited. But the protocol also includes an option to send enforcement policies to endpoints, which gets far more involved. Even though 802.1X is a mature standard, interoperability can still be problematic in heterogeneous network/security environments. Individual vendors have generally sorted interoperability between their own NAC and general networking products, but it’s never trivial to make .1X work at enterprise scale.
4. SNMP: Another option for integration with switches is using SNMP to send commands to the networking gear. The advantages of SNMP clearly center around ubiquity of support, but security is a serious concern (especially with early versions of the protocol), so ensure you pay attention to device authentication and session security.

* All of the above

As usual, there is plenty of religion about which integration technique is best, which continues to amuse us. Our stance hasn’t changed: diversity in integration techniques is better than no diversity. We also prefer multiple enforcement tactics – multiple, layered controls provide additional hurdles for attackers. That means you want the ability to enforce access policies at the switch, perhaps with an inline device front-ending your most sensitive information.

You can also leverage some direct endpoint/device-based methods to mess with a user’s IP stack, including measures such as TCP resets, DHCP tampering, and ARP poisoning to spike sessions or redirect users to an authentication portal. As discussed in the enforcement post, there are clear weaknesses to some of these protocol-based techniques from a security standpoint. But depending on the use case for access and sensitivity of the protected data, these techniques may be a good compliment to consider.

The Weakest Link

Finally, you need to balance deployment breadth against security, because the NAC device needs access to all traffic to enforce access control policies across the enterprise. If there is a blind spot on the network, that makes it easier for an attacker to gain access and compromise an authorized device – and then to bypass network-based access control. The weakest link is the link you don’t see, you see?

So starting with your proof of concept (PoC), focus your design on making sure you have sufficient visibility to meet security requirements. This often requires savvy use of SPAN ports for passive monitoring, and designing choke points for inline devices, to avoid unacceptable latency for applications. We always recommend focus on protecting the most critical stuff when planning a roll-out – be very sure to enforce network access control where it’s needed most.

Audit trail

We all saw Terminator and have no intention of allowing SkyNet to reconfigure our networks without approval, so it’s critical to keep a focus on auditing all changes made to any network infrastructure equipment by NAC (or any other technology, for that matter). Not only is this standard operational practice to facilitate troubleshooting, it’s also required by compliance regulations. The assessor will need to be shown that you understand why any change is made to the network (especially to any protected segments) and have documentation of who made each change.

Monoculture

As Dan Geer so eloquently explained years ago, there are clear disadvantages to a single-vendor environment – particularly being dependent on a monoculture, and aggravated if the key vendor’s goals are incompatible with your own. Of course, vendors who have made countless acquisitions over the past few years tell the other side of the tale, playing up the benefits of integrated management and enhanced integration in their unified environments. Unsurprisingly, we believe the truth lies in the middle.

First you need to understand the true extent of integration within a vendor’s product line. Just because you buy products on the same purchase order doesn’t mean the products are integrated. This is particularly acute for companies that grow via acquisition. If the integration is real, then evaluate the benefits of integrated management for the deployment use cases. If you have modest requirements, simple SNMP enforcement might be more than sufficient. And that can work well in a multiple-vendor environment. But if you need 802.1X interoperability may be problematic and overly complex. So there really isn’t a clean answer to the question of single vs. multiple vendors.

To be clear, smaller vendors usually cannot provide the entire infrastructure, so they aggressively support the infrastructure market share leaders. The best tactic is to be skeptical – about everything. Don’t trust a slide deck or a vendor’s data sheet. One of the tactics we’ll discuss in our next post on Quick Wins is to test out the integration in a proof of concept.