The views of one man on security, privacy and anything else that catches his attention. The views expressed on this blog do not reflect the views of my employer or anyone other than myself.

Archive for February, 2010

Chaos ensues this week when Martin, Rich, and Zach are joined by more of the Securosis gang (Mike Rothman and Adrian Lane). Somewhere between jabs at Martin and chatter about, uh, “pay-for companionship” and “stimulants”, we actually talked about some security stuff. Who’da thunk?

Several months ago the organizers of the 2010 RSA Conference contacted me and asked me if I’d be interested in moderating a panel on responsible disclosure. Being no dummy, my first reaction was to do some research and make sure my podcast co-host weren’t trying to pull a practical joke. If you know Rich and Zach, you know that’s not a totally unreasonable assumption to make. But it turned out to be the real deal and I’ve spent the last couple of months working with folks and trying to organize what promises to be one of the highlights of the conference, at least for me.

I’m not a vulnerability researcher; I don’t work for a major software vendor. I am a customer of many of the same software vendors we all used on a daily basis and the vulnerability disclosure debate impacts my job as a security professional in more ways than I care to imagine. My first real exposure to the debate came in 2005 when Cisco hit Michael Lynn with a gag order just before his presentation on a major vulnerability at Black Hat. I was outraged that Cisco would treat Micheal Lynn like a criminal rather than owning up to the problem and creating a patch. I’ve mellowed a little since then but I’ve still kept up with the debate and the different ideas behind full disclosure, no disclosure and responsible disclosure. But what’s more than a little disheartening is that the conversation really hasn’t changed much since 2005 and researchers and vendors are still battling it out on a daily basis. We’re seeing the idea of responsible disclosure take the center of the debate and a few vendors have improved greatly, but as an industry, we still have a long way to go in actually improving the situation.

One of the problems, as I see it, is that we haven’t really defined what the ‘responsible’ in responsible disclosure really means. If we’re going to call it responsible disclosure, we have to break down and define what responsibilities vendor and researcher actually have to each other and the public. A second problem is that we’ve been treating this discussion as only having two sides, when there’s really a third actor on the stage, the customer. While the vendors and the researchers spend time yelling and sniping at each other it’s the people who’ve spent money on software that really suffer from the fallout of the arguments. We, the users and purchasers of software, don’t really have much of a voice in the conversation. At RSA 2010, we’re going to change that, at least for the day.

Join me on Wednesday, March 3rd at 10:40 am to discuss with a panel of industry experts exactly what responsible disclosure means to them and what responsibilities they owe each other. And we’ll have the people who are actually impacted by the debate involved to talk about how the actions of both researchers and software vendors affect their life on a daily basis. Michael Barrett, CISO of PayPal and Tim Stanley, CISO of Continental Airlines will get a chance to tell vendors and researchers that the current system isn’t working. HD Moore of the Metasploit Project and Steve Dispensa from Phone Factor will have a chance to air their own concerns about the disclosure process as researchers. Finally Katie Moussouris, Senior Security Strategist for Microsoft and Brad Arkin, Director of Product Security and Privacy can talk about how the process is evolving within their corporations. Given who’s involved, it promises to be fun and I won’t be surprised if there’s more than a little heat to the debate.

To give you a little taste of what’s to come, please listen to several short interviews with Katie, Steve and Tim where they lay out the basis for their stance on responsible disclosure. The discussion was calm during the interviews, but given how passionate each of these people are about the impact of this debate, expect some very interesting points to be made and maybe even some changes to how you view ‘responsible disclosure’

PCI (Payment Card Industry Data Security Standards) compliance and cloud computing are two great tastes that truly suck when you put them together. So much so that even putting the two concepts together in a sentence leaves a bad taste in my mouth. PCI compliance is a fact of life that most merchants have finally realized they can’t put off any longer or at least an annoyance they have to meet with if they want to continue to process credit cards at a reasonable cost. Cloud computing is the the tech buzzword of 2009/2010 that can do everything from save your company tons of money to cure the common cold. If it involves a computer, someone, somewhere is saying it can be done cheaper and faster if we’ll just ‘move it to the cloud’. Which is marketing speak for “we have a technology no one understands, so let’s throw it at anything people are spending money on!” Of course, since businesses are spending money on PCI, smart marketing folks all over the place are trying to get some of that money spent on ‘the cloud’. Thereby proving that the same marketing people don’t understand PCI and don’t understand Cloud Computing. While I don’t profess to understand cloud computing either (though I have friends that do), I do understand PCI.

If you’re not dealing with PCI on a daily basis, it’s easy to forget some of the subtleties. One of the main subtleties many people choose to ignore is that PCI compliance (and PCI validation, a rant for another day) are black and white propositions. You either meet with all 200+ PCI requirements and are compliant or you miss even a single requirement and you’re not. While there is some room for interpretation and compensating controls, if you don’t meet the intent of the PCI requirements, your not complaint and you won’t be validated when your QSA makes his annual visit. It’s a rude awakening for some folks when they realize that none of the requirements are optional. Not that I’m even sure you can have an ‘optional requirement’.

Phil Cox wrote a good article on why PCI Compliance in the Cloud is unlikely if not impossible given the current status of cloud computing and PCI. He has a good run down of the specific security measures required to be PCI compliant that can’t be met by any Cloud service provider at this time. Issues such as segregating merchant environments (are you REALLY segmented from your neighbors in the Cloud?), restriction of privileges so your Cloud neighbor can’t come visiting and log retention and auditing. These are some of the basic requirements of PCI as well as being some of the basic ideas for security in general. Keeping someone from jumping from their Cloud resources to yours is pretty darn important and something that’s going to be pretty hard to prove during your annual assessment without digging deeply into the technology. And having the log files to show what was done when and by who is vitally important when you’re doing your forensics after the compromise. Between detection and forensics, log review and management is one of the most important aspects of PCI, something you just don’t get with most (any?) Cloud providers.

However, what set’s me off about Phil’s article is his opening questions and the misconceptions it has the potential to propagate:

Can I be PCI compliant in a public cloud? If you do not store or process cardholder data in a public cloud, then it is possible to reach compliance with PCI-DSS. If you do store or process cardholder data in a public cloud, however, then it is my opinion that it would not be possible to currently achieve PCI-DSS compliance.

You can achieve compliance if all you are doing is securely transmitting cardholder data over a public cloud (similar to the Internet today).

If you do not store or process cardholder data in the public cloud, then you’re not really in the Cloud! You can have all of your web servers running on a Amazon EC2 server and then hand off the credit card transaction to a third party to process, but at that point you can be PCI compliant and in the Cloud, but you certainly are not ‘PCI compliant in the Cloud’. You’ve outsourced your processing and you’ve reduced the scope of your PCI environment to exclude the Cloud, but you’ve also divorced the two concepts from one another. And I’d argue that even allowing the cardholder information to be transmitted through your Cloud environment is enough to place your servers back into scope for your PCI assessment. Remember, everything that stores, processes or transmits cardholder data is considered to be in scope for your annual assessment. The only way for a system to be out of scope is if it has no access to cardholder data; being a conduit to another system is a form of access and therefore falls within scope for PCI.

Cloud providers know their services aren’t currently ready for merchants and PCI compliance. Amazon knew last year that their EC2 and S3 offerings weren’t going to be able to enable merchants to be compliant. They’re smart enough to admit it and train their staff to understand why their Cloud offerings can’t be used for PCI compliance. Cloud computing and PCI compliance are probably going to continue to be strangers at least through 2010; the newest version of the PCI requirements will be out later this year and major changes for cloud computing aren’t part of this revision. There may be a technical update or clarification concerning Cloud computing, but in all likelihood any major changes are going to have to wait for the next version of the PCI requirements, which won’t be issued until 2012. Either way, it’s not worth holding your breath for the changes.

The primary problem with attaining PCI compliance in the Cloud is an issue of visibility; there’s no way for me, as an assessor, to truly review and validate system configuration when your systems are temporary and could be deleted with a few clicks of the mouse. Cloud service providers should be and probably are looking at ways to offer up services that take advantage of all the positive aspects of cloud computing while still allowing for all 200+ PCI requirements to be met. Service providers are going to have to take a long look at how they manage the creation and deletion of virtual servers, segregation of resources and collection, monitoring and retention of log information. When you have to keep every log even once the virtual server has been consigned to the bit bucket, storage costs can skyrocket. Not to mention the headache of letting the QSA of each and every merchant you host look over your systems for PCI validation.

Don’t trust the marketing propaganda that tells you can be compliant while using their Cloud service. There may be a time in the not too distant future where PCI and cloud computing can live and work together, but it’s not now and it’s probably not going to be in 2010 at all. If you have to use the Cloud to save your company money, make sure you’re not asking your customers to enter their credit card number on the Cloud servers; either send the transaction to a third party processor or bring the transaction in house at that point. You can’t be ‘PCI Compliant in the Cloud’ but you can use cloud services and be compliant. Just make sure you don’t get any of your peanut butter on my chocolate.

PCI (Payment Card Industry Data Security Standards) compliance and cloud computing are two great tastes that truly suck when you put them together. So much so that even putting the two concepts together in a sentence leaves a bad taste in my mouth. PCI compliance is a fact of life that most merchants have finally realized they can’t put off any longer or at least an annoyance they have to meet with if they want to continue to process credit cards at a reasonable cost. Cloud computing is the the tech buzzword of 2009/2010 that can do everything from save your company tons of money to cure the common cold. If it involves a computer, someone, somewhere is saying it can be done cheaper and faster if we’ll just ‘move it to the cloud’. Which is marketing speak for “we have a technology no one understands, so let’s throw it at anything people are spending money on!” Of course, since businesses are spending money on PCI, smart marketing folks all over the place are trying to get some of that money spent on ‘the cloud’. Thereby proving that the same marketing people don’t understand PCI and don’t understand Cloud Computing. While I don’t profess to understand cloud computing either (though I have friends that do), I do understand PCI.

If you’re not dealing with PCI on a daily basis, it’s easy to forget some of the subtleties. One of the main subtleties many people choose to ignore is that PCI compliance (and PCI validation, a rant for another day) are black and white propositions. You either meet with all 200+ PCI requirements and are compliant or you miss even a single requirement and you’re not. While there is some room for interpretation and compensating controls, if you don’t meet the intent of the PCI requirements, your not complaint and you won’t be validated when your QSA makes his annual visit. It’s a rude awakening for some folks when they realize that none of the requirements are optional. Not that I’m even sure you can have an ‘optional requirement’.

Phil Cox wrote a good article on why PCI Compliance in the Cloud is unlikely if not impossible given the current status of cloud computing and PCI. He has a good run down of the specific security measures required to be PCI compliant that can’t be met by any Cloud service provider at this time. Issues such as segregating merchant environments (are you REALLY segmented from your neighbors in the Cloud?), restriction of privileges so your Cloud neighbor can’t come visiting and log retention and auditing. These are some of the basic requirements of PCI as well as being some of the basic ideas for security in general. Keeping someone from jumping from their Cloud resources to yours is pretty darn important and something that’s going to be pretty hard to prove during your annual assessment without digging deeply into the technology. And having the log files to show what was done when and by who is vitally important when you’re doing your forensics after the compromise. Between detection and forensics, log review and management is one of the most important aspects of PCI, something you just don’t get with most (any?) Cloud providers.

However, what set’s me off about Phil’s article is his opening questions and the misconceptions it has the potential to propagate:

Can I be PCI compliant in a public cloud? If you do not store or process cardholder data in a public cloud, then it is possible to reach compliance with PCI-DSS. If you do store or process cardholder data in a public cloud, however, then it is my opinion that it would not be possible to currently achieve PCI-DSS compliance.

You can achieve compliance if all you are doing is securely transmitting cardholder data over a public cloud (similar to the Internet today).

If you do not store or process cardholder data in the public cloud, then you’re not really in the Cloud! You can have all of your web servers running on a Amazon EC2 server and then hand off the credit card transaction to a third party to process, but at that point you can be PCI compliant and in the Cloud, but you certainly are not ‘PCI compliant in the Cloud’. You’ve outsourced your processing and you’ve reduced the scope of your PCI environment to exclude the Cloud, but you’ve also divorced the two concepts from one another. And I’d argue that even allowing the cardholder information to be transmitted through your Cloud environment is enough to place your servers back into scope for your PCI assessment. Remember, everything that stores, processes or transmits cardholder data is considered to be in scope for your annual assessment. The only way for a system to be out of scope is if it has no access to cardholder data; being a conduit to another system is a form of access and therefore falls within scope for PCI.

Cloud providers know their services aren’t currently ready for merchants and PCI compliance. Amazon knew last year that their EC2 and S3 offerings weren’t going to be able to enable merchants to be compliant. They’re smart enough to admit it and train their staff to understand why their Cloud offerings can’t be used for PCI compliance. Cloud computing and PCI compliance are probably going to continue to be strangers at least through 2010; the newest version of the PCI requirements will be out later this year and major changes for cloud computing aren’t part of this revision. There may be a technical update or clarification concerning Cloud computing, but in all likelihood any major changes are going to have to wait for the next version of the PCI requirements, which won’t be issued until 2012. Either way, it’s not worth holding your breath for the changes.

The primary problem with attaining PCI compliance in the Cloud is an issue of visibility; there’s no way for me, as an assessor, to truly review and validate system configuration when your systems are temporary and could be deleted with a few clicks of the mouse. Cloud service providers should be and probably are looking at ways to offer up services that take advantage of all the positive aspects of cloud computing while still allowing for all 200+ PCI requirements to be met. Service providers are going to have to take a long look at how they manage the creation and deletion of virtual servers, segregation of resources and collection, monitoring and retention of log information. When you have to keep every log even once the virtual server has been consigned to the bit bucket, storage costs can skyrocket. Not to mention the headache of letting the QSA of each and every merchant you host look over your systems for PCI validation.

Don’t trust the marketing propaganda that tells you can be compliant while using their Cloud service. There may be a time in the not too distant future where PCI and cloud computing can live and work together, but it’s not now and it’s probably not going to be in 2010 at all. If you have to use the Cloud to save your company money, make sure you’re not asking your customers to enter their credit card number on the Cloud servers; either send the transaction to a third party processor or bring the transaction in house at that point. You can’t be ‘PCI Compliant in the Cloud’ but you can use cloud services and be compliant. Just make sure you don’t get any of your peanut butter on my chocolate.

After missing last week due to overlapping travel, we’re back this week with all three of us (although Rich is a bit under the weather). It’s the usual weekly roundup with only a minor diversion to talk about some thingy that some computer company announced with an “i” in the name.

I read somewhere that starting a new job is one of the top three stressors you can have in your life. Death obviously tops the list with divorce and moving in the top five as well. My own experience tends to back up this theory and I’ve had my fair share of stress from changing jobs the last few years. As many readers know, I left a position at Trustwave last year and started with Verizon Business. I’ve had enough experience with changing jobs that when I started noticing some of the signs of stress, I decided to do something I had never done before: I took an unannounced blog sabbatical; I realized I hadn’t written anything other than show notes in several weeks and decided to extend it.

Blogging takes a fair amount of mental energy, even the short posts I tend to write. Learning the way a new business works and how the processes flow also takes a lot of the same human CPU cycles. In the past, I’ve tried to keep blogging and adjust to a new position at the same time. It hasn’t always worked out so well, so this time I put my emphasis on the day job and let the blog languish. At first it was just going to be a couple of weeks, but at some point I decided that the sabbatical would be over on February 1, 2010. Arbitrary deadlines are great, you can move them around as much as you like. And some times you can even meet them.

I’ve been continuing the podcast with Rich and Zach, though that’s taken a bit of a hit with our travel schedules as well. We’re working on getting a regular schedule back in place, though that may end up being a lost cause until after the RSA Conference this year. We’re all so busy preparing for the event and traveling that finding a time even two of us can get together to record is sometimes difficult. This week was no exception, but I’m sure we’ll find a way to manage it. The good news is that we have real possibilities of face to face time amongst us this year.

I plan on blogging less than I have in the past, but the trade off is that I hope to be able to produce longer posts with more of my own thoughts in them, rather than just pointing to something someone else has said. I also write over at the RSA blog once in a while and may be putting out articles through one or two other venues. Have no fear that you’ll miss anything I write, I’ll tweet and otherwise self-promote when I do. I’m looking forward to the third annual Security Groundhog Day panel this year as well as moderating a panel called Responsible Disclosure: It’s Their Fault! at the 2010 RSA Conference. Come support me at the talks, they’ll both be entertaining if not enlightening. And let’s not forget the Security Bloggers Meetup Wednesday night, March 3rd. Alan Shimel has just posted the finalists for the 2010 Social Security Awards, so head over their to take a look at the list.

This is going to be a busy year. Between work, two kids that are getting to a socially active age and a host of events like RSAC, BH/DC, Security BSides and FIRST coming up there’s not a lot of time to spare to blog about something someone else said, unless I’ve actually got something to add to the conversation. I’ll save what time I can devote to blogging to contributing something new rather than just being part of an echo chamber. Life’s too short to spend on writing fluff.

I’m still around. I’m still blogging, podcasting, attending events and being part of the security social media scene. But sometimes I’m shutting all that down for a couple of days or even a couple weeks at a time to deal with family, work and life in general. Time to get everything a little more in balance for a change, something I’m not really very good at.