As we continue with “Network Security in the Age of Any Computing”, we have already hit the risks and the need for segmentation to restrict access to sensitive data. Now we focus on technologies that can help restrict access – which tend to be NAC, firewalls, and other network layer controls (such as VLANs and physical segmentation). Each technology has pros and cons. There are no ‘right’ answers – just a set of compromises that must be made b weighing the various available technology options.

NAC

Everyone likes to beat on Network Access Control (NAC), including us. The technology has been around for years, and most of those years have been marketed as The Year of NAC. Unfortunately the technology was oversold years ago, and could not deliver on its promise of securing everything. Imagine that – marketing getting ahead of both technology and user requirements. But folks in the NAC space have been (more quietly) moving their products along, and more importantly building NAC capabilities into a broader network security use case.

But before we jump in, let’s take a look at what NAC really does. Basically it scrutinizes the devices on your network to make sure they are configured correctly, and accessing what they are supposed to. That’s the access control part of the name. The most prevalent use case has always been for guest/contractor access, where it’s particularly important to ensure any devices connecting to the network are authorized and configured correctly.

Of course, under any computing, every device should now be considered a guest as much as feasible. Given the requirement to ensure the right devices access only the right resources, integrating mobile devices security with Network Access Control offers a means to implement control structures so one can trust but verify these devices. Which is what it’s all about, right?

So what’s the issue? Why isn’t NAC proliferating through everything and everywhere, including all these mobile devices? Like most interesting technologies, there is still too much complexity for mass market deployment. You’ll need to link up NAC with your identity infrastructure – which is getting easier through standard technologies like Active Directory, LDAP, and RADIUS, but is still not easy. From a deployment standpoint, the management devices need to see most of the traffic flowing through your network, which requires scalability and sensitivity to latency during design. Finally, you need to integrate with existing network and security infrastructure – at least if you want to actually block any bad stuff – which will be the subject of a later post in this series.

As folks who follow markets for a living we know that once the hype around any market starts dying down, the technology starts becoming more prevalent – especially at the large enterprise level. NAC is no different. You don’t hear a lot about it, but it’s happening, largely driven by the proliferation of these mobile devices and the need to more effectively segment the network.

Firewalls

As described in the PCI Guidance we excerpted, our PCI friends believe firewalls are key to network segmentation and protecting sensitive information. They are right that front-ending sensitive data stores with a firewall is a best practice to control access to sensitive segments. Unfortunately, traditional firewalls tend to only understand IP addresses, ports, and protocols. With a number of newer web-based applications – increasingly encapsulated on port 80 – that can be problematic.

This is driving the evolution of the firewall to become much more application aware. We have covered that evolution extensively, so we won’t rehash it all here. But in the use case of network segmentation for dealing with mobile devices, scalability of application layer inspection remains a major concern. These devices need the ability to inspect and enforce application layer policies at multi-gigabit internal network speeds. That’s a tall order for today’s firewall devices, but as with everything else in technology, the devices continue to get faster and more mature. All hail Moore’s Law!

So these evolved firewalls are also instrumental for implementing a network segmentation architecture to support any computing.

Network Layer Controls

But the path of least resistance tends to be based around leveraging devices already in place. That means using the built-in capabilities of network switches and routers to enforce required segmentation and access control capabilities. First let’s hit on the brute force approach, which is physical segmentation. As we described in the last post, we believe that Internet access for mobile devices and guests should be on a totally disparate network. You don’t want to give a savvy attacker any chance to jump from you guest network to your internal net. This level of physical segmentation is great when the usage model supports it, but for most computing functions it doesn’t.

So many folks leverage technologies such as VLAN (virtual LANs) to build logical networks on top of a single physical infrastructure. At the theoretical level, this works fine and will likely be good enough to pass your PCI assessment. That said, the objective isn’t to get the rubber stamp, but to protect the information. So we need to take a critical look at where VLANs can be broken and see whether that risk is acceptable.

There are many ways to defeat VLAN-based segmentation, including VLAN hopping. To be fair, most modern switches can detect and block most of these attacks if configured correctly. That’s always the case – devices are only as strong as their configuration, and it’s rarely safe to assume a solid and secure configuration. Nor is leaving the security of your critical data to a single control. Layers of security are good. More layers are better.

But given that everyone has switches and they all support VLANs and physical segmentation, this will continue to be a common means for restricting access to sensitive data, which is a good thing. VLANs + firewalls + NAC provide a comprehensive system to ensure only the right devices are accessing critical data. That doesn’t mean you need to do everything, but depending on the real sensitivity of the data, it shouldn’t hurt.

Device Health

As described in the Mobile Device Security paper, there are many risks – especially in light of the prevalence of malware on traditional PCs and misconfiguration on all devices. When evaluating network layer controls, assess your need for device context – the security posture of any device connecting to your networks. Obviously the bar will be set differently depending on what the device is accessing.

So, for example, you may need to carefully scrutinize any device accessing your ‘vault’ of protected cardholder data. In that case, NAC + firewall will be critical to protect those resources. But for everything else, a VLAN-only structure may be sufficient – even though you’d rather not have any general-purpose applications compromised – if it’s a manageable risk.

The point is to design network security controls based on what they protect, and that it’s okay to have different tiers of protection based on what resources are available on that particular segment (whether physical or logical).

Visibility vs. Control

One other consideration for enforcement is whether you want to focus on knowing what’s happening in your environment (visibility), or the ability to actively block traffic that violates policy (control). This decision has a profound impact on the architecture you implement to enforce it. If you only need visibility you can send log files and/or traffic flows to a device for analysis. This more audit-centric use case is becoming popular with folks who are unable to implement inline devices for blocking, due to either latency or political issues.

But if you want ultimate control over the traffic that reaches these sensitive segments, you need to have a box inspecting all traffic inline, with the ability to block offending traffic. Yes, there are ways (such as TCP resets) to intervene and tear down offending sessions without being inline, but they are all much easier to defeat than inline blocking.

Again, there are no right or wrong answers – just considerations when designing your own network security control environment. Clearly you will be dealing with more and varied types of devices moving forward, and they need deeper access to more sensitive information. We advocate a phased approach, where the first wave focuses on visibility. This helps show the seriousness of the issue, and doesn’t run the risk of interfering with business. You know it’s a bad day when you block something that results in the loss of a multi-million dollar deal.

The next step becomes implementing blocking controls to enforce the segmentation strategy. This phasing enables you to focus inline devices where they are needed, and to avoid disrupting business operations.

Next we will focus on how these enforcement technologies need to integrate with your existing network and security gear. Ripping and replacing all your existing stuff is rarely an option, so you will need to make sure everything plays nicely together.