PCI DSS Compliance Vulnerabilities Found WebGUI
-
I created a WAN rule to allow Clover Security subnets to run the scans. Clover Security stated that I had to open the firewall to their subnets so they could run the internal scans. What can I do differently to improve this situation?
-
@firewalljunky said in PCI DSS Compliance Vulnerabilities Found WebGUI:
Clover Security stated that I had to open the firewall to their subnets so they could run the internal scans. What can I do differently to improve this situation?
There is no such requirement - and to be honest it is in violation of the step 1 of the documentation..
Have them point out in the pci compliance documentation where it states that you need to modify your existing company policy to reduce your security policy to allow for such a scan. If these services are open to external or devices/vlan that pci is used on - then yes they would be in scope.
But there is nothing in the policy that says anything of the sort that you should lower your firewall rules to allow for such a scan of services that nothing in pci would ever have access to in the first place.. whole point of step 1 is building firewall configurations that isolate pci..
Show them your firewall policy - and yes you might have to scan again after any firewall changes to make sure you have not inadvertently exposed something to internet or pci that should not be exposed..
Your external rules that allow access to the pci stuff from the internet, should be modified to allow for their IPs to scan your pci stuff from the internet.. But unless you have by policy already your ssh or web gui to your firewall exposed to the public internet.. They should not be able to see such services - if they could you really pretty much failed step one of becoming pci compliant ;)
Same goes when they scan from the vlan your pci stuff resides on... The only location where you can access firewall services, should be from your management vlan, and should only be accessed via unique user Ids, and all access should be logged, etc.
If you can access your firewall services from anything other than your management vlan/pc(s) then your doing security wrong - and yes should fail pci.. I don't care if your ssh is version xyz and patched with all the latest and greatest.. That service and the web gui should only be accessible from your management vlan..
If those services are available from your pci vlans/devices or the internet - then yes they would need to meet security requirements for versions and patches. That why they should NOT be available via those networks - unless there is specific need for them to be to accomplish your pci stuff.
-
@johnpoz is correct. You should have a Management LAN (either a physically separate interface or a VLAN) for any access to the firewall itself (meaning the web GUI and any SSH connection). All other networks should be blocked from seeing the web GUI and accessing the firewall via SSH.
Your PCI DSS devices should all be isolated on their own internal network. Yours is the second recent post with this type of topic. Seems like maybe there is some misunderstanding. It would be natural to let the compliance scanner have relatively unfettered access to the network containing the PCI devices. And from that network they would scan for vulnerabilities, but only to devices normally exposed to that PCI network.
It is quite out of the norm for a compliance scanner to want total and complete unfettered access to your entire network unless that is specifically what you contracted with them for. It sounds like, from your description and that of the other recent poster, that the compliance scanner just wants you to totally disable the firewall ...
. -
It seems counterproductive to let them have unfettered access to everything. I will change the firewall rule to only let them have access to the credit card VLAN for the scan. That VLAN does not have access to the WebGUI. Does this seem reasonable?
-
@firewalljunky said in PCI DSS Compliance Vulnerabilities Found WebGUI:
It seems counterproductive to let them have unfettered access to everything. I will change the firewall rule to only let them have access to the credit card VLAN for the scan. That VLAN does not have access to the WebGUI. Does this seem reasonable?
Yes, that would be reasonable and expected.
-
Not really.. You should not be opening your pci vlan externally - for them to do an internal scan they should be placing a box on that vlan, or running software from one of your servers already in that vlan.
The only time rules should be modified is when you have your external pci rules locked down to only IPs that use your pci, say your stores or other locations for example.. In such a scenario those rules should be modified to allow the external scan to see your external pci services.. just like they were one of your stores or trusted sites.. This is done by just adding their provided scanning IPs to your existing rules that are setup for pci.
The time I could see altering internal rules would be if by your company policy you would not allow there device to actually be placed on your pci vlan(s).. If so then the vlan you do put their device on should have unfettered access to the vlan(s) your pci device sits on.. This is common setups where the pci vlan does not have outbound internet.. And their scanner needs to phone home... So you can place their scanner on a vlan that is allowed to talk outbound to the internet, etc.
edit: I should post this in the other thread as well.. The guidelines for ASV - no where in that document state that you should open up ports.. What is mentioned is dynamic blocking, ie IPS for example. This needs to be disabled while they are conducting their external scan for atleast their IPs..
https://www.pcisecuritystandards.org/documents/ASV_Program_Guide_v3.0.pdf
While goes over temp changes to prevent active filtering from messing with the scan.. It also clearly states that rules do not need to be modified. So if you do not allow access to ssh or http for example from the internet, or internally.. Those rules do not need to be altered to do the scan.
"temporary configuration changes are not required for systems that consistently block attack traffic"
-
Then I will delete the rule I created and run the scan. Thanks for all of the information.
-
It's like the people doing these scans have no clue to security, or what they are looking for to make sure the site is secure.. Prob never even read the requirements or guide for ASVs
This seems quite obvious to me
"Temporary configuration changes do not require that the scan customer “white list” or provide the ASV a higher level of network access. "
-
I agree 100%. It makes no sense to open things up for them when it should never be opened in the first place.
-
You can not on purpose block them, be that manually or with specific rules.. And any sort of automatic blocking could provide for false sense of security, and invalidate the scan..
But its like my shrimp analogy in the other thread. Hey I don't eat shrimp, last time I ate shrimp I got sick.. Why do you want me to eat shrimp? ;) No I am not going to eat that shrimp - because I could die! ;)
To take that further - the purpose of the scan is to find if shrimp is this food I am going to eat.. Not to put it in and see if I get sick ;)
BTW - I love shrimp and eat it all the time ;) Just an analogy that popped into my head..
-
That was hilarious! Thanks for the analogy.
-
Yeah their job is to look for shrimp in my food.. There is no reason for them to look in food I am never going to eat ;) Only the food I am going to eat..
Not their job to tell me there is shrimp in the house - you could die.. No I am not going to eat that shrimp... But hey you can check all the meals I am going to eat.. Pretty pointless to tell me there is shrimp in the freezer out in the garage.. I can not get into the garage freezer its locked, only my wife can get in there - she likes shrimp, and she doesn't get sick from it ;)
But you know what - you can keep checking my meals (3 month scans, and scans after changes) you know in case my wife makes a mistake and cooks something with shrimp in it ;)
You can check that its locked.. To validate only my wife can get in there, maybe she left it unlocked. But me and my buddy pci can not get in there - so no reason to give you the key so you can look inside to validate yes there is shrimp in there.. Even if the shrimp might be bad - doesn't matter.. We don't eat it anyway, nor does my pci buddy..
