Archive for November, 2009

Nov 25 2009

The Network Security Podcast, Episode 174

Published by under Podcast

You can clearly tell it’s a holiday week in this episode, as we meander our way through an even more random selection of stories than usual. Martin was on the road and Rich manged to not [redacted] up the recording, and we even have a little music.

Happy Thanksgiving everyone!

(If you are in the US… the rests of you enjoy your non-holiday week anyway).

Network Security Podcast, Episode 174, November 24, 2009
Time:  33:54

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

No responses yet

Nov 18 2009

No podcast this week

Published by under Podcast

We worked at it, we really did. I made special arrangements to be able to Skype in from my hotel room, Zach called in from home and Rich recorded everything at his home office. It all worked out. Or so we thought. When Rich went back to edit the podcast he found that his software had failed without warning and all he had recorded was his own audio, which might be interesting as a funny aside some day, but hardly makes for a satisfying podcast.

We’ll back next week. I’m still on the road, Rich will be doing the recording again, but this time he’ll be recording to a secondary device. Which is something I’ll be doing in the future as well so don’t lose any other podcasts. In the mean time, Zach and I have some time to plot our revenge on Rich for his failure.

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

No responses yet

Nov 12 2009

Masking vs. Truncating

Published by under General

I don’t get a ton of questions about PCI sent to me, but from time to time someone asks a question that deserves a blog post.  Earlier today I received a question from a reader, Michele, that reflects a common misunderstanding in the PCI sphere:

I was reviewing the PCI DSS 1.2 section 3.4 yesterday, and was surprised to see that “masking” was not an option for PAN at rest / storage.  Am I interpreting it correctly that it must be encrypted while stored, but upon display it would be decrypted and masked?  To further that thought, if we receive PAN already masked and then store it, does that fall under PCI DSS?  My thinking is that technically it does not, as the PAN is already masked when received and there is no ability to trace back to the original clear text PAN.

There’s a basic misunderstanding of what exactly masking is.  Many people either don’t know that there’s such a thing as truncation and assume any time they can’t see the entire card number it’s masking, or they assume masking and truncation are the same thing.  They are not and here’s the definitions of masking and truncation straight from the PCI Council Glossary:

Masking:

Method of concealing a segment of data when displayed. Masking is used
when there is no business requirement to view the entire PAN.

Truncation:

Method of rendering the full PAN unreadable by permanently removing a
segment of PAN data.

Think of the cardholder data as numbers written down on a piece of paper.  Masking the numbers would be similar to taking a piece of correction tape and covering up the majority of the numbers so only the last four would be readable by the next person you hand the paper to.  The data still exists under the correction tape, even though it’s hidden.  But the piece of tape can be peeled back with some amount of effort and therefore that piece of paper still needs to be protected so that no one with malicious intent can recover the cardholder data and use it.

Truncation however can be thought of as never writing the numbers down in the first place or erasing them so completely they’re never recoverable.  You’re not recording the entire data on the sheet of paper and therefore it can never be used as to commit fraud against the credit card companies or consumers.  That piece of paper has no value to the malicious attacker and therefore doesn’t need to be protected, at least not to the same degree that the masked data needs to.  There may still be other data of value associated with the record, but the truncated data itself has no data.

If you’re viewing the data on the screen and you can only see a small portion of the data, you don’t know if you’re viewing truncated or masked data without digging deeper into the process.  Can the data be recovered in some way or is what’s in the database the same thing you’re seeing on the screen.  If you’re on the average sales floor, you can review the tickets for the day and see the last four digits of the card number on the receipts and the reports.  If the application has been built correctly, it won’t matter if you’re a salesperson or the manager, you won’t be able get more than the last four digits since they aren’t being saved in the store and there’s no way for anyone in the store to get the data back from system since it’s been truncated and no longer exists at that location.

Switch to the back office and the accounting or loss prevention departments and it’s a different story.  The default view that the members of these departments should be seeing is only the last four digits of the card number.  However, if there’s a billing issue or a potential fraud situation, company personnel have the ability to unmask the full card number as part of their research.   The data still exists on the server, however the majority of the time it is being hidden (masked); only when someone with legitimate business need reveals it is it shown.  Since the data is available for recall on the servers, they are fully in scope for a PCI assessment and need to be protected appropriately. 

To answer the question, data at rest can never be ‘masked’.  It’s only when it is recalled and presented in part to the user that it is considered masked.  This is why you don’t see masking as an option in requirement 3.4.  If you’re only receiving cardholder data that contains the a subset of the full card number, such as the last four or the first six and the last four, then it’s been truncated.  At that point you don’t have the full card number, it can’t be reconstructed and it doesn’t have to be protected as if it was cardholder data.  That’s not to say the other data associated with that record don’t have value and shouldn’t be protected, however truncated data is not governed by the PCI requirements. 

