Branden Williams' Security Convergence Blog

Thanks to the Security Blogger's Network, I am pleased to offer one free pass to CSI 2008 in DC! You will need to put some thought into your entry as this is not just some easy give away.

To enter into this contest, all you need to do is email me your favorite security related story. Something that you saw that was clearly a huge security problem. Like if you saw a metal detector in a building that was maybe turned off, or maybe a NEXT box running an e-commerce web server in the last year. Here are the rules:

1. All entries must be received via email by Thursday, November 6th, 5PM Central time.
2. One entry per person.
3. Your entry can be a story with text, a picture, or both.
4. DO NOT put proper names of companies or people in here. We want to protect the guilty (just a little).
5. By entering you agree to allow me to post the entry in part or in its entirety on this blog.
6. Employees of VeriSign are not eligible.

Since there are only a few of you out there that read this, the odds are pretty good of winning!

If you don't want to enter and just want to get 25% off your registration, enter the code 'BLOG25' during the registration process!

Posted by Branden Williams at 8:45 AM | Permalink | Comments (1)

One major change to PCI version 1.2 is the new requirements and testing procedures for Req. 12.8. 12.8 deals with how merchants and service providers should handle their third parties that can affect the security of cardholder data. The card brands have told us in the past that they would not expect a service provider to prevent a merchant from being compliant, but that the merchant must understand that they will carry the liability for a breach at their service provider's site.

We've seen 12.8 morph considerably from PCI version 1.0 to 1.2. The intent was to help merchants understand how service providers deal with their data, and make sure that they are protected if there is a breach at their service provider. I still believe that the intent is the same, but the language around the requirement and testing procedure has been relaxed slightly, but still points out the liability. This means that you may not have to alter that master services agreement that was originally inked in 1979, but that legal on both sides must be made aware of the stakes involved.

There are a couple of industries that have unique problems as it relates to PCI. One of those industries is the travel industry (shout out to Yvette!). The service providers that they rely on provide some infrastructure (such as common use terminals, or shared ticket counter or gate space) that is virtually unmaintained, and the airports have been unwilling to put any additional support into these systems. Thus, the contracts do not mention anything about data security or PCI, and would not be compliant under PCI 1.1.

Now with PCI 1.2, the travel industry has a way to deal with these common use areas in a manner that does not affect their compliance. Security is still definitely an issue, but this is another one of those issues where you don't want to totally rely on PCI Compliance to keep you breach free.

Posted by Branden Williams at 7:19 AM | Permalink | Comments (0)

Researchers Martin Vuagnoux and Sylvain Pasini recently released video demonstrating the ability to pull electromagnetic eminations from wired keyboards. Both videos show how various configurations of standard keyboards could have keystrokes intercepted through the air.

Many of us have heard of the old TEMPEST project that was made famous by their demonstration of the ability to intercept the data that would be displayed on Cathode Ray Tube monitors. Imagine having someone sit outside your office or home and being able to see on their monitor the very same things you are looking at on yours.

I wonder how many more corporate scandals would hit the press if this happened regularly.

Now it appears that simply typing your passwords or authentication information on a keyboard could expose them to the world at large. If you never worried about using password only authentication to protect data, you definitely should now.

The truly scary piece for me is that now that this has been demonstrated, any attacks that we see will probably be narrowly focused and targeted. Security controls in most corporations are not designed to withstand such an attack. These attacks will single out individuals—an attack method that is widely successful.

An additional factor of authentication such as a One Time Password might be able to stave off an attack, at least when it comes to leaking valid credentials to an attacker. Then again, depending on the method, it might not be able to do that.

I'd be interested to see if someone could direct a signal at a machine to insert characters into the computer remotely. Wouldn't that be wicked?

Posted by Branden Williams at 11:01 AM | Permalink | Comments (1)

Final round of questions from the field!

The first question from this session was "Are end of life operating systems able to be used?" The thing that really worries me about retail is that information security does not seem to be built into the price of goods on the shelf. When someone asks if they are expected to replace hundreds or thousands of devices for PCI Compliance because Microsoft will not support them anymore, I worry more about the overall security of the company. This seems like a reactive approach without any forward strategy, which is unfortunately fairly common.

I understand the business implications here. If your competitors are not doing this, you could face additional price pressures by trying to do the right thing. That said, I am a firm believer in doing the right thing for the best long term growth strategy.

Next couple of questions are arguments of semantics. It also seems that some of the attendees are not fully using the information provided by the Council. There is the Navigating PCI-DSS document that helps with intent, and the FAQ which answers some of the questions that were asked.

Next one was a compliance versus security question. The point made is valid, but with PCI-DSS being applicable to any merchant accepting credit cards regardless of size, you can't expect that the merchant with 100 cards per year is going to jump through the same hoops as a Fortune 500 retailer.

Also, it is a bad idea to spend ten minutes trying to show the Council how smart you are about security. They will remember you, and not necessarily in a good light.

Next question was an excellent point on a potential interpretation of 12.8 that will be giving QSAs a headache. I won't go into it here, but we have to think about intent and use a little common sense.

A question about dates was posed next, but that is answered in the lifecycle document. Also, don't forget, the card brands are the enforcement arm of PCI, not the Council.

Next couple of questions were just minor questions that any QSA should be able to answer.

Then came a merchant that put forth a story about the work he had to do to maintain his business. Again, folks, you've got to build security and compliance into the cost of your product. The one point of his that is valid is that he wants things more prescriptive to avoid variance in QSAs (with applause from a few people at the end). While this is not necessarily achievable, I do think VeriSign might have some solutions for you. If this was you, please email me. We can help you through this on a global scale.

And that concludes the Q/A session!

Posted by Branden Williams at 5:24 AM | Permalink | Comments (0)

I always enjoy the Q/A sessions that the Council has at these events. I don't know how many sessions I will be able to blog about (we only want the interesting ones anyway), but here's the first bunch of Q/A from this session!

The first question was around segmentation and SANs. I'd never heard the question asked that way, but most SANs by nature are segmented from each other.

The more interesting point here is what constitutes segmentation? So many assessors only consider firewalls a method of segmentation. According to the documentation provided by the council, segmentation can be accomplished in multiple ways--not just by deploying firewalls. QSAs should be looking at the whole solution, not just fixating on a point solution (hey, sound familiar from a remediation perspective?).

Second question was on sampling... another issue that often comes up. The new version of the standard says to use a representative sample (they used to use the term selective sample), but since the samples are not statistically valid, it makes choosing a sample a bit of a gut feel. You will see variance between QSAs here as we all seem to have a different opinion on what constitutes a representative sample.

Then a question was posed on a move to use standardized solutions. The recent push with the standard is to remove specific products and technologies which is the right way to go (by the way, that is called being vendor neutral, not vendor agnostic). The point was really geared towards small companies that may be looking to buy pre-packaged solutions as opposed to designing their own. I feel their pain; vendors often pitch silver bullet solutions that do not work together very well.

The next question was a cleverly disguised sales pitch. Don't do that. Seriously.

Ahh, my nemesis just asked a question. Guess what question he asked? "Can you make a statement that says you don't have to store cardholder data?" It's in there bud, just take a look. I'll re-iterate for you in case you don't want to search:

Merchants are not required to store cardholder data. Every merchant we have worked with has been able to get their acquirers to accept truncated numbers for chargebacks (or other post-settlement operations). I know that people still believe that the associations require merchants to store data because I had a discussion with a CISO on this issue recently. It would be great if you could stop spreading mis-information.

On the other hand, you do make writing this blog interesting...

The next several questions are nothing that has not been answered before, mostly around scope creep issues.

Back to segmentation, and this one was a customer specific question from a QSA! The old "I have a client that..."

So there you have it! Lots of similar questions from the US PCI meeting.

Posted by Branden Williams at 2:23 AM | Permalink | Comments (0)

Greetings folks! Couple of updates in this post.

October's Herding Cats is up and ready for you to read! Pretty soon here I will be setting up a URL where you can download all the published versions of this column regardless of your membership status with the ISSA. Need a little time though baby birds. Until then, members of the ISSA can download the most recent version here. As you can tell, I have been reading a lot of James Patterson recently. Sorry about that.

Also, if you are going to be at the PCI Europe Community Meeting this week, look me up! I'll be wheels down in Brussels on Tuesday in time for the networking session. I am looking forward to meeting more of you this week.

I am transiting through London first, so if you are in London and want to grab a pint, drop me a line!

Posted by Branden Williams at 4:06 PM | Permalink | Comments (0)

Look out merchants, there is a sneaky omission to PCI v1.2 that does not seem to be making any headlines, and I'm wondering if this will just fly under the radar until someone like me stands up and points it out. All the discussion thus far has been around Anti-Virus, Network Segmentation (or lack of a requirement for), WEP, and firewall rules having a six month review (vs. quarterly). But, does anyone remember this little tidbit from the PCI v1.1 when trying to determine the scope of a PCI Assessment?

Any data repositories outside of the authorization and settlement environment where more than 500 thousand account numbers are stored [are in scope].

I've heard that this little loophole has saved many merchants from fines simply because they were able to take some non-compliant processes and get them under this threshold. Don't get me wrong, merchants would be liable for a breach if those non-compliant processes were linked to a breach, but anything below this threshold would technically not be material enough to show up in a Report on Compliance generated by a QSA.

Well, that whole provision is GONE from PCI v1.2. This means that merchants and service providers (small service providers could get hit hard with this) will have to do a better job of 1) defining where their data is, and 2) making those repositories compliant as they could be subject to the review of a QSA. Based on my interaction with customers, I think this is one of the more significant (if not the most significant) changes in the standard that people should worry about.

What do you think?

If you are worried about it, don't forget to ask a VeriSign consultant about our Data Discovery service that can help you map out all of this data (and other non-PCI data) across your enterprise.

Posted by Branden Williams at 4:27 AM | Permalink | Comments (0)

VeriSign's Managed Security Services group provides all kinds of services to assist organizations in the heavy lifting associated with some security tasks. Those tasks that are easy if you have one, but not easy if you have a thousand.

In a recent internal email string, one of our engineers told us they are seeing a dramatic increase in the amount of PDFs that have malicious JavaScript embedded in them. These exploits use the OpenAction function (like the HTML document.onload() function) as a vehicle to obtain full machine compromise with a root kit. I'm not sure why we feel the need to embed scripting into a PDF (isn't that what the web and offline browsing is for?), but it appears that once again functionality has usurped security.

I guess the next step is to make text files more functional so we can exploit those.

Posted by Branden Williams at 6:56 AM | Permalink | Comments (0)

One of the topics that I often get into discussions with customers is pulling data out of volatile memory (RAM). The argument that is usually made related to insecure RAM storage is, "Well, someone would have to get on the machine and know exactly where to look in memory and it would just not be feasible for someone to do."

My response to this argument is typically something along the lines of "Obscurity is NOT Security." Obscurity is a poor defense against security problems.

It now appears there is evidence of malware that can grab data in memory to the hacker's delight. It's not really rocket science folks; it is actually pretty simple. This technique has legitimate uses in programming, and now that less and less data is being written to disk, the bad guys have modified their techniques to take advantage of volatile memory.

They are doing it by using common debugging software to pull and/or monitor the contents of the running volatile memory. For many merchants, this means that full magnetic stripe data is there for the taking.

Keep in mind, there is not a ton you can do about the majority of POS applications out there. Unless it is receiving the data encrypted, it will probably be in memory un-encrypted or could at least be pieced together while a crypto routine runs. This to me us much more serious than the issue of data sitting in a pagefile. It seems that if you have the ability to distribute the malware, you will get realtime data on a regular basis and won't be looking through snapshots of a pagefile.

Of course, I suppose you could just as easily hook into the routines that write things to disk and capture it there.

Regardless, it looks like the malware is out there. Be sure you are patching your machines and doing solid egress filtering as most of the malware compromises a machine first, then sends data offsite.

Posted by Branden Williams at 4:13 AM | Permalink | Comments (0)

Are you interested in how 1.2 affects you? The Council provided a detailed list of changes between the two standards, but sometimes it can be a little overwhelming. The guys over at Aegenis have posted a good summary for those of you who want to cut to the chase.

If you have specific questions to your business, why not reach out to a VeriSign consultant? We can provide you the expertise you need!

Posted by Branden Williams at 9:29 AM | Permalink | Comments (1)

Just like the rest of you, I couldn't sleep all night. I tossed and turned in anticipation for this glorious day. It was much like being a kid again and waiting for Christmas morning to hurry up and get here so I could open presents!

I jumped out of bed promptly when my alarm went off, got ready for my day and bounded up my stairs to my new office (I've moved my office so that the new kiddo can get the bigger room), plopped myself into my chair and furiously tried to wake up my PC. I unlocked it and browsed over and ...

*sigh* should have slept in. I've been hitting reload every ten seconds since (Grey's Anatomy style).

BUT it is NOW OUT! Yaay!

Click here to see Version 1.2 of the standard and the summary of changes.

Posted by Branden Williams at 7:36 AM | Permalink | Comments (0)