Network Security Blog

I was only able to get a few interviews while I was in Vegas this year.  But one of my favorites was talking to Joe Grand, the creator of all five year’s worth of electronic Defcon badges.  This year’s badge was smaller than previous years but it had some unique and interesting capabilities and it was also the most artistic of them all.  Joe talks about the hardware that went into making the badge, some of the difficulties they encountered (and there are always difficulties) and plans for next year’s badge.  No, I didn’t get a scoop and can’t tell you what it will be, but if Joe Grand is involved, I’m willing to bet they’ll still be really cool.

BHDC 2010:  Joe Grand

Last year Rich Mogull and Jeremiah Grossman created a little know certification, the Certified Application Security Specialist or Certified ASS.  To those in the know, or with the intelligence of the average house pet, it should be immediately obvious that this was an April Fool’s joke.  Funny, and it’s been a continuing joke through out the community, but apparently someone took it seriously enough to actually include it in a job description recently on Craigslist.  And strangely enough, the link I had now leads to the scam page on Craigslist.  Luckily I had the foresight to grab a copy of the post before it disappeared.  What were these people thinking?  Don’t they know they’re supposed to save this sort of stuff for the beginning of April?  The full job description after the page break.

Tired of Coding? Become an Application Security Specialist! (san jose south)

We have an immediate opening for a junior application security specialist (ASS) to join our growing consulting company. This permanent, full-time position is a great opportunity for someone with strong web application development skills that would like to move into the interesting and fun field of application security. This is a highly technical hands-on role that will utilize your web application development skills but involves little coding.

We will provide the right candidate with on-the-job training. The goal will be to quickly teach you how to perform detailed web application security assessments (black-box) and penetration tests by pairing you up with seasoned consultants. We have plenty of interesting projects to work on, including a wide variety of web applications (financial, e-commerce, gaming, etc.) and web services. Longer-term, we will train you to perform security code reviews.

This is an opportunity for a team player who would like to move into a new and exciting field, is ready to get started quickly, and is eager to learn some new skills and have fun while doing so.

Continue Reading »

Zach Lanier brought up HacKid (pronounced ‘hacked’ I’m told) on the podcast last night and I just realized I haven’t even written a single post on the subject.  My friend Chris Hoff, aka @beaker, is one of the key organizers and Zach is on the committee as well, and this looks like it’s going to be the start of something that’s every bet as fresh and original as BSides, except this time it will be kids who are learning, rather than a bunch of angsty security professionals who felt they weren’t being properly represented at Black Hat (I’m teasing, if that isn’t immediately obvious)

My kids are little geeks, similar to many of your kids in all likelihood.  They wake up in the morning and hop online or start playing on the DSi, or just pick up a book and read.  Their favorite magazines are Make and Science Illustrated.  And some fool introduced them to Japanese (is there any other type?) anime a couple of years ago.  So a convention aimed at teaching them how the Internet works, how to stay safe online and building robots really appeals to them.  Add to it that the convention is happening at the Microsoft NERD center and MIT is just down the street and you’ve got something that budding geeks will find unresistable.

If you’re on the East Coast anywhere near Boston, have kids between the ages of 5 and 17, think about taking them to HacKid in October.  Do keep in mind that every young person must be accompanied by an old person (read: adult guardian), but that each of the classes will likely have almost as much to teach the adult as they do the kids.  Everything is being done on a volunteer basis and the event is organized as a non-profit, so the money is all going to a good cause.  But hurry if you’re going to sign up, the cost goes up from $50 each to $75 next week. 

Branden Williams is one of the thought leaders in the PCI field, or at least someone like me who blogs about it a lot and hopes others find value in our thoughts.  I had a few minutes to catch up with him at Black Hat, where we discussed what he’d seen at Black Hat as well as the upcoming changes to the PCI DSS.  It appears that not much has changed since our talk and that the conclusions that we drew still remain consistent with what the PCI Council has released since then.  Pardon the background noise, we accidentally chose what we thought was a quiet corner but turned out to be one of the major staff entrances and exits.

Black Hat 2010:  Branden Williams, Director of Security Consulting,RSA

I’ve been working in and around the payment card industry for over four and a half years now.  A year and a half working for a service provider and seeing the worst of credit card storage possible and three years of performing Payment Card Industry Data Security Standards (PCI-DSS) assessments have shown me both the best and the worst of how merchants, service providers and other entities protect our cardholder data.  I’ve seen, and made, huge mistakes in implementing and securing cardholder environments.  I’ve assessed clients who’ve gone far beyond the requirements of PCI to truly secure their networks and I’ve seen administrators struggle to get even the most basic security measures in place because they don’t have the resources to do more.  Throughout all my experiences the one thing I’ve always been able to do is learn from the failures and triumphs of the individuals I deal with and I think I’ve gained a pretty deep understanding of the credit card systems and some of the things that are required to maintain a base level of security in today’s world.  And when it comes down to it, that’s all a framework like PCI is, an attempt to create a security baseline.

While I do have a lot of experience in PCI, I will never claim to have the all the answers to securing a cardholder environment.  I won’t even claim that I understand all the implications that writing a policy and technology framework like the PCI-DSS.  But I do have some ideas around how I’d do things differently if I was writing the requirements.  Boy do I have some ideas.  And I know that I have a lot of friends and peers in the industry who are more than willing to give those ideas a thorough looking over and thrashing to separate the wheat from the chaff and help me winnow out what’s useless from what can really help the industry in the long term.  So over the next couple of months, I’m going to lay out a series on how I’d write the PCI-DSS.  I expect that many of the ideas I throw out will be torn apart, but I want to encourage people to start thinking about how we can change the standards going forward.

One of the reasons I’m starting this right now is that the PCI Council has just released Summary of Changes for PCI 2.0 and changed from a two year to a three year lifecycle.  While the changes aren’t set in stone as of yet and all we have so far is an outline of what these changes are, what we have seen is nothing more than minor clarifications and minimalistic guidance for virtualization.  Since the new changes aren’t fully revealed yet, it’s hard to be too tough on the PCI Council; yet minor changes coupled with lengthening the time between revisions seems to be a plan to calcify the PCI-DSS and protect anyone from having to make major changes to their environments.  I feel there’s been enough time and feedback that this approach is not in the best interest of security nor is it really in the best interest of the public.  Bluntly put, the change to a three year life cycle should have been accompanied by a major revision of the requirements, not the minor tweaks we’re getting.

I won’t call what I’m thinking of PCI; the PCI-DSS is what it is and I can’t change that directly.  What I’ll be writing is just a series of thought constructs based on what I think are the real steps we should be taking to secure the credit card process.  I want to think outside the box that we’re currently in, looking at what we do now and trying to understand how we can do it better without tearing apart the merchants and service providers with additional costs and burdens.  I’m realistic enough to know that anything that requires large amounts of time and money are going to be met with screams of denial and pain.  But I also know we can refocus many of the efforts we’re making now and use the same tools we already have in place more effectively.

I want to start with a few principles that I think everything else should derive from.  And I know even these principles need to be challenged and refined.  The first of these is simple:  Everything flows from policy.   This is currently the last requirement in the PCI-DSS and I have always thought that it was the biggest mistake that was made when the original CISP requirements were written up.  As it stands now, policy is stuck onto the end of the requirements almost as an afterthought, even though in many companies it’s what gives the teams trying to secure the environment the ability to make clear cut decisions about what is and isn’t acceptable in the cardholder environment.  It’s also very helpful in getting the budget to purchase the tools you need.  Of course, I’ve already had one person tell me that starting with policy is doomed to failure, but this is my framework, so too bad.

