What to Expect from a Vulnerability Scan
For a lot of our customers, their first introduction to pentesting is a vulnerability scan from BHIS. This is after talking to the testers, of course, and setting up rules of engagement, sharing which hosts are within scope, and talking over how we, as testers here at BHIS, can best help secure their environment. But still – this is the first time the rubber meets the road, and it can make people understandably nervous. What is a scan, anyway? Will it crash things? Do we need to run it at night or on a weekend? We field a lot of these questions, and this post is here to help you get an idea of why we do these scans and what you can expect. Make sure you’re comfortable, and let’s get started.
First, an intro to vulnerability scans. As you may have noticed from our new homepage redesign at https://www.blackhillsinfosec.com/, we frequently compare penetration tests to climbing a mountain, with our ultimate objective – the “crown jewels” of an organization – at the top. You can climb a mountain by just walking up to it and starting, of course, but you’re probably going to have a rough time of it, frequently making it part way up before you realize you’ve taken a bad route, climbing back down, and starting over. In this world, a vulnerability scan is a map of the mountain – not a perfect one, but better than nothing. Using this map, the testers here at BHIS can be your adventure guides – we can plan routes up, make sure to fully explore the mountain, find hidden crevices and caves, and do it all much faster than if we were to just start climbing.
Here at BHIS, we generally use Nessus for our scans. A quick skim through the Nessus propaganda gives you some idea of why – Tenable (the company behind Nessus) claims that over 24,000 organizations around the world use Nessus, and I believe them. When we launch scans, we do so with a finely-tuned policy based on the PCI standard scan, the same one used by thousands upon thousands of others – they’re called PCI standards for a reason. What does this mean for you? It means you’re not going to have anything weird slamming your network. No DoS attacks, no bruteforcing passwords, and so on. We like to get creative in our tests, but an automated vulnerability scan is not the place to do it. Creativity is for humans. Sorry, robots.
I asked the testers at BHIS for their most out-there Nessus stories, and got very little despite decades of cumulative experience regularly running these scans. The short of it is that anything that Nessus breaks must be so fragile that you should reconsider it being on your production network at all.
Here’s what John has to say, after hundreds of tests over many years:
Testers, please share a list of any system/service that crashed in a test.
I will start.
1. Killed a switch in 2003.
2. Submitted emails… Lots of emails to some open contact email page. This has happened on a number of different customers. It is also not specific to Nessus, but to any web scanner/crawler.
3. Um… Ahh… Might be getting old…..
I did hear a couple of stories along the lines of, “Well, we hit the customer with a scan and they had their monitoring set up to alert on so many things that the SOC lit up like the 4th of July and the alert traffic brought down their network.” That’s certainly bad, but also… if your IDS is set that aggressively, I mostly feel bad for the analysts who have to sift through all that noise. This is a vulnerability in itself, and a good one to know about!
Other than that, everything we know is hearsay. I’ve heard legends of printers spewing page after page with cryptic packets printed on them (rumors that anyone who reads the pages in their entirety gains eldritch networking powers are entirely unfounded), or of SCADA systems crashing, but nobody at BHIS has seen this firsthand. The closest we got was David Fletcher, who told a story of HID physical access controllers on a production network which stopped responding to the connected card readers after being scanned and needed to be rebooted. It turned out, though, that these same controllers had default hard-coded credentials which couldn’t be changed and cached the last read from each connected card reader on their web interface, which allowed anyone to impersonate anyone else by just grabbing these cached scans.
These are the sorts of issues we see – if Nessus breaks it, it’s a good sign that something is very, very wrong. We tune our Nessus scan policy to avoid these issues (ignoring printers, skipping SCADA systems), and I want to underscore that despite decades of combined experience running these scans, here at BHIS we very rarely see anything break because of a scan.
At the end of the day, BHIS is here to help you secure the mountain that is your organization, and the map generated by Nessus is a great help to us (and you!) in doing so. We can work without it, but we’ll be climbing blind, and a lot slower because of it. If you have any concerns about scanning your network, just chat with your tester about it – we’ve seen a lot, and it’s our job to guide you through your test, whether it’s your first or your hundredth.
Ready to learn more?
Level up your skills with affordable classes from Antisyphon!
Available live/virtual and on-demand
