Reality IT: When a Security Project Hurts Network Performance, Pull the Plug!

A 'Friendly' Rivalry

A few months ago, our network team found itself struggling to support yet another in a seemingly endless stream of IT security projects. This one was to implement token-based authentication, which was supposed to shore up ACME's access control. Our IT security manager, Bucky Rogers, was once again straining his relationship with our network manager, Dirk Packett. Yes, they both work for me, but that doesn't mean I can force them to get along (although I have considered bringing in Rock 'Em Sock 'Em Robots to let them work out their problems). Of course, conflicts between network people and security people aren't unusual, but Bucky doesn't help when he uses his "sky is falling" approach to ramrod project approvals from our internal auditing department, with whom he works closely.

None of the network folks were thrilled with the idea of token-based authentication. The technology required deployment of a hardware-based system that would force the end user to log on with a special keyfob device that provides a code to augment the usual user name and password. It seemed like overkill to some--we had a secure authentication system with hardened passwords, aging and the whole nine yards--but the project was about halfway down Bucky's list of priorities, and we had reached that point in our IT security improvement plan. So, the project went forward.

Going Live

Bucky's team researched options and worked with Dirk's crew on the project planning. They ordered the equipment and installed the authentication server software on several servers for redundancy. We tested the technology over a period of several weeks, and then one evening we cut over to the new system with no ill effects--that night.We didn't realize that by doing the cutover at night, when traffic was light, we weren't immediately experiencing the new system's full impact on network performance. And we hadn't expected the system to add significant additional traffic. But the next morning, when employees started to log in and fire up their client- server apps, we had a problem. Our network performance took a nosedive, traffic spiked, and user productivity came to a near standstill. Users who arrived later could not log in at all.

Working with the authentication vendor's tech support, we resolved the problem--or so we thought. But every few days, the traffic spiked again and we had to pull the vendor back in. Dirk wanted to pull the plug on the technology, but Bucky was pigheaded about it. I gave them a few more days to work things out--but after that, we would have to shut it down.

On a subsequent Monday morning, the network crew spotted traffic spikes again, so Dirk pressed me to let him take down the authentication server application, and I gave him the go-ahead. When Bucky arrived, he was piping hot and spouting threats of internal audit rule noncompliance. I told Bucky we could live without this for now. Somehow, we had found ourselves solving a problem that didn't exist yet. Sure, token-based authentication would improve our security, but at such a high cost to our network performance, it simply wasn't worth it.

Problem Re-Solved?

Projects like this are not good for IT's image. We work hard to maintain good service levels, and when a supposed "improvement" hurts productivity, it damages our reputation, too. Bucky and Dirk are working with the security vendor to solve the problem--we may end up returning the hardware and going with another vendor.The moral of the story: Just because a project relates to security doesn't mean it should automatically soar through the approval process. The network should never be so secure that your own users can't get in.

Hunter Metatek is an enterprise IT director with 15 years' experience in network engineering and management. The events chronicled in this column are based in fact--only the names are fiction. Write to the author at [email protected].