Network Security Blog

Once again it’s time to clean out my cache of tabs in Firefox.  I’ve found that open and closing tabs as much as I do hastens the memory leaks in Firefox.  Or at least my perception of them.  So it’s a good time to capture in a blog post the articles that I’ve found most interesting in the last week and restart Firefox to recapture that memory.  Now if only I had a way to do the same for myself.

Monday morning reading:

• How hackers snatch real-time security ID numbers – Whatever one man can secure, another man can break into.  I find it interesting that we’re starting to name virus techniques, since the viruses themselves have become so modular.
• Capability and maturity model creation in information security – Mike Dahn has written a guest post for IT Compliance Advisor.  He suggests that we have two main issues with reaching compliance and a real maturity model is needed to attain and maintain compliance.  Great article.
• ‘The Analyzer’ pleads guilty in $10 million bank hacking case – Sometimes they actually catch and prosecute the bad guys.  Not as often as we’d like, but I think it’s increasing in frequency.  
• Introducing Amazon Virtual Private Cloud (VPC) – I’m still deciphering the complexity of this but it seems the big selling point seems to be the establishment of a VPN connection and a private IP space.  Chris Hoff has always has a good dissection of this type of cloud computing news.
• Social network privacy study finds identity link to cookies – You mean we’re being tracked by our social networks?  
• Twitter XSS vulnerability not yet fixed – I’m not sure expecting Twitter to wave a magic wand and fix a major bug immediately is fair or realistic.  But it needs to get fixed quickly none the less.

Rich and I are both a little short on time today, so it’s a good thing I recorded an interview with Gregory Conti, West Point professor and security author last week.  We have a couple of stories we go over briefly and no lack of opinions to go with them.  In other words, pretty much the same as every week.

Network Security Podcast, Episode 164
Time:  41:01

Show Notes:

• Hacker ring tied to major breaches just the tip of the iceberg – Oh goody, there’s more coming down the pipeline that we haven’t heard of yet!
• Breaking News:  Mac OS X Snow Leopard built-in AV? – Does anyone care?  But it does give Rich a few minutes to gush about the security updates in 10.6.
• Greg Conti – Author of Googling Security and Security Data Visualization.  But not the guy you want designing your next web site.
• Tonight’s Music:  Swampcandy with Devil in her Suitcase

To get $300 off Hacker Halted 2009 in Miami, Florida from September 23-25, click on the banner below, select VIP Pass under Conference Pass and and enter code “HHUSA-MM-AP999“

I almost feel bad; my co-host Rich Mogull organized a PCI roundtable to allow some of our friends in the security world to go off on PCI and more specifically Heartland.  I say almost, since as a QSA I probably would have to have been on the defensive for the whole conversation.  They attack the myth of ‘PCI==Security’ and take CEO’s who assume that PCI is responsible for securing their company.  I love hearing the opinions of a bunch of security curmudgeons like Mike Rothman, Alex Hutton, Nick Selby and Josh Corman.

There’s a little harsh language, so if you’re sensitive to that, skip this podcast.

The Ranting Roundtable – PCI

Martin is back this week as we discuss some of the most fascinating drama to come out of the security world in quite some time. As the initial indictments for the Hannaford and Heartland breaches go public, all sorts of fascinating tidbits emerge. There are double crossing informants, Russian connections, and secret breaches that haven’t hit the public yet. We also finally learn exactly how most of these breaches occured. Heck, it’s almost interesting enough for a TV movie!

Network Security Podcast, Episode 163
Time: 38:44

Show Notes:

• Rich writes a letter to the CEO of Heartland. He is not expecting a Christmas card.
• Rich covers all the drama of the Heartland and Hannaford breach indictment.
• ATM skimming ring hits Chicago. And the banks didn’t bother to warn anyone.
• Hackers reverse-hack the police that busted them in Australia.
• DNA evidence can be fabricated.
• Tonight’s Music:  Coffee Man by Calvin Owens

To get $300 off Hacker Halted 2009 in Miami, Florida from September 23-25, click on the banner below, select VIP Pass under Conference Pass and and enter code “HHUSA-MM-AP999“

Rich Mogull took the time to read through the entire indictment against the hackers who targeted not only Heartland, but also 7-Eleven and Hannaford as well.  The first thing that really leaps out at me about this is that the attacks were using command execution via SQL injection or XSS via SQL injection.  Given that these are both methods of attack that the PCI DSS specifically calls out to protect against, this blows a pretty big hole in the case Heartland CEO Robert Carr made that his QSA let him down.  We’ve known about SQL injection for years and there should be no need for a QSA to tell a company or it’s security team about the problem.  There should also be no reason that SQL command execution should be enabled on any SQL server that’s exposed to potentially malicious traffic.   As Rich points out, on most modern SQL servers, this is a capability that has to be enabled, not a feature that’s turned on by default.

