Vulnerability scanning requires careful configuration decisions that directly affect the accuracy, depth, and operational impact of each scan. Key settings include scan scope, active versus passive methods, credential use, agent deployment, and sensitivity levels.
Vulnerability Scanning Setup
There are a lot of different ways that we could set up our vulnerability scanning software. There's also quite a few considerations when we're setting up those different options. There are going to be a lot of different settings that we're going to want to tweak and adjust, and it will even affect which software we purchase.
So let's talk about some settings and how we would set up this vulnerability scanning. For instance, we'll want to consider the scope, of whether we're trying to set it up internal or external. We're going to want to consider whether we're doing active or passive scanning, or whether we're using credentials or it's going to be non-credentialed, agent or agentless, and what these sensitivity levels are going to be.
One of the biggest decisions is whether we're doing internal scans or external scans. Internal scans would be something that's done within our network, versus external scans is what can be hit from the outside.
If it's an external scan, maybe we're basing it off of IPs or ports and doing scans from that perspective, and what is compromised, or what is the vulnerabilities from that perspective. Or maybe we are doing it based off of a URL, some sort of domain, and we're hitting that domain and seeing what the exposure level of that domain is. Or maybe we're hitting some sort of specific application and gaining access to that application and seeing what it looks like, gaining access to that application from the outside.
There also is internal scans, which looks very different, because there's a lot more open on the inside. So hopefully we got things locked down from the outside, that the attack surface is fairly small, but internally then that opens up us for a lot of different devices that are internally. We have switches, we have the internal part of the firewall, we have these different devices that are on our network. And so we're going to be taking a look at that network and the infrastructure and the different devices on it, and maybe some of the applications that are running internally.
Or maybe we're a software company and we're developing code. So that's another aspect here: are we scanning that code and software that we're creating, and what does that look like if it's internal on our network, or even I guess to a certain degree external.
We might do some sort of asset discovery. So in this example right here, let's say we are installing our vulnerability scanning software right here, and then setting that software up, and we give it an IP address range of something that's internal here. One of the things that it might do first is do an IP — just a ping. It just might ping a bunch of IP addresses and see what equipment it can ping and get a response back from. Once it gets response back, then it knows there's something live on the other side of that, on that IP address on the other side. So from there, maybe it does some sort of port scanning and figures out what ports are open. There are other ways to go about this too, but essentially what we're looking for is some sort of asset discovery, and discovering everything that's on the network.
There's something called device fingerprinting. So when a scanning software discovers a device, it can start saying, well, what ports are open on that device, and what is the different communication that that device is maybe sending out, and what is the frequency of that communication that's sending out. And it looks at what kind of patterns there are, and so now we have a fingerprint of that device.
And it's amazing what it can discover from there. It not only can discover whether it's a Windows machine or Linux machine, but also what distro it is — not only what distro, but what version of distro it is — just by its unique pattern of how it can communicate, and what ports are open, and whatever else it's measuring.
When we're setting up vulnerability scanning, we're going to have to decide whether we want to do active or passive scanning. Active would be a scanner that's actively looking for devices. Going out and doing a ping to find those devices would be an example of that; testing out the different ports to see what's open would be an example of that.
Now passive would mean that it's not doing the actual ping, it's not doing the actual port scan, it's not actually testing out those individual ports, but instead it's listening. So maybe what we're doing is replicating the traffic to our vulnerability scanner, and that vulnerability scanner is listening for traffic patterns. And now what it does is it determines, well, this IP address is live because it receives communication that maybe it's going out to the internet, or maybe it's going to another device on the network, and this receives that communication, and now it knows that IP address is live. Same thing with the ports: well, what is it communicating across? Well, if it's replying back to another device with https traffic, then maybe it knows now that port 80 is open on this device. So it can passively sense the different traffic that's happening on this device to get that fingerprint.
Doing an active scan can discover more on the network, but also put the device at risk of being discovered itself. And so by actively going out and pinging things, then this device goes on the map of all the other devices, which we may or may not want. So doing a passive scan makes it a little more stealth.
If we are doing active scans, another consideration is are we going to do credentialed or non-credentialed, and you're going to get different results depending on what you choose.
For instance, let's say we have scanning software and we're scanning this machine right here, and maybe on this machine we have port 443 and a web app that's up and running on it. This web app maybe has a way to log into it. Now if it's non-credentialed, it's not going to log into it, it's just testing it from the outside as if there is a hacker trying to hack that doesn't have credentials. And what are the vulnerabilities, what is the assessment at that point in time? The results of that is just going to be what is the attack surface from somebody who's not logged in and not trusted by the machine.
But then we could also give them credentials, could add credentials onto the scanning software, where then it's going to actually log into the app and then start scanning from this credential standpoint. There even could be, we could be testing multiple credentials. Maybe there's different levels, maybe there's a user level and an admin level, and we want to test to see what a user level and admin level would have access to through this application, this web application. So maybe it tests first of all this user level and sees what it can get to and if there's vulnerabilities from that perspective, and then from an admin level, and what is the vulnerabilities from that level. So we could be actually using multiple credentials in that case.
Most of what we talked about so far is really more agentless. That is, this is the vulnerability scanner and it's scanning this device; even if it's logging into the machine, into the app, that is an example of being agentless.
But maybe we want to discover more, and so what we do is we install an agent on this machine, and then the scanner then is communicating with that agent, and that agent does a lot of local scanning, and the agent will report back to the server and let the server know what's happening on the actual machine. So that would be an agent based.
Essentially, when we're configuring all of this, one of the considerations is going to be the sensitivity level. We want to discover all of the vulnerabilities on our network, but we also don't want to be disruptive. And so there's this balance between being disruptive and really just making sure we're doing a really thorough job.
Here's what I mean by that. Let's say all of our network here — this looks like a very small network, but let's say it's a much larger network. Let's say we have a 10.0.0.0/8 network. And if you know much about networking, this is a huge network to scan; we're talking about millions of addresses here. It's quite crazy. And not only that, but let's say we want to scan, when we discover an IP address, we want to discover every port on there. And so the ports range from 0 to 65,536, or some subset of that. So maybe we're scanning just a huge amount of ports with this. So when we find a live machine, then we're going to scan for what services are on those ports.
And so this ends up being a huge scan, is what I'm getting to — that we're going to be testing everything out. Well, we're going to generate a lot of traffic with that. This machine right here is going to be very active for a long period of time, and that's going to eat up a lot of resources. And so we might want to choose what sensitivity level we have with this, of what we're scanning.
There are different ways to kind of be able to shape this. For instance, we can use things like templates. Templates allow us to really zero a little more down into what is the scope, and what are we scanning, and how are we scanning for it.
So as an example of this, if we discover a machine on this network, what we might do is we might scan some of the more popular port ranges here, and like the more critical ones that we deem as being critical. Maybe it discovers this is a Linux machine and maybe we have a Linux template, or maybe it discovers a Windows machine and we have a Windows template. So templates are a way to really zero in on what our settings are going to be and what it is that we're going to scan. So it's a great way to be able to kind of limit how intrusive we are on this network.
One thing we're going to want to scope in all of this is our critical infrastructure, things like operational technology, industrial control systems, supervisor control data and acquisition, or SCADA systems. One of the reasons for this is because these often get overlooked, and so there are a lot of security concerns around these type of devices.
Let's just see a couple examples of what this might look like. One is your HVAC system. Your HVAC system is an industrial control system that has this communication that goes back and forth. There's something that senses the heat, there's something that turns on and off the HVAC system, there's something that opens baffles up and or closes them depending on which zones you want to heat or cool down. And so that would be an example of a system that is often overlooked. But if it's overlooked and it's on the network, that opens us up for vulnerabilities, because now that's a system that people can get into and then take control of, and now they have access to the rest of the network. And there is a lot of documented cases of that exactly happening, big cases.
There's also the SCADA system, so the supervisor control and data acquisition. This is what runs factory floors, and there's these robots that carry out some sort of functions, but they communicate to the rest of the network. And so here again are systems that have computing components to it that sometimes get overlooked, that could cause devastating effects on the network if it was ever compromised.
Now the thing is that when we're scanning our network and we're looking for vulnerabilities, we could just throw everything at it. Number one, that can be a lot of data, and number two, it could be a lot of traffic, and there could be a lot of performance concerns about it. So let's talk about some other considerations when it comes to setting up these different settings.
Now, I was a director at a SaaS company, and we had a web application that was accessible from the outside world. This is not our network diagram — it looked quite a bit different than this, it was way more secure than what I've got right here — but we're just going to use this as an example. Now the thing is that I would hire third-party entities to come in and do vulnerability scanning and pen testing. And the thing is, if they are doing pen testing on our live environment and they're actively looking for things that could really bring it down, there could be some real performance hits, and that's affecting our end users, and so that could be really problematic.
So there's a lot of considerations that we have around operations of when we're doing the scanning, and what we're doing the scanning on, and how in-depth the scanning is, and the performance there are for our end users. Even if you're not a SaaS company, you have users internal on your network — business users, employees, stakeholders that are using your network — and you don't want to impact their performance and their experience.
So some considerations: maybe we are having somebody external doing some scanning on our systems, and we have some bandwidth limitations. Well, that would be a concern about filling up that bandwidth there. So what we may do is we may ask them to limit how much bandwidth, by either not doing all of the tests all at once but kind of staggering those — that would be one example — or just have bandwidth limitations put on what they're scanning and how they're being scanned, to limit how much flow of traffic is happening at any given time.
One of the things that we could do is really pay attention to the scheduling of these scans. For instance, the SaaS company that I worked for, when we'd have our scanning software and our pen testing, when we had things operational, there are certain blocks of time we really wanted to be sensitive to our users. And we had international users, and so we had to be really concerned about other time zones as well. So let's say we had this 20 hour block of time that we need to be really careful, and this 4 hour block of time where really no one was on during that time. So we would schedule a lot of our maintenance and a lot of our scans and a lot of our pen testing during this block of time. So that would be, from a scheduling perspective, how we can kind of work with that, of when we do our scans and when we're going to impact any kind of performance related scans.
Another thing we could do is something called query throttling. Query is essentially, it's kind of like a question we're asking a server, questions we're asking them to pull data, let's say. And so this, let's say, is a database right here, and we're pulling data from that database. Well, one of the things that I required my users to do is not pull data during certain periods of time, or if they were going to pull data, to throttle that query and make sure that they didn't query too much at any given time, and do it in maybe chunks of querying, so that way it didn't overtax this system and impact the rest of our users.
One other consideration that we need to have is how the network is segmented. A lot of times what we have is we have a segmented network — or most of the time, I'd say if any kind of size of business, you're going to have VLANs, you're going to have maybe different sites, you're going to have maybe different environments — and you're going to want to take that all into consideration when you're doing these scans, of how you're going to scan all of these different segments within your network.
Ultimately there's a lot of considerations here, and setting up these different settings and the different considerations of how we do the configuration is going to be an important part of your vulnerability scanning.
TechKnowSurge builds IT and cybersecurity professionals through hands-on, concept-first training built around real understanding — not memorization. Free interactive tools, structured programs, and 25+ years of real-world experience, all in one place.
Explore free tools and programs →