Network Security Blog

I’m a big fan of tokenization and end to end encryption (E2E2).  Never mind the fact that neither technology is fully developed, nor do we even have a real definition of either technology.  The fact that both of these technologies have the potential to take credit card information our of the general merchant environment and gives the bad guys less reason to attack is enough for me.  It won’t stop attacks against merchants all together, but it will cut down on the value of breaking in and therefore cut down on the number of attacks, at least in theory.  It will also cut down on merchants’ responsibility for meeting with the PCI DSS requirements, since much of environment that the QSA’s have to review will now be out of scope.  But without the threat of PCI (and potential fines/fee increases) will merchants keep up the minimum security safeguards that PCI mandated or will they revert to their old ways and ignore security for the most part?

One of the big questions that comes up over and over again is how effective is PCI in securing the merchant environment.  And the answer is, no one really knows.  Breach disclosure laws prior to 2003 were non-existent, and even once California passed SB1386 and got the legal ball rolling, breach disclosures have been spotty at best.  Now that we’ve got some 40 states that have some form of breach disclosure law, the information we’re able to gather is much more consistent.  Unluckily, we still lost the ability to have any real baseline to measure the success of PCI against and anyone who says that PCI is or isn’t effective is mostly going on their own anecdotal evidence, not hard data.  Verizon’s Incident Metrics Framework may help in gathering statistics going forward, but we’ve already lost the data needed to measure the effectiveness of PCI.  (Disclaimer:  I work as a QSA for Verizon Business)

As tokenization and E2E2 take hold, we’re going to have another chance to see how effective PCI is in securing the merchant environment and whether or not merchants are really going to secure their environment without the threat of PCI hanging over their heads.  There’s almost nothing in PCI that a shop with a good security program shouldn’t be doing in the first place.  Firewall reviews, anti-virus, log monitoring, IDS, etc. are all safeguards that are mandated by PCI but are security measures that any good security shop should be putting in place for their organization by default.  The fact that many organizations couldn’t get the funding for some of these tools until PCI came along is a measure of how hard it is to get the budget for security.  And if organizations start losing the funding for these projects because tokenization and E2E2 have taken the majority of their systems out of the scope of PCI, we’ll know that PCI was the real driver for the safeguards, not any real concerns over security.

PCI is expensive.  Security is expensive.  Not necessarily because the tools are expensive, but because merchants ignored security for years and have had to spend a lot of money and time to implement the tools they should have been running in the first place.  If they can reduce the scope of the systems they have to protect through new technologies and no longer have to be assessed on an annual basis, do you think they’re going to keep paying for the tools that they implemented just for compliance or do you think they’re going to let their IDS and log management tools fall by the wayside?  I know that some of the shops I’ve seen will keep the tools and keep using them properly.  But I think the majority of merchants are going to go back to their old ways and do the bare minimum that their security group can fight to keep.  If your company’s marketing department depends on PCI to make sales, I’d be very afraid of tokenization and end-to-end encryption.

We’ve been hearing about the Aurora attacks on Google and a host of other companies since early January.  So why is it that NSS Labs is finding that the majority of the End Point Protection (aka AV) companies aren’t protecting against the vulnerability yet?  And why is AVG upset with NSS Labs and their testing methods? To answer these questions and many more, Rich and Martin were joined tonight by Vikram Phatak, the CTO of NSS Labs.  Vik gave us some of the back story on why they were testing AV products and some of the surprising discoveries they made.  It’s not easy being an independent testing company and sometimes you’re going to annoy people despite your best efforts.  And sometimes people are going to be annoyed with you no matter what.

One point Vik wanted to make that didn’t make it into the podcast is that the 0day that was used in the Aurora attack is not just being used against corporate targets.  It’s being used against consumers as well, so it’s important that the average home user be aware that their AV product may not be protecting them at this point.  What is part of the podcast is a discussion of how many AV vendors are trying to protect against the payload that malware is attempting to deliver, not the exploit itself.  Both are important points people need to be aware of.

Network Security Podcast, Episode 189, March 16, 2010
Time:  39:56

Show Notes:

• Vulnerability-based protection and the Google “Operation Aurora” attack
• NSS Labs’ Questionable Report – Note that the screen shot shown is of the Firefox browser, not IE in any form
• AVG & The Aurora Exploit
• Questionable Questions (and some answers)
• 7th Annual ISSA Security Conference
• Please take our short listener survey to help us create a better podcast!

One of the things I don’t believe we see enough of in the security field is independent testing.  Vendors of all stripes make claims about what their products do, and without independent testing it’s hard to tell if they’re the cream of the crop or a bad apple.  ICSA Labs is one of the few companies that do the sort of testing that’s needed to provide the information to tell the two extremes apart.  I took a few minutes to sit down with Andy Hayter of ICSA Labs to talk about anti-virus testing, education of consumers and a new initiative to use the testing ICSA does in the real world.  For the sake of transparency, ICSA is a part of Verizon, the company I work for as well.