It’s a little surprising to me that one group of hackers is connected to so many high profile breaches, including TJX, OfficeMax and Dave & Busters.  Are they an isolated group who managed to find a way into these networks or are they just the group of hackers that was stupid enough to get caught?  The possibility that these guys are just the hackers who were unlucky enough to get caught worries me, since their capture may lead a number of security professionals to breath a sigh of relief and get back to life as normal.  Which means arguing with management to get new tools and toys for the network while ignoring serious configuration errors like having SQL command execution enabled on transaction servers. 

Sigh.  I’d figured this out on a gut level some time ago, but it’s disheartening to see it actually put down in writing: A security breach won’t affect a company’s reputation in the long term.  Or even that much in the short term.  If the TJX compromise taught us nothing else, it’s that the average investor doesn’t follow the breaches or doesn’t care about the impact a company’s security has on it’s customers if they do.  TJX actually used their compromise as a marketing opportunity and showed a minor uptick in business after the compromise.

As Larry Walsh points out, reputation fluctuates by a company’s actions and security is only a minor part of reputation.  Based on what we’ve seen historically, it’s only a very small part, which is incredibly sad.  People either don’t understand or don’t care about what a breach is going to do to their privacy and credit.

I finally had the time to sit down and read the NSS Labs Web Browser Security Phishing Protection paper this morning. This paper is a test of the more popular browsers in use today and how well the reputation based systems they’ve built work to protect users against phishing attempts by malicious sites.  The big winners in the test were Firefox 3 (not 3.5) and IE8, which almost tied at 80% and 83% accuracy for blocking phishing sites.  Given that the study quotes a margin of error of 3.6%, the two browsers are equal for most intents and purposes.  The big loser of the test was Safari 4, which only had a 2% blocking rate for malicious sites.  I hope Safari on my iPhone is better than it is on my Macbook, or at least that there are less phishing sites targeting the iPhone.

It’s very interesting that Firefox 3, Chrome 2 and Safari 4 all use Google’s Safebrowsing data feed but have very different results from the same data.  Chrome 2 only had a 16% success rate in blocking, compared with Firefox 3 at 80% and Safari 4 at 2%.  So why the big difference between the three browsers running off of the same information?  NSS Labs doesn’t offer an explanation and apparently none of the developers did either, so either Firefox is pulling in a lot of additional information from somewhere or the Chrome and Safari developers have some learning to do.

What I personally found the most interesting about the paper though was that the Anti-Phishing Working Group is quoted as saying that the average phishing site only has a lifespan of approximately 52 hours.  None of the browsers really reach full effectiveness for blocking a phishing site for about 48 hours after the site has become active, therefore you’re only getting 4 hours of maximum benefits.  The long term trends look good, but it’s a little disturbing that many phishing sites are relatively undetected for at least the first 24 to 48 hours they’re live. 

I’d be curious to see how Firefox 3.5 changes this mix.  Apparently it wasn’t stable enough to be used in this test, but maybe we’ll see a new set of tests next quarter.  I’m also wondering what affect the FF plugin NoScript would have on the results.  Since NoScript isn’t strictly speaking an anti-phishing tool, I doubt NSS Labs will be testing it any time soon, but I’d like to know how much more secure it makes my web surfing experience.

Now to go back and read the Socially Engineered Malware report. 

I’ve long said that as it currently stands, it’s going to be nearly impossible to become PCI compliant using any of the cloud based solutions.  Scanning, auditing and even the contractual requirements of PCI guarantee that you won’t be able to be compliant if you’re using the cloud.  The good thing is that at least Amazon is being perfectly honest about this and is telling their customers that EC2 and S3 aren’t compliant solutions, instead offering up their their Flexible Payment Solution (FPS) as a way to use their services in a compliant way. 

Be wary when looking at a cloud solution for processing or storing you business’ credit card transactions.  Not all of the sales people are going to be familiar with the PCI requirements and may steer you wrong.  They may believe that their solution is perfectly secure and is compliant, without realizing how difficult the scanning, or even the contractual, requirements are for a company to meet.  But best intentions won’t be enough if you’re relying on their solution to secure your transactions and make you compliant.

Here it is, straight from the horses mouth.  Twice.

Hi,

Thank you for contacting Amazon Web Services. Our payment system is PCI compliant and it is an “alternative payment processing service” meaning your users re-direct to our platform to conduct the payment event using their credit cards or bank accounts. The benefit for you is that we handle all the sensitive customer data so you don’t have to. If you haven’t looked at it, I highly suggest you check out the features and functions of our Flexible Payment Service and our Payment Widgets ( http://aws.amazon.com/fps).

As for PCI level 2 compliance, that requires external scanning via a 3rd party, PCI-approved vendor. It is possible for you to build a PCI level 2 compliant app in our AWS cloud using EC2 and S3, but you cannot achieve level 1 compliance. And you have to provide the appropriate encryption mechanisms and key management processes. If you have a data breach, you automatically need to become level 1 compliant which requires on-site auditing; that is something we cannot extend to our customers. This seems like a risk that could challenge your business; as a best practice, I recommend businesses always plan for level 1 compliance. So, from a compliance and risk management perspective, we recommend that you do not store sensitive credit card payment information in our EC2/S3 system because it is not inherently PCI level 1 compliant. It is quite feasible for you to run your entire app in our cloud but keep the credit card data stored on your own local servers which are available for auditing, scanning, and on-site review at any time.

Regards,

Amazon Web Services
http://aws.amazon.com

and

Hi Jason,

 

Thanks for contacting us.  I manage sales for AWS in the Southwest Region.

 

We are excited to hear about your interest in moving to EC2.  We do not and will not provide a written agreement attesting compliance and assuming responsibility for cardholder data.  Please see below for our general guidance on PCI compliance.

 

From a compliance and risk management perspective, we recommend customers not to store sensitive credit card payment information on EC2/S3 systems as they are not inherently PCI level 1 compliant. It is quite feasible one to run an entire application in AWS cloud while keeping the credit card data stored on within the local servers at the customer site, which are available for auditing, scanning, and on-site review at any time.  As for PCI level 2 compliance, that requires external scanning via a 3rd party, PCI-approved vendor. It is possible for you to build a PCI level 2 compliant app in our AWS cloud using EC2 and S3.

 

Flexible Payment Service (FPS), which is AWS payment system is PCI compliant and it is an “alternative payment processing service” meaning a customer’s users re-direct to our platform to conduct the payment event using their credit cards or bank accounts.

 

Let me know if you any follow-up questions.

 

Thanks,

 

<name removed>

Account Manager

Amazon Web Services

http://aws.amazon.com

You can view the full thread on the Amazon site.

This morning when I collected a bunch of PCI articles I thought people might be interested in, I thought that was going to be end of it.  Not much could have been farther from the truth.  The PCI furor caused by the comments of Robert Carr has grown, with some serious outrage and some even more serious thought about who’s responsible for securing the enterprise.  I think it’s very good, we need to have this sort of debate for people to realize that it’s not the responsibility of a compliance program, an auditor or an assessor to secure a network.  People like me are there to validate the protections that are in place, but it’s the people who manage the network to secure it.  And the ultimate manager of the network is always the CEO.

• PCI, QSAs, Hackers and Slacker: Will the real enemy please stand up? – Bill Brenner tries to take a moderate approach to the original article.  Which I personally find inappropriate, but he’s allowed his opinion.
• Heartland CEO and Outrage – I think Adam’s defending Mr. Carr.  Either that or he’s saying that the outrage is just as wrong as the original statement, but that would be insanity.
• Incomplete Thought:  Compliance, Governance, Audit and Risk aka GRC We’re doing it wrong – “It’s all about risk, even when you don’t think it is.”  Very true words.
• Bob Carr:  “QSA’s let us down.” And things never heard by a QSA – “Please, penetrate my network deeper”  That just sounds wrong.  And I know I’ll never hear that from a client.
• The Auditor’s Prerogative – No network is so squeeky clean a decent assessor can’t find at least one mistake.  But that doesn’t mean the assesor is the enemy.
• Standards aren’t security: PCI compliance and Heartland’s data breach – A secure network often means a compliant network.  But a compliant network only sometimes means a secure network.  Therefore COMPLIANCE DOES NOT EQUAL SECURITY! 

Here’s the latest in the series of interviews I gathered at the FIRST Conference in Kyoto, Japan this year:

Episode 11: Sherri Davidoff and Jonathan Ham, Proprietary Data Leaks
In this at-the-conference interview, Sherri and Jonathan recap their presentation, add insight and talk about their new SANS course being offered. Sherri Davidoff is a longtime information security consultant specializing in forensics, penetration testing and incident response. Jonathan Ham is an independent consultant who specializes in large-scale enterprise security issues.