2

This question comes up a lot as I do evaluations for different customers. I currently recommend the following:

  • All outbound SSH & RDP blocked by default from user network (non-CDE)
  • All outbound SSH & RDP blocked by default from production network (non-CDE)
  • All outbound SSH & RDP blocked by default from Card Data Environment (CDE)
  • All outbound SSH & RDP for business requires change control ticket and exception ticket

I cite PCI DSS 3.0 section 1.2.1 as justification. However, it is not explicitly stated that this is required. I get further pushback that this is too far reaching.

Reasons for requirement in my findings:

  • SSH allows outbound connect from pivot hosts secure communications, especially when connected to production
  • Disabling should be part of a DLP protection strategy
  • Follows principals of deny-all for greater protections
  • Prevents moonlighting to other customers/clients while on this companies time

But is there any explicit requirements, that can be articulated, that PCI DSS requires this model?

Improve this question

1 Answer 1

Reset to default
1

You could isolate the user network and production network completely from the CDE, such as so a total compromise of the non-CDE enviroment cannot in any way compromise, reduce the security, or in some other way, affect the CDE enviroment.

If you do that, then the user network and production network would be considered out of scope of PCI.

However, its good computer hygiene to still block SSH/RDP outgoing default to prevent malware from "phoning home". But by isolating the CDE from the non-CDE enviroment to gain out-of-scope for user network and production network, then you dont need to have any "strict" procedures for opening ports. Eg, you do not need to follow PCI-DSS procedures for opening ports on the non-CDE part of network.

Then you can have SSH/RDP closed, but those that need SSH/RDP for business simply need to phone call and have the port opened in front of them.

Thus you Place the CDE with its own firewall, on one public WAN internet Connection, and the user network/production network, on a Another WAN Connection with its own firewall. This will make the CDE network and user/production network, to be completely separate.

No part of the user or production network may be authorized to pass the CDE firewall, Everything Before CDE firewall should be treated as WAN when talking about PCI-DSS compliance.

Note that the CDE Firewall also needs to be put inside the physical bounds of the CDE PCI-DSS enviroment aswell, so the CDE firewall itself gains the same physical security as the CDE enviroment.

Note that the "moonlighting" part is not something defined by PCI-DSS. PCI-DSS is about protecting your customers, not yourself. By gaining out-of-scope for your user-network and production-network, you do not need to care about protecting your customers when fiddling with the user-network and production-network, you only need to care about yourself.

Thus, if you then want to have "moonlighting" protection, its up to the Company. They dont need to Think a smallest bit about PCI-DSS when fiddling with user/production network if the CDE enviroment is properly segmented.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .