Archive for August, 2009

Aug 31 2009

Monday morning randomness

Published by under General

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:

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

One response so far

Aug 25 2009

Network Security Podcast, Episode 164

Published by under Podcast

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:

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

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

One response so far

Aug 20 2009

Ranting Roundtable on PCI

Published by under PCI

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

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

3 responses so far

Aug 18 2009

The Network Security Podcast, Episode 163

Published by under PCI,Podcast

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:

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

    [Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

    2 responses so far

    Aug 18 2009

    They didn’t just hack Heartland

    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. 

    [Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

    One response so far

    Aug 17 2009

    Security breaches don’t affect company reputations

    Published by under General,Privacy,Risk

    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.

    [Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

    2 responses so far

    Aug 16 2009

    Firefox and IE8 tied, Safari 4 loses big

    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. 

    [Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

    One response so far

    Aug 14 2009

    Cannot achieve PCI compliance with Amazon EC2/S3

    Published by under PCI

    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.

    [Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

    10 responses so far

    Aug 13 2009

    Thursday night PCI articles

    Published by under PCI

    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.

    [Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

    2 responses so far

    Aug 13 2009

    FIRST Podcast: Davidoff and Ham

    Published by under Podcast

    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.

    [Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

    2 responses so far

    Next »