If your company is receiving the full card number but only displaying the masked to workers, even if no one at your company has access to the card holder data, you’re responsible for protecting the data pursuant to the PCI requirements.  If there’s no need for the data, ask for truncated data in the first place and save your company the effort of dealing with PCI, QSA’s and the entire Report on Compliance process.  I’m a nice guy, but even my biggest fans amongst the clients I deal with will tell you that there’s always a certain level of pain associated with having me come on-site for the annual review. 

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

3 responses so far

Nov 10 2009

Network Security Podcast, Episode 173

Published by under Podcast

It’s one of those glorious days we all look forward too; all of the regular hosts of the podcast are on the road and in most cases thousands of miles from home.  Luckily we planned ahead and this week Martin is joined by Adrian Lane of Securosis instead of the usual cast of characters.  We recorded a couple of days early so that we’d have a podcast out, even though we probably missed one or two breaking stories.  Not that we’d know, since we’re all on the road and have limited access to our news feeds and Twitter.

Network Security Podcast, Episode 173, November 10, 2009
Time:  31:45

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

No responses yet

Nov 08 2009

Simple worm RickRolls jailbroken iPhones

I knew it had to be just a matter of time before someone took advantage all of the jailbroken iPhones and created another malicious tool to pwn them.  This time the attacker has been RickRolling iPhone users, changing the background on the phones to a picture of Rick Astley.  The worm is fairly simple and uses the default password set up on the SSH daemon when you jailbreak your iPhone, so if you’ve taken the 5 minutes required to change the password, you’re perfectly safe from the effects of the worm.  Of course, it’s written by someone in Australia going by the name of ‘ikee’ and generally has only been hitting phones down under, but given that the ikee code was released, along with an interview, it’s only a matter of time before someone else creates a new version that does something much nastier than putting up a picture of an 80’s pop icon.  I can think of a couple of people I know who’d be willing to put pictures of goats or lemons or things with spelling close to that on your iPhone.  And those are just the people who are there to be playful.

I’ve said it a number of times in the last week, but it bears saying again:  If you’ve jailbroken your iPhone, change your iPhone’s root password immediately!

By the way, I don’t know anyone who’s jailbroken their iPhone in order to access pirated software, everyone I’ve talked to did it so they could install software that unlocks capabilities that Apple doesn’t want us to have in existing apps, for example tools like xGPS and SBSettings.

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

2 responses so far

Nov 08 2009

Ethics of spilled COFEE

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. 

 

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

8 responses so far

Nov 07 2009

How to change the SSH passsword on your iPhone

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

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

No responses yet

Nov 05 2009

Good luck, Alan

Published by under General

Nine years at one company is almost longer than my entire career in information security.  But that’s how long Alan Shimel was at StillSecure.  Was being the operative word, since Alan has announced that he’s left the company and will be moving on to something new.  He’s not exactly sure what that is yet, but I’m sure Alan will be a valuable resource where ever he ends up.  He’s taking some time off to collect his thoughts and spend time with family, both of which are things I definitely consider time well spent.

Thanks the Alan and Mitchell Ashley I spent some time at StillSecure a few years ago as the Cobia Product Evangelist, which I’m sure some of you will remember.  Unluckily it turned out to be too big of a change and I just wasn’t ready for the position.  Alan, Mitchell and the rest of the folks at StillSecure did their best to help me, but I left when it became clear that it just wasn’t the right place or the right time for me.  The good thing though has been the friends I made and retained at StillSecure, a lot of good people who I make a point of saying hello to every chance I get.

Alan’s making a gutsy move.  It takes a lot to say to yourself “I need to change, even if that means stepping off into the unknown.”  I know he’ll land somewhere interesting if nothing else. 

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

2 responses so far

Nov 04 2009

I’ll do anything! Absolutely anything!

Published by under Family,General,PCI

I love my children, I really do.  Especially when they remind me of some of the life lessons I learned long ago but have forgotten from my conscious mind.  And even more importantly when those life lessons are the same lessons that can be applied to the job I do on a daily basis.  Let me tell you a short story and how that relates to security in general and PCI specifically.

As we all know, Halloween was only a few days ago and many of us have large bowls filled with candy sitting around the house.  My house is no different and like many other parents, we’ve tried limiting the intake of candy by our kids to dessert and perhaps one or two pieces of candy throughout the day.  Today was no exception, so when my children asked if they could have dessert, I told them they could have one piece of candy each.  My eldest son thought this was fine, but my youngest son spent a fair amount of time rooting around his bowl and when I finally told him it was time to make a decision, the look he gave me told me something was up.  I had him open his hand and show me what was in it; not surprisingly, he’d tried to hide a second piece of hard candy in his hand, hoping I wouldn’t catch it and he’d get two pieces of candy.  Big no-no.

