Lull in Action Is Time to Tie Up Loose Ends

The blackout at the end of the quarter is a chance for documentation and evaluation of new technologies.

My company's quarter-end blackout always means we're in for a slow week, since we can't make any changes to our production environment. When I have some extra time like that, I usually like to catch up on documentation and evaluate new technology, and that's what I did when this past quarter ended.

As I've mentioned in previous articles , our mass deployment of RSA Security Inc.'s SecurID tokens is a critical project, touching thousands of users. Failure is not an option, and the definition of failure could include a deployment that generates thousands of help desk support calls. To keep that from happening, documentation and training are part of the deployment strategy.

Happily, I was able to get some cycles from another department's technical writer, who created some Web content about two-factor authentication that can eventually be made available to the masses. If we start raising awareness early and drill some of the new lingo associated with this project into employees' heads, the deployment will have a better shot at success.

There are three important terms users must be familiar with. The first is tokencode, which refers to the number displayed on a token. The next is PIN, which is the personal identification number each user will define and use as a password. The third term is passcode, which the PIN and tokencode combine to form.

Those three terms are the usual causes of support calls in a SecurID rollout, and we want to clear up confusion beforehand so that users don't beset the help desk. We also hope to curb the number of support calls by finding a way to deploy the software tokens without users having to do anything other than set their PINs. We're diligently working on that, and I will report on our progress in my next installment.

WAP Strategy Session

On another front, I've been talking to Alpharetta, Ga.-based AirDefense Inc., which has an appliance for detecting rogue wireless access points that integrates with the Cisco access points we have already deployed en masse. I received one of the appliances to evaluate today, and I managed to get it racked and powered and will start testing within the next week or so. I also received several access points from Cisco that I will configure as sensors.

AirDefense claims that when the Cisco sensors discover an access point, its appliance can determine whether it's on our network.

I plan to deploy some low-cost access points that I ordered from Office Depot. I figure that employees who set up unauthorized access points will probably buy their hardware at a retail store rather than spend several hundred dollars on a Cisco access point. I ended up getting six different wireless access points/routers. I'll place four of them on our network at various locations and one on an external Digital Subscriber Line, which we use for troubleshooting external access issues. I'll power up the remaining access point, but I won't connect it to any networks.

AirDefense's technology could play a significant part in our strategy for detecting rogue wireless access points. We can't rely solely on scanning the network or grabbing the media access control addresses off of our switches. Those methods are also very important in our overall strategy, but if the AirDefense appliance is sound, we will have a robust approach to discovering unauthorized access points on our network. I'll keep you informed about this as well.

Implications of Growth

The enforced downtime at the end of the quarter allowed me to contemplate the implications of the fact that our company is growing by leaps and bounds. We've added several thousand users and millions of dollars in servers and other infrastructure over the past several years. My department has deployed technologies such as two-factor authentication and Tripwire Inc.'s software for intrusion detection and prevention, and we're evaluating identity management software.

We're also getting ready to deploy disk encryption, and we continue to conduct vulnerability assessments at the network, host and application levels. My people are present at almost every major meeting concerning architecture, change control and project intake. We also write policies, procedures and guidelines and are responsible for the care and feeding of our entire security infrastructure. My department is solely responsible for everything from administration of our authentication systems to troubleshooting problems. We're becoming overloaded with work.

I continually make upper management aware of our workload and have requested additional head count, but I've always been met with resistance, mainly because of budget constraints. In large companies, it's pretty standard for the information security department to have one engineer for every 1,000 employees. I have seven engineers for a little over 8,000 employees, so we're about one engineer shy of the standard.

Relief may come in the form of four data center operations employees taking over security analysis. If executed properly, that move would alleviate a lot of the day-to-day burden now on the shoulders of the information security staff by shifting some of the operational and analysis work to security operations. That would allow us to focus on other security decision-making responsibilities: architecture, engineering, new and emerging technologies, policy enforcement and so on.

This plan is still in its infancy, and I'm sure there will be plenty of discussions around general responsibilities as this endeavor moves forward.

What Do You Think?

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, or join the discussion in our forum at QuickLink a1590

Copyright © 2005 IDG Communications, Inc.

7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon