Whats new with PCI-DSS 2.0 - Part 1

The much-awaited PCI-DSS standard v 2.0 is out now. The PCI Security Standards Council (SSC) has released the standard on the 28th of Oct 2010 and is available for download at their site, along with the Summary of Changes from v 1.2.1 to 2.0. Some of the changes are small changes in verbiage, just clarifying the stance on certain issues, while some others are changes which may have medium to large scale impacts in certain PCI environments. In this two part blogpost I will be discussing some of the key changes which may have that kind of impact.

The first thing I noticed was the amount of detail provided to QSAs at the beginning of the document. The Report on Compliance Details, Scoping, etc. have been detailed very heavily. This is good, because over some fears over lack of quality norms by QSAs, the reports were lax on details (due to laxity of testing). The SSC has been consistently trying to improve the quality of assessment and the initial sections of the Security Assessment Procedures are evidence of that.

Requirement 1, The Firewall and Network Security Requirement has largely gone through changes in verbiage, clarifying some of the questions about implementation of firewalls and network segmentation. The IP Masquerading requirement using NAT/PAT as the benchmark has been extended to including load balancers, content caches, firewalls, etc. Also, employees with personal firewall software on their computers in the PCI scoped environment should be unable to turn them off. Sensible, but largely basic.

Clarity on the "One Primary Function Per Server" rule has been given at last. The rule has been interpreted in several ways, but there is a measure of clarity with the 2.0. The Standard stipulates that you must use one primary server per function where the security levels of those functions vary, for instance, DNS, Web and DB server, or Card Management Application Server and Database Server. They have also indicated that in a VM environment, one primary function per virtual machine is in order. This was a requirement that was being taken to a ridiculous level on both sides of the spectrum.

Another important change, which comes across as innocuous but can have far reaching implications is the non-console administrative access requirement, where the PCI stipulates that when accessing system components like network devices and servers from a non-console administrative perspective, encryption like SSH, SSL, etc have to be used to access. In earlier avatars of the standard, this was just a simple allusion to SSL or SSH or IPSec, but they have now mandated strong cryptography. This causes quite an issue with network devices that ship with SSL certificates that still support SSLv2 or MD5, or in case of SSH with SSHv1. These were taken as compliant (with PCI 1.2.1) because they supported encrypted non-console admin access. Now, however with the strong crypto requirement for non-console admin access, these will have to be overhauled with better SSL certs and SSH implementations, and even in the case of IPSec, stronger crypto.

One of the requirements that I believe will set PCI back by some measure is Requirement 3.2. This requirement mandates that entities should not store Sensitive Authentication Data under any circumstances (even if encrypted). This requirement was extremely difficult to enforce in Issuing Banks or Issuing Processors as several of them are on Mainframe legacy apps and these apps, not only store CVV(aka Card Security Code), but also log the full card track data and transaction in cleartext. However, certain issuing banks/processors have adopted the standard where the CVV is generated on the fly (by a Hardware Security Module) for authorization and compared with the CVV sent in the transaction and if the CVVs are found to match, the transaction is authorized. This is a good practice, which ensures that CVVs arent stored by the organization. But these implementations (in my experience) are still the minority. The PCI 2.0 has allowed Issuing organizations to store sensitive authentication data like the CVV. They hav excepted issuers and processors from this requirement. I believe this is a bad move, because issuing orgs now, do not have an impetus to change over to better (and more secure) practices in relation to storage of Sensitive Authentication Data.

The Standard also changes some key issues with key management (no pun intended). The standard has mentioned that key-encrypting-keys (KEK) need to be equivalent to the Data-Encrypting-Key(DEK) in terms of size. Now, as it can be imagined, the DEK encrypts the Data and the KEK, as an additional measure of security is used to encrypt the DEK. In many applications, the DEK is a symmetric cipher (like AES 256 ot 3 DES 128) and the KEK is an asymmetric cipher (RSA, DSA, etc). This is usually done because reasons of efficiency. Data encryption is a heavy process, hence symmetric encryption is utilized for higher speeds of encryption. Asymmetric is used for KEKS, because the private-public keypair and is easier to secure than another symmetric key. However, with the mandate of the PCI on DEKs and KEKs having equivalent size, length and complexity, the tables are turned. The equivalent of a 256 bit symmetric cipher is a 15460 bit asymmetric cipher. Ouch.

