Network Security Blog

One of my security contacts pinged me via IM this morning and asked “Where can I find a list of security podcasts?”  I couldn’t think of a list immediately, so I moved to one of the other dozen windows open on my desktop and tweeted the question.  The first reply was a list that I’ve known of for a long time, the Getmon IT Security Podcast Links.  The second reply was to look at the nominees list for the Social Security Awards, a list I helped work on myself.  All I can say in my defense is that it’s still early and my third cup of coffee hadn’t kicked in yet.  

Of course, start by subscribing to the Network Security Podcast and moving on from there. 


Update:  Another list to add to the list of lists:  http://www.securitycast.net/secpods-opml.xml

The 2009 Data Breach Investigation by Verizon is out, and I have to be honest, all I’ve had time to read so far has been pages 41-43.  Why those pages?  Because they’re the pages that specifically call out the statistics surrounding breaches affecting merchants who are (or should be) complying with the Payment Card Industry Data Security Standards (PCI DSS).  Not at all surprising, at least to me, is that the study found that PCI compliance is important and that 81% of the companies researched in this report weren’t PCI compliant at the time of the breach.  Of course, that also means that 19% of the companies breached had either self-assessed or been assessed by a QSA and were thought to be compliant at the time of the breach.

These numbers make sense to a certain degree; whether you agree or disagree that PCI is raising the bar on merchant security overall, the fact is that for many smaller businesses, it’s forcing them to put into place safeguards they may not have thought of or been willing to pay for otherwise.  For larger merchants, the PCI DSS forces them to codify and staff many of the security process they may have already have had in place, as well as requiring them add new layers of security they didn’t have had in place before.  It would be very interesting to see the numbers sliced and diced based on the size of the merchants involved or on whether they were self-assessed or had a QSA do an assessment.

What really disappoints me is what’s shown in Table 10:  Results of post-breach PCI DSS reviews conducted by Verizon Business IR.  This table shows exactly which requirements were and weren’t in place at the time of the breach.    The big winner was not surprisingly requirement 5, use anti-virus, which is probably the easiest requirement for most businesses to meet.  But even that requirement was only in place in 62% of the instances!  The big losers were requirement 6, develop secure systems and requirement 10, monitor your systems, at only 5% in place for each of these requirements!  To a certain degree I can understand that developing secure systems is hard and that some businesses might have a hard time developing secure coding practices and system configurations, but to think that only 5% of merchants involved in breaches were properly monitoring their own systems makes my head spin.  It probably shouldn’t because the chance of a network suffering a breach goes down drastically when people actually pay attention to what’s happening on their systems.

What scares me is that the next biggest lack of compliance is in requirement 3:  Protect stored data.  Only 11% of the merchants that were studied for this report were in compliance with this requirement when they were breached.  Yet if you read the PCI Council’s Prioritized Approach for PCI DSS 1.2, they state that a merchant’s first priority should be to ‘remove sensitive authentication data and limit data retention.’  Why?  Because that’s where the majority of the risk is for most merchants.  If you’re properly encrypting cardholder data, a compromise will be damaging to your reputation, but it won’t be nearly as damaging to your bottom line.  Even better, if you don’t keep cardholder data or never have it to begin with, you might still get breached but you won’t be the next name on the compromise hit parade.  Merchants need to take a long look at their data retention policies as well as investigating some of the newer tokenization possibilities out there.  Remember, the bad guys can’t steal what you don’t have.

Merchants complain, sometimes very vocally, about the money and effort required to implement PCI.  It can be expensive, especially if security has been on the back burner at a company, which it often is.  In some ways, they’ve mortgaged the security of their company in favor short term savings.  They’ve assessed the risk and come to the conclusion that it’ll be easier to ignore the problem and hope they don’t get compromised.  In many cases, the merchant’s been right, they haven’t been compromised and might not be.  But for the merchants that were covered in Verizon’s report, they played roulette and lost.  If you’re one of the merchants who’s complaining that securing your business in order to take credit cards, maybe you’re looking at the equation wrong; you should be looking at the cost of securing your enterprise in order to take credit cards and evaluating whether or not it’s worth the costs involved.  I seriously believe some merchants either shouldn’t be taking cards at all or should be outsourcing that part of their operations to a third party who specializes in securing the data.  Sometimes it’s easier and cheaper to have someone else do the work than doing it yourself.  And sometimes, it’s not worth the risk of taking credit cards, even though that’s unthinkable to some merchants.

