Critical Assets – Security and Compliance

You might not remember the whole thing about hoverboards and the “behind the scenes” footage from Back to the Future -  Part II, but I do. There was this producer or director or some other sort of executive in charge of the movie, and he calmly explained that the hoverboard in the movie was in fact real. He then went on to explain in elaborate detail how it would soon be available in stores all over the US.

Not a hint of sarcasm, no jesting facial expressions. This guy was dead serious.

I know this because I was 14 at the time, and I swore that I would have one for my birthday. My buddy Eric was even hinting that he thought his mom had picked one up and stashed it away for Christmas already, fearing that they would sell out.

Well, as i’m sure you’ve already guessed, the joke’s on Eric and I, because there is no hoverboard. Never has been… probably never will be.

This is why I want to talk to you about “cloud security.” Now, I’m not implying that you’re 14 and gullible, but there are actual people out there who believe in this thing, and if you’re one of them, then you might also start examining why you started adding “ph” to everything that formerly started with an “f” in infosec, right about the same time everyone else did. Actual hackers stopped doing this in the early 90s. The industry started doing it in about 2003.

Scientifically speaking, there’s no way that cloud security can exist, because it has a dependency on “the cloud,” which I have yet to locate.

Do you know why the cloud cannot exist? because for something to be relevant nomenclature in technology, it needs to be something that has a net positive or negative effect on either most companies or most consumers. The cloud doesn’t matter, and I can prove it. Do this:

1. The name of your company is ______(A)________.

2. You currently rely on “the cloud” and the security of the cloud for _____B_____, ______C______, and _____D______.

3. The market space you are in is ________E_______.

4. A security technology that is cloud specific is: _______F________.

4. Assemble the following sentence:

Since i’ve been at ______A______, our ________B________ , ________C_______, and ______D_______ have enabled the company to  improve bottom line, increase productivity, and set an example in the _______E_______ industry, showing that obviously, we’re still a market leader, and that cloud computing has changed the way we do business, forever. Also, I try to stay childlike by perpetuating my belief in the existence of ______F_______.

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.

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