Known vulnerability patching rates

The PCI DSS Barbecue

I predict that on 1 July 2018, I will be calmly eating a barbecuesandwich, talking with friends and possibly, I will burn a copy of the RFC2246: TLS version 1.0 standard for entertainment value.  Those will lesseffective Vendor, Network, Systems, Application and Cryptography managementprocesses in place will feel as if they are being barbecued more than enjoyingthis day.  This will happen for several reasons.

No one identified all the dependencies in the use of cryptographywith Vendors, the firm itself or its customers.  These waited until 29June 2018 to open up a change ticket and discovered that it was not a simpletechnology matter.  Further, these did not authorize internalvulnerability scans outside of PCI in scope systems to find all the not inscope systems that will prevent PCI in scope systems from being fullycompliant.  Finally, there will be a Vendor with a truly horrible websitewhere their best day cryptography will be lower than the firm’s worst daycryptography standards.

Enjoy the barbecue rather than be barbecued.

Look at your vendor websites, it isfree:

Scan your whole internal network to find your dependent systems.  

Consider your lead times.  A simple patch can fix the issuein 30 days.  Escalating the case for a vendor to find a patch, test it,deploy it, upgrade your systems and then deploy to production along withdependencies on other systems can take 6 months. One has until December 31,2017 to find these.  If not, 30 June 2018 as a PCI compliant date will betechnologically infeasible.  One can dance and evade the true intent ofPCI DSS requirements, maybe this will save the firm from the implications oflack of compliance with PCI DSS requirements while doing business with paymentcards.

You must sign in to rate content.


There are no comments yet for this post.

Leave a Comment

You must be logged in to post a comment.