Where do you put vulnerability assessment (VA) scanners in a very distributed network? Consider a scenario where a company has a presence in North America, Europe, and South Asia. As part of its annual penetration testing environment, the company wants to conduct vulnerability assessment at all its demilitarized zones (DMZ). North America may have DMZs in Delaware and Texas, Europe may have only one DMZ in London while South Asia may have in Bangalore, Calcutta, and Hyderabad.
There are some architects who believe that the VA scanners should be caged within each DMZ while others who think a VA scanner can be placed anywhere other than the untrusted zone and a firewall rule that allows only the VA scanner access all of the DMZs. While there are benefits for both extremes, we need to prepare a strategy balancing cost and benefits. The time constraint does not permit to conduct the VA scan in phases (DMZ by DMZ).
There are four options:
1. A Scanner Per DMZ
Here a scanner is placed in each of the DMZ of the corporate. From a security risk perspective, this is the best strategy. However, is it cost effective? It may not be.
2. A Scanner in one DMZ Per Site
How about placing a scanner at one of the DMZ for each site? This will reduce the cost the scanner. However, firewalls made need to be open between neighbouring DMZs so that scanner has access to all the DMZ in a site. It’s fine as long as the rest of the DMZs trust the DMZ where the scanner is located. There is always the risk of a hacker compromising the scanner and getting access to neighbouring DMZ. However, there is no need to open traffic to the trusted zones.
3. A Scanner in Trusted Zone Per Site
Another way is to put the scanner in the trusted zone of each site and open the firewall for the scanner to each DMZ in the site. A hacker needs to compromise the DMZ and need access to the trusted zone before messing up with the scanner. It’s as good as compromising other systems in the trusted zone. Here is no need to open traffic between the DMZs.
4. A Scanner in the Corporate Network Cloud
What about having just one scanner in the corporate network cloud and it accessing all of the DMZs? If the sites are located very far, there could be latency issues as well as issues with the performance of the scanner itself. If the scanner gets compromised, then a hacker may be able to get access to all of the DMZs but not beyond that.
Shaheen,
If you are only using one VA Scanner from a central office, my advice would be a management VLAN or DMZ that has access to all subnets/VLANs/DMZs of interest. Typically, physically separated environments would have remote scanners to keep the network traffic utilization at a minimum; however this solutions is for Enterprises and costs more to implement. Remote VA scanners would have to be place where it can both scan all remote subnets including DMZs and able to communicate with the central VA server. The Remote scanners are used for scanning purposes only and does not store the vulnerability data locally on the remote scanner; however, transfers the data encrypted back to a central VA management server for reporting and disposition.
Carl
Shaheen,
This is the classic security/performance/cost model which has to be balanced in order to maximize the most adequate results. For instance, your first scenario “1) a scanner per DMZ” is the most secure, and should yield the best performance from a network latency standpoint. However, this model is cost inhibitive to say the least. There are varying levels of compromise until we get to your last model “4) a scanner in the corporate network cloud” which is obviously more cost effective as there is only one scanner to maintain. However, this model may yield insufficient performance gains based on geographic network latency. The real answer is to understand the network topology that you are dealing with and design accordingly.
Inevitably, all models will require a constant level of hardening through effective patching and update management, along with configuration management to ensure that items such as defaults are not left unattended either application or system-wide. This is applicable to whatever solution you choose; either a hardware (appliance) or software deployment.
Depending on your intentions, scan data can typically be stored locally or offloaded to a database for further correlation and reporting management. Although, ensure that you address any regulatory requirements if your scan data pulls vulnerability checks that could potentially render sensitive data within it’s results. Overall, the technical method is rather straight forward once you dig deep and understand the environment; however, most likely politics will muddy the waters. Hope this helps.
–Chris Patten
It really boils down to the objectives of your scan.
Do you want to have the same view an external attacker would have? If so, then the only requirement would be for the scanner to be outside your network, accessing your DMZ just like any public, unprivileged host.
If you are looking for more visibility, i.e potential holes in services that are not visible to hosts outside the DMZ, then the scanner would have to be on the same segment as those hosts (assuming the DMZ is flat and there are no layer-3 devices filtering inter-node traffic in the DMZ). An easier way of achieving similar visibility (minus the pain of placing scanners in multiple DMZ segments, or having a single scanner in the trusted zone accessing all DMZs) would be to still have the scanner external to the DMZ, but granting it’s public IP certain “privileges” that are not normally accessible by any other IP outside the firewall.
I don’t worry about scanner compromise no more than I worry about the compromise of any server in general; it has to be locked down in the same fashion, and access to it should be rigorously monitored and allowed only from trusted public IPs (unless you have a secure out-of-band management interface that you can access from the inside and that can’t lead back into the trusted network).
With regards to latency, you can always adjust the scan aggressiveness taking into account delays that you would normally encounter depending on the region being scanned (tune the timeouts & number of simultaneous host scans).
Shaheen,
I would look to #3 or #4. I would not consider the security concerns to be driving factors in the decision, because I would consider #3 and #4 to be adequate. Rather, I would look to cost and managerial issues when making a decision. We need to punch holes in our firewalls anyway in order manage the DMZ machines, so adding a few more holes for VA should not be so important.
In my opinion, the future of the DMZ lies in device simplicity. I am in favor of removing general purpose machines from the DMZ whenever possible, and then replacing them with hardened reverse proxy devices. I guess you know from the time that we worked together, that I am a big fan of reverse proxies. I think that Web Application Firewalls and XML Firewall devices are wonderful. As opposed to deploying a large number of general purpose machines in a DMZ that each need VA, would we be more secure with just a few hardened DMZ appliances?
Glenn
Unfortunately I’ve had the opportunity of dealing with this type of situation and Patten is 100% correct on this being the cost/performance/security model.
I’m assuming this isn’t a PCI requirement, as you are required for external scans to be 3rd party, but can do internal scans yourself.
I’m somewhat of a firm believer that while the external scans are important, they are by far the easiest to implement due to one device to many. I do personally believe that internal scans are very important. If a hacker can make it in much of the time it is free game on lets say a botnet cloud once he gets in. While many people harden the exterior they seen to forget most of the vulnerabilities internally. If you do get a 0day hacker, your external vulnerability scanning is hit and miss, it’s always a timing issue. If you only have the external scans and get exploited from a 0day, you might not notice the internal threat until it’s too late. This is obviously mitigated by devices that do profiling such as a Juniper IDP that detects internal anomalies. Your “internal” scanner though might not catch it immediately but it will see it after the vulnerabilities get posted a few days later which might be sufficient. I find 0day anomaly scanners to be very inconsistent in general anyway. While most of the vulnerability scanners are solid, you might have to wait a few days due to the signature discovery delay to be found. It really depends on network infrastructure and if you are utilizing profiling/IPS internally.
For remote sites I personally would like a scanner internally and not in the DMZ. I would utilize a scanner for DMZ things remotely, like from your base office. Imo, it doesn’t really need to be placed physically inside the remote sites DMZ’s. Theoretically what a hacker was seeing you could implement a scan remotely to see his perceptive on the situation – granted this isn’t ideal, but in theory people should not be able to make it down once they compromise the DMZ due to natting and a firewall in between internal resources . Your internal scanner however protects more things because it can find things after the initial hack, where your external scanner might not. Ideally you would have both a internal/external scanner for every site (yes we can all dream can’t we).
Whatever you do don’t bridge the streams (awesome ghostbusters reference I patted myself on the back as I typed this one handed). I’ve seen instances of people slapping a qualys with one port in the DMZ and one port internally. I’m a firm believer with physically seperating as much as possible DMZ/internal, unless you are really moving towards a cohesive model with DLP implemented (if you are not familiar with this, it’s the “new” buzz word of not having a perimeter but having overall security within the realm, it does away with layers models) personally I don’t think we are at that point with our security technologies. I also see alot of situations where people are using vlan, or other logical boundaries from DMZ to internal, especially with VM farms. It’s always a good rule of thumb that any backplane can usually be compromised if the hacker knows what they are doing, and it is completely out of our control.
At our current stage I think it becomes an issue on what your layers look like. Are your remote offices just logically vlaned from DMZ to internal? If that is the case, then having a scanner on multiple vlans is not that big of an issue, as they are considered hardened devices and you probably have less “hardened” devices. A internal scanner while doing the external scans from the home office would be more ideal imo though, and these obviously mitigated by good IPS/IDP as well. It really depends on how sensitive your data is at the remote sites as well.
There are some options from a company called Outpost24 based in Sweden. They could supply two products. The first would be Outscan which scans from the outside and HIAB (Hacker in a Box) sits inside your network so can scan internally. I can confirm they are reasonably priced. The nice feature is they are third party (good for audit/compliance) but you manage everything including the ip ranges and scheduling so no surprising alerts from IDS/IPS systems. Take a look here http://www.outpost24.com and drop me a message if you would like a contact name who can discuss pricing. Oh by the way I am in no way affiliated with this company or product and receive nothing either cash or otherwise from recommending them.
Cheers
Jeff
Thank you all for your suggestions and great advices. I believe option 3 is the most favored one. Thanks once again for your participation in this discussion.