> PCI requirement providing Intrusion Detection at the entrance to Cardholder > Data Environments as well as at critical points inside the Cardholder Data > Environment. Intrusion Detection requires decryption of TLS. For some > large, complex organizations this can be a large number of physical > inspection points, more than can be accommodated by MITM. I understand this > may not be a problem for your current environment but others do not have that > luxury. >
This may be less than an ideal requirement. Malware wants to do three things (with some hand waiving): (1) spread, (2) collect data, and (3) egress data. I think Step (1) and intrusion detection is a worthy cause, but not at the cost of breaking the secure channel. Perhaps it would be better to focus on (2) and (3). (2) can be tricky based on how deeply the malware is burrowed in. (3) is much easier since the malware needs to open a socket. Policies for (3) are really just whitelist/blacklist approaches. I'm guessing egress points are wide open at the moment, and the PCI requirement is fostering blacklists and causing the organization to be reactive. If the egress points are closed at the organizational boundary, then the organization is proactive and using a whitelist approach. Would it be possible to have the PCI folks re-examine their position since it seems to be boxing BITS members into something untenable? Jeff _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
