Critical Assets – Security and Compliance

hax0rz oh gn0!

I’m addressing this about 6 months too late, but there was an extremely repetitive, relatively ignorant article that was written by M. E. Kabay which rehashes the topic of whether or not you should hire hackers for what seems to be the hundredth time. There are additional comments on Brad Johnson’s blog here:  http://systemexperts.blogspot.com/2009/10/hiring-hackers-please-dont-by-brad.html

The only people who argue against hiring hackers are people who are riding their coat tails, or trying to create controversy that simply isn’t there. Put simply, the information security industry was -created- by the very  hackers that the article suggests you shouldn’t trust. The concept of compliance regimes, security standards, controls, and technologies like firewalls, IDS/IPS, DLP, etc… wouldn’t exist without the need for security, and the need for security is addressed by these companies… right… the ones created by hackers.

In fact, suggesting that you shouldn’t ever hire a hacker to work on your security project is analogous to suggesting that a doctor who has performed exploratory surgery on a patient with success is somehow less qualified to address your ailment.

Chris and Al,  both of whom I have seen own various parts of our nation’s infrastructure first hand, are two of the most respected early security technology executives in the industry. Maybe you’ve heard of their companies: Secure Networks, and ISS.  Sorry guys, you’re outed. It’s been like 20 years, so I’m pretty sure you’re safe from a statutes perspective. Point being that hackers are the primary people who are responsible for you having an industry to work in.

Its just funny to me that people are still having this conversation, because the argument that no one should hire hackers is silly. If you want to buy a product or have a service executed that even remotely involves security, you WILL be hiring a hacker, and you don’t really have a choice in the matter. If you end up with zero hacker involvement, you may want to review the efficacy of the product or service you just bought.

Whenever we do a pentest that has a social engineering phase in it, an important part of the test is to consider all of the parties involved, the vector of attack, and the potential outcome of the attack. By doing this, you

only add the necessary amount of risk to the business required in order to demonstrate the vulnerability.

Either that, or you trigger an emergency alert scenario that goes out to all credit unions on behalf of the NCUA.

This happened during a penetration test being run by a company called “Microsolved” which was being conducted for a specific credit union.

This is a pretty clear example of how a poorly planned social engineering scenario can backfire, and falsely alert thousands of people to a scenario that doesn’t exist, wasting potentially millions of dollars in prep time and execution of incident response plans for an incident that didn’t exist.

Don’t get me wrong, mock scenarios are great for testing plans. They are however, not that great when they

exercise plans of companies who are not involved in the penetration test.

Furthermore, the guy at the bank who was responsible for the pentest apparently went on vacation while the test was occurring:

“But, on the day the package was received, the person responsible for the test was out of the office. So the employee who received the suspicious letter, which bore a NCUA logo and the bogus signature of former Chairman Michael Fryzel, reported it to the NCUA fraud hot line.”

The other part of this story that I found fascinating is the NCUA’s response to all of this, which pretty clearly had little to no executive involvement, and wasn’t reviewed by anyone with responsibility for security or compliance. They say, and I quote:

“Credit unions are not authorized to create facsimile documents bearing NCUA logos or signatures, or to improperly represent communications from NCUA, even during the legitimate conduct of business, such as a computer security assessment.”

Seriously? The federally sponsored organization that supervises federal credit union activity is more concerned with….improper logo usage than they are with the implication that they were tricked into sending out alert letters to nearly 8000 companies.

I guess I’d better take this Kellog’s sticker off my sniper rifle. They might get the wrong idea about me being a cereal killer.

In a move that everyone seems to think is paramount, but in actuality was truly inevitable, a QSAC is being sued over delivering a compliant ROC to an entity that was compromised.

The only surprising part is that its Cardsystems. Right… the one you kept hearing about over and over, about 5 years ago. The Cardsystems board was forced to sell thecompany to PayByTouch Processing as a result of Visa  taking the company off of VisaNet post-breach. I know this case all too well. I’m the one who did the follow up assessments post acquisition.

From the wired article:

“Visa executive told an audience earlier this month that the companies were not compliant, though auditors certified they were. “No compromised entity has yet been found to be in compliance with [the standards] at the time of the breach,” she said.”

I love how Visa and the SSC keep sticking to their guns on this one even though everyone knows its a bag of BS. I even call it a bag of BS on the interview I did with exotic liability. Why is it BS? Because anyone canwalk into any merchant or service provider, compliant or not, and find 1000 little nuances that probably don’t matter and use them interpretively to MAKE the merchant not compliant.

The bottom line here is that Cardsystems is going to drop this case. Why? Because they don’t have one!

First of all, QSACs and QSAs have NO legal or contractual obligation to provide an accurate report. They have a moral responsibility to do the right thing. Big whoop. Secondly, I know for a fact that none of the people who were working at Savvis and were on this project are still there, and good luck rounding them all up. Thirdly – Cardsystems as a corporation is nothing more than a shell at this point. I’m guessing that the judge will see right through this feeble attempt at a cash grab for what it is… completely lame corporate behavior with no merit.

On top of all that – why would you wait 5 years to suddenly decide that you need to lay blame for your own crappy security infrastucture work on an auditing firm who’s job it was to evaluate it for a 3rd party? Seriously, get a mirror. I’ve seen your network. Even in its repaired, remediated state, its not all that much to write home about.

Cardsystems – This suit is a joke. You’re not going to win. Try to fade out of the media limelight slowly so that noone notices how lame you are. By the way – nice job laying off all the people who fixed your security problems as soon as the heat was off (Hi Kurt, Hi Joe). That was a really classy move.

Savvis – Bummer fellas. I guess the good news is that your company is bigger than theirs, so you’ll win the standoff if that’s what it comes down to.

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).