TR Forums

Typically this is a Windows-related thing for businesses, but feel free to move this if it's more relevant elsewhere.

So I was wondering what people use for scanning for vulnerabilities when doing IT audits? Qualsys, Nessus, etc. And what methodology?

Here's the setup: We're looking into possibly replacing our existing intrusion detection/prevention vendor because they have a product that says our workstations are perfectly locked down but when we enable file and print sharing, we get tons of vulnerabilities. We'd looked into something like this for patch management of 3rd party applications like Acrobat Reader and JAVA; we have WSUS to take care of MS-related patches (mostly).

All the solutions we looked into required you to enable file and print sharing. However, we disable it because there's no need for workstations to share out anything and there's less a chance that they will be vulnerable to attacks from that vector if we just disable it entirely. That's the hope at least.

Anyway, we've been evaluating various products and some claim to scan workstations as long as they have AD credentials to log onto the local workstations but in the end it either doesn't work or there's some addendum later on saying, "oh yeah, we need F&P sharing enabled to install a local agent, scan, and then uninstall a local agent." I don't even care if we have to permanently install agents for vulnerability scanning, I just don't want to enable file and print sharing to get accurate scan results.

Now at some point in this process we had the epiphany that in all the years since we moved from Netware (and even before since we were using Windows workstations) not a single outside IT auditing/security firm or a state or federal IT audit team has EVER asked for us to enable file and print sharing before they ran vulnerability tests. These are the same entities who have asked for a domain login and to have our firewalls and IDS/IPS services whitelist their attempts to scan and penetrate our network externally.

So you'd think that you can't make the argument that they want a "true" test by not having us change our network for their scan since they already have us do that and have us give them the keys to the kingdom with a login. And many of the vulnerabilities found with the file and print sharing enabled are relevant since a user browsing to a malicious website could exploit those unpatched vulnerabilities. So it seems like that is something both 3rd party firms and fed/state people would care about.

I can't believe that we're the only ones to have come to this point. I mean, I'm cynical enough as it is--is an entire industry based on finding vulerabilities just half-assing it?

That's why I'm askin' y'all. Anyone doing things in a way that would make sense to the scenario I laid out? Anyone in auditing firms or government entities that could speak to these concerns? I believe the closest we've gotten for an answer is "well, do whatever you think your policy requires you to do in this situation." That was from a government person and really isn't much direction.

Coming from the gov't side here, I don't get to use scanning tools. All I'm allowed to do is to review the results of what other 3rd-party contractors have done. You see, in the financial examination world, we are simply not allowed to touch the institution's systems.

The 3rd party reports I read all use the common tools. Haven't seen anything new or novel.

There are a few different things you are talking about in the same post there.
Intrusion detection / Prevention and scanning is usually very separate entities where I come from, although they are all part of security in layers or defense in layers models. Then on top of that you have endpoint security which might have both patch management, FW, AV and IDS/IDP functionality wrapped under it.

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.

Unless you use a solution that will actually try to use an exploit that it has found to verify it, but that is pretty uncommon from scheduled scan solutions. Those kinds of deeper scanning tools, can also by themselves pretty much be a risk if not used correctly depending on the system. I've seen everything from firewalls to servers misbehave and crash badly from such things, even when used properly.

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.


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.

Aphasia wrote:

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:

Aphasia wrote:

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.

For vulnerability scanning, we use Tenable Nessus. Some auditors (3rd party, not actual regulators) I've worked with in the past use GFI LAN Guard, and it seems to perform much like Nessus. For patch management, we use a product from Shavlik (www.shavlik.com), which is now owned by VMware. The product was formerly called Net Chk Protect, but I think they call it VMware Protect or some such now. We have it installed on a WSUS Server VM. You can create a domain admin account for the service to run without requiring agents on all the clients you wish to scan. Be aware that it too requires things like WMI and Remote Registry as well as a couple of Windows Firewall rules on the clients you wish to scan. But it provides relatively blanket coverage for MS products and a ton of third party stuff (e.g., Chrome, Firefox, Adobe AIR/Flash/Reader, Java, Quick Time, iTunes, etc.).

Thanks for the heads up on the patch management piece. We were thinking of something like SCCM but hadn't gone too far down that road yet. Seen the GFI product, yeah.

VMWare licensing scares and confuses us. We use ESXi for a few things and in trying to figure out pricing for other products it was a pain. At one point we thought we had that "protect" product but they were just giving us a list of products we could buy if we wanted to rather than a list of what we were actually licensed for. Good times, that.

The licensing for this product is fairly simple: there is a license fee at X per server and Y per workstation. Then each one has a maintenance/support fee as well. Depending on the number of boxes you have to scan, it's actually priced very competitively, IMHO.

Scrotos wrote:

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.

Disclaimer: I'm not a "proper" IT pro, don't have a IT degree... but here is my take on it.
On top of using many of these commercial vulnerability scanners, using less reputable tools used by hackers can also yield a lot of useful information. But the problem is that almost no organization would allow the use of "shady" tools because of the massive amounts of problems it can have on the network like crashing firewalls, creating a vulnerability, and other unintended consequences, like a malware embedded in the tools themselves spreading through the network.

