I was just reading an article discussing the timeframe for upcoming revisions to the PCI-DSS. Nothing quite so exciting as reading about a compliance roadmap, right? This article reminded us about PCI Section 6.6 becoming mandatory in June 2008, with additional guidance and clarification coming in May (hey, a whole month to prepare!). As a refresher, 6.6 says that web applications must be reviewed by a third party for security vulnerabilities, or a web application firewall (WAF) must be installed. Anyway, in this article, PCI-DSS General Manager Bob Russo makes the following statement:

“Personally, I’d love to see everyone go through on OWASP-based source-code review, but certainly, that’s not going to happen,” Russo said, referring to the expensive and time-consuming process of manual code reviews. “So the application firewall is probably the best thing to do, but there needs to be some clarification around what it needs to do. That clarification is coming; that’s been the biggest question.”

Really? The WAF is the “best thing to do?” Maybe he meant to say “cheapest” or “quickest,” but how is a WAF better than fixing the root cause of vulnerabilities? I don’t deny that a WAF can be valuable to a layered security approach. For example, if I need to quickly plug a hole in my web app, I can configure the WAF to block it, thereby buying time for the development team to fix the problem. Instead of having to fix the bug immediately, it can be rolled into the next release cycle, with the WAF protecting the site in the interim.

Sure, the WAF can protect against some known attacks, and if you set it up the right way, it can attempt to detect and block other, unknown attacks — that is, if it’s configured aggressively enough. Except very few companies will actually do that. Nobody wants to risk the WAF confusing a legitimate request with an attempted attack and subsequently blocking user traffic.

This is why I argued, a while back, that a WAF really should be considered a compensating control since it is more of a band-aid than a best practice solution. That would give the requirement a lot more credibility rather than giving enterprises an easy way out.

Earlier this week, I attended the first PCI Community Meeting in Toronto, a gathering organized by the PCI Security Standards Council to bring QSAs, ASVs, and other PCI stakeholders together in one room with the PCI Council. Let’s be honest here — in the security industry, discussing regulatory compliance is about as dull as it gets. On the other hand, compliance is also a major catalyst, sometimes the only catalyst, in convincing organizations to improve their security posture, so it’s important to understand. As might be expected, I focused my attention on the sessions dealing with upcoming application security requirements and standards. Of particular interest were the two panel discussions covering the Payment Application Data Security Standard (PA-DSS) and Requirement 6.6 of the PCI Data Security Standard (PCI-DSS).

PA-DSS

The PA-DSS is basically an extension of Visa’s Payment Application Best Practices (PABP) guidelines. Essentially, it’s a standard that will be applied to any application that stores, processes, or transmits cardholder data in a merchant or service provider environment. This is not to be confused with the PCI-DSS, which applies to entities/companies as opposed to applications. The PCI Council will release a draft of the PA-DSS in October for comments and suggestions, leading to a final version by the end of Q4. They are currently working on the certification process for existing QPASPs (Visa’s certification for PA assessors) to become PA-QSAs by Q2 2008.

The panel outlined the changes to PABP as follows:

• Explanation/Clarification. Just providing additional text around the best practices, presumably to make them easier to understand.
• Enhancements. Things necessary to turn a Best Practices document into a standard. The panel did not go into exhaustive detail on the enhancements, but the examples given were requiring assessors to use forensic tools to examine the output of the PA, introducing stronger lab requirements, and requiring a penetration test of the PA to identify common (e.g. OWASP-style) vulnerabilities.

Unfortunately, this was the extent of the detail. I wanted more information on the enhancements but didn’t get a chance to ask a question due to time constraints. Specifically, it would be nice to understand whether code analysis would be an alternate option for the penetration test requirement. Or what exactly they meant by using forensic tools to examine the application’s output.