A good fallout of the key management requirements is the 'split-knowledge' requirement. Earlier, the standard mandated split knowledge and dual-control of the encryption keys by key custodians for key generation,etc. This was a serious issue with Applications, as key management could be automated, but because of this requirement mandating split-knowledge and dual control of keys, developers used to come up with clunky executables (or other kludges) that would allow key custodians to enter half a key each for generation or key change. Now, however the stance has changed to the fact that split-knowledge of keys by custodians is only necessary in case of manually driven key management processes (where split knowledge and dual control make sense). Great news for applications, where the key management processes are (and ideally should be) automated.

This ends Part 1 of my PCI-DSS 2.0 review. This will be followed up with the rest of the review in Part 2. Hope you find it useful!

Why you might be 'Californicated' by SB-1386

SB 1386 is something most of us havent heard of. In the PCI and (fading) ISO juggernaut, organizations (especially outsourcing companies) have not taken cognizance of an important legal statute that might be a game changer for the way they do business with their principals in the US. Let me throw some light on what SB 1386 is all about. This is based on a conversation I had with another person from the outsourcing industry. The conversation might make a lot of sense to many people reading this....

What is the SB 1386?
SB 1386 is popularly known as The California Breach Security Information Act. It was an act enacted in the year 2002 and came to effect in 2003. The act focuses on the privacy of the personal information of the citizens of the state of California. The act states that any organization that believes that there has been a breach of un-encrypted personal information of California state residents is required to disclose the breach publicly.

What is 'Personal Information'? It is very vague...
No, its not vague. The act defines 'Personal Information' as the individual's first name or initial and last name in combination with one of the following: social security numbers, California State Identification Numbers, Credit/Debit Card numbers, PINS or access codes.

Ok. I am listening. Who does it apply to?
It applies to anyone doing business with anyone who is a California resident. If you have employees or customers in California, even a single one, it applies to you. If you are an outsourcing company that has a customer who has employees or customers who are California residents, then it applies to you. If you store data for entities that have information of California residents, then it applies. Large and small does not make a difference. It applies all the same.

That's alright. Its just a disclosure clause. No big deal....
That is where you are very wrong. You will have to disclose the breach to all those affected by it. These leads to a public relations war which you might have to wage with a great deal of reputational and financial expense. Your reputation WILL go to the cleaners because of a breach. You WILL face lawsuits from angry consumers and IF you are an outsourcing company, your customers will probably walk away from you and your prospects will NOT return your calls. Catch my point?

Yes, I think so. Wow, that seems worrying. I am an outsourcing partner for a lot of clients in the US. Can you tell me how it affects me?
Well, for starters if you are call center or a similar entity making outbound calls to US customers, you probably have the information which is defined by the act as "personal data", then you are in scope. If you are a back-end data processing center handling accounting or payroll or any other data processing activity for your client, then you are in scope. You will need to start securing all that data and doing it seriously. A lot of companies have breached your customer's data and you dont want that to happen. See here and here

I think I need some water now. My throat has gone dry. Anyway, what do I do now? How do I prevent a disaster from occurring?
For starters, call in a professional to audit your information security practices and let it be a thorough technical review and not a documentation and policy audit. Conduct a risk assessment for the data you handle and store and then formulate protection strategies in conjunction with your client. Have the auditor issue a formal audit report on completion and please, for heaven's sake, follow all the advice which you have been given. Dont try and cut corners on security practices, you will be in for a rude shock. Also be especially vigilant about employees who are working in your processes. It is very important to conduct periodic assessments and actively investigate any traces of malpractice from employees. Remember that insiders are the greatest cause of data theft in your industry.

Right then, but didnt you say something about encrypted data. So, if I encrypt data will I not have to disclose?
Well, yes, but have you encrypted data? and are you confident that your data has been consistently encrypted and the encryption keys managed properly for all your encrypted data?

I dont think I have encrypted any data. I am not really sure. I have got to check......
Then you most probably wouldn't have. Anyway, you better get going and do something about SB1386 otherwise you might be in for a world of pain. Think on the lines of being shot in the face with an AK-47.

(Gulps) Yes, not a pleasant situation. Anyway, I got to go. See you then...
Bye...

Why doesn't anyone pull their security SOx up?

This is a question, which has been raging in my mind for a while now. It has been something, which I see a great scope for improvement for and something that is currently, very rarely, if ever, followed.

The Prologue
First, a prologue to the entire story. I am sure all of you know the Sarbanes Oxley Standard, popularly known as SOx. It is one of the most important compliance requirements of publicly listed companies in the US. It is governed by the PCAOB (Public Company Accounting Oversight Board), which is an independent oversight body for SOx. SOx arrived in the wake of several scams such as Enron and WorldCom. These scams rocked the business world and caused a great deal of embarassment for corporate America. All these scams had something in common; they had cooked the books (misstated financials) and this syndrome percolated to the very top, including the CEOs and CFOs of some of these organizations.

