Triaging High Publicity Vulnerabilities with Nucleus and Two Scanners
We have a couple of Nucleus customers doing something innovative – and given the amount of pain that Log4J is causing everyone, we want to share their wisdom with the rest of the security community. This isn’t the first vulnerability to need massive triage at massive scale and desperately needs prioritization, and it won’t be the last. We want to share their approach with you to find systems in various states of mitigation so you can prioritize the unmitigated systems first.
Theoretically this is something you can do without Nucleus. If that’s the approach you take, we’re glad we were able to help you. We think Nucleus makes this a little bit simpler, but this isn’t the time for sales pitches. This is the time to solve problems.
Configure a Red Scanner and a Blue Scanner
I have deployed vulnerability scanners in probably 50 different companies at this point in my career. And I told every single one of those companies, whether the actual number was 49 or 51, to make sure they did one thing if they did nothing else: whitelist their scanner IP addresses in all of their security appliances and products. The reason for whitelisting is that a network-based scanner cannot find all of your vulnerabilities if they have other security products interfering with their processing, so you will get false negatives if you don’t whitelist the scanner.
That’s best practice.
We’re going to go against best practice in this next step. For this type of triage, you need a blue (friendly) scanner and a red (unfriendly) scanner. You can use two different scanner solutions for this approach, or you can use your normal scanner solution. An increasing number of companies have two different vulnerability scanners from two vendors; if that’s the case, simply designate one as the red scanner and one as the blue scanner.
If one of your solutions is agent based, it’s a blue scanner by definition. Agent based scans work around all of those security measures: that’s why they’re notably more accurate. You can also use a network based scanner for your blue scanner; just make sure you whitelist it everywhere for best accuracy.
For your red scanner, make sure your network-based scan appliances are not whitelisted in your firewalls, IPS, anti-virus, endpoint protection, and any other security products you have. The red scanner is going to test your network defenses. These scans, especially the unauthenticated ones, look very much like exploit activity, so those security products’ job is to block them. We want the false negatives in this case.
If you only have one vulnerability scanner, spin up a scan appliance and don’t whitelist it. Designate that scan appliance as your red scanner. Run your blue scans through your regular, whitelisted scan appliances, and your red scans through your red scanner appliance.
The red scanner/blue scanner terminology and definitions are used throughout this blog post.
Keeping Your Red Scanner from DoSing Your Network
There’s a reason besides accuracy that the scanner vendors tell you to whitelist your scanners and all of your other security appliances. When those scan appliances throw 50,000 checks against every single IP address on your network, that can overwhelm your other security products. The newest products running on the newest hardware might be able to handle it. But that one firewall running on 15-year-old hardware that you haven’t gotten around to replacing yet? Don’t worry, everyone else has at least one of those too. Your firewall hardware that’s almost old enough to get a driver’s license probably won’t handle that barrage of hostile-looking traffic so well.
To keep the load manageable, and to speed up the scan, configure a scan profile that only checks for the vulnerability that you are concerned about. In the case of Log4J, it’s probably CVE-2021-44228, CVE-2021-45046, and CVE-2021-4104. Your scanner may have one ID that covers all three CVEs, one for each, or some combination in between. Check your scanner vendor’s knowledge base to compile a list of IDs to scan for.
Now scan your network with your red scanner. Should you use authentication? It depends. You may need to try both with and without authentication to see if it makes a difference. An unauthenticated scan is more likely to get caught, but won’t find as much. If you want, and you have time, scan both with and without authentication and call the authenticated scan from your red scanner a purple scan.
Triaging Without Nucleus
If you are not a Nucleus customer, I recommend that you either scan your network with your blue scanner using that same scan profile, or if you already have recent scan results, export only the CVEs that you care about.
After your scan(s) and export complete, merge the files. Any system that shows up in the merged file only once has some amount of mitigation in place. Do not make the mistake of calling it fully mitigated, because you haven’t thrown every possible exploit at it. But there is a nonzero chance that whatever interfered with your scan will also interfere with attacker exploits. They have some level of protection.
Systems that show up more than once in the report are sitting ducks. They are the ones that need immediate help. Your teams need to patch those systems first, and your SOC needs to monitor the hell out of them.
Triaging with Nucleus
If you are a Nucleus customer, thank you. Let me see if I can help you. Presumably whatever you want to use as a blue scanner is already reporting into Nucleus.
Run your red and/or purple scans with your red scanner. When the scan completes, export that scan in the data type that Nucleus supports. In the case of Tenable products, that will be .nessus format. In the case of OpenVAS, Qualys, Rapid7, or Retina, that will be XML format.
if you are using the same product as both your red and blue scanner, I recommend you chase the red scan with a normal scan, so you don’t overwrite findings in your scanner.
Inside Nucleus, navigate to Data Ingest > Import via File to import your red scan and your purple scan if you have one into Nucleus. Nucleus will detect that these scans were done with odd settings and will not overwrite normal findings from that same source. If you use a different product entirely as your blue scanner, no worries.
When the status next to your uploaded file gets a green check mark with the word “Success” next to it, it’s time to run a report. Navigate to Vulnerabilities > Active. Click Filter > CVE search and type the CVE you care about. When the list comes up, click Export > Excel (Detailed).
Load the export into Excel, and use pivot tables to find assets that show up more than once. The more times they show up, the less protected they are. Those least protected assets deserve the most attention from your remediation team and your SOC. Tend to those first, then work down the list. This won’t solve all of your problems, but this is a smart way to use your available tools to help alleviate some of the chaos.
Getting Even Fancier…
If you anticipate doing red and blue scanning a fair bit, you may want to set up a dedicated connector in Nucleus for your red scanner. The set-up specifics can vary a little from source to source; the general idea is to set up another Nucleus connector to whatever you are using as your red scanner, then import via scan, rather than asset tag or asset group as you normally would. Make sure you conduct your red scans with a specific scheduled scan, and then import that scan and only that scan with your dedicated red connector.
If I were a Nucleus customer setting this up for the long term, I’d strongly consider deploying a dedicated red scanner. If budget is a problem, the open-source OpenVAS scanner would be fine for this purpose. Having a dedicated red scanner eliminates the danger of comingling data between red and blue. Getting this done quickly enough to help with one specific emergency can be extremely difficult, but in the long term, it could be useful.
The advantage to conducting red scans on a dedicated connector is that you can use a Nucleus automation rule to put any assets coming in from that connector into a dedicated asset group called unmitigated. Then you will be able to quickly find systems of interest right in the Nucleus web UI by checking that unmitigated asset group. You could even use an asset processing rule dedicated to that connector to increase one or more of the risk attributes so those systems automatically score higher.