Companies Don't Need NAC. They Need PAC.

PAC, as in personal access control. Getting unauthorized access to a company's assets is often child's play, and security pros know that.

Mike Fratto

May 28, 2008

4 Min Read
Network Computing logo

PAC, as in personal access control. Getting unauthorized access to a company's assets is often child's play, and security pros know that. Guys like Steve Stasiukonis, CEO of Secure Network, and Ira Winkler, CEO of ISAG, can regale you with stories of literally walking into supposedly high-security buildings like they walk into the grocery store. The underlying flaw is often people. These two gentlemen look like nice guys, and they are. But if Steve and Ira were morally challenged, they could the steal the shirt off your back. No matter the physical controls in a building -- cameras, card readers, man traps (vestibules with two locked doors), guards checking ID cards, etc. -- walking into a building is often simpler and cheaper than trying to hack your way in. What is scary is that even though companies have well-defined procedures for handing out ID cards, a smile and reasonable story can subvert the whole process.

Stasiukonis was telling me about a recent penetration test his company went on. I didn't ask who and he didn't volunteer the company name. As part of the penetration test, Steve actually got an employee ID issued to him and then he got contractor ID's for his crew. He entered a secure data center and learned the network architecture from the IT staff, including their future plans. He listened in on meetings, videotaped presentations, and wandered undetected into the CEO's office.

The crumbling of this company's physical access controls began with getting a badge. Stasiukonis wasn't properly vetted before getting a badge. Once he had a badge, making him an authorized employee, the internal controls failed to keep him and his team from information and places they probably shouldn't have been in the first place. This story is very much analogous to the limitations of current NAC technologies, namely, once you have access to the network, there isn't enough access control to restrict what a malicious user can do.

I don't think Stasiukonis tried to get authorized network access -- he didn't need it -- but if he tried, there is no reason to think he would have failed. NAC, whether you are looking at network admission control, which is primarily focused on admitting hosts to the network, or network access control, which focuses on admitting hosts to the network and then regulating the services a host can access once connected, simply fails if your company improperly vets access requests.

A number of vendors, like Bradford Networks, Cisco, and Great Bay Software, are developing or selling guest sponsorship products that allow an employee to sponsor guest network access, similar to how employees can get a temporary guest pass to enter a building. From a business process point of view, that sounds like a great idea. Let the central IT department define the policies that employees can sponsor, grant sponsorship privileges to employees, and you can off-load the management burden from IT to someone else. But given the overwhelming evidence demonstrating how easy sweet-talking a building badge from an unsuspecting employee is, getting network access won't be that much more difficult.Granted, few companies, compared to all companies, need to run highly secure facilities. Doing so is unnecessary and cost-prohibitive. Many companies' goals may be more modest. They simply want to control guests accessing the network. Regardless, before embarking on a NAC deployment, spend the time thinking through all the requirements and processes that you will need to enable your goals.

If your goal is to treat guests differently from employees, then how will you determine a guest user or computer from a company-owned asset? How will a guest be authorized to get a pass onto the network, and who is responsible for doing that? If your goal is more fine-grained access control, perhaps determining access based on a user role or group membership, then where is that information stored, who is responsible for defining who is a member of each group, and what will you do about conflicts that occur when a user is a member of two potentially conflicting groups? It all comes down to defining a process, educating people about the process, and then implementing a product that supports your process.

About the Author(s)

Mike Fratto

Former Network Computing Editor

Stay informed! Sign up to get expert advice and insight delivered direct to your inbox

You May Also Like

More Insights