“Homeland Security” for Networks

By Chris Poe

It seems every time an IT team does due diligence to secure a network, another threat rears its ugly head. For a network to be truly invulnerable, it would have to be completely closed, but those who’ve invested a fortune in technology actually expect it to be usable. Guaranteed stability and reliability combined with usability—and they want flexibility too? How much more “unreasonable” can they be?

But threats no longer come just from outside your organization. Now we’re faced with having to protect the network from threats originating on the inside, often from our own users, whether malicious or not. Today, users who inadvertently click on the wrong link or open the wrong email message could infect a network or provide a “backdoor” in for malicious activity to occur the next time they simply plug in to the network, even without logging on.

This problem of IT security is much like Homeland Security. We’ve never had to worry about being compromised from within our own borders. Now we do, and internal security requires extensive cooperation and collaboration between multiple entities or agencies.

Similarly with IT security, just guarding the perimeter is no longer sufficient. To secure your network from both external and internal threats you must be able to control who gets onto your network. This is where NAC comes in. Network Access (or Admission) Control regulates access to the network “plumbing.”

Client systems, which are often mobile devices that connect to untold other networks, must be scrutinized before even being allowed to place traffic on your production network. Those that are compliant can be given the appropriate access. Those that are not compliant should be denied access altogether—perhaps by blocking the network port or automatically placing them on a quarantined network (virtual LAN or IP network) until such time as the system becomes compliant. Additionally, unless client support has a lot of extra time on its hands to address compliance issues, non-compliant systems should be offered the ability to self-remediate.

There are different ways to create a NAC system—some basic and simple to implement, while others are more complex, robust and flexible. Ultimately, your system must be able to control and secure the inquiring “W’s”:

• Who gets access?
• What station do they use (does it meet the minimum standards as defined by policy)?
• From Where in the network?
• When, How (virtual private network, wireless, etc.) and what kind of access is provided?

The different architectures for NAC systems are very much reliant upon the infrastructure already in place. Embedding NAC within your infrastructure in what’s called “Out Of Band” enables access control to be pushed out all the way to the edge (network access port or even the client device itself). This model requires that the infrastructure be configured with appropriate “isolation” networks that are used for separating unknown users or users who are not compliant with the network security policy. This deployment model is the preferred option for NAC because of the granular control down to the port level.

While “Out of Band” NAC may be optimal, it does require network changes to provide the “isolation” areas and may not be possible for all environments. Some NAC vendors provide another deployment model “In Band” where NAC does not integrate with the infrastructure but works more like a firewall not allowing traffic beyond where it’s placed in the network. This still protects network locations upstream of the “In Band” NAC server and provides required NAC functionality.

You do not have flash or javascript support.

Average (0 votes)

Reply