I faced two issues this week, and both came about as a result of security policies that have been routinely ignored. The first had to do with our wireless LAN infrastructure.

Although I work out of the main data center, I frequently travel to the corporate headquarters campus. On those occasions, I often use my iPaq Pocket PC and AirMagnet Inc.'s software to scan for rogue access points on the WLAN. The installation of unauthorized APs has been a continuing problem, so when I detected one the other day, I wasn't surprised.

This AP registered a signal strength of about 70% -- strong enough to lead me to believe that it wasn't transmitting from outside of my company's offices. Indeed, I was able to associate to the AP, open a browser window and get to the corporate intranet. The device had no encryption enabled, it was broadcasting the Service Set Identifier code, and the AP gave my device an IP address that wasn't within our corporate address range.

I called the network engineering group and gave it my device's media access control address and location, thinking that they could log into the switch that was serving the location, look up my MAC address, identify the port and trace it to a specific wall jack. In the past, I've successfully identified rogue APs in this manner.

However, in this instance, the group wasn't able to find my MAC address. I even had the network engineer check some nearby switches, but no luck. Then I tried using AirMagnet's Find utility, which works as a signal-strength meter to help locate the AP. I've gotten close in the past using this method, but it still requires that I peek into employee offices, conference rooms, break areas and so on, to visually locate the AP. In the process, employees have gotten upset with me and started complaining.

This time, however, it worked like a charm. I could see the AP sitting right on top of an employee's monitor.

The device was a WLAN router, which explains why my MAC address didn't show up on the switch port. Because this AP functioned as a router, not a hub, the MAC address wouldn't have registered on the switch. The employee wasn't in, so I had the facilities department open his office. I then unplugged the AP and left a note indicating why I had disconnected it.

Later, the employee said he had installed the AP because his boss "said it would be OK." Neither of them had read the network access policy on our intranet, which prohibits unauthorized network-access devices from being attached to the corporate network.

Apparently, our policy awareness training still isn't working. I sent him a note with a Web link to the policy.

Something in Common

A few weeks back, in the aftermath of a SQL Slammer outbreak, a manager proposed that my small group take on incident-handling and remediation issues -- a task that other departments take care of today and that we're not equipped to do.

I researched how we can do a better job and discovered that IT security isn't the only group with a written incident-handling policy. The data center operations group has its own, 20-page guide, and the networking group has something similar. Each contains relevant information with respect to incident-handling best practices, but each is department-specific. What's even more disturbing, however, is that no one uses these documents. They just sit in a binder on a bookshelf or in electronic form in a shared disk space available only to members of each department.

To rectify that, I wrote a single-page incident-protocol document that outlines the main steps all departments should take when responding to an incident. My goal was to create something that could be printed on a small reference card and placed next to the telephone contact list, security badge and SecurID token that most operations employees carry around. I focused on four areas: preparation, identification, response and containment.

Preparation deals with knowing whom to call when an incident occurs. Identification addresses how to identify and classify an event to avoid false positives. Response dictates the actions to take when an incident has occurred, and containment deals with how to keep the incident from doing more damage or continuing to affect the network.

For example, containment might involve disabling a switch port or implementing access control lists on a router. I want the reference card to help workers become more efficient at handling incidents in a timely manner. Eventually, we'll create a formal crisis-action team and run simulations for training.Although we're getting better at responding to incidents, common problems arise. One is that no one wants to take charge. There are always lots of managers, directors, engineers and analysts standing around the operations center, looking at logs, e-mail and other tools and forming opinions. But no one is calling the shots. Eventually, someone steps up to the plate.

Another problem is that there is always confusion as to who should conduct certain activities. For example, a common and easy way to identify a Windows resource on an enterprise network is to enter the nbtstat-A command. In our desktop and production server environment, this command will typically identify the user or system name of the machine.

For some reason, there's always a question regarding who should issue the command. I don't quite understand why, as it's a task that takes only a few seconds to complete. Hopefully, by creating a common incident-response protocol and ensuring that everyone is on the same page, our responses to all events will become standardized, and incident management will become a routine aspect of doing business.

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 mathias_thurman@yahoo.com, or join the discussion in our forum. QuickLink a1590

To find a complete archive of our Security Manager's Journals, go online towww.computerworld.com/secjournal.