Another step in our relentless march toward better security: A couple of weeks ago, our network access control (NAC) initiative moved to initial deployment.
Trouble Ticket
Network access control is ready for deployment. Action plan: Move slowly so as not to disrupt the business with sudden tight controls.
Our main goal with NAC is to restrict the access of unauthorized devices to certain segments of our corporate network. Several times, noncorporate devices connected to our corporate network introduced malware or were found to contain some of our intellectual property. We have a corporate policy that prohibits the use of personal devices on our network, but without NAC, we couldn't effectively enforce it.
With the initial deployment, we're focusing on end-user access points: the wired ports and wireless hubs in our offices, as well as the VPN. These are a higher priority than securing our production server networks and the engineering and test-and-development network segments in the data center. We'll get to those later.
We chose a NAC tool with a centralized management console that monitors every switch port on the VLANs serving our 50-plus offices around the world. With such far-flung facilities, this is more cost-effective than installing appliances at every location.
I'm sure you know how NAC works. Any device that connects to a switch port or authenticates to the network via 802.1x is interrogated before it is granted network access. Most of our authorized devices are Windows PCs. If a PC is seeking access, we first want to determine if it is a member of our domain. Next, we check that it's running our systems management software. For now, we're assuming that any PC that passes that test is up to date with patches and endpoint protection. Eventually, we might directly interrogate the device about those things, but for now we're going to be satisfied with this. PCs with the systems management software will be allowed to connect to the corporate network. Others will be halted and given some options: install the required software, be placed on a segmented network to facilitate that, or be given access to our guest network for limited Internet access.
In practice, this means that if a PC is a domain member but isn't running the systems management software, we may elect to install the software. On the other hand, if a PC is not a domain member (for example, one that has been brought in from home or by a vendor's rep) but is up to date with patches and is running an antivirus client, we may decide to grant access to the guest network. That option would still give a vendor's rep access to the Internet in order to provide product demos.
Other Devices
We have a few corporate-sanctioned Linux machines and Macs. To control their access to the corporate network, we could install a NAC agent on each device, create exceptions by registering the devices' MAC addresses or obtain each device's SSH key so that the NAC tool can interrogate the device. As for iPads, iPhones and Android mobile devices, they will be routed to the guest network unless they connect via a VPN client.
At this point in our NAC deployment, we're only monitoring the activity and not actually enforcing network lockouts, so as not to disrupt business activity. It's a good thing, too, since a whole lot of devices are failing to meet even our initial security policy. In initial monitoring, more than 40% of the Windows PCs could not be properly interrogated. Many of them were domain members, but we could not determine if they were running the systems management software. This will have to be looked into, as will the plethora of Linux and Apple devices that are connected to the network but are not corporate owned.
This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@yahoo.com.
Join in the discussions about security! computerworld.com/blogs/security
Read more about security in Computerworld's Security Topic Center.