Other relevant questions that came up had to do with versioning and recertification. For example, if a PA vendor releases a minor update, what is required in order to recertify the application? Would they be required to conduct another pen test, even if all they did was add a minor feature, such as the ability to recognize a new type of gift card? The panel’s response was that if a recompile was required then recertification would be necessary. However, that recertification effort could be targeted towards the new functionality. The other good question was under what lab conditions would the application be tested — the vendor or the customer. If you consider applications such as SAP, PeopleSoft, etc. which tend to be highly customized for each customer install, does it make sense to test in a vendor lab only, with no context of how the application will be deployed and configured in a production environment?

Requirement 6.6

Requirement 6.6 of the PCI-DSS becomes mandatory in June 2008 and requires all web-facing applications to either undergo a code review OR be protected by a web application firewall. There were questions on what “web-facing” means, and the Council admitted that it needed rewording. This could be interpreted as any application using HTTP as a transport mechanism, or it could mean only those applications that were Internet-facing. It sounded as if they meant the latter, but they did not say so outright which was confusing. Web services applications would also be within scope. Many people were confused about the requirements for a WAF, specifically because there are no guidelines on what functionality the WAF must have, how it must be configured, etc. Joe Lindstrom, a panelist who runs Symantec’s compliance practice, outlined these features to look for when selecting a WAF:

• Layer of defense for known attacks (e.g. OWASP Top 10)
• LDAP and/or Active Directory integration
• Logging and monitoring capabilities
• Minimal performance impact

From a security perspective, I am not sure why performance impact was on the list. As long as the security requirements are met, it should be up to you to decide how much of a performance hit your application can handle. Another panelist, Dave Wichers from Aspect Security, suggested that a WAF should also do egress filtering to detect sensitive information such as track data leaving the network.

WAFs can be configured in so many different ways, however, that people were really looking for detailed guidelines on what would satisfy the requirement. First, WAFs can be run in “detect” or “prevent” mode. The former simply logs anomalies, while the latter actively blocks traffic once it detects those anomalies. Obviously, this is a big difference from an operational risk perspective, and most organizations use “detect” mode for that reason. Secondly, the effectiveness of a WAF is limited if it is not tuned specifically for the web application that it is protecting. In order for it to know what constitutes malicious traffic, it needs to understand what normal application traffic looks like. It’s kind of like tuning an IDS, except at the application layer. Of course, this means that a certain amount of retraining is required whenever the application is updated or changed, so again, WAFs are commonly deployed without proper tuning in order to avoid unforeseen disruptions.

One panelist, Kennet Westby from Coalfire Systems, pointed out that Requirement 6.6 should not be an either-or option, since code review is an integral part of the SDLC. This time, I made it up to the microphone before time expired, and asked if the council had considered making code review the sole requirement but allowing a WAF to be used as a compensating control. In my view, this seemed more closely aligned with the intent of PCI as a security standard. Incorporating code review into the development process is the best practice, whereas a WAF is essentially just a band-aid, not a replacement for code review. Granted, a SDLC cannot be put in place overnight, and a WAF can be effective as quick fix — something is better than nothing — but it certainly shouldn’t be an equivalent way to satisfy the requirement. Dave Wichers responded to my question, agreeing that code review was the “right way,” but added that a code review is not a viable option for many companies, thus they had to offer WAF as an alternative. Time ran out, so I’m still not clear exactly what he meant by that, and I need to follow up to get more clarity on his comment. Still, I saw some heads nodding and received some positive feedback from a couple people in the audience, so I guess I’m not the only one thinking along these lines.

The panel also brought up the question of whether automated code analysis solutions could be used to satisfy the code review requirement. The general consensus on stage was that you still needed a security professional in the loop due to the false positive (FP) and false negative (FN) problem. This isn’t to say that companies shouldn’t use these tools to help them achieve compliance, but that the tools alone would not satisfy the requirement. While the panel did not recommend any specific products, they suggested that organizations should focus on three main factors when selecting code analysis vendors:

• Maturity of the product
• Ease of integration into the SDLC
• FP and FN rates as an accuracy benchmark

The idea of benchmarking for FP/FN rates shows a level of maturity that this industry is undergoing. It would be an eye-opening exercise to apply these standards to human code reviewers and human penetration testers as well. In fact, I think people would be shocked when they realize the FN levels they are accepting today.

