PCI-DSS v1.2 - My thoughts, concerns and questions

Linux_Bot · October 6, 2008, 3:20pm

Having had the opportunity to go to the 2008 PCI-SCC meeting in Orlando this year, that just so happened to be conveniently 5 minutes down the street from my office. And having had a couple of weeks to digest the new PCI-DSS v1.2 standard, here are some of my thoughts, concerns and questions. I'm not going to go into all the minor changes or clarifications, but rather the ones I feel have the most impact to the most organizations. One of the first ones I think that jumped out to allot of us was the notes added to requirement 6.1, concerning patch management. The testing procedure under 6.1.b states that patches rated critical must be shown to be installed within one month, however the following has now been added under the NOTES of requirement 6.1;

6.1 - Note: An organization may consider applying a risk-based approach to prioritize their patch installations.

Keywords are �may� and �risk-based� here.

Now I'm not going to let the old I.T. security administrator in me get up on my infosec soapbox on this topic, because it is a very subjective area with many variables that most auditors in general do not always understand (I'm talking about arguing risks). This addition under the notes to the overall requirement, although welcome to all, particularly systems administrators, does in my opinion have a downside. My concern is from an I.T. security perspective, not only a compliance one, where I think many organizations will once again not put enough resources behind a solid but practical patch management program and become laxed once again . Ok let me get back on track here, testing procedure 3.4.1.b for requirement 3.4.

3.4.1.b - Verify that cryptographic keys are stored securely (for example, stored on removable media that is adequately protected with strong access controls).

�Stored Securely� being the key word here, the change and relief I think here is that having the keys stored locally on the system isn't a deal breaker. Although one may argue a best practice may be to have them located somewhere else, it is no longer required.

Another one I find worth mentioning and would also like to get a general consensus is on 4.2 where instant messaging has now been added to the language. Here's an area where both the I.T. security geek and compliance manager in me are in complete agreement. I like to have strong controls including when possible content controls on all communication channels that have the ability to travel outside my network. My question is where the consensus on both scope and controls will fall on instant messaging.

Requirement 11.4 has now been thankfully changed to where it now states and/ or in reference to IDS and/ or IPS. I can say that 99.9% of any network administrators I have ever worked or spoken with always stayed away in general to any device that has the access or ability to change routing and/ or firewall tables, a decision I 100% agree with.

Requirement 11.3 and the clarification (as the PC-SSC refers to it) of penetration testing both internal and external. Wooo did I here that right, internal being the key word here. Now as a former I.T. security administrator I agree 100% with a vulnerability management program that includes limited internal vulnerability scans of production servers that are online and where warranted limited penetration tests, particularly sensitive web applications. But I can't say I agree with a requirement that now requires full penetration tests on all in-scope hosts internally.

In requirement 5.1 I welcome the terminology being changed from anti-virus to �malicious code�, it makes the requirement more flexible. But one new development in the requirement that many may think is trivial but does raise some long term concern with me is the addition of the word �Rootkit�. Now I agree this is a form of nasty code that needs to be addressed, but I would like to get a consensus on this one. I have two questions; 1. Does this now mean that anti-virus installations on Windows servers will have to have a rootkit component in them, and 2. The phrase �commonly affected systems� used under requirement 5.1, does this now mean that UNIX systems will need to have automated rootkit detection. Being a former UNIX administrator I fully understand the danger of rootkit's, particularly on a *nix system and having strong systems controls and a hardened box to prevent such a rogue set of code getting a hold of the machine. But since UNIX systems can be affected by rootkit's, and the requirement is worded as commonly affected by�, are we looking at down the road having to have automated rootkit detection running resident on a UNIX server? hmmm that's a thought.

More...