Risky Business #100 -- L0phtCrack is back
This week's podcast is brought to you by Tenable Network Security and hosted, as always, by Vigabyte virtual hosting.
It's a special day for us at Risky Business HQ -- we've launched our new Web site: http://risky.biz/
We now publish two podcasts, video and written news and opinion. There's also forums, so by all means go and sign up for an account! We'll see you in there.
On this week's show we're talking to L0pht/@stake/Veracode co-founder Chris Wysopal about the rebirth of L0phtCrack, the legendary password cracking package.
just wanted to throw my 2 cents in the ring here.
your caller referenced req 2.2.1 as a reason for why turning on the IPS functionality provided by a firewall, such as a cisco ASA or PIX, would be a PCI violation and i would disagree.
the idea behind this requirement is to separate functions between different devices. so you don't wind up with the situation were web services are running on the same device as database services or authentication services like AD or NDS aren't running on the same device as security services like AV. to suggest that each and every service in an organization must be on a different device is missing the point and completely impractical for most businesses.
to come back to your original comment regarding turning on the IPS functionality just to check a box you might get you past that one particular compliance check box. the problem is you're going to fail on all of the other requirements that deal with reviewing the output logs, alerting and most importantly being able to prove you have the ability to detect intrusions and are making an effort to do so.
pci really comes down to two things. there's the standards themselves (PCI-DSS, PA-DSS and PED) which are frameworks for the security of credit card data. my belief is these documents are for the most part written very well and on point with their intended goal. they provide the right balance of high level direction and actual details for what to put in place for the protection of data.
the second part of pci is the compliance and validation piece. this is where i believe there is a lot of room for improvement. there are way too many companies out there just checking boxes. since only the upper tier, level 1 merchants, are required to bring in a QSA to validate compliance you've got an enormous number of merchants doing this themselves. most don't really care about the security aspect, aren't being forced to and just wanted to say they're "compliant" so they don't get fined. this attitude will come back to haunt them if there's every a breach and their forced into an audit by the card brands.they only way i see this changing is if the banks these merchants are responsible to start their own programs to perform routine audits. this opens a huge can of worms from a legal perspective so it's no wonder there is no talk of this that i'm aware of.
or the card brands could just change the entire credit card processing system so that no one in the chain ever has access to the raw credit card data other than the bank that issued the card. but i would venture a guess that there's way too many people with a vested interest in the current system and it would cost way too much money for that to ever occur.
that turned out to be a much longer post than i originally intended.
ps - keep up the good work patrick, i enjoy the podcast immensely. the new site looks great as well. now if i can just figure out how to get at all of the older episodes that i missed that would be awesome.
update - i just listened to episode 101 on the way home from work and your discussion with paul regarding this topic made me laugh out loud as it was exactly my final point above.
Thanks for your contribution, Lance...
I'm happy to leave discussion of the finer points of PCI to guys like you who, errr, actually know what they're talking about.
Every podcast since episode one is archived here on risky.biz and also at itradio.com.au/security
I get miiiighty embarrassed listening back to the earlier episodes though. :)
This is the guy with the (apparently) jittery voice who called up.
Thank you for your post, I do not know how QSAs view the separation of functions. If the QSA sees the IDS/IPS as another layer in security, do they want to have this seperated from the firewall?
I get your (well made) point though. I just do not know how the criteria is interpretated by QSAs.
A chat with Bromium co-founder and CTO Simon Crosby...4 days 5 hours ago
What does one do with USD$100m in stolen Bitcoins?4 days 5 hours ago
$600 million buys you a lot of fail, apparently...1 week 4 days ago
Get your fill of the week's news!1 week 4 days ago
The Grugq spitballs some secure IM ideas...2 weeks 4 days ago