I was in a fairly understanding mood, so I simply took the second took the second piece of candy away and told him he could have the first piece of candy he’d picked.  He gave me the puppy dog eyes, which I ignored and told him that he’d made his choice and had to live with it.  Rather than eat that piece of candy, he said it wasn’t what he wanted threw it back in the bowl and walked away.  A few minutes went by, we told the boys to go brush their teeth and go to bed.  Cue the histrionics!

The screams went along the lines of “I’m not going to bed without dessert!” and “I’ll do anything for dessert!  Absolutely anything!”  Which was met with “You had your chance, you made your choice, now it’s too late.”  He screamed, he cried, he screamed some more.  But Daddy can be an immovable object when his mind is set, and a tired eight year old is going to bed whether he wills it or not, so Daddy won the argument.  We’ll see if he’s learned his lesson for tomorrow night’s desert.

How does this relate to security?  Often, at least from our point of view, management is much like a spoiled eight year old who wants what they want, when they want it and the consequences be damned!  As an assessor, I hear companies tell me about a date they have to be compliant by and they’ll do absolutely anything to meet with that date.  But when you start telling them what’s going to be required to be complaint, you start hearing all the excuses as to why particular pieces are impossible, can’t we just assess on what they will be doing in the future or ignore that part of the requirements since they’ll be doing it “really soon”.    I have about as much sympathy for them as I do for my son; I’m not the one who’s missing dessert, so he can either do what he’s supposed to or miss out on his sweets.

The cry of “I’ll do anything!” only lasts until it’s time to actually do something all to often.  I use compliance as an example, but this is just a big a problem in the rest of security.  Management sees another company in their market get compromised and says they’ll do anything to avoid the same fate.  Of course, ‘anything’ only lasts until they see the actual manpower and budgetary numbers that would be required to secure the company from the same fate that befell the the competitor.  And they get extra sensitive when told that the numbers you gave them will only protect them from the vulnerability du jour and additional resources will be required to become what you’d consider reasonably secure.

PCI is much the same way.  Business think they can get away with half-way measures that almost, sort of meet with the PCI requirements, but when a QSA comes in and says, “Let me see what’s in your other hand.”, the crying begins.  “I’ll do anything to be compliant!”  Well, start by writing policies that meet the minimum standards.  “Anything but that!”  Configure your firewalls so they aren’t swiss cheese allowing almost anything any “Well, anything but those two things!”  Implement a log manager.  “Anything but …” You get the picture; the definition of anything quickly narrows from the dictionary definition of ‘anything’ to ‘the absolute minimum I can get away with’.  It’s human nature to try to get as much as possible with as little effort as possible, whether your a mega-corporation or a eight year old.

PCI isn’t difficult, it’s a pretty minimum baseline for securing your company.  Risk vs compliance arguments aside, most of the things in PCI are measures the vast majority of businesses should be doing to establish a secure infrastructure that’s capable of keeping the bad guys out or detecting when they do get in.  The people who are screaming because it’s too hard are the same people who probably wouldn’t be giving the security and IT teams the resources needed to secure the enterprise in the first place.  And much like an eight year old they’d rather scream and cry after the fact than plan ahead, follow the rules and do the right thing in the first place.

You can’t send a corporation to bed without dessert and you can’t leave them unprotected.  Just like parenting, you have to do your best and hope that it’s the right thing.  Businesses are going to be much better served by trying to look ahead at what needs to done and how to do it effectively and efficiently rather than waiting until the last minute.  It’s a mark of maturity that many businesses may never show.  And again, just like a parent, it’s our job as security professionals to try to teach the businesses we work for how to plan ahead rather than screaming “I’ll do anything” when it’s already too late.

I think it’s time for me to go raid the candy bowl.  Unless my wife says it’s already too late.

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

4 responses so far

Nov 03 2009

The Network Security Podcast, Episode 172

Published by under Podcast

“The Episode that almost Wasn’t”  It’s been a day.  Shortly before we were scheduled to start, there was a pop and the power went out at Martin’s house.  Rich has issues of his own to deal with.  And Zach is … somewhere.  It was only because the local electric company responded quickly for the first time I can remember were we able to squeeze in a podcast recording between emergencies.  And now that we’ve recorded and posted, it’s time to put our noses back to the grindstone and work for a couple more hours.

Network Security Podcast, Episode 172
Time:  33:26

Show Notes:

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

One response so far

Next »