Limiting what contractors can do on the network

How can you limit contractors' access to confidential data on your networks, while letting them get on with their jobs?

Share

Question: We have contractors perform a number of critical services, such as managing our IBM blade servers. These staff have to be on the LAN, and they're long-time contractors, so trust levels run pretty high, but I know they shouldn't be able to go everywhere on the LAN. How can I limit their access while still letting them do their jobs, and most important, not making them feel like I don't trust them?

Contractors definitely represent a unique security challenge. Unlike typical guests, who are there for just a short time and need only Internet access, contractors - especially long-term contractors - are much closer to employee status.

The problem, of course, is that they're not employees. So for regulatory reasons, or for just common sense reasons, you can't give them wide-open access to your entire enterprise network. Yet in nearly all cases, they have to be on your LAN to do their jobs.

In my industry, auditors are a great example - they need to access several financial systems, and they're on site for as long as a month at a time. In hospitals, the service technicians that come in to work on the x-ray machines and other medical devices are a great example of this issue. Similarly, lots of companies have outsourced portions of their IT functions, such as managing blade servers. Very often, those third-party contractors end up at your facility for years, with a company business card, desk and email address.

But it's not appropriate for these workers to be able to access your company's source code or other intellectual property, your financial data (unless they're the auditors), or future product plans. Often, these workers move from company to company within the same industry, so their ability to relay information to a very interested competitor isn't hard to fathom.

To limit contractor access, I relied on the trusty network segmentation tools of virtual LANs (VLANs) and access control lists (ACLs) for years. But ultimately, the problems with this approach forced me to look for more automated tools.

First, the staff time needed to set up and maintain VLANs and ACLs just got out of hand. Any time there's a move, or a new contractor joins the group, IT needs to ensure these settings are up to date. Having the logical separation essentially hard-wired into the physical design adds a lot of complexity.

Find your next job with computerworld UK jobs