Archive for July, 2010

Jul 29 2010

BHDC2010: Mary Landesman, Cisco

Published by under Podcast

Cisco recently released the 2010 Midyear Security Report and I caught up with one of the principal authors, Mary Landesman, Senior Security Researcher at Cisco.  Mary talks about the outcomes of the report and how the security landscape is changing.


[Slashdot] [Digg] [Reddit] [] [Facebook] [Technorati] [Google] [StumbleUpon]

2 responses so far

Jul 27 2010

Headed to Vegas!

Well, not quite; I have a few more hours of getting packed and work before I head to the airport, but close enough.  But around lunch, I’ll be throwing all my stuff in the trunk of the car and heading for Las Vegas, Black Hat, Defcon and BSides!  I find this trio of events to be my favorite get together of security professionals.  Black Hat has the slightly more serious, business oriented presentations, Defcon tends to be a bit outrages and inflammatory, while BSides is the new kid who’s experimenting with different formats and venues.  If you’re a security professional of almost any stripe and you’re not at least petitioning to attend these events, you need to start.  The networking opportunities alone are worth the cost and when you throw what you learn about current threats, it’s not that difficult to justify, especially BSides and Defcon.  Tell your boss you heard about an amazing panel going on Sunday at noon called PCI, Compromising Controls and Compromising Security.

Whether you’re going or not, Rob McMillan over at IDG has done a good job of summarizing some of the key stories you should be watching come out  of Vegas this week.  I should be able to get interviews with at least a few of the people giving these talks, so keep an eye out here and the podcast page for this year’s series of microcasts.  Or if you hate those, you might just want to unsubscribe until next week.  In fact, if you don’t want to hear about the events going on in Vegas this week, you just might want to stop reading most security blogs, Twitter, Facebook, blogs and most other social media outlets security folks use for a little while. 

Following the twitter stream, it’s easy to see that there are a lot of security professionals eager to get to Las Vegas, meet with old friends, make new ones and get the party started.  And the parties really are an integral part of the the whole experience.  If nothing else, try making it to the IOActive Freakshow Saturday night; if last year is any example of what they have planned for this year, it’ll be worth it if only so you can say you saw it.  Just be careful how much you drink and what you say, you don’t want to be this year’s example of someone who ignored that cardinal rule.

So much for seeing eight hours of sleep a night for at least a week.

[Slashdot] [Digg] [Reddit] [] [Facebook] [Technorati] [Google] [StumbleUpon]

Comments Off on Headed to Vegas!

Jul 22 2010

Help a man out!

Published by under General,Social Networking

Like many people in the security blogger community, Tyler Reguly pays for his blog and other community efforts out of his own pocket.  For the most part, that’s not a big issue, since there are many options for blogs that are free or cheap.  But Tyler does more than just blog, he also hosts Damn Vulnerable Linux on his servers.  Again, usually not a problem, except he got SlashDotted and now has a bill of several thousand dollars to pay!  You can read the whole story and help by donating a few dollars to his cause.  I’ve had a few brushes with the same experience myself, so I can fully understand the panic he’s probably going through.  And on the off chance that he get’s more than the bill costs, he’ll be donating the overage to Hackers for Charity.

[Slashdot] [Digg] [Reddit] [] [Facebook] [Technorati] [Google] [StumbleUpon]

Comments Off on Help a man out!

Jul 20 2010

Network Security Podcast, Episode 206

Published by under Podcast

Zach couldn’t make it tonight, but Rich and Martin open the show with a call to our listeners for more email questions and topic suggestions. After answering a listener question last week, we realized it would be nice to engage with all of you a little bit more. But not too much… I mean we don’t want to touch you or anything.

We also spend a little time talking about how we handle our connectivity and security while at Black Hat and Defcon, which happen to be next week.

Network Security Podcast, Episode 206, July 20, 2010
Time: 42:38

Show Notes:s

[Slashdot] [Digg] [Reddit] [] [Facebook] [Technorati] [Google] [StumbleUpon]

One response so far

Jul 20 2010

It’s good, but it could have been so much better

Published by under Encryption,PCI

I really wish I had the time to fully explore the idea, but there’s a certain amount of resonance between the criticisms Adrian Lane at Securosis levels against Visa’s guidance on  tokenization and criticism of the PCI security standards in general.  I believe we’re to the stage as an industry that we mainly agree that the PCI standards are a good starting point but there’s so much more the PCI Council could be requiring merchants and service providers to do for security.  Visa’s guidance is much the same way, it’s a good start, but it could have been so much more.  And in both cases, I believe the reasons for the compromises can be boiled down to not wanting to require too much of the community and not wanting to limit the flexibility of the standards too much.

I believe that the Visa best practice papers for tokenization and truncation are just like the PCI standards themselves; they’re a good place to start your journey, but these requirements aren’t enough to build your entire security stance from.  It’s up to you to continue from here to determine how the particular technologies are going to impact and secure your environment.  I think the difference between providing guidance and issuing edicts is something we’ll be talking about next Sunday at Defcon, so this is good timing.

I agree with many of Adrian’s criticisms, including that Visa could have just given more specific guidance overall.  But I also understand Visa’s need to keep the guidance vague enough so as not to provide undue direction to what is basically a fledgling market space.   Which is exactly where I see the tie in with Josh Corman’s primary argument about the PCI Council; intentionally or not, they are steering the security market space through the PCI standards.  Visa could be a force for good in the tokenization and truncation markets if they predict correctly and back solutions that are for the best over the long term.  Or they could be seen as stifling innovation if they issue poor guidance.  Much like the PCI Council.

Earlier today I heard someone make the statement that the majority of companies who are compromised are using encryption in some form, but they still got compromised.  He was reminding me that none of the other silver bullet’s we’ve thought would save us from the bad guys have worked, so use truncation and tokenization, but know they won’t solve all our security issues.  As is so often the case, they’ll just move the attack to other targets and use other vectors.

[Slashdot] [Digg] [Reddit] [] [Facebook] [Technorati] [Google] [StumbleUpon]

2 responses so far

Jul 14 2010

Truncation and Tokenization guidance from the PCI Council

Published by under Encryption,PCI

If you’ve been thinking about using tokenization or truncation to limit the scope of your PCI environment, you need take a few minutes to read the two documents Visa just released, Visa Best Practices: Tokenization and Visa Best Practices for Primary Account Number Storage and Truncation.  Neither of these documents are more than four pages in length, so they only take a few minutes to read, but they give you a good starting place for asking questions about both of these market spaces.  There’s nothing exciting or unexpected in either of these documents and you’ll need to do a lot more research to understand the more complex elements of both solutions, especially as they relate to your specific environment. 

If you’re part of a merchant organization or somehow dealing with credit card numbers and you’re not considering tokenization or truncation, why not?  Is it lack of time, lack of resources, lack of management backing or something else?  Have these technologies simply not risen to the level where you felt the need to take them seriously?  I’m curious as to why you might not be looking at a technology that could limit the amount of sensitive information on your network.  I’ve talked to a number of merchants over the last year and there’s been plenty of interest in the ideas of tokenization and truncation, but I’ve only seen a few merchants actually making a move towards implementation.

I hope the next guidance we’ll see comes from the PCI Council, giving instructions on how both of these technologies can be used to reduce the scope of a PCI assessment.  What can you take out of scope?  What common mistakes might bring systems back into scope?  What should we be looking for in an implementation?  These are still relatively new technologies, the implementations differ significantly enough that greater direction and care are going to be needed in their assessment and validation.  There are some things that are laid out in the Visa documents, but I think we need to look for more specific guidance from the Council.

[Slashdot] [Digg] [Reddit] [] [Facebook] [Technorati] [Google] [StumbleUpon]

Comments Off on Truncation and Tokenization guidance from the PCI Council

Jul 13 2010

Network Security Podcast, Episode 205

Published by under PCI,Podcast

