There are multiple definitions of negative security, I am taking this phrase in this context as follows: When looking at a result of a scan report, we inverse the result, personally mark everything that has not been found as negative, and verify the security there.
Example Finding
We have one hundred hosts, and find a single type of vulnerability on all except one host. Per normal process the finding will be evaluated, checked, patched. In the above mentioned context of negative security, we are now checking that one host. Why does this vulnerability not appear there? Has someone manually patched it already, missing all others. Or is there some deeper issue on the system. Maybe the tool is missing, but should be there. All those scenarios are now starting to become something to think about, on that one system, that was not in the vulnerability report.
Disaster Example Report
Zero security issues detected. Nice. For the general mechanism this is perfect and we can move on with other high priority items. Let’s take a step back and view the report from another angle, is everything alright? Checking a few rows further down, 0 scanned hosts. Wait, what?
We have the best possible case of what this post wants to demonstrate. Even though everything looks in order, at least from the compliance and reporting perspective we are green, we are actually not sure the data basis we have built our report on, is correct. Maybe an important network rule was removed that explicitly allowed our scanner to access all systems. Another possibility is the hosts have implemented a new source restriction, forgetting the security tools. Or the tool system got migrated, a new IP address instead of re-assigning the old one. Configuration is in best cases in a code management repository and was reviewed, but better check there as well. And not to forget on the scanner directly, maybe the culprit is there. It does not need to be anyone’s fault this bit flipped, making the configuration file for all IPs to be scanned, setting a file termination character into one of those lines.
Fishing Report
You are scanning the internal 10.42.1.0/24 subnet from your scanner, but receive a report with some vulnerabilities, all matching the number of hosts running webservers, databases or related. Applying what we did above, you are checking the overall summary, and find 255 systems in the scan report. Thinking back at your computer science class, you remember a /24 subnet only has 254 valid addresses that can be used. This time, we have too many systems, how can it be? Maybe the network device is acting up?, but then why do we have valid reporting entries. You start digging, grepping through logs on the scanner, until you start checking internal documentations created by the operator team. You cannot find 10.42.1.0/24 anywhere, you do find single hosts of the scanned subnet, but you also find 10.42.1.0. Checking the debug logs of your scanner, indeed 10.42.1.0 up to 10.42.1.254 have been replying to your scanner probes. That is accounting for the 1 extra, but why is it there? You find in your authenticated scan logs, details on the network configuration: 10.42.0.0/23. Whatever the reason of this implementation, be it hacky internal splitting of the net and having given the other range to the security team only is something to cross check the first section is being scanned as well. Otherwise, the systems do not care being assigned the .0 IP address in the subnet, maybe neither should you, and what we thought we have found, has actually been a red herring, a non issue.
Conclusion
One should always cross check the existing inventory, scan configuration and reporting to actually match the expected number of systems all across the board. Be vary when only some and not all systems are receiving a vulnerability detection, even though you checked with engineering teams, and all systems are supposed to be having this installed.
Never stop questioning and critical thinking, but don’t go down the rabbit hole too deep, as sometimes, red herrings are floating all over the place. In the end, we are doing the best we can, with the limited time have been provided with. And don’t be discouraged if you bite into a herring from time to time, one might learn bits and pieces in the process, being able to spot them early on next time.