NAC (Network Admission Control or Network Access Control) has existed for a few years now, yet we still haven't seen wide spread adoption of it within the corporate network environment. Despite being pushed by the major network solution vendors, including Cisco & Juniper, as the best way to control access to the networked environment organisations are yet to dive headlong in to the space.

NAC, as a concept, is a very good way to maintain a thorough control of who accesses the organisation's networked infrastructure. The ability to require a user to authenticate not just to the workstation, but to the edge of the network infrastructure and to have that authentication be passed through every choke point within the network, including switches, routers and internal firewalls, is an excellent way of ensuring that whomever is trying to access a specific network resource is actually permitted to do so. However, the solutions offered by hardware vendors, such as Cisco & Juniper, come with a major impediment to their broad adoption. They require you to use their hardware wherever you want to achieve enforcement.

What this means is that if you have a typical corporate network environment, where you have a mixture of switching, routing and other networking hardware, that you have acquired over time and you wish to implement a NAC solution from a network vendor you have to contemplate the cost of replacing your entire network infrastructure in one hit. Most organisations simply can not afford the cost of this, let alone the time and productivity impact such a transition makes.

To address this issue a new type of NAC solution, one based on software alone has stepped in to the breach. Software NAC involves a central policy server that is communicated with by an end-point software agent that is installed on to workstations. If the software agent is not present or the person authenticating to the workstation is not adequately credentialed then the policy server restricts the user's access to the network. The way the typical software NAC solution achieves this is by acting as the DHCP (Dynamic Host Configuration Protocol) server for the controlled network environment and assigning IP addresses & associated network details (routes, DNS servers, etc...) based on the authenticating users permissions. This approach however presents a problem.

When security of a network is controlled via DHCP it relies on the ignorance of the user to not know how to assign their own network details to gain access to the network. However most PC users with more than a few years experience know how to manually assign themselves an IP address. They can also use network sniffing tools (such as Wireshark) to sniff the network to identify available DNS servers, and upstream routers (if they manually assign the same IP address as a workstation already in use they will see reply packets from router ARP queries & DNS server responses as the DHCP assigned workstations makes queries. Having established these details the user can then manually reassign their IP address to one that is not in use). So ultimately this means that the level of security being achieved with software NAC is only as good as the ignorance of the userbase.

In recent years, however, I have had the pleasure of using a software NAC solution that takes a different, if controversial, approach to enforcement. CyberGatekeeper DNAC, by InfoExpress (http://www.infoexpress.com), performs its enforcement utilising more of a "neighborhood watch" mechanism based on the MAC (Media Access Control) Address details of workstations (& other network devices) attached to the network.

The way CyberGatekeeper DNAC works is also by deploying a software agent on to the workstations, however enforcement is done by workstation peers within the same network segment. Within a network segment workstations (or servers) that have the DNAC agent installed negotiate amongst themselves, automatically, as to who will take on the role of the local enforcer. The agent that is acting as a local enforcer polls the other networked devices within the network segment to determine whether they have the DNAC agent running and whether that agent's system is running in a compliant manner. If the enforcing agent identifies a networked device that is not running the agent, or the agent's system is non-compliant (and the device is not in a white-list) the enforcing agent (and this is the controversial bit) utilises MAC address spoofing to force the non-compliant network device to route its traffic via the enforcing agent and then restricts that non-compliant network device's access to the network.

The astute reader might, at this stage, point out that MAC addresses can be spoofed also. Yes they can, but the knowledge required to spoof a MAC address is substantially more than manually setting an IP address, and the ramifications of spoofing a MAC address are also more dramatic. For example, if an unauthorised user chose to spoof the MAC address of a printer, because its in the CyberGatekeeper white-list of systems to always permit access, the printer would become unavailable to the network and would quickly be noticed.

Whilst the solution from InfoExpress is not perfect, it is the only solution I have seen getting deployed in to "normal" companies, that is very robust and is very affordable because you don't need to change any of your network infrastructure to run it. It works over any IP based network, and works across VPNs, WiFi and many other sorts of connectivity. It is very affordable, but more robust than the vast majority of the other software based NAC solutions (including those by anti-virus vendors).

Whilst I am normally very pro-standards, sometimes someone surprises you with a liberal interpretation of a standard (and this is very liberal) that makes you think, "maybe its good to be a little flexible?" Nice one InfoExpress.

(Please note that I have been very generalised in describing how all of these technologies work, more detail can be obtained by the reader by making inquiries of their preferred hardware & software NAC vendors.)