informa
Commentary

The Inconvenient Truth Behind Security

A co-worker forwarded me an e-mail in which the original sender was asking about running vulnerability scans on his own and stated he was concerned about the scans causing downtime while the servers were being tested.
A co-worker forwarded me an e-mail in which the original sender was asking about running vulnerability scans on his own and stated he was concerned about the scans causing downtime while the servers were being tested.We bantered back and forth, but the reality of the situation was clear, and one we've all seen at one point or another. It's the one where someone wants a little security and is gung-ho to push the red button until he realizes that a security process can often have a negative impact if not done right.

In this example, the person was ready to start using Nessus without having a clear understanding of how it works and what would happen to the targets being scanned. While I think the default configuration for a Nessus scan can be quite safe, the possibility that something can go wrong is always there. This case was a prime example of someone just wanting to push a button and get results without having a clue about what's going on under the hood.

It is important to know what's really going on when you press "SCAN." I've seen servers that were overloaded prior to the scan that locked up or rebooted right in the middle of a scan. Then there are the checks that fall into the experimental and thorough categories for Nessus that are valuable, but you definitely don't want to run on a production environment if you can't afford downtime.

Did you catch the key part of that last statement? That's right -- production environment. Are there development and test environments that mirror the production environment that can be used as the targets for vulnerability scanning? If there isn't a test environment, then are there scheduled maintenance windows where downtime would not be devastating to the business, and can the production environment be restored quickly from backup if something goes wrong?

I can't count the number of times I've been asked to perform vulnerability scans for a client, only to find out they want it run against production servers -- and they've never tested the ease and effectiveness of restoring from their backups. I recently had a situation where I was using a web crawler to spider a Website. All I wanted was to generate a site map to understand the target better, and I ended up deleting nearly 50 records because the DELETE function was called when certain links were followed. Thankfully, the client's backups worked.

At the end of the day, everyone must realize security's cost. It could impact how someone logs into an internal corporate site from on the road, costing them an extra 30 seconds for the NAC client to run, or it might be a fiscal cost for a transparent solution allowing for network monitoring and data leakage protection. The simple fact is that security isn't convenient, and it's not found in the reports after clicking SCAN.

John H. Sawyer is a senior security engineer on the IT Security Team at the University of Florida. The views and opinions expressed in this blog are his own and do not represent the views and opinions of the UF IT Security Team or the University of Florida. When John's not fighting flaming, malware-infested machines or performing autopsies on blitzed boxes, he can usually be found hanging with his family, bouncing a baby on one knee and balancing a laptop on the other. Special to Dark Reading.

Recommended Reading: