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.

On Twitter this morning, @secrunner made the following comment:

“I think it’s surprising that PCI still hasn’t developed a program to certify pen testers or at least standardize the approach”

In reply I stated that given the level of certification for ASV’s (Approved Scanning Vendors), I’m just as happy if the PCI Council would stay out of the business of certifying pen testers or creating a standardized approach.  In reply @secrunner asked the following:

“In the spirit of PCI, isn’t even some standard (even a low one) better than none?”

The answer is, no, it’s not.  To be more specific, my answer was “Low standards for a merchant are better than nothing.  Low standards for a vendor are misleading at best, dangerous at worst.”  Let me explain why I think this way:

When you go shopping, one of the last things on your mind is probably “How does this merchant protect my cardholder information?”.  It’s one of the first things I think of, but that’s what I do for a living.  Most people are just concerned about if their merchant is going to have their size or the best price on the new toy they want.  They just assume the merchant has taken the necessary steps to secure their cardholder information.  And if they haven’t, consumers know that they’re only responsible for the first $50 dollars worth of fraud, and even that is usually absorbed by their bank or credit card company.  Sure, getting a new card issued to you is a bit of a hassle, but for most people it’s something that’s over and done with in a few minutes.

In this case, security is assumed and is not the primary concern of the person doing the purchasing.  A default standard such as the Payment Card Industry (PCI) Data Security Standards (DSS) is important and useful because it gives a baseline level of security for the industry to meet.  It may not be the level of security the company really needs to protect themselves, but all too often this baseline is more than the company was doing prior to the standard.  It may not be perfect security, but at least it pulls you up from the level of ‘low hanging fruit’. 

Certifying a vendor as a ‘compliant’ or ‘certified’ is a completely different story.  When an industry group such as the PCI Council makes a standard for a class of vendor and then certifies these vendors as meeting a certain baseline, this certification becomes one of the primary influencers in the purchasing decision.  Using the ASV certification as an example, a merchant won’t even consider a scanning vendor for their company unless the PCI Council has already certified them.  The merchant has to use a vendor who’s been certified otherwise they can’t submit the scans as part of their own compliance.  A large part of why this works is that external scanning of web sites is a fairly well understood, repeatable and, most importantly, testable process.  It can be easily automated and running the same test against the same site ten times will generally generate the same results every time (okay, maybe 90% of the time)

Penetration testing is an entirely different issue.  Yes, there are automated tools.  Yes, some pen testers don’t go much beyond that level.  But the good pen testers I know treat penetrating a company’s defenses more like an art than a science.  Metasploit and other tools are their paintbrushes, but it’s the person who’s using the tools that is actually making it possible to find the vulnerabilities in your company so that you can shore up your weaknesses and prevent someone else from finding them.  This isn’t a process that easily documented, standardized or testable.  It might be something you can do on a person by person basis, just as the PCI Council does for QSA’s now, but it would be nearly impossible to do for a company.

Let’s be honest, in the PCI-DSS, the idea of ‘penetration test’ is barely even defined.  It has to have a network portion and an application portion, but the how’s and what’s of penetration testing are left up to the QSA to verify and validate.  There’s no agreed upon standard in the industry of what makes a pen test a valid and acceptable pen test, let alone within the PCI community.  If the PCI Council wanted to certify pen testing companies, the first major hurdle they’d run into is making up that definition.  Then they’d have to come up with a way of testing companies’ adherence to the standards and create a certification program.  This would be a huge battle to undertake and the benefits would be minimal. 

Right now, it’s up to market pressures and QSA’s to determine what’s a ‘real’ penetration test.  If someone created a penetration testing certification there’s only one group of people it’d help:  marketing.  Most merchants wouldn’t read the requirements for the certification, they’d just use the certification process as a check box to weed out potential vendors.  And I can guarantee that the marketing teams would love that.  And I doubt it would make the results of penetration tests any better; in my opinion it would simply mean that most companies would ‘dumb down’ whatever they’re currently doing so that it met with the minimum standards and no more.  I much prefer seeing the merchant who’s having the pen test performed ask questions about exactly what’s going to be done and try to understand what they’re getting themselves in for.

This one hit’s close to home quite literally; Andrew Storms had some major issues this weekend with how a pizza place close to his house handled his credit card information.  Andrew only lives a city or so away from me and the pizzeria is one that I might visit for lunch or dinner given the chance.  Or rather, I might have before I read his story.  Now I’ll probably avoid it, going some place where I have a little more hope they’ll treat my credit card and other personal information with a little more caution.

The short version of Andrew’s story is that he ordered a pizza online and when the owner/delivery guy showed up, he told Andrew he’d received the credit card number via email from the central corporate website in an email.  There are so many forms of wrong here that it’s hard to know where to start.  This is a violation of PCI, there’s a chance it’s a violation of several state and federal laws (depending on how card data is handled from this point on) and it is simply bad practice in general.  But the real problem came when Andrew tried to figure out how to report this and get the merchant to change how he’s doing business.  As best as we can figure out, there is no way for a consumer to report a merchant to the credit card companies or his acquiring bank. 

It’s a huge hole in the system.  The pizzeria is a very small chain, there’s a corporate web site that’s probably run by a third party and it’s mailing credit card numbers, along with other important PII like name and address.  Unless the owner is using a shredder, which I doubt, all it would take is one episode of dumpster diving for a local data breach to happen.  While the pizzeria probably doesn’t get more than a couple dozen online orders a week, even one breach is too many if it’s your credit card.

Consumers don’t have much power in the credit card system, but this is an egregious issue that should have some sort of reporting mechanism.  Andrew canceled his card and tried to report the merchant, but there’s literally no way I or anyone I know can think of to report the merchant and force some sort of change to their system.  Quite frankly they’re a Level 4 merchant who might have heard of PCI but has no idea it actually applies to them.  It’s not a problem of the merchant being malicious, it’s a problem of the merchant simply being ignorant of the problem and having bigger issues to worry about, such as trying to get a new business off the ground.  I don’t blame him, but I do want some form of reporting for situations like this so that consumers can be protected and merchants can be warned to stop practices that are dangerous to their customers.

Last year Microsoft released a tool called COFEE (Computer Online Forensic Evidence Extractor) to law enforcement agencies around the nation and around the world a couple of years ago.  While COFEE is a professional tool, it’s meant for the average police officer who may not have a lot of experience with computers; you just plug a USB key with COFEE installed and if autorun is enabled on the computer, it will run a series of diagnostics, writes a report and generally gives a quick and dirty analysis of the computer.  It’s not an exhaustive tool and most of the commands and tools the COFEE uses are things that you already have on your computer and could run manually any time you want.  It’s a tool law enforcement officers need and should have, and it’s been a pretty closely guarded tool – until now.

In the last 48 hours, a user on the what.cd uploaded torrent of COFEE and made it available for any user to download.  Which, of course, means that it’s now available on any number of bittorrent sites.  The site it was originally found on did something they rarely do and took the torrent offline, but it was already too late and the tool is in the wild.  Even if many of the bittorent sites agree to pull the torrent, there’s enough users who have the file and enough sites that will be uncooperative that it’s very unlikely that this djinni can be put back in the bottle.  The fact that this tool has been a big mystery before now has made it very enticing, but getting your hands on a copy has been limited to a very few people who were in law enforcement or had friends that were.

It needs to be pointed out that is owned and jealously guarded by Microsoft.  I won’t be surprised if they start going after people to get this removed from the Internet.  Surprisingly the folks at What.cd say they took down the torrent on their own, with no prompting from either Microsoft or law enforcement.  It may be that they decided the amount of attention it could draw to a site like theirs was more than they were willing to itself.  Or it could be they did it for altruistic reasons, but I’m more willing to believe in the former than the latter.

Now that the COFEE has been spilled into the tubes of the Interweb thingy, what are our moral and ethical responsibilities as security professionals concerning the tool?  Should we ignore it and hope the police can pull it off the bittorrent sites before everyone and their brother have a copy?  Should we be reporting people who make it available?  Or should we be reviewing the tool ourselves and proposing ways to make it better?  This is a tool that’s aimed at letting police officers who are computer novices collect valuable forensics information using applications that are available natively in Windows and creating a simple report for future reference.  While this is interesting, it’s nothing top secret or even that revolutionary.  I suspect the main reason it was only available to law enforcement officers was to keep the malware creators and hackers from the limits of COFEE and figuring ways to prevent it from collecting anything if they ever have their own computers compromised. 

Personally I think the tool’s been leaked and rather than try to get it back, law enforcement and the security community should be concentrating on providing an even better tool that will do everything COFEE can do and more using open source tools.  There are any number of forensics tools already out there that will do a very good job of evaluating a desktop’s running configuration that could be made at least as easy to use as COFEE; the hard part would probably be getting law enforcement agents to accept something that didn’t have a huge name like Microsoft behind it.  For example, if a limited version of Backtrack was created that would run when you plug a USB key into the computer, the amount of data collected could be greatly increased. 

If there are already other tools available that can easily and cheaply provide law enforcement with forensics evidence they can use in court, I don’t know of them and would appreciate some pointers.  If not, someone needs to create something and make it available to law enforcement, especially if it’s something that’s easy for a computer neophyte to use.  I don’t think that having COFEE leaked reduces it’s effectiveness or makes it harder for law enforcement to use, but I believe that the open source community can create a better tool and make it available to everyone without feeling a need to keep it’s capabilities secret. 

I mentioned a couple of days ago that once you jailbreak your iPhone, you’ve bypassed many of the security protections Apple put in place.  One of the biggest concerns once you do this is the SSH service running on the iPhone, since it’s relatively easy to find the default password for the phone (it’s ‘alpine’).  My solution is to use SBSettings and simply turn off SSH on the iPhone all together.  But if you have reason to leave SSH running, you need to at least change the password, especially if you’re going to any security conventions or will be traveling through target rich environments that might draw the attention of malicious elements (aka, hackers).  You know, places like airports, train stations, Las Vegas, New York, etc.

How to Change the iPhone’s Root Password

Every geek in the world knows that Microsoft’s newest platform, Windows 7, is out today.  I have been playing with the Release to Manufacturer version for over a month now on my netbook and I’ve been very happy with it’s performance so far.  Microsoft seems to have gone out of their way to make Win 7 snappy and responsive even even on the minimal hardware that popular netbooks have.  Watching movies is sometimes a little choppy on my system, but surfing the ‘Net and reading email is just as easy as if I had a full sized computer.

Where I’ve had a problem is with the drivers for my Asus 1005HA.  Asus had refused to make drivers for Win 7 available prior to the release and given the history of last minute changes to new OS’s, I can’t say that I blame them.  But that’s left me without a number of the drivers and utilities I would have had available if I’d left the system running with the Windows XP it came with.  This has been a small but annoying issue, since the majority of the Win 7 drivers work just fine out of the box. 

Asus is doing there best, but I’m obviously not the only netbook owner who’s trying to get the latest and greatest updates for Win 7, since the site has been unavailable almost as often as it’s been up this morning.  I keep having to refresh the screen every so often to get back to the driver page and downloads are slow as molasses, but I’m gradually getting everything I need to get every patch and utility I want.  There’s nothing worse than a security guy who doesn’t have his system patched and up to date.

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.

Some encounters are almost too strange to believe.  That doesn’t make them any less real.

I was walking down the street in San Francisco at lunch time Friday afternoon.  As I came up to a busy street corner I saw a paper grocery bag sitting on a bench with no one around it.  I walked up to the bag and peeked in to find three external hard drives, one Maxtor and two brands I didn’t recognize.  The drives looked like they were either well used or the product of a dumpster dive.  I knocked on the door of the one business nearby, but no one answered.  After a few minutes someone came out who worked in the building; he said there’d been a break-in recently but that he didn’t know anything about the drives.  I tried to call Rich for advice, but he was busy so I decided I’d finish my walk to lunch and think on the situation for a little while.

One burrito later, I walked up on the scene again.  This time a homeless man in dirty, ripped slacks was surveying the bag of hard drives.  He looked around much like I had done thirty minutes earlier, then scuttled up to the bag and pulled out one of the external hard drives.  After sniffing it for a second, he licked one side of the drive and put it back in the bag.  He then ran over to a parking meter and licked it, licked the taillights on both sides of an SUV and vanished from my sight behind the car. 

I lost any interest in the hard drives at that point.  That takes mom’s caution of “you don’t know where that’s been” to a whole new level.

Saliva incident aside, what would you do if you found a bag of hard drives in a park or public place?  Calling 911 didn’t seem appropriate, though there is a slim possiblity of explosives.  Taking the drives home and performing some forensics research on them crossed my mind; I have the technology if not much skill in the area.  I tried to turn them in to the business, but there was no one there.  I guess the gentlemen with the inquisitive taste buds saved me from a moral dilema. 

What would you have done?

The wife and I are all packed, the house sitter has been briefed (“Just don’t burn down the house while we’re gone”) and we’re heading off to the airport in a few minutes to fly to Kyoto, Japan to attend the 21st annual FIRST Conference.  The folks at FIRST have tapped me to be the media sponsor for the event this year and I’ll be blogging, tweeting and conducting interviews live on the floor of the conference.  There is a very interesting group of international speakers who all work in the incident response field, some (like me) less than others.  So here’s my question to you:  Who would you like to hear me interview from the list of speakers in Kyoto?  Leave a comment on the blog, tweet me (@mckeay) or send me an email and I’ll do my best to get an interview with your target of choice.  The interviews will be posted within a few weeks after the conference and I’ll try to sneak one or two in while I’m there.

Note to Rich:  Don’t burn down the podcast while I’m gone!

I really wish I could disagree more with Dave Shackleford and his post, 10 Things Your Auditor Isn’t Telling You, but I think he’s really hit it on the head with this one.  And hit it hard.  He starts the post by saying he’s not trying to be mean, but as a PCI QSA, there are a couple of times I had cringe, because it really hits close to home.  It’s tough, because some of the points he makes are almost unavoidable in an audit process while others are signs of an industry that needs more skilled practitioners than are currently available.  And his final point is definitely true: the people at a company I’m assessing may like me as a person, but I have yet to meet someone who actually likes the process of being assessed and doesn’t channel at least a little of the dislike back to the assessor.