Enter SOx. SOx was the brainchild of two US senators whose last names have been given to the standard. Their take on this was that shareholders and the general public need to be able to reaffirm their faith in an organization's financial statements. This involved, first of all, establishing accountability from the top management (as they had been intricately involved in the scams previously and had the most reason to misstate financials) and providing auditors with the teeth to ensure that the organization's control environment was adequate to ensure the "true and fair" view of financial statements. Therefore, as one can clearly see, SOx is primarily concerned with the integrity of the Financial Statements and the environment in which they are processed and created. The auditor assessing an entity for SOx needs to ensure that the environment in which Financials are prepared is secure and more importantly, an environment with controls which can be relied on to ensure the integrity of information and lastly make sure that the Financials are not misstated. This involves a process many of us have heard of. Identify scope, perform Risk Assessment, Document controls, Test controls, identify gaps, continuous improvement.

The Conundrum
Our look at SOx was fine and dandy, but all that is not new, right? All of you have heard it time and time again. Especially those of you who work for large consulting firms have seen SOx being thrown around in a conversation a lot of times. I have been interacting lately, with a lot of the auditors who assess their clients for SOx compliance. My question to them usually is, "How do you assess the integrity of the environment, which is involved in the creation and processing of financial information?". Their answer to that is something like this, "We usually ask a few questions about their IT policies and procedures and establish whether we can rely on the financial statements. Our worry is more on the business processes".

When I say "financial information", it means information from all quarters which is leading to the preparation of financial statements. It means, any system which is involved in the initiation, authorization, recording, processing and reporting of financial information. So you can imagine that this is.....a lot. An ERP system which is part of the organization would be a part of it, in case of an e-commerce company, for instance, the e-commerce accounting and inventory management modules of the applications would probably need to be a part of the SOx assessment.

Let me give you, quite a real scenario and then explain the matter. What if an ERP application is vulnerable to an Application vulnerability like XSS or SQL Injection where an insider might be able to hijack sessions, gain access to the privileged information and make unauthorized changes which are not logged, not checked in any way. If an employee were able to submit an expense statement and hijack his manager's session and authorize the expense statement, with no logging. Would I, as an auditor rely on the financial statements for a SOx environment, knowing that the application could be compromised and the financials could potentially be modified or in some cases even destroyed, and more so, without being checked (no logging). Taking the business process side of things, if the same person could could initiate an expense statement and authorize it himself as part of a business process, that would be looked upon as a serious hole in the internal control of an organization and the assessor would have no doubt that it was a significant deficiency. Let us take another instance, if a business unit of a corporation were vulnerable to several network issues, let us assume that they do not have proper firewalls rules, restricting specific IP and port sets, that default passwords still exist on their network devices and servers. Let us assume that a supplier breaks into this network and overstates the value of the organization's account payables. Would, I as an auditor sign off on that entity's financials, knowing that the entity can be easily breached and integrity of data can be adversely affected?

This is just from the auditor's standpoint. A company would be held equally responsible for its negligence to IT security (as IT is a key driver in financial statements) and its reputation and business value would be seriously impacted.

Unfortunately, the scenarios I gave you have real life significance and are quite real in the corporate environment and I believe that they are largely going unchecked, because the auditors for SOx are usually not capable of assessing IT controls and are under the false belief that SOx only applies to business process and related internal control, whereas the real scenario is quite different. In today's world of highly connected enterprises, IT is a huge area of consideration. IT controls, in essence form an integral part of the entity's internal control and can significantly impact the way financial statements are initiated, authorized, processed and recorded.

The Solution
My advice to the SOx assessors and auditors of the world is this. IT security is an important consideration for any entity today. SOx does not absolve you of the duty of performing basic risk assessment and control testing (like you would do for business process with assessment of internal control to ensure that financial statements may be relied upon). Integrity of information can be made or broken by IT security in today's digital age. SOx must be treated like any other security compliance which requires scoping of processes and applications affecting financial information, performing Risk Assessment, testing controls of the processes or applications and gap analysis. As you can see, this clearly involves issues like Firewall management, Application and Network security testing, Secure Application development, deployment and configuration, Network Change Management, Logging, Integrity Monitoring, Patching, AV and all the other IT security requirements which one can formulate through effective risk assessment and best practices. Bottom line. SOx is not just a financial standard. It has a serious impact in an IT environment and from an IT standpoint.

The Devil's Advocate: Compliance vs Security