Staying on the topic of benchmarking for a moment, the WAF discussion is interesting. What percentage of attacks do people think these are actually stopping? Is it 20% or 80%? I haven’t ever seen any solid data here, though anecdotally, the reviews certainly have not been glowing. This is a big of an unknown as FP/FN rates of code analysis tools. If automated code analysis is going to be held up to benchmark scrutiny, then WAFs and manual assessments need to be as well.

Conclusions

Overall, I found that the sessions were probably a little bit on the short side. At each session I attended, there was never enough time at the end to address audience questions. Many of the audience members were from companies working toward PCI compliance, so the questions tended to revolve around interpretation of the PCI language and intent (Is such-and-such considered a compensating control? What do you mean by connected entities?), leaving less time for discussion of the technical merits of the security requirements.

Identity theft and the huge TJX breach have brought information technology and security to the forefront and now the states of Texas and Massachusetts are contemplating bills that would hold corporations financially responsible for security breaches.

Computerworld’s Article states that “Texas mulls bill that would make PCI requirements a state law”. According to the article, Texas Bill HB 3222 passed the House of Representatives 139-0. It should prove interesting to see what the Texas Senate and Governor Rick Perry have to say about this. Is this really the right move for any state? Massachusetts is also considering legislation that will hold a breached entity responsible for the costs associated with consumer protection.

I feel Information (Security) Standards and Frameworks really should be a part of every corporation’s processes and policies. IS027001, ITIL, CobiT and BS7799 have been around for some time and they are comprehensive and well thought out (IMHO). Is PCI DSS really the right standard to work from? I’d have to say anything is better than nothing but the more comprehensive, the better. I also have mixed feelings about additional legislation. Why not let the corporations hammer it out? Then again, unless there are very specific requirements with repercussions, someone, somewhere will avoid them.

In case you’re unfamiliar PCI DSS has 12 basic requirements:

Build and Maintain a Secure Network
Requirement 1: Install and maintain a firewall configuration to protect cardholder data.
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters.
Protect Cardholder Data
Requirement 3: Protect stored cardholder data.
Requirement 4: Encrypt transmission of cardholder data across open, public networks.
Maintain a Vulnerability Management Program
Requirement 5: Use and regularly update anti-virus software.
Requirement 6: Develop and maintain secure systems and applications.
Implement Strong Access Control Measures
Requirement 7: Restrict access to cardholder data by business need-to-know.
Requirement 8: Assign a unique ID to each person with computer access.
Requirement 9: Restrict physical access to cardholder data.
Regularly Monitor and Test Networks
Requirement 10: Track and monitor all access to network resources and cardholder data.
Requirement 11: Regularly test security systems and processes.
Maintain an Information Security Policy
Requirement 12: Maintain a policy that addresses information.

Seems pretty basic, doesn’t it? As you get deeper into the standard, it becomes somewhat confusing… Then let the bean counters and other wordsmiths at it … Hopefully Texas and the other states that follow suit are smarter than that.

Jeremiah Grossman talked about PCI DSS section 6.6 and the application firewall issues. Some may consider that to be more band-aid work instead of doing the right thing and working on the basic building blocks that build our entire infrastructure – the applications themselves. I would argue that PCI DSS is very close to being a band-aid framework itself. While it is a good small step, it is not comprehensive enough or specific enough to become LAW. Granted, with the Brands backing the standard and certification process, it’s a framework that has some teeth, but I think the jury’s still out on the fines and usage of those “teeth”.

Computers, networks and applications have been around for quite some time (Captain Obvious, there). We rely upon them day in and day out to perform some of our most critical work functions. Protecting these assets, the media &data they control seems (to me, Captain Obvious) to be common sense. Why do we need legislation to force something down our throats? Does this really help us to align Information Security to our business objectives?

Since this is a blog, I should probably venture forth some of my own opinion: I have very mixed feelings about this. As a consultant, I worked with quite a few organizations with an incredibly high tolerance for risk. Controls that would have been very simple to implement were ignored. I witnessed a good deal of ignorant risk avoidance instead of educated risk determination (“if we don’t know about it, we’re not responsible”). Then again, some laws can be used a sales scare tactic: “WE MAKE YOU SOX COMPLIANT” or become a whole industry unto themselves.