Rich and Zach are still sweltering in their perspective heat waves, but Martin managed to nab an interview with Bob Russo, the head of the PCI Security Standards Council. We also cover a couple of stories and some honest to goodness listener mail!

Network Security Podcast, Episode 205, July 13, 2010
Time:  44:44

Show Notes:

[Slashdot] [Digg] [Reddit] [] [Facebook] [Technorati] [Google] [StumbleUpon]

Comments Off on Network Security Podcast, Episode 205

Jul 12 2010

My “Letter to the Client”

Published by under PCI

Last week another assessor friend of mine started a new blog, Fear Not the Assessor.  She started it off with an excellent post, Letter to the Client.  Almost every QSA goes into a new client with a certain sense of trepidation due to client’s preconceived notions and most merchants going into an assessment for the first time are nervous because they don’t know what to expect, all they know is what they’ve read online.  That first phone call with the client is always so much fun for everyone involved.  The Letter attacks some of those notions and list some of the steps a client should be taking before the QSA ever comes on site.  As a way of introduction, a letter like this really helps put many clients at ease, letting them know that you’re there to help and not simply pass judgment on them. 

Here’s a letter of my own with several more points to ponder.

Dear Client,

We’re about to start on an effort of many months of work that both of us hope will culminate in the issuance of a compliant Report on Compliance.  There will be surprises and setbacks along the way, but I’m sure that we can work together to overcome them.  My job is to help assess the security of your cardholder environment and provide you with honest feedback about your compliance with the PCI standards.  Your job is to provide me with the information I need to make that assessment.  Together we will document your environment and show that it is both secure and compliant.

Several things you should know:

  1. Securing your data and your network should be the goal and PCI is just a signpost along the way.  Please, please, please don’t make the mistake of thinking once you pass your assessment that you’re secure and you have no more work to do until next year.  PCI is a good starting point for securing your environment, but each company is so unique that there are innumerable holes it leaves open to exploitation.  And the assessment only covers your cardholder data environment: what about the rest of your network?
  2. I am judge, but I am not jury nor executioner.  I will make judgment calls on the state of your environment and I may find things I do not believe are compliant.  You may agree or you may think your controls and safeguards are sufficient.  Make your case to me, and if we still don’t agree, we can bring in other QSA’s within my company to review the situation, starting with my manager.  Sometimes they’ll see something I didn’t. 
  3. I will never leave you wondering if I found something wrong.   I will always try to let you know at the end of the day, if not at the end of each meeting, if I have any questions or concerns.  It’s in both of our best interests for me to be as transparent as possible.  The sooner you know of an issue, the sooner you can begin investigating and getting it resolved.
  4. You are my client and it is my job to help you receive a compliant RoC.  I will give you the best advice I can to help you achieve compliance.  But it is up to you to establish the policies, procedures and controls needed to reach this goal.  If I identify a requirement that is not being met, I will bring it to your attention and help you address the issue in a timely and cost conscious manner.

Clear communication is a good salve for many of the pains an annual PCI assessment brings.  I look forward to learning about your company, your network and your people.  And I hope that the lessons I’ve learned helping dozens of companies become compliant can be used to help you avoid some of the pitfalls and false starts of compliance.

[Slashdot] [Digg] [Reddit] [] [Facebook] [Technorati] [Google] [StumbleUpon]

3 responses so far

Jul 06 2010

Network Security Podcast, Episode 204

Published by under Podcast

Once again we have a wandering host; Rich has wandered off into the hinterlands of Denver (Boulder, I think) and is too busy to call in for the podcast.  Left to their own devices, Zach and Martin muddle through tonight’s podcast without major mishap.  We’ve got a little PCI, a little disclosure and some potential cracks in the Apple Store armor. 

Network Security Podcast, Episode 204, July 6, 2010
Time:  30:28

Show Notes:

[Slashdot] [Digg] [Reddit] [] [Facebook] [Technorati] [Google] [StumbleUpon]

Comments Off on Network Security Podcast, Episode 204