It’s time for the next of ten posts with a detailed analysis on a PCI Requirement! Last time we talked about PCI Requirement 4.1 and mobility. If you have a requirement you want reviewed, post it here! Today, it’s fun with interpretation around patch management and IPS. This isn’t a topic I’ve addressed before, but it is something I’ve debated with a customer. Now, on to our anonymous submitter:
Some Host Based IPS vendors and QSAs are saying that if a host based IPS product can block any exploits related to a specific Microsoft patch (virtual patching), then the in-scope system does not have that specific patch applied within 30 days. Even if it SPT cc data!
Hrm, interesting. A quick check of the PCI DSS FAQ shows that this question is either not asked enough or they don’t feel comfortable taking a position on this. Let’s dig into the requirements!
First, Requirement 6.1 tells us that we have one month to patch any system once a vendor releases a critical security patch. Critical security patches generally remedy vulnerabilities that would let an attacker fully compromise a system remotely, or at least gain access to cardholder data remotely. GENERALLY. Just remember there are always exceptions, but this is a good litmus test. The requirement also goes on to describe how companies can take a risk-based approach to slow down their patch cycles if their IT department can’t complete it in time.
OK, I have to get on my soapbox for a minute. Feel free to come on up here if you like, it’s certainly big enough. There is no reason why critical patches can’t be deployed in one month unless your IT department is failing to properly support your business (which it may be). Lagging on critical security patches is inexcusable in today’s environment. I had a top global bank tell me that in 2007 they were able to push a patch in three days. THREE DAYS. IT management systems have come a long way in five years, so if it still takes you ninety, it’s time to examine the operational efficiency of your IT department and make some changes.
Allllll-righty then, let’s put that soapbox away for another day and continue.
IPS technology, in light of the PCI DSS, is not a base requirement (IDS is, so we’re talking active > passive) of the standard, so it could be used as a compensating control for a number of other requirements if needed. Good QSAs are probably not very tolerant of laziness (albeit, I’ve met a few lazy QSAs recently), so don’t expect that you can get passes by implementing an IPS to cover all of your exposed vulnerabilities. That said, using an IPS on a temporary basis could be considered a compensating control for not patching within one month with three very important caveats:
The IPS must be able to protect the system REGARDLESS of the source of the traffic. Meaning, that IPS better be able to block an attack from a host internal to the network just like it would from the Internet. Otherwise, it’s pointless.
- You must be able to VALIDATE that this option is actually effective and it doesn’t allow the vulnerability to be exploited.
- You can’t extend the lazy patching attitude toward patching your IDS when that vendor releases a security patch.
I think the bigger discussion here (once you temporarily band-aid the compliance situation) is looking at IT operations to ensure patches are deployed in a timely fashion.
Thanks for the question! If you have your own requirement you want analyzed, go to this post and add a comment!