I’m the first to admit I’m looking at Verizon’s report through a very narrow lens.  It supports my view that even if PCI isn’t the perfect solution to securing merchants and cardholder data, it has been making an impact on the overall security of merchants.  We still have a long way to go, PCI has to evolve and merchants have to be more scrupulous about putting the right controls in place, but it’s having a positive effect.  In Verizon’s own words, “these breaches, in general, did not occur in organizations that were highly compliant with PCI DSS.”

Rich and I are both nearly at our wit’s end today.  Whatever that really means.  We’re trying to do our day jobs while helping organize the Security Bloggers Meetup and Social Security Awards, and trying to manage our schedules for next week as well.  We realized during the show that we hadn’t really set aside any time to get together and record a podcast during RSA, so you may get a number of interviews from the event without actually hearing Rich and I in the same room.  We talk a lot about what we’ll be doing at RSA along with a couple comments about the Twitter worm from Easter weekend and the continuing issue of AT&T fiber cables being cut in the Bay Area.

Hope to see you at RSA next week!

Network Security Podcast, Episode 146, April 14, 2009
Time:  30:51

Tonight’s music:  The Pain of Numbers by Get Three Coffins Ready

I really have to wonder if Michael Mooney is trying to get arrested; after creating three Twitter XSS worms over the weekend, the 17 year old author responded to an editor at Net News Daily and told the editor that he wasn’t worried and that he knows this stunt could land him in jail.  Like many grey and black hat hackers, he blames Twitter for leaving open the vulnerability, rather than taking any of the responsibility for notifying Twitter of the issue.

This Twitter XSS attack by Mikeyy caused quite a stir over the weekend, infecting thousands of users and creating tweets to point them back to his StalkerDaily site.  The accounts that started this have been shut down and work is in progress to clean up the issues, but it may be a few more days before we know for certain that everything is safe again.  There doesn’t appear to be any theft of personal information or account passwords involved in the worm, it was simply a publicity stunt to garner traffic for StalkerDaily, at least accoding to F-Secure and Twitter.

Don’t be at all surprised if this is only the first wave of Twitter worms.  Even if Twitter has already patched this vulnerability, it’s a big application with a lot of people banging against it trying to find the next set of vulnerabilties.  They’ll be found, sooner or later, it’s just a fact of life.  If you’re not already using Firefox and NoScript, now is a good time to start, at least when checking out people’s profiles.

Mikeyy is not an adult, he didn’t do anything that destructive, but his actions may be technically illegal, even if Twitter doesn’t want to prosocute directly.  His arrogance in claiming the worm and showing no signs of being even slightly apologetic for releasing it on Twitter don’t bode well for his future and the authorities need to have a long talk with him about it if nothing else.  I’ve long been a believer in responsible disclosure and this sort of behaviour is about as far from responsible disclosure as you can get. 

The thing we need to learn the most from this is that any web application is vulnerable.  Mickeey didn’t do much damage, all things considered, and he probably won’t get in too much trouble just because of that.   The next person who discovers a vulnerability in Twitter might not be quite so nice however.

Update:  Here’s some steps you can take to protect yourself – Twitter worm attack continues:  Here’s how to keep safe
Technorati Tags: Twitter, XSS, StalkDaily

Was it really almost three years ago that I interviewed Brian Contos about his then-new book, Enemy at the Water Cooler?  I won’t say it feels like it was just yesterday, but it really doesn’t feel like it was that long ago.  Brian is now the Chief Security Strategist at Imperva and wanted to return the favor by interviewing me and finding out what makes me tick. I get a little embarassed sometimes when people want to find out about why I got into blogging and podcasting, not that I’ve ever let that stop me from talking about it.  Brian’s had several other interviews with security professionals working in the PCI field, such as Branden Williams and Anton Chuvakin.

Interview with Martin McKeay – Host of the Network Security Blog and Podcast Series and QSA

Technorati Tags: Podcast, Interview, PCI

Several months ago I was approached by the Forum of Incident Response and Security Teams (FIRST) to act as their official ‘podcast sponsor’ for the 2009 FIRST Conference in Kyoto, Japan, June 28 through July 3.  I’d heard of FIRST before and even done a little blogging to support them in 2008, but I really hadn’t had the need or the motivation to involved with them.  I wish I’d followed up last year and learned more about them, because it’s not too often that I really get the chance to work with a multi-national organization that has members from some of the largest incident response teams in the world, including BT, IBM, SANS, GIAC and just about every CERT/CIRT group around the globe you’d care to mention.  This is where some of the people who’re at the top of the incident response game come to meet and discuss what’s really going on behind the scenes.  The conference in Kyoto will be the 21st annual FIRST conference, which by itself gives you a clue about how important a group FIRST is.

So, of course, I leaped at the chance to go to Kyoto this summer and cover the conference.  It didn’t hurt that I’d already been talking to my wife about going to Japan this summer and that I’ll be spending my birthday somewhere I’ve wanted to go since I was about 10 years old.  I will be supporting FIRST by recording a series of podcasts leading up to the event to share some of the history behind the event, give listeners an idea of the topics that will be covered at the conference and even a little bit of flavor about what Kyoto will look and sound like in June.  I’ve already recorded several interviews with the people who will be speaking at the event, such as Jeff Carpenter from CERT-CC and Slawek Ligier from Verisign and have even more that I’m lining up for the future.  We’ll be releasing these podcasts on a weekly basis and I’ll be on-site to interview the speakers live from the event.  I’ll even be speaking at the event myself.

The first FIRST podcast is an interview with Mick Creane who is the 2009 FIRST Conference Program Chair.  Mick’s job has been to organize the conference overall and find interesting people to come speak at the event.  He gives us a litttle background into why this year’s topic is “Aftermath: crafts and lessons of incident recovery”.  Many of us think of ‘incident response’ as a computer security issue, but as Mick points out in the podcast, it’s at least as much about the physical recovery after an incident as it is the virtual recovery.  He also talks about some of the folks who’ll be speaking and why it’s so important that an event like this continues to be international, not just US or north american.

FIRST Podcast, Episode 1:  Mick Creane, 2009 Program Chair for the 21st Annual FIRST Conference

Next week I’ll be returning with Jeff Carpenter from CERT-CC, one of the organizer of the 2009 Best Practices Contest:  Detect.  It’s not too late to get your own submission in for the chance to win $5000!  And keep your ears open for interviews live from the event this summer.

Technorati Tags: FIRST, incident response, podcast

All it took was a hacksaw and a few minutes underground and someone was able to take down internet, phone and cell phone coverage for much of the south Bay Area here in California.  Four fiber optic cables in San Jose and two more in San Carlos were cut yesterday effectively taking most of Silicon Valley off line and causing thousands to lose their connectivity and be without services for hours.  And now AT&T is offering a $100,000 reward for any information that will help them catch the person who cut the cables.

So why would someone cut these six cables?  This had to be someone who had some experience with AT&T, Verizon and Sprint, since they knew not only where to find the cables underground, but knew which cables to cut to cause the maximum damage.  Which means this was thought out and intentional.  My first thought is that it’s some Hollywood movie caper where the bad guy’s are trying to silence an alarm at one of the businesses affected by the outage so they can perform dastardly deeds undisturbed.  My second thought is that it’s someone using this to cover up some sort of wire tapping they’re putting in place while everyone’s attention is gathered elsewhere in the infrastructure.  Someone who’s not a governmental agency, due to the loud nature of the event; they’d be much quieter and just install something in the basement of AT&T. Except that’s already been done.

But the reality is probably closer to a disgruntled employee who was recently laid off by one of the companies affected by this event.  Someone who knew enough about the infrastructure to understand where the systems would be most vulnerable, know how to get to the cables and know how to cut the least of them to be the most effective.  While the overall infrastructure of the Internet and our communications systems are generally robust, this event proves that connectivity to a specific area can be easily disrupted if you know where the pressure points are and how to affect them.  This might be knowledge that can be gained in some other way, but the simplest explanation is that it was someone who’d worked on theses specific networks and knew exactly how to cause the most damage quickly.  If you’re someone who’s recently been laid off by one of the companies affected, don’t be surprised if you get a knock on your door by an investigative agency in the next couple of days.