The second principle is Keep it simple.  Come on, 200+ requirements??  How many of these are redundant, needless or just a vestige of something that is no longer reasonable to require.  We’re still required to check for a stateful firewall, even though every firewall built in the last 5 (10?) years is stateful.  I’m sure you can think of dozens of other requirements that are similarly outdated and needless.  Why have requirements that are simply placeholders that serve no real purpose?  Once a requirement becomes outdated, it needs to be retired to make room for something more important.

My final principle is Concentrate on results, not technologies.  There are very few things I like to see more in an assessment than a client who’s met with the PCI-DSS in a way that goes well beyond the simple requirement and actually secures their environment.  Andy Ellis, aka @CSOAndy is one of my heroes in the industry because of everything that he and his team have done to secure Akamai.  I need to talk to him to see how much he’s willing to disclose about what Akamai does differently, but let’s just say that his compliance assessments are truly unique and not something you ever want to send a junior assessor to deal with.  My goal is to develop a framework that concentrates on the results we want to see, not the tools you have to have in place to make it happen.

I think I’m taking on an impossible task here.  But I my goal isn’t to tell anyone what they’re doing wrong; it’s to come up with alternative ways to meet the same goal, which is securing the credit card process and promote security for enterprises overall.  I’m going to stumble a lot, I’m going to make mistakes and people are going to tear my ideas apart.  But if I can get you thinking about how we can do things differently, I’ll consider this experiment a success.  I want people to consider what we’re doing now and how we can do it better.  Some of my ideas will be thought of as impossible in the ‘real world’; some ideas will be taken almost directly from the PCI-DSS. And some will be taken directly from friends and peers.  My biggest fear is not being criticized for the effort; my biggest fear is that it’ll be ignored.

Here’s the most complete review of the changes I’ve seen to the update of the PCI-DSS and PA-DSS to version 2.0 over at the PCI Guru blog.  And a hat tip to John Kindervag for pointing me in the right direction. That’s all for now. 

This morning the PCI Council released the Summary of Changes for PCI 2.0.  And to be brutally honest, so far I’m completely underwhelmed.  Obviously we don’t have the details on what the changes actually are, but the high level view of them makes it sound like there are almost no significant changes.  Strike that: there are no significant changes at all.  There is some clarification and some mention of virtualization, but I was hoping for more.  I wasn’t expecting much more, but I was hoping.

I got to talk to Bob Russo from the PCI Council in July, and he’d hinted at the level of change.  And maybe I’m just not realistic in asking for major changes.  Despite the fact that PCI has been around for a while now, there are still a lot of merchants and service providers who have issues complying.  It may be that the realistic thing for the Council to do is continue to build support and compliance with what they have now, rather than pushing to increase security by making major changes.  Sometimes it is better to accept minor changes you know you can enforce than to try for something grander that you’ll never attain.

I’m hoping to get another chance to talk to Mr. Russo.  I’ve asked nicely, really I have.  I’d like to understand why this is the sum total of changes they’re making before switching to a three year lifecycle.  I’m not sure I’ll like the answers, but I still want to hear them directly from the man who’s in charge of the group setting and managing the PCI Standards.  Obviously, my approval is not necessary, but as one of the people who helps enforce the PCI Data Security Standards, I want to understand the reasoning.

This week’s episode was pretty refreshing- rather than covering our usual news stories, we spent most of our time answering some questions from our listeners (that’s you). Please keep ‘em coming folks- we’d much rather try and help you out than blather about unimportant nonsense in our feed readers. Besides, if you ask enough questions we don’t have to read. Which is good. Because Rich never learned how.

Network Security Podcast, Episode 208, August 10, 2010
Time:  45:27

Show Notes:

• Listener Q&A (half the show)
• Disclosure spat on Twitter (no link)
• Don’t plant child porn on your boss’ computer
• NatGeo goes to DefCon (great article!)
• Tonight’s Music:  What about the Love? by Art Linton