Protect your scanning credentials with defense in depth

A common objection I hear to scanning systems with credentials is the fear of that account getting compromised. In this blog post, I will talk about ways to mitigate that risk using defense in depth. I will also explain why scanning with credentials is itself a vital component of defense in depth.

Set up alerts on your scan credentials

The first and most cost effective option is to set up alerting. You know the IP addresses of all of your scanners. You know what accounts they are going to be using for scanning. Use a dedicated service account, not your own credentials. If you see any login activity with one of those accounts you use for authenticated scans coming from any other IP address, your SIEM should be alerting. Then your SOC can intervene.

This may sound familiar to regular readers of this blog, as I recommend the SIEM as a mitigation or compensating control for unpatchable curl vulnerabilities as well.

This is also a compensating control for scanning with administrative credentials. You need to scan with credentials that are administrative in nature. Otherwise, your vulnerability scanner can’t see what your remediators can see, and it can’t give relevant advice to your remediators. Your remediators need admin credentials to do their job effectively. So does your vulnerability scanner. Sometimes least privilege means local administrator and sudo rights. Least privilege isn’t about providing the least privilege possible. Effective least privilege provides the least privilege required to do the job well, and then ensures controls are in place to remain secure.

Log on restrictions to protect scanning credentials

Active Directory has the ability to restrict what time an account is allowed to log in, and, if I am remembering correctly, what IP addresses it can log in from. I think restricting the login hours of your scanner account causes more problems than it solves, but if you don’t have any other options, this security control gives some additional defense in depth.

Use password rotation

Tools like Cyber-Ark can change the passwords on accounts on a recurring basis. This means in the event of the account getting compromised, whoever gets the password has less than 30 minutes to make any use of it. Depending on your scanner and how the integration with Cyber-Ark works, Cyber-Ark can also pass the proper credentials for any given machine, reducing the number of login failures your vulnerability scanning creates. This is super helpful when you have multiple domains, which frequently can be problematic to scan.

Integrating your vulnerability scanner with Cyber-Ark is worth the effort. If you also have alerting, and there is a domain admin account in the same tool that the SOC can use, that means they can intervene and lock the account as soon as they see the alert. Furthermore, now they also know there is a bad guy on your network, and they know what machine they are on, so they can begin the incident response process.

Your vulnerability scanner account is self-protecting

Last but far from least, your vulnerability scanner account is a compensating control for itself. Think about how an account can get compromised. A bad guy has to be sitting on your network. How does a bad guy get into your network in the first place? By exploiting vulnerabilities. If you are finding vulnerabilities and fixing them, that stops the main vector bad guys used to get in to your network. It forces them to use social engineering instead.

Defeatists will stop there, but social engineering is noticeably less effective as exploiting vulnerabilities. Back when I was an ace remediator, fixing 800,000 vulnerabilities with an MTTR of 30 days, we had one incident in four years. That incident was due to social engineering. And at my final corporate security job, before I jumped into the vendor space, I nearly worked myself out of a job. Our network wasn’t perfectly clean, but it was as clean as it could get. I wrote a risk acceptance for a CVSS 4 on internal TLS. Virtually all of the alerts I investigated turned out to be external drive-by attacks bouncing off our network. I didn’t leave that job because I was overworked. I left because I was bored.

And when something does get through, your EDR tool can take over. An honest EDR vendor will tell you their protections are much less effective if you don’t patch.

Alternatives to credentialed scanning

Still not sold? Use agents to get the benefits of authenticated scanning without needing credentials. An agent sitting on the system is able to retrieve all of the data that a credentialed scan would. However, you need to resist the temptation to play your security tools out of position. Most of the popular EDR tools now offer very basic vulnerability scanning capabilities. But the data they gather contains far less detail than what you will get from a dedicated vulnerability scanning tool like Nessus. If you have a Gartner subscription, they have a report about vulnerability scanning with EDR tools, so you don’t have to take my word for it. You can go see what Gartner says.

But using an agent rather than scanning over the network means far fewer credentials flying around over the wire. You will still need to scan your network devices. And recent events in the Cisco universe only highlight the importance of scanning your networking instructure, not just the systems plugged into the network.

Using agents reduces the risk. Then you can put other controls in place to protect the scanning accounts that you need to use on devices that can’t run agents.

In some organizations, agents are a dirty word, but at the very least, use them on your domain controllers. Then you don’t have to scan with a domain admin account, and can just use a local admin account to scan your member systems.