NSP-RSAC2010-ICSALabs.mp3

As a PCI QSA, one of the big technologies I’m looking at this show is end-to-end encryption (E2EE).  So it’s no surprise that my first interview of RSA 2010 is with Mark Bower, the Director of Information Protection Solutions at Voltage Security.  We talk about what E2EE is, how it will affect merchants and what we might be seeing in the future from Voltage SecureData Payments POS SDK.  I hope that we’ll see adoption of Voltage’s SDK or something very similar in the coming year, we need to help merchants protect cardholder data as close to the point it enters their network as possible.

NSP-RSAC2010-VoltageSecurity.mp3

My friend Alex Hutton and the rest of the RISK Team at Verizon Business have done it again! This time rather than release a report about breaches however, they’ve release the Verizon Incident Sharing Metrics Framework (VerIS for short).    All the awesomeness that went into creating the 2009 Verizon Breach Report is being shared with the incident response community so that we can compare apples to apples when it comes to compromises.  Rather than each company capturing it’s own unique dataset and creating statistics in their own particular way, VerIS is a framework that allows companies to capture the same sorts of data at the compromise and compare it directly to the compromises other companies are seeing.  This is exactly what we’ve been asking for since the first Verizon Breach Report.

One of the highlights of the year for me is when the Verizon Breach Report comes out.  Many of us have anecdotal evidence of breaches and know on a visceral level that if we don’t secure our networks and enforce policies that bad things are going to happen.  But the Breach Report is what allows us to take it from feelings and anecdotes to being able to show our company’s leadership exactly what lapses in security have led to many of the breaches in the last year.  If you haven’t read the 2009 Verizon Breach Report, stop reading this and go review it now.  After you’ve read that, you may also want to fill out some marketing surveys and read the Trustwave Global Security Report of 2010. Or at least read Rich’s short review of the report.  Including the part where he asks the folks at SpiderLabs to use a standard base of metrics.

The Verizon Incident Sharing Metrics Framework gives us the ability to start collecting one of the things security is sorely missing:  common collection and comparison methods for breaches.  Long ago and far, far away I used to be in the life insurance biz and one of the cornerstones of insurance is actuarial tables. An insurance company can look at your height, weight, sex, and several dozen other statistics and tell you very easily if you’re likely to die from some factor within the span of their insurance policy.  It’s no accident that as you become older insurance becomes more expensive.  They know exactly what your chances are compared to those like you, in large part because they’ve had centuries of common data to draw from and create tables how those factors affect your long term survival.  And as much as we talk about statistics in security, we’re a fledgling science and have a relatively small, confused dataset to draw from when creating our own actuarial tables.  We literally don’t even have enough information to know what we don’t know yet, let alone create any sort of meaningful security measure to breach relationships.   VerIS gives us a chance to start changing this.

Read the slick on what data VerIS is aimed at collecting and how it can be sliced and diced; I make no secret of the fact that I’m more of a consumer of the final information than I am interested in how it was collected.  But what I find fascinating and important is the goals Verizon Business is setting with this framework.  It’s not meant to be the last word in incident metrics; it’s only a starting point that other companies can extend.  VzB is actually looking for help extending the framework and making it as powerful as they can.  The VerIS Framework is meant to promote information sharing and if enough people contribute to the underlying datasets, we can get something important out of this as a community.  It’s not hard to add your own unique twist to how you slice and dice the information, but what’s important is that we have a common set of statistics to start from so we can know we’re comparing the same factors when looking at breaches.

It’s going to be a while before we have anything as deep and rich (and boring) as an insurance company’s actuarial tables.  But if a common framework gives us the possibility of being able to scientifically state what security measures are effective and which are only skin deep, VerIS is a winner.  One of the complaints about a compliance framework like PCI is that it doesn’t respond well to changes in the real world.  But what if the PCI Council mandated the use of something like the Verizon Incident Sharing Framework and made changes to the next version of PCI based on that instead of vendor and merchant wants and desires?  Now that would make PCI something truly effective.

*Full disclosure:  I work as a QSA at Verizon Business for my day job.  However everything about this blog is strictly my opinion and no one but my wife has more than a cursory influence on what I write here.

Richard Bejtlich had to take a couple of minutes yesterday to rant about someone who posted in a forum that we just need to protect the data.  Don’t we wish it was that simple?  Which form of the data is it we’re trying to protect?  At rest, in motion, encrypted, unencrypted, printed out, on your screen, at the POS, on the server, in the database, in the client/customer’s hands etc. etc. ad nauseum.  The basic thought from the original commenter was that if we just protect the data itself, none of what’s going on in our network should matter, since the data itself is safe.  But as Richard points out, it’s impossible to separate the data from the servers and networks that it exists on, and therefore ‘protecting the data’ just isn’t enough. 