The most vulnerable factor in any network are the people using it, so on top of generating a ton of data for auditors, educating the workforce beyond the minimal automated training tools would be beneficial. But again, the problem is that most organizations don't want to spend the time or the money to do such a thing.

If anything, Nessus Vulnerability Scanner does have a decent reputation and is used by hackers as one of the tools to find vulnerabilities in a network. So hey, if hackers are using it, then it's gotta be good right? Haha... Metasploit is also a good, though it's for a slightly different purpose, but using Nessus and Metasploit together can be very powerful. If you are just looking to make that auditors happy then Nessus alone is probably the best choice.

If you are actually doing pen-testing, lots of those tools that are a bit shady might see some use, but there is also tons of legitimate tools with similar functionality without built-in pre-existing exploits, but a few of those have very large costs associated with them. For only scanning, Nessus is usually decent, and as you said, for actually trying out exploits, metasploit is good. Some of the more expensive tools integrate and automate a whole lot of functionality that you can otherwise do manually with similar and harder to use tools. A good starting point for people that just want to look at what's available should start with downloading backtrack/kali and go from there.

For the record, this is where my own knowledge starts to thin out. I've only been a bystander on pen-testing and forensics things. And since we have people infinitely way more qualified doing that, I hope to learn that in the future, but aren't doing it right now. What I have done is been involved with a fair bit of audits, although I'm only a CISSP and you usually have a few more specialized CISA or similar leading those, but I have been on the receiving side of audits more then I would want to and involved with designing networks/security solutions that was being audited.

Scrotos wrote:

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.

I actually haven't, the scan's we did was as part of a larger service and were all non-credentialed. Only tested the credentialed scans in lab environment and don't remember the details about that. That was several years ago so I don't know how much Nessus changed since then either.

But my opinion is that the workstation itself should be tested as it is configured in use as much as you can, especially if doing a non credentialed scan. If you do a credentialed scan, you really have to look both at how the product does it, which tests you perform how your normal configuration would handle it with and without the services enabled vs. disabled. That is why auditing from a technical standpoint really isn't a fully automated solution from my POV. Any decent auditor should take note of if you actually are testing on a different configuration from what you actually run with. And this is also why people need somebody qualified to determine which of the things that turn up in the report might still be considered an issue after you default back to your standard configuration. Or mitigate any other found things.

If you are testing a workstations ability online to withstand a particular set of vulnerabilities then having the network interfere would be a bad thing since it could leave holes as I said before. But of course, that is dependent on the conditions of the test. Are you considering that any form of use of said vulnerability might be used from the same lan-segment, vs. another segment through the firewall. In the second case there's definitely a value of also running a test with the firewall intact as it would be in production.

That is why having an agent locally on the platform is a good solution to certain problem scenarios that might otherwise arise from running too much remotely. For example, Scanning without having wmi/file print sharing enabled if you don't use it in your platform. If you really need to do credentialed scan it might be possible to customize a GPO or similar that would enable the things you need. It might just be that file/print sharing actually enables all of those services, beyond some extras on top that you don't know. Many security products, both end-point solutions and firewalls often integrated with AD. And some of those are "said" to require administrative privileges on the domain, which for most people is actually ludicrous, but when you actually look at the things needed, there is almost ALWAYS knowledgebase articles oh what is really needed and how to customize the implementations.

Cisco ACS for instance need some privileges to be able to create it's own machine objects in the AD when doing integration. That can be worked around by pre-creating them, then having temporary rights for certain things. Checkpoint firewalls also "need" administrative access, or rather, they subscribe to security log events via WMI. Trend has similar integrations for some of their products, etc.

If you can master it, here's another great Linux based kit: http://www.backtrack-linux.org/

One of our linux fans was trying Backtrack a while ago but he left. I'll take a looksee. The guy who has been doing the main research is gone for a week to drink himself into a stupor and forget as much of this stuff as he can.

Pagey - lol - nice way of saying TLDR

Also Scrotos - if the pentesting/scanning oriented Backtrack/Kali dont satisfy your curiosity you can also play with the forensics oriented distribution Helix.

We have some PCI compliance guidlines that we're looking into at my work. It might get implemented in a few months. The product 'they', and 'they' meaning the business office lady taking on the project, want to use is called IdentidyFinder, http://www.identityfinder.com/us/HowItWorks/Technology. It's not a Winders security patch thing, for that we just use spiceworks and WSUS, but more of a data visibility tool. These are internally run and don't require front door access. If a company wanted that kind of access, tell them they're nuts and just give them VPN and an AD account. Or if you're a little sadistic, give them a modem they can dial into.

As for the IPS/IDS, unless you have a lot of them, they generally are pretty passive and not very visible. We're scraping by with three layers, IPS, Firewall, and SEP.

drsauced wrote:

Or if you're a little sadistic, give them a modem they can dial into.

And I'll then check the logs to see who requested modem access, who verified the identity of the requester, who authorized the access, and who turned off the modem when the requested access job was complete. If it's not all in the logs, expect a criticism in the Report of Examination.

Pagey works/has worked for a bank. He knows the drill.

[/day job]