Network Security Blog

Martin is back from Vienna, but Zach is off in NYC. Thus Rich and Martin catch up, talk about the cloud security class and the rest of the security news. Martin is surprisingly coherent despite the jetlag.  Some might argue that Zach is one of the few things that keep Martin and Rich from rambling at length.  And they might be right.

Network Security Podcast, Episode 244, June 21, 2011
Time:  37:36

Show Notes:

• Dropbox opens everything for 4 hours. Yipee.
• How to encrypt your stuff on Dropbox.
• LulzSec caught? Yeah, we had to talk about them.
• People messing up and embedding keys in their Amazon AMIs.
• Deception- new social engineering TV show.
• Tonight’s music:  Merchant of Chaos by Jacob Bratton

I make no bones about it, I’m a very big fan of the concept of tokenizing credit card numbers as early in the merchant stream as possible.  For some merchants this will mean that they are replacing their credit cards with random tokens in their back end servers, using the token internally, but still storing the credit card in a heavily defended server somewhere in the data center.  For other merchants tokenization will mean encrypting the data at the PIN pad, sending it to their acquiring bank and receiving a token to use in place of the credit card number within their own systems and thereby taking most of the merchant’s systems out of scope for a PCI assessment.

These sound like, and are, both worthy uses of tokenization, there’s a lot of confusion about the difference between these two extremes of the technology and especially about how these differences can affect your implementation and scope!  Which is why I’m glad to see an article like Walter Conway’s, “Playing Token Trick or Treat“.  As much as many people would like to see a straight forward review of specific products that allow for tokenization, this is still to much of a nascent technology for reviews to be realistic or useful.  Anyone who implements a tokenization solution will be on the cutting edge, and in many cases will be beta testing technologies for the manufacturers.  It’s early enough in the process that by being involved in a tokenization project, you can actually have a large influence on the products we see over the next few years.  Which is exactly why it’s so very important to know exactly which questions to ask when evaluating and implementing a tokenization solution.

Walt’s first question is probably the most important of them all, “Have you found all your cardholder data?”  Even if you’re not assessing a tokenization solution, this is an important question to be asking yourself on a regular basis.  And once you’ve asked it, go back and ask again.  And again.  And again.  Until you’ve asked half a dozen or more times and continue to ask every few months, you won’t have any level of certainty that you’ve found it all.  Even then, it’s possible you’ll develop a leak somewhere and cardholder will pollute portions of you’re network that were never intended to hold or secure cardholder data. 

Walt has a good number of other questions you should be asking if you’re assessing, or just curious about, a tokenization solution.  Make sure you understand the possibilities and the pitfalls of any solution before you make the leap of faith required to implement such a young technology. 

Update 10/11/10:  Here’s the second article on tokenization and some of the questions to ask, “If your token vendor goes bankrupt, what happens to your data?”

We’re all back on the air and Mad Mike Rothman has been put back in his cage.  Okay, maybe not his cage, but between Rich, Zach and Martin, there’s not room for one more loudmouth this week.  Besides, we actually getting the three of us around the virtual coffee table to kvetch.  Zach is on the road, so he phones it in this week and Martin gives a quick review of the PCI Community Meeting without actually revealing anything that went on.  That would be against the rules. 

Network Security Podcast, Episode 214, September 29, 2010
Time:  40:40

Show Notes: 

• Witty Banter (’cause if we say it enough, we might start believing it)
• Iran confirms massive Stuxnet infection of industrial systems
• Stuxnet worm: facts first
• Lockpicks by Open Locksport
• ElcomSoft turns your laptop into a one-touch Wifi cracking system
• U.S. wants to make it easier to wiretap the Internet
• New payment tokenization service unveiled for Akamai Cloud
• Music: Lance with Rise and Shine Hero

I am not a lawyer and I don’t even pretend to understand the complexity of our patent system when it is applied to software, but I’m always astounded when company’s file lawsuits based on broad, over-arching technology solutions.  I find this especially distressing when it affects a market that is, in itself, a fairly simple idea, like database encryption.  So when I received a press release from Protegrity stating they’d filed suit against Ingrian, Safenet, NuBridges and Voltage this morning, it did not sit well with me.

I’ve seen too many companies over the last decade that are nothing more than patent trolls who acquire patents specifically for the purpose of lawsuits.  Protegrity clearly is not a patent troll, they’ve been very active in the database encryption market and likely have every right to file this lawsuit.  I’m more concerned in a number of ways with the turn our patent process has taken since software patents were allowed than this particular lawsuit, but I’m hoping that Protegrity isn’t using a legal attack to take out some of it’s biggest competitors in the field of database encryption.  Only time will tell if it has that affect, whether it’s intended or not.

The other thing that really worries me is the affect this will have on the still young end-to-end encryption market space.  Will the potential of a lawsuit based on these or other patents related to E2E have a chilling affect on new technology that shows the potential to make huge improvements in credit card security?  Or is there so much money to be made in the E2E field, so many big names backing the smaller players, that the potential of a lawsuit will be overcome by the potential to make a profit?  I suspect the potential lawsuits will make companies think twice, but in the end the potential profit will quickly overcome any worries about lawsuits.