PCI is already a requirement at places that take credit cards so a law would only require it in other spheres. Does a blog need to be PCI compliant if they accept personal information in a profile? What is the scope?

Legislation, reasonable or unreasonable, tends to be contagious.

Security awareness is an incredible thing:
California SB1386 brought personal information breach to the forefront of social consciousness. Identity theft has become more prevalent in society. We need to know when/if our personal data has been compromised, so we can determine if it’s being used by someone else. I myself received more than 5 letters from the Veterans Administration when they thought they lost a laptop with Vet’s personal information on it… then received another 5 when they determined they didn’t lose my information and recovered the laptop.

Choicepoint, the first significant public disclosure: of course, they waited quite a bit before disclosing that “identity thieves stole the personal data of at least 163,000 Americans”.

TJX, yet another one:

Would these entities have disclosed their breached status without this legislation?

Bloated legislation, not so hot:
Sarbanes Oxley – Specifically section 404. Whole security industries popped up over night to help with this legislation. Try Googling: “Sarbanes-Oxley act section 404”
Heng Hsieu Lin and Frederick H. Wu wrote about the limitations of Section 404: “This aim is misguided for a number of reasons. First, internal control was not conceptually designed to be a panacea for corporate ills.”

Anecdotal evidence: prior to joining Veracode, I was on site with a customer auditing their IS027001 Information Security Management System. The company had a control (for SOX-404) that stated “An intrusion prevention system (IPS) will be in front of all financial systems”. As part of the diligence process, I requested records of operation, which their policy stated were compiled logs from their IPS. They were unable to produce logs, as the IPS had been turned off. This particular customer had passed their SOX audit with flying colors, yet one of their primary controls had not been active in at least the 9 months preceding their SOX audit.

The Point:
Although I am all for responsibility and actionable policy, why not use common sense, do the right thing and avoid making more bloated laws? If we have to make legislation to cover those that will not perform due diligence in protecting our assets, then make the law actionable, simple, effective, clear and concise. Research before action!

TJX issued a press release yesterday coming clean on what they know about the breach of their corporate network. They are now admitting that they have been compromised as early as July 2005 and continued to be compromised up until December 2006. It is unlikely only one attacker found the vulnerabilities exploited. I wouldn’t be surprized if dozens of attackers found their way into the network during that time.

One of the pieces of data stolen was driver license numbers given by customers when returning merchandise to “T.J. Maxx, Marshalls, and HomeGoods stores in the U.S. and Puerto Rico for the last four months of 2003 and May and June 2004.” Drivers license numbers in many states are the same as social security numbers. Along with names and addresses this is the “keys to the kingdom” for identity theft. My state, Massachusetts, offers an alternative license number. When you renew your license they ask you whether or not you want an “S number” or to keep your “old number”. I don’t know why anyone would want to keep their social security number.

Giving up such sensitive personal information just to return merchandise has always made me a bit nervous. Now I dont feel paranoid. If you give up information in the current corporate information security climate, it has a high likelihood of being stolen. Presenting a drivers license number to return merchandise only benefits the merchant. It protects them by being able to track the people who abuse the store’s return policy. It is likely that the merchant is going to hold on to this information for a long time. In such a one sided transaction of sensitive information the merchant has a duty to be a trusted custodian of this data and go above and beyond the PCI data standards. Yet, this storage of personal info is completely outside of PCI and is unregulated.

Consumers have to start to demand protections for personal data handed over to merchants when there is no benefit to them. If there are no assurances of protection they should refuse. I was asked yesterday for my social security number in order to file a claim for a broken window on my car. I asked why the number was needed and the woman on the phone couldn’t give me an answer. I said I was uncomfortable giving over my social security number when it wasn’t required and there was no reason other than the insurance company’s convenience. She then said they would send a form in the mail asking for it. I am not planning on filling it in until I get some better answers.