In reality, this wasn’t much more damage than might be caused by a severe winter storm downing a couple of trees, but the amount of press coverage it’s created is far more damaging to the telecom companies than a downed tree would be.  It shows that despite all the redundancy that they advertise, or at least is assumed by most people, they still have portions of their networks that can be taken offline with a couple snips.  This is not the sort of embarrassment that any company wants to have aired so publicly.  No wonder they’re offering such a big reward; the PR to recover from this is going to cost them a lot more than the reward itself.  And what if the vandal strikes again, perhaps somewhere even more vital?  Some sort of explosive placed in the right part of downtown San Francisco could take a heck of a lot more than 60,000 people offline for a long time.  Don’t be surprised if we see this labeled as ‘terrorism’ and have the alert level raised in the Bay Area until this person is caught.

Update:  I wish I’d seen this article before writing my own.  I hadn’t know there were contract negotiations going on between AT&T and the folks who do a majority of their repair work.  That could provide a heck of a lot of motivation to someone who’s affected by the lapsed contracts.  And explain why a hacksaw was used instead of something more destructive.

As much as I’d like to take a few days and head out to Las Vegas for CSI SX and Interop, it’s just not in the cards for me this year.  However, if you have the time to go, the organizers have given me a promo code you can use to get a 15% discount on admittance.    All you have to do is use the code ‘MCKSX‘.  There’s going to be a track on compliance as well as a track on cloud computing, both issues I’d really like to hear other people’s opinions on.  Not that I don’t have my own opinions, but I’m always interested in hearing how other people view these issues.

If you end up going and use the discount code, let me know.  I’d love to get a chance to hear about the experiece and maybe even set up a short interview for the podcast from the showroom floor.  I’m not sure that would qualify as anyone’s 15 minutes of fame, but it still might be fun.

Rich and I recorded this week’s podcast Monday night because I was supposed to be in San Francisco at Seesmic HQ learning about the newest version of the Twhirl twitter client, but after the day I’ve had, coming home and doing the final edit on the podcast was a much better idea.  Besides that I have another podcast to do some editing on and about twenty hours of other work I need to get done.  The worst part is that I have the new Harry Dresden book, Turn Coat, by Jim Butcher and don’t have the time to read it tonight.  And my life is relatively calm compared to Rich’s.  Oh well, if we survive the week, there’ll be another podcast next week.

Network Security Podcast, Episode 145, April 7, 2009
Time:  31:52

Show Notes: 

• Thoughts and notes from the PCI DSS hearing in the US. House of Representatives
• Portable Ubuntu runs Ubuntu inside Windows – I couldn’t get this to work, let me know if you have better luck
• Tonight’s Music:  Mistaken by Nick Cook

Sometimes things just don’t go as you planned.  Sometimes nothing goes as you planned.  And sometimes the stuff hits the fan.  Over the last few days, stuff that has been hitting the fan is the sanity of the people who’re putting on the Security Bloggers Meetup and the Social Security Awards.  We’ve had the best of intentions and done the best we can to create both an enjoyable event and a mechanism to recognize some of the leaders in our community, but we’ve made some mistakes.  Hopefully the event will still be a lot of fun, but we’re having to make some changes to how the Social Security Awards are operating in response to the errors we made and the way it’s affected the outcome of the awards.  For a fuller update on the story, read Rich’s post on the RSA Conference Blog “Reboot:  Fixing the mistakes we made with the Social Security Awards“

We’re being as open and honest about the process as we can in the hopes that you’ll give us feedback and ideas for doing this better next year.  We also hope that the issues we’re experiencing with the SSA’s won’t turn anyone off from coming to the Meetup.  The Awards ceremony will only be a small part of the whole event and our goal is still to have fun and give everyone involved in social media from the security sphere a chance to meet and put a face to the voices and written word.  If this incident is something that makes you change your mind about coming, please send me an email and let me know why.  Again we’re doing our best to make this right and prevent it from happening again.