As always, read the press release, read between the lines and make your own decision.  I’ve included the entire press release below the break for your review.

Continue Reading »

I really wish I had the time to fully explore the idea, but there’s a certain amount of resonance between the criticisms Adrian Lane at Securosis levels against Visa’s guidance on  tokenization and criticism of the PCI security standards in general.  I believe we’re to the stage as an industry that we mainly agree that the PCI standards are a good starting point but there’s so much more the PCI Council could be requiring merchants and service providers to do for security.  Visa’s guidance is much the same way, it’s a good start, but it could have been so much more.  And in both cases, I believe the reasons for the compromises can be boiled down to not wanting to require too much of the community and not wanting to limit the flexibility of the standards too much.

I believe that the Visa best practice papers for tokenization and truncation are just like the PCI standards themselves; they’re a good place to start your journey, but these requirements aren’t enough to build your entire security stance from.  It’s up to you to continue from here to determine how the particular technologies are going to impact and secure your environment.  I think the difference between providing guidance and issuing edicts is something we’ll be talking about next Sunday at Defcon, so this is good timing.

I agree with many of Adrian’s criticisms, including that Visa could have just given more specific guidance overall.  But I also understand Visa’s need to keep the guidance vague enough so as not to provide undue direction to what is basically a fledgling market space.   Which is exactly where I see the tie in with Josh Corman’s primary argument about the PCI Council; intentionally or not, they are steering the security market space through the PCI standards.  Visa could be a force for good in the tokenization and truncation markets if they predict correctly and back solutions that are for the best over the long term.  Or they could be seen as stifling innovation if they issue poor guidance.  Much like the PCI Council.

Earlier today I heard someone make the statement that the majority of companies who are compromised are using encryption in some form, but they still got compromised.  He was reminding me that none of the other silver bullet’s we’ve thought would save us from the bad guys have worked, so use truncation and tokenization, but know they won’t solve all our security issues.  As is so often the case, they’ll just move the attack to other targets and use other vectors.

If you’ve been thinking about using tokenization or truncation to limit the scope of your PCI environment, you need take a few minutes to read the two documents Visa just released, Visa Best Practices: Tokenization and Visa Best Practices for Primary Account Number Storage and Truncation.  Neither of these documents are more than four pages in length, so they only take a few minutes to read, but they give you a good starting place for asking questions about both of these market spaces.  There’s nothing exciting or unexpected in either of these documents and you’ll need to do a lot more research to understand the more complex elements of both solutions, especially as they relate to your specific environment. 

If you’re part of a merchant organization or somehow dealing with credit card numbers and you’re not considering tokenization or truncation, why not?  Is it lack of time, lack of resources, lack of management backing or something else?  Have these technologies simply not risen to the level where you felt the need to take them seriously?  I’m curious as to why you might not be looking at a technology that could limit the amount of sensitive information on your network.  I’ve talked to a number of merchants over the last year and there’s been plenty of interest in the ideas of tokenization and truncation, but I’ve only seen a few merchants actually making a move towards implementation.

I hope the next guidance we’ll see comes from the PCI Council, giving instructions on how both of these technologies can be used to reduce the scope of a PCI assessment.  What can you take out of scope?  What common mistakes might bring systems back into scope?  What should we be looking for in an implementation?  These are still relatively new technologies, the implementations differ significantly enough that greater direction and care are going to be needed in their assessment and validation.  There are some things that are laid out in the Visa documents, but I think we need to look for more specific guidance from the Council.

It may not quite be VPN for Dummies, but Astaro RED sounds pretty close if you ask me.  I talked to Jan Hichert at Astaro about RED (Remote Ethernet Device) at RSA earlier this year and the way he talked about this new product, it seems like it’s an easy way for companies to add a remote office without many of the headaches this often entails.  I haven’t played with it myself and haven’t talked to anyone who has yet, but at least in theory it sounds like a good product.  Basically, you run Astaro Security Gateway at your central office, when you bring the remote RED box online, it phones home to Astaro, where it receives instructions on how to connect to your central office server.  There is configuration, but it’s mostly handled by Astaro before it ever gets to your office.  I’m sure Jack Daniel can tell you more if you’re interested, but in the mean time, the press release follows after the break.

Continue Reading »

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.

So Symantec bought VeriSign’s Identity and Authentication Business today for $1.28B in cash.  A large part of this is the SSL Certificate service and their Public Key Infrastructure.  So what?  Both SSL certs and PKI are mature, stable technologies without much room for growth at the moment.  I’m not sure how this strategy is going to play out, I don’t see that this something dynamic enough to engender excitement in anyone in the security community.  I’m also not the type of blogger who can look at this purchase and find deeper meaning in it; which is why it’s lucky that I have friends like Mike Rothman to take a longer look at Symantec’s purchase.

PS. Symantec had a webcast earlier today that might have made this clearer to me, but I was unluckily on the road at the time and couldn’t listen in.

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