[PCI-DSS] 1.3.5 Restrict outbound traffic from the cardholder data environment to the Internet such that outbound traffic can only access IP addresses within the DMZ.
1.3.5 Verify that outbound traffic from the cardholder data environment to the Internet can only access IP addresses within the DMZ.
In my scenario, telesales staff enter credit card details into an internal web application. They also have email and web access on the same machines.
This point seems to suggest that I need a proxy server in a DMZ and that all email / web traffic must pass through the proxy server. I already have a UTM appliance that all Internal traffic passes through, is this enough, or do I really need to implement a DMZ and proxy server? I don’t see any benefit in doing this.
How can someone implement PCI requirement 1.3.5 in this case
I have done proper network segmentation where my app server lives behind 2 firewalls, separated by a DMZ area before connecting to the internet.
Public Internet <|> Firewall <|> DMZ/HTTP Web <|> Firewall <|> J2EE App Server
My J2EE App Server needs to send data out to the internet using SSH/SFTP as well as FTP/SSL to my suppliers. It currently makes a connection outbound on port 22 through the 2 firewalls before reaching the internet.
Am i compliant in terms of requirement 1.3.5 ?
outbound traffic under 1.3.5
Technically you would not be in compliance if you allow direct access from the card holder data environment to the Internet. Choices might be to proxy through the DMZ or to implement compensating controls. The issue is that you had to implement rules to allow that connection out which could be a future path for malware or an attacker to move data out.
mmm that would be pretty bad here. How are people sending these data back and forth? Not all protocols are proxy-able.
HTTPS does.
SSH/SFTP ?
FTP/S ?
I can’t imagine that all traffics that contain PCI related today travel strictly through HTTPS.
proper segmentation
Segmenting the Internet from the internal network is only one aspect of segmentation. If you were to segment the internal network so the card holder data was virtually and/or physically on a different network (VLAN, internal firewall, etc.) from the server that needed to push data to a supplier, and then not allow machines in the card holder data segment to directly access the Internet that might suffice. The key is that the card holder data environment cannot be allowed to directly access the Internet. Good segmentation is your friend. Segmentation also shrinks the assessment scope for PCI DSS which only applies to the card holder data environment.
[FONT=Comic Sans MS]
[/FONT]
[FONT=Comic Sans MS][/FONT]
[FONT=Comic Sans MS]Roger, [/FONT]
[FONT=Comic Sans MS][/FONT]
[FONT=Comic Sans MS]Thanks for the clarification. With the use of subnet-ting where the DB is on a different subnet than the App Server, you are suggesting that the requirement in Section 1.3.5 may be satisfied as long as the App Server is only used to process the PCI data and only the DB is used to 'store’ the PCI data? [/FONT]
[FONT=Comic Sans MS][/FONT]
[FONT=Comic Sans MS][/FONT]
[FONT=Comic Sans MS]Public Internet <|> Firewall <|> DMZ/HTTP Web <|> Firewall <|> J2EE App Server <| separate-vlan-subnet |> Database[/FONT]
[FONT=Comic Sans MS][/FONT]
[FONT=Comic Sans MS]The definition of “Cardholder data environment” as per PCI 1.2 says [/FONT]
[FONT=Comic Sans MS][/FONT]
[FONT=Arial][SIZE=2][FONT=Arial][SIZE=2][LEFT][FONT=Comic Sans MS]" The cardholder data environment is that part of the network that possesses cardholder data or sensitive authentication data".[/FONT]
[FONT=Comic Sans MS][/FONT]
[FONT=Comic Sans MS]I interpret the term “possesses” to be “stores” as supposed to ‘processes’ . Thoughts?[/FONT] [/LEFT]
[/SIZE][/FONT][/SIZE][/FONT]
with the Below example can my servers in the CHD segment pickup authentication from Segment outside the CHD (Corporate network) segment. also my Antivirus,AD, Patch Mgmt, servers are outside the CHD Segment. will this be any issue for compliance?
http://blog.tevora.com/pci/ask-the-pci-ninja-pci-dss-1-3-5-outbound-traffic-2/
some useful information here.
“possesses”
Possesses, in this case, means processes, stores, or transmits in the clear. Now, if the sensitive card holder data (CHD) is processed, stored, or transmitted in its encrypted form, then technically the CHD itself was not “possessed” since it was protected by encryption. That’s why, for example, you can accept CHD over the Internet in an SSL tunnel. This is essentially the solution you see where applications simply pass the CHD encrypted to something like like PayPal’s PayFlow service (nee: Verisign PayFlow) and thus can properly claim to have no CHD in their environment. So, if your app server never sees the CHD in the clear, then technically it’s not in the card holder environment as long as it’s properly segmented away.
I have done proper network segmentation where my app server lives behind 2 firewalls, separated by a DMZ area before connecting to the internet.