Let’s use Heartland Payment Systems as an example: a piece of code on the servers that were processing the cardholder data was compromised and the data was being stolen in the brief time between when it was received over a secure connection and when it was encrypted.  Simply protecting the data fails here.  There’s no iteration of protect the data that could have possibly worked here.  The data had to be in an unencrypted state for a brief time; it was impossible for it to go from the encryption of SSL to another form without existing in an unencrypted form during the process at some point.  Which is why the simple maxim of protecting the data itself is always going to break down at some point; in order to be usable, the data is always going to have to be in a vulnerable, unencrypted state at some point.  Which is why we will always have the concept of defense in depth in security and why we need overlapping security controls that cover for each other’s weak points.

There’s no one true way to data security.  Ask the physical security guys who have centuries of history and lessons to draw from.  Every security measure has it’s weakness that will be exploited at some time, no matter how small.  There aren’t simple ‘just do X’ answers in our chosen profession, it’s always going to be about making trade-offs between security, usability and resources.  Some security philosophies work better than others, but just like security measures themselves, we have to embrace a set of overlapping security philosophies just like we have to have overlapping security measures.  Otherwise we’re just fooling ourselves and leaving blind spots for the enemy to exploit.

Bill Brenner’s recent article, 4 ways to get the most from your PCI QSAs, hits the nail on the head.  His very first point is especially germane in my experience; merchants and service providers need to be sure they’re picking a QSA company that can successfully evaluate their particular environment and is not just the lowest bidder.  Too many companies treat PCI and their QSA as a nuisance that they have too put up with for several weeks a year and can ignore the rest of the time.

My best assessment experiences have been with companies that treat PCI and their QSA as a way to effect change in their environment and are honest with themselves and the QSA.  I’ve often asked the security manager of a company what they need to do to secure their corporation and what I can do as their consultant to help affect those changes.  It’s often surprising how many security measures have been resisted by management when the request is coming from internal security but will be okay’d the moment an external consultant or assessor mentions how the measure will help make compliance easier.  I’m sure I’m not the only one who’s ever used an external authority figure, like a QSA, to push for a new tool or policy I needed to secure my enterprise.

Another point in Bill’s article to be especially aware of is that your QSA is going to find weaknesses in your enterprise if they dig.  It’s a fact of life that mistakes happen, configurations get changed, policies aren’t written as tightly as they could and that we’re all human.  I have yet to discover an enterprise that I couldn’t find some system misconfigured or a minor point of the PCI requirements misinterpreted.  The secret is to build a relationship with your assessor before that point so that you feel comfortable with this discovery, that it is taken as a positive event that allows you to learn and that the assessor isn’t a bad guy trying tear down your hard work.  Every QSA I’ve ever talked to about it is trying their hardest to help you secure your enterprise and leave you in a better security stance than when they arrived.

The worst experiences I’ve had as a QSA are with companies that thought I was their enemy or that the best way to get through their assessment was to try to distract me from what’s really happening in their enterprise.  The best you can hope for under those circumstances is that you’ll pass your assessment, but you won’t actually gain anything from the experience the QSA brings to the table and your enterprise.  You may have gotten certified for another year, but it undermines your own security and the effectiveness of the PCI process.  In a worst case scenario, you won’t pass your assessment because of what the QSA ends up finding despite your best efforts or you’ll pass your assessment by covering up insecurities and end up being compromised through one of the systems you hid during the assessment.

I imagine there are a fair number of people out there who are like me and instead of a cup of coffee and the morning paper they take the same cup of coffee and open up their favorite news sites online to get the morning’s news.  So I imagine there were more than a few people who were surprised yesterday morning to get a little something extra when they opened the New York Times site yesterday and got a pop-up ad telling them that their computer was infected with several hundred viruses and that they needed to buy some wonderful new anti-virus product to secure themselves.

We don’t know exactly how the NYT site was compromised and this code implemented, but there is a good analysis of the malware at Inputs & Outputs.  The ad used a scare tactic but by itself it didn’t do much.  But this phishing scheme did point users to a small program that probably did some very interesting things to the end user’s computer if you believed you actually were infected.  If you’re a Firefox user with NoScript installed, you probably didn’t even notice that this fun piece of code had been added to the NYT site.  Score one more for blocking scripts by default.

Looking at the analysis of this compromise, it appears that the code wasn’t directly on a NYT server, rather it was served up by one of the third-party services that provide ads for the NYT.  Once again, it shows that even if you trust a particular site you’re visiting, the interaction between that site and the secondary systems supporting it offer a great attack vector for the bad guys to gain access through.  The New York Times probably has a great security team who’s up on the latest vulnerabilities and does an excellent job protecting their site, but if the other companies they rely on for additional code can’t protect their systems, even the best team at the NYT won’t be able to do a thing.  It’s something for anyone who relies on third-party code on their site to think about.

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.