Saturday Oct 27, 2012

Patching and PCI Compliance

One of my friends and master of the security universe, Darren Moffat, pointed me to Dan Anderson's blog the other day.  Dan went to Toorcon which is a security conference where he went to a talk on security patching titled, "Stop Patching, for Stronger PCI Compliance".  I realize that often times speakers will use a headline grabbing title to create interest in their talk and this one certainly got my attention.  I did not go to the conference and did not see the presentation, so I can only go by what is in the Toorcon agenda summary and on Dan's blog, but the general statement to stop patching for stronger PCI compliance seems a bit misleading to me.  Clearly patching is important to all systems management and should be a part of any organization's security hygiene.  Further, PCI does require the patching of systems to maintain compliance.  So it's important to mention that organizations should not simply stop patching their systems; and I want to believe that was not the speakers intent.

So let's look at PCI requirement 6:

"Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed by vendor- provided security patches, which must be installed by the entities that manage the systems. All critical systems must have the most recently released, appropriate software patches to protect against exploitation and compromise of cardholder data by malicious individuals and malicious software."

Notice the word "appropriate" in the requirement.  This is stated to give organizations some latitude and apply patches that make sense in their environment and that target the vulnerabilities in question.  Haven't we all seen a vulnerability scanner throw a false positive and flag some module and point to a recommended patch, only to realize that the module doesn't exist on our system?  Applying such a patch would obviously not be appropriate.  This does not mean an organization can ignore the fact they need to apply security patches.  It's pretty clear they must.  Of course, organizations have other options in terms of compliance when it comes to patching.  For example, they could remove a system from scope and make sure that system does not process or contain cardholder data.  [This may or may not be a significant undertaking.  I just wanted to point out that there are always options available.]

PCI DSS requirement 6.1 also includes the following note:

"Note: An organization may consider applying a risk-based approach to prioritize their patch installations. For example, by prioritizing critical infrastructure (for example, public-facing devices and systems, databases) higher than less-critical internal devices, to ensure high-priority systems and devices are addressed within one month, and addressing less critical devices and systems within three months."

Notice there is no mention to stop patching one's systems.  And the note also states organization may apply a risk based approach. [A smart approach but also not mandated].  Such a risk based approach is not intended to remove the requirement to patch one's systems.  It is meant, as stated, to allow one to prioritize their patch installations.  

So what does this mean to an organization that must comply with PCI DSS and maintain some sanity around their patch management and overall operational readiness?  I for one like to think that most organizations take a common sense and balanced approach to their business and security posture.  If patching is becoming an unbearable task, review why that is the case and possibly look for means to improve operational efficiencies; but also recognize that security is important to maintaining the availability and integrity of one's systems.  Likewise, whether we like it or not, the cyber-world we live in is getting more complex and threatening - and I dont think it's going to get better any time soon.


Friday Oct 19, 2012

Engineered Systems and PCI

Oracle has a number of different engineered systems.  These are design to be highly integrated, optimized and secure systems.  The Exadata database engineered system and the Exalogic application engineered system are two good examples.  Often I am asked how these comply with different standards and regulations.  Exalogic is the Oracle engineered system that supports applications and the focus of today's blog.  First, we must recognize that as a collection of hardware and software, we cannot simply state that Exalogic is "compliant" with PCI DSS.  This is because Exalogic must be implemented within the context of one's existing IT infrastructure, the security features of that infrastructure, the governance framework that exists, security policies, operational procedures, and other factors.  What we can say though, is that Exalogic has been designed with various security capabilities that can be utilized to support compliance to PCI DSS as well as other standards and regulations (e.g., NIST and HIPAA).  Given that, Exalogic can be an excellant platform for running PCI related payment applications.  Coalfire Systems, a leading QSA in the US, has evaluated Exalogic against PCI DSS and supports this position.  Their evaluation can be found here: Exalogic and PCI Compliance.


I hope you find it useful. 

Monday Oct 15, 2012

Welcome to the PCI DSS questions and answers blog!

Welcome to the new PCI DSS questions and answers blog.  This is the place where I hope to answer all of those nagging questions you have about PCI DSS - as in the Payment Card Industry Data Security Standard.  As this is my first blog entry, let me introduce myself.  I am a security architect in the Oracle Enterprise Solutions Group and have been doing security, architecture, cryptography, compliance and governance for over 30 years.  Previously, I worked at Sun Microsystems, Visa and Bank of America.  

At Visa, I was part of the Technology Risk team.  It was there that I would say the concept of the PCI security standards was first contemplated.  We had already developed various cryptographic techniques and standards (think PIN processing [PVV] or credit card validation [CVV]) and recognized in the 90's that as credit card transactions were moving beyond the VisaNet private network and into the public Internet, there was a need for standardizing security best practices in a more comprehensive way.  (I use security best practices in a very broad way.  I am including technical, operational, governance and other controls, processes and management level policies here.)  Just imagine what could happen to all that sensitive cardholder information if a web merchant didn't implement basic security services such as a firewall to protect their network or encrypt that data where it was stored?  Those best practices were eventually instantiated into PCI DSS.

The way I like to think about it, the foundation for PCI DSS (besides being a good way to reduce fraud and risk) was:  

  1. make it easy to understand and implement (I know some will say, "yeah, sure" to this, but PCI DSS really is not that complex),
  2. make it comprehensive (it pretty much covers all of the fundamental areas of a security architecture) and
  3. make it a living standard (and given the the revisions we have seen, I think it certainly is).  

I'm not going to go into more detail on PCI DSS.  Anyone can go to the PCI website and download all of the standards there: https://www.pcisecuritystandards.org/  Likewise, there are a number of books on the subject that dissect PCI DSS pretty well.  I will post reviews of books and other sources in the future.

So what does all of this mean?  It means that PCI DSS is intended to be a baseline for how to secure an IT system.  No, it is not perfect.  And no, even if you follow it to the letter, it is very possible you could fail an assessment.  But PCI DSS is intended to represent a holistic approach to security architecture and thus can be addressed in a number of different ways.  There is no single correct answer to PCI DSS.  It needs to be applied in each environment according to the unique architectural characteristics of that environment. And of course, when we consider that QSA's are only human and have their own unique ways to interpret PCI DSS, well, ultimately, it will be up to the QSA to determined if PCI DSS has been satisfied.  (Note, in some cases organization may not be required to use a QSA, if for example, they are a low volume merchant; but feel free to as questions.) 

With that brief introduction feel free to send in your questions.  Please keep in mind of course, this blog represent only my own opinion on PCI DSS.  It is always best to get the opinion of your QSA on all matters concerning PCI DSS.  

About

Joel Weise

Search

Categories
Archives
October 2012 »
SunMonTueWedThuFriSat
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
16
17
18
20
21
22
23
24
25
26
28
29
30
31
   
       
Today