Critical Assets – Security and Compliance

In short – Yes.

Organizations that are in the process of determining whether or not they should install an application firewall in front of their web facing applications, OR do a code review should make a best effort to do both.

Why? Because, web application firewalls, while very useful, and generally very thorough are designed to perform a limited number of protection tasks, that are typically based on existing, deployed web technologies.

Web technologies are evolving, and more and more custom applications exist. For instance, CGI based vulnerabilities popped up as soon as CGI came into existence. Developers simply did not understand the threats associated with query string vulnerabilities, safe passage of variables, or safe backend system call execution. Then of course, php and asp represented new threats such as SQL injection, file path inclusion, XSS, etc.

Every time there has been a shift in web technology, a new threat landscape has emerged. More and more, open-source server-side web-apps are showing up in payment environments. Mambo CMS is a perfect example. It provides a great platform for easy deployment of nearly any site architecture. It’s also been compromised many times, and its been deployed as a front end for applications which process payments.

When you weigh the option that DSS provides of either source code review or web application firewall, you should understand that you’re going to obtain vastly different results from those two methods.

Installing a web application firewall will thwart the 99.9% of attacks that happen as a result of publicly disclosed vulnerabilities that are either being executed by a bot or an attacker with a luke warm degree of motivation.

A source code review will afford you visibility into the security of the application from otherwise unknown attack vectors and hopefully give you insight into not only vulnerabilities that exist as a result of insecure coding techniques, but along with a solid educational experience, the peace of mind that your developers are learning how to avoid common mistakes after you’ve received the results of the review.

Also, less vulnerabilities in the protected zone means less possibility of internal compromise. Don’t forget that the majority of compromises happen from within.

So again, the answer to the question is yes. Install a web application firewall if your organization can afford the technology. Perform a source code review of both 3^rd party apps, and –especially- in-house developed code to provide a second layer of protection and valuable feedback to your development team.

This will allow you to use PCI as a valuable tool, instead of just one more exercise in compliance.

A friend who recently went through the new annual QSA re-certification training a while back shared the most recent training manual with me. I have to say, that some of the clarifications are astonishingly… bad.

Specifically what I am taking issue with is the clarification around network segmentation. The title of the slide is:

“What are acceptable forms of Network Segementation?”

Then the slide describes Cisco access control lists.

Right.

Think I’m nuts? The slide goes on further to give the following example:

access-list 100 deny ip 10.0.0.0 0.255.255.255 any log

access-list 100 deny ip 127.0.0.0 0.255.255.255 any log

etc...

Another interesting sub bulletpoint is “Confirm audit logging is in place for all access to segmented network,” suggesting that there are cases wherein you would not only be exclusively using ACLs, but that you may create specific ACLs which allow access to the “protected” network from the unprotected interface.

Translated:

“Cisco ACLs are effective protection for the cardholder environment, and if you need to make exceptions to your already bad security practice by allowing administrative traffic in from the outside, then go ahead.”

Its any wonder that compliance numbers grow every year, and so do the number of compromises.

I was speaking with a friend and colleague today about his experience with the most recent PCI training and what I found out was, well, interesting to say the least.

On the topic of independence and thoroughness, the SSC is apparently suggesting that it is acceptable to have an individual QSA:

• Perform the assessment.
• Remediate the issues in the environment.
• Re-assess the environment in subsequent years.

In my opinion, you may as well have the merchant or service provider simply self-assess at this point, because the QSA’s objectivity is all but gone.

Anyone who has ever gone through QSA training and has spent any time doing work in the infosec space will tell you that the training materials are fairly simple, and the test is a walk in the park.

In fact most QSAs will tell you that they haven’t learned anything substantially new by virtue of becoming a QSA. For the most part, the certification only enables them be the examiner of record on paper.

In other words, no special knowledge required, zero objectivity, and lots of multi-year managed service contracts between QSAs and merchants.

Its not hard to see why things like Heartland and RBS are happening. The ROC has become less honest than the tax return.

Visa and Mastercard are currently holding conferences with a number of large issuing banks, discussing what appears to be a another Heartland-like breach of another major payment processor. They have not announced who got hacked as of yet, but if I were a betting man, I would put my money one of the TSYS acquirees (ie Vital) or TSYS itself.

Any other bets?

You know, alot of people have been discussing the fact that what appears to be the biggest credit card compromise to date was reported to the public on inauguration day, and how this is an attempt to bury the news in all the other hype.

What is more interesting however, are the sketchy details that we have about what actually happened.

The supposed facts according to Heartland (per Brian Kreb’s article)

• Heartland does “not know” how long the breach has been taking place.
• The company processes 100 Million transactions per month.
• Malware was involved.
• Data was being sniffed.
• The company is claiming that full track data was not compromised.

There have been alot of suggestions that this was an “inside job,” but I am skeptical.  It is unlikely an employee of the organization wrote the perfect custom malware solution to rip the company off, and established a relationship with some overseas criminal mastermind to offload hundreds of millions of card numbers.

I think that more likely, someone at Heartland didn’t set up host-based security properly in addition to the perimeter being soft, and the systems in question didn’t get included as part of the PCI sample set, so noone caught it.

Furthermore, the data obviously wasn’t being encrypted in transit – by Heartland’s own admittance -it was grabbed off the wire.

In as far as the malware is concerned, File Integrity Monitoring (required by PCI) should have caught this. Also, the required IDS/IPS solution should have seen a bunch of weird stuff going out over the wire.

What will the overall ‘lesson learned’ from this breach be?

My prediction: Data Loss Prevention products are going to be required at ingress/egress points on the cardholder environment. Another prediction: This will be released as a clarification / addendum before the next dot release of the DSS (1.3).