Vulnerability scanning is not a maybe, it must be a core part of your information security programme. It must also be a regular activity that is directly linked to the pace of change within your organisation. The thing is, many organisations just get a popular tool, choose some default settings and then scan away. When the scans come back and there are no High or Critical vulnerabilities the IT function breathes a sigh of relief and moves on with other more pressing work…but there are many reasons why this approach is going to get you into trouble. In this article, we’ll discuss three things you need to know when configuring and interpreting your scan results to make sure you don’t inadvertently give yourself a MASSIVE false sense of security!
As a precursor…why bother scanning for vulnerabilities at all?
The software you rely upon, whether developed yourself or by a third party, will invariably have multiple security vulnerabilities. The more complex the piece of software, the more lines of code. The more code, the higher the chances someone was rushed to push a feature into production that ultimately exposed the family jewels because no one did any regression testing or worse, the exposure was deliberate because the restrictive setting led to too many service desk tickets so the service desk engineer just disabled the control!
Software bugs are so commonplace we now affectionately have terms such as Patch Tuesday where all the major vendors push out their security patches – yes, EVERY Tuesday! You can even have a full-time career as a security researcher earning significant cash hunting for security bugs. If you identify a security vulnerability you could get yourself a six-figure Bug Bounty as a reward (but please stop bothering us about DMARC because the record is not set to quarantine or reject – if we have a record at all, we know!). The simple fact of the matter is your software will contain security vulnerabilities and you need to know that they exist so they can be fixed!
It’s worth pointing out that not all security vulnerabilities have security patches. Sometimes security researchers will tell software vendors they have vulnerabilities but the vendor ignores the warnings. Sometimes there is a delay between a security vulnerability discovery and a patch becoming available. In this timeframe, you are exposed. A hacker could thus take advantage of the window between a vendor becoming aware of a vulnerability and a patch becoming available. In this time, the hacker could create an exploit that uses the weakness the vulnerability creates to attack your organisation! At the same time you could apply other mitigating controls or carry out heightened monitoring…but you need to know what to look for! If you don’t know the vulnerability exists, you could be a sitting duck…and a blind duck at that!
But we’re just a little fish, why would anyone care about us?
The short answer is it doesn’t matter what size or type of fish you are. That’s not how hackers operate. Hackers write scripts that just search the entire Internet indiscriminately. They can just set a script going that literally goes through every single device connected to the Internet and identifies what vulnerabilities exist on your site. The script will then log all the collected data to a database. They can then put all those IP addresses or website addresses through free sites that enrich their data with other metadata such as headcount, industry, or market capitalisation. These days hackers can also scrape websites for your customers just by looking for a testimonials page. Now, hey presto, the hackers can just whack the output into Excel (they wouldn’t actually do this), apply the appropriate filters and off they go with a very specific set of targets linked to their objectives. If you are exposed to an exploitable vulnerability. If you have also boasted about signing a major financial services client…well you may be on someone’s hitlist! If you are linked to an organisation that has poor environmental credentials, linked to a specific country that doesn’t like dogs. You could be targeted. The hackers don’t know who you are. They don’t even care who you are. You’re just a means to a greater end!
The three things you need to know about vulnerability scanning
Hopefully, we’re all on the same page at this point that vulnerability scanning is a necessity. But as I mentioned in the opening paragraph what if you have a scanning tool and are just simply trusting the results? After all, you have bought this tool because it’s the best on the market and claims to update its vulnerability scanning engine quicker than anyone else. Your tool may be the best on the market, but it will only work effectively if it’s configured correctly. It will only act as an effective information security decision support tool if you as the end-user know how to interpret the tool’s output correctly. With this in mind, let’s look at three things that can help you get the best out of your vulnerability scanning.
Know your environment!
Before you scan a single host, you must understand the environment you are scanning. You should establish several hypotheses prior to your first scan. For example, you know that a specific server contains software that is vulnerable to Log4j. One of your hypotheses must be that the scan will pick this up. If it doesn’t you know something is wrong. You know you have three domain controllers so you will expect to see several ports open on these hosts. Maybe you believe you’re a totally Microsoft house and definitely don’t have any Linux so you can establish a hypothesis here too…then when a Linux distro pops up you can investigate and find it’s some kind of media server in a meeting room (remember when people used to meet in person). I could go on but to summarise it’s very hard to identify whether the scan is functioning properly if you don’t know what good should look like – good is not necessarily a clear scan but a scan that is accurate! One way to achieve this is to baseline scan results against your Asset Management register…you do have an asset management register don’t you…if not, please get one ASAP!
Configure the tool properly!
OK, so we now know what the output of our scan should look like in terms of the assets and vulnerabilities it should definitely expose. The next thing we need to know is how to configure the tool properly. As we are working in threes for this article, here are three common reasons scans don’t provide the correct results. The first is the scan range. If you’re not scanning the correct range of hosts/IPs then assets will get missed. Make sure you get IP ranges or host lists peer-reviewed to ensure the ranges are both complete and accurate. The second, and this trips up lots of people, is authentication. Scans can provide results in both authenticated and unauthenticated modes. The authenticated mode will however provide more accurate results and identify more vulnerabilities so a good practice is to run an authenticated scan. If, however, the authentication credentials are incorrect (or have expired) the scan will still run. There will just be an “information” alert to let you know authentication failed (more on this in the next section). The third issue is external to the vulnerability scanning tool. You must ensure the scanning tool can scan the environment as intended. That is to say, the correct ports/protocols across your network need to be enabled for the duration of the scan window. If the vulnerability scanner can’t access the intended hosts/IPs, it won’t provide you with an accurate output. As the saying goes “garbage in, garbage out” so before running a scan make sure you have your tool configured properly. As a bonus tip, keep a copy of your scan configurations in your IT Service Management Tool’s Knowledgebase and keep them updated as the environment changes.
ALWAYS read the Information Alerts!
So you have run your scan. Now it’s just a case of filtering for Critical and High-risk vulnerabilities, creating tickets for remediation in the service desk and you’re done…right? Whoa, there kidney bean!! There are a few other things you need to consider before reporting all is well to senior management. Before even looking at those Highs and Criticals we need to validate the scan operated correctly. Remember the hypotheses discussed above? They need to be validated. Were they all proved correct? If not, check the config, and the network access control rules, fix any issues and then rerun the scans. Next, go through the information section. Were there any authentication issues raised? If so, something is wrong. Fix the issue and then rerun the scans. Once any authentication issues have been ironed out, look at the rest of the information alerts. These alerts will tell you about what is happening in your environment that could be perfectly legitimate activity or could highlight something that is not supposed to be happening. For example, port 22 is open on a host. There should be no SFTP activity on that host so what is that doing there? Raise a ticket to find out. There are 10 hosts in that VNET/VPC (hey we’re all cloud now) and there should only be 8. What are the two other hosts doing there? Was that a proof of concept that hasn’t been shut down properly or is one of your IT Admins using the corporate network for their own side hustle? Raise a ticket to investigate. The hostname of a box doesn’t follow the standard naming convention – is it legit or has the network been compromised? Raise a…ok you get the drift. As you can see the information section of a scan report can be just as important (if not more so) than the items expressly marked as High or Critical. Why? Because the issues listed in the information section could be hiding a whole menagerie of High and Critical vulnerabilities that are context-driven. Port 22 is not a vulnerability if the box is an SFTP server but if it’s on the same box as your production database there is something seriously wrong with your setup!
Happy Scanning
The above list of considerations is by no means exhaustive – and we haven’t talked about plugins or how to conduct follow-up investigations – but the topics discussed are some of the key reasons why rookie security analysts miss things in scans and organisations get blindsided. The key takeaway is don’t blindly trust the output of automated scans. The more senior you are, the more likely you will just see the exception reporting. If you’re at CISO level, you may not see any of the raw output at all. You could be presented with a picture that all is rosy when things are anything but. Whatever level you are at, challenge downwards from time to time. Ask for the raw data, review the output and highlight where things are clearly not right. If you don’t have expertise in this area to provide effective challenge…get in touch, we can help!
About Fox Red Risk
Fox Red Risk is a boutique data protection and cybersecurity consultancy and Managed Security Service Provider which, amongst other things, helps client organisations with implementing control frameworks for resilience, data protection and information security risk management. Call us on 020 8242 6047 or contact us via the website to discuss your needs.
22301 22301:2019 article 28 awareness bcms BIA business continuity calculating risk change management ciso controller cybersecurity data breach data privacy Data Protection data protection by design data protection officer data protection service Data Subject Access Request DPO DSAR GDPR incident management information security leadership monitoring operational resilience Outsourced DPO Privacy processor risk risk appetite risk management ROI security security as a service small business strategic strategy Subject Access Request tools training transparency vciso virtual ciso