The fires in blogosphere are ablaze with talk about the Heartland Payment Systems breach. There has been a great deal of PCI bashing, right from Bob Russo's statements to the whole issue of Compliance and Security.

For those who are not aware of the HPS, or who have had their head in the ground because of the current economic meltdown, I shall recap. Heartland Payment Systems is a large Payment processor in the US. Malicious software in their payment processing network seems to have caused one of the largest breaches in history. It seems as though over a 100 million cards may have been stolen. The great gory details of the story are not known yet as forensics for this sort of thing takes quite a while.

Security vs Compliance is one of the most significant things I have heard being posted all over the Internet. Everyone seems to be talking about the fact that Compliance cannot be equated to Security and that the PCI Standards are flawed in their attempt to make their industry more secure.

Us security folk secretly love an incident of this magnitude. Its incidents like these which makes people sit up and take notice of security needs and this is our time to shine :) But on a more serious note, let us take stock of some important facts at this point.

Agreed, Security != Compliance. I believe strongly that those who expect their plain-vanilla compliance program to do miracles for them. Compliance can never take the place of a voluntarily committed security program which comes from experience and a proactive risk approach. But, at the same time, one cannot simply discount the fact that compliance is important. Take the case of the American Capital markets. The deregulation (lack of compliance and enforcement) did not ensure that all the Banks and large Investment houses take a "Safety First" stance. They continuously created their weird and arcane financial intruments, which were toxic for the economy. Until there was a Sarbanes Oxley for the Corporate world, there would be no accountability for any of the Top Management's statements and actions (case: Enron). In fact, only the stick that is accompanied with non-compliance (fines, increased transaction costs, de-listing, etc) gets some companies adopt a security program. The carrot that comes (proactive security, better understanding of risks, threats and vulnerabilities, etc) with compliance simply does not appeal to these companies.
In my time handling several PCI projects, I realized that there are always a bunch of organizations which are driven towards genuinely acheieving optimum security and not just chasing a certification and there are others, who decide to "dress their processes well" before the auditor walks in. We need to understand that there are always going to be organizations like the latter and accept the fact that these organizations can only be driven to better security by incentivizing them in forms such as low cost of security, increased business opportunity because of enhanced security and of course, once they get hacked and lose data and reputation (and if they are still not bankrupt in the process), would try and develop a proactive, risk based approach to security. This brings me to my second point....

PCI = Risk-based Security Compliance. When I hear someone talk about PCI Compliance, I usually hear the word "checklist". PCI is viewed as more of a checklist assessment and once the checklist is filled with "Yes", everyone's happy. This is very very far from the truth. Companies and Security professionals who look at PCI in this light are actually getting it all wrong. PCI is nothing but Asset Based Risk Assessment, where the asset in question is Cardholder Information and the ultimate objective is the protection of Cardholder Information. Which is why Security pros need to understand the systems of interest, access paths, points and containers in which the asset is housed and devise security solutions based on the PCI Requirements. One cannot advise a small organization getting PCI Compliant to drive its entire encryption process using a HSM (Hardware Security Module) or a large processor like Heartland to use something like TrueCrypt to drive encryption. Yes, PCI is granular, PCI is very clear on most counts, but by treating PCI Compliance as a checklist assessment or a checklist compliance program, security assessors are actually saying that Compliance = Security, which brings me to my next point.

In the long run, compliance ultimately becomes "bastardized" because of the people advocating and following it. The same thing happened for ISO-27001, which is a great standard, but eventually became mis-understood and mis-interpreted beyond recognition. I came across and ISO-27001 certification which was only done for the "Security Components" of a company's infrastructure (namely 2 firewalls and 2 routers, in which case the routers are not actually a "Security Component"). There is nothing inherently wrong with the standard. It is just that for the sake of convenience of both the security assessor and the assessee, the standards are interpreted in a way which does not take into account, the all-important aspect of Risk (which is unique to every organization). So, to re-iterate, when an organization is going in for PCI Compliance, it needs to determine what kind of entity it is. Is it the former type, proactive, and risk-based towards security needs, or is it like the latter, the "Chasing certifications 'cause I need this business" type. If a company actually believes that it is in the first type, then it needs to evaluate security professionals who share the same values and ensure that the professionals deliver on their promises at performing a solid evaluation of risk and then concomitant controls.

In conclusion, I would like to say this. Although Compliance and Security are not necessarily the same thing, we need to appreciate the fact that compliance, when interpreted and enforced correctly does eventually lead to a solid Information Security program. It is upto the people in the organization to determine what they want, Compliance leading to Effective Security or Compliance just leading to.....Compliance.