Most of the scanning solutions I've seen, I've used Nessus a fair bit, we also looked at Qualys and some other tools, and most can usually do either an authenticated (blind) scan according to the latest definitions, or do an scan using credentials where they actually look at things from within. The problem is that depending on your infrastructure, network segmentation, endpoint security / local firewalls these answers might or might not constitute a vulnerability and a risk, which is why you need people that can pretty much interpretate the raw info into something useful.
But I have never heard of them needing file-print sharing enabled since they usually use WMI or similar when using authenticated scans for checking up on the local versions according to either signatures or known problems associated with those. As for patch management or other agents, I don't have a clue. But it sounds darn odd. And if you have the ability to via patch management permanently install a local agent, then it definitely shouldn't need any file/print sharing enabled.
And that is what we thought, too, but even Nessus gets to a point where it talks about WMI and all that jazz and also has a "btw, you also have to enable file and print sharing." Actually, I think this is the relevant part:1. The WMI service must be enabled on the target.
2. The Remote Registry service must be enabled (it is disabled by default). It can be enabled manually for continuing audits, either by an administrator or by Nessus. Using plugins 42897 and 42898, Nessus can enable the service just for the duration of the scan.
3. File & Printer Sharing must be enabled in the target’s network configuration.
4. Ports 139 and 445 must be open between the Nessus scanner and the target.
5. An SMB account must be used that has local administrator rights on the target.
You may be required to change the Windows local security policies or they could block access or inherent permissions. A common policy that will affect credentialed scans is found under:
Then you also have the problem, what are you actually doing an audit for. The premises for the test pretty much tells you how much you want to include/exclude and part of the methodology you might want to use. Infrastructure as well as hosts, external/internal, blind scan or various inside scenarios, how much pre-existing info are you allowed, will it be a known or unknown test for operations. Is it a clean slate health check or are you actually auditing towards a pre-existing baseline or policy.
If it's actually looking at a full blind test, or "true" test, then allowing firewall would invalidate that test pretty quickly. If you are looking to secure workstations and servers, you usually don't want to even try to include infrastructure in that test, and thus whitelist and take infrastructure out of the equation in it's entirety, as much as they can anyway. The product is that it could otherwise be a decent chance that it could leave servers open with vulnerabilities because the current rule set doesn't allow the tool to do it's job, and later on somebody makes a change to the rule set and boom, server network infected.
Most of the time we are doing an audit so that Ned doesn't write us up. Get enough of those and the state or fed can shut you down. Granted, you'd have to have massive problems and ignore the auditor findings for a few cycles, but it's a good motivation.
And like he said, to provide reams of paperwork to the auditors so they can audit the audits.
Basically we just want to be as secure as possible in the limits that the C-level people give us, i.e. we'd love to have a whitelist for allowed websites to go to for work but that was a non-starter for all the blokes who want to go to ESPN or NFL.COM. We thought
getting a clean bill of health with our monthly scans and 3rd party scans meant we were doing well but one day we had a machine with file and print sharing on and it popped up a few hundred vulnerabilities where before there were none.
We started looking into what happened and that's when we realized that even our existing system, which claims to work with just AD credentials to scan machines, didn't work unless you enabled file and print sharing. Since a user accessing a website is already getting past file and print sharing, we'd want to know what vulnerabilites really are accessible to the world. We've already found a few MS updates that WSUS didn't provide, for example.
Our last fed auditor actually sat down with us and had us walk him through our scanning methodology to see single workstation results. What will he say when we give him our results showing how great we are and then he has us do a test with file and print sharing enabled and the results come back looking massively bad?
So you're saying that's why the firewall is set to let the 3rd party people do their tests. Sure, ok. But by that token the workstations should be under the same "open" policy too. I don't see that as a good idea for our overall network security in general. And it wouldn't be an issue if Nessus or Qualsys or the other products we looked at actually gave the proper results without file and printing enabled.
You're far more familiar with Nessus than we are. Have you ever tried running a test with a machine both with file and print sharing enabled and with it disabled? We found differences in the results. And hell, the instructions say to enable it anyway.