Vulnerability draws yawn from operations

You've just completed an extensive vulnerability assessment and have compiled the results. You give the report to the appropriate manager, who decides not to implement some of the corrective actions associated with a discovered threat. You want to be diplomatic about getting the discrepancies fixed, but you don't want to alienate anyone or create enemies. What do you do? I recently faced this very problem. Here's what happened and how I resolved it.

A Problem Appears

As part of a recent virtual private network (VPN) initiative, I performed a vulnerability assessment of about 1,500 remote laptops that will soon be loaded with the VPN client software. The laptops are all configured using the same software image, so by assessing one, I should be assessing them all assuming that users haven't changed anything on their laptops.

I used automated tools for the assessment, including Internet Scanner from Atlanta-based Internet Security Systems Inc. and Nessus, the open-source vulnerability scanning software. The combination should address 95 percent of potential vulnerabilities. I also conducted a manual review of some of the permissions and other security-related settings available in the operating system.

My assessment revealed a serious vulnerability in Windows NT. The configuration allowed the creation of a null session, which a hacker could exploit to connect to the laptops and read files without authentication.

As I mulled these results at my desk one evening, I heard a knock at my door. Standing in the doorway with his arms crossed was the CIO. He wanted to know the status of a recent virus attack that had plagued our network. Unfortunately, I couldn't give him the details he wanted. My security architecture position doesn't include ongoing virus-detection responsibilities, so I referred him to the operations group.

The message, however, was clear. When a security event occurs and the CIO gets involved, he will immediately turn to the security manager for answers and, in some cases, accountability. If an incident like this occurs only infrequently, I can live with it. However, if it were a weekly occurrence, the CIO might start to question my effectiveness. In other words, I could end up paying for mistakes made by the operations group.

With that episode fresh in my mind, I went to a meeting with operations group managers to discuss server and workstation baseline image issues. I asked the security department to scrutinize all baseline configurations prior to release and that subsequent changes to the baseline images also be submitted for reassessment.

If a modification caused a departure from the previously secured baseline, then a retrofit of the existing infrastructure would need to be explored and executed to ensure that all installations remain within security best practices.

I mentioned my recent laptop assessment and recommendations but met resistance from the operations manager in charge of laptop configurations. My assertion that the null-session problem was a serious vulnerability didn't sway him. Instead of raising concerns and putting him on the spot, I decided to take the issue off-line.

After the meeting, I pulled the manager aside to impress upon him the severity of the security issues I had discovered. I also asked why he wasn't considering incorporating my recommended corrective action into the baseline images and retrofitting the laptops.

He made several excuses, but his main rationale was that "in six months, we'll be upgrading to another operating system, and making dramatic changes at this point might cause more trouble than it's worth."

This appeared to be a lose/lose situation for a security manager. Do I force a confrontation with the manager or keep quiet and risk the CIO's wrath?

Pushing the Issue

I decided to respond by introducing the manager to what I call a risk accountability document. If, at the end of the day, a manager doesn't want to implement a specified corrective action to a known threat, I create a document that delineates the vulnerability, the corrective action necessary and the risk of not closing the security hole. I then ask the manager to write down the justification for why he has chosen not to perform the corrective action and sign it. That document goes to the CIO for signing. If an incident occurs based on a previously documented vulnerability, I have a document that in effect releases me from liability.

No manager is going to sign this, of course. But the process forces the manager to be accountable for the risk involved in not fixing the problem.

When the operations manager read through the document, he quickly decided that the problems were serious enough to warrant a change and committed to scheduling a retrofit of the vulnerable systems.

I decided to push my luck. I wasn't comfortable with the administrative password used on the desktop computers, I said. It was easy to guess, it didn't conform to the company's password policy, and many employees already knew the password. Future plans would incorporate the use of SecurID tokens for administrative access to systems, but until then, the password should be changed and controlled. The manager frowned, clenched his teeth and agreed to address this problem as well.

The manager was, in fact, quite embarrassed about the password issue and asked me to keep it quiet. I agreed, as long as steps were being taken to remedy the situation.

I think my method of dealing with this problem was fair and straightforward. But perhaps I could have finessed the situation somehow without forcing the manager into a corner. Have you faced a similar scenario and come up with a better solution? If so, I invite you to share your experiences in the Security Manager's Journal forum.


Securing Windows NT/2000 Servers for the Internet by Stefan Norberg and Deborah Russell (O'Reilly & Associates Inc., 2000): O'Reilly continues to produce excellent reference material, and this book is another example. If you are responsible for Windows NT or 2000 security, this book is a must-read. The authors provide details on many of the core elements of Windows security, from services to profiles and general best practices. Rather than simply telling the reader to check this box or stop that service, they describe the purpose of the service or option and any ramifications of disabling it. One caveat: The book doesn't include information on securing Internet Information and Enterprise management software suites such as IBM's Tivoli product and Computer Associates International Inc.'s Unicenter are powerful tools for implementing and managing security configuration changes across desktop and server The source for the Nessus remote-scanning tool, which is available for Windows or Unix I used Internet Security Systems Inc.'s Internet Scanner in my security assessment. You'll find more information about it here.

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

More about CA TechnologiesIBM AustraliaInternet Security SystemsISS GroupReillySecurity SystemsTivoliUnicenter

Show Comments