Archive for May, 2010

May 28 2010

It’s frustrating being a QSA, but sometimes it’s rewarding

Published by under PCI

It can be downright disheartening to be a QSA.  If you do your job and identify holes in a merchant or service provider’s systems, they’re upset.  If you try to help them adapt their current systems to meet with PCI, they think you’re letting them off the hook.  If you send them a packet of documents about what to expect during the assessment and what they’ll need to gather, more often than not the client will ignore it and claim you never told them what you needed.  If their due date for compliance is coming up quick, it won’t matter how long you told them the writing and quality control process would take, they want their Report on Compliance turned around overnight.  And then there’s the whole ‘check list’ mentality that has many people responding to the letter of the PCI DSS, completely ignoring that with a little more effort they could have increased their security instead of just marking off a box.  Yes, being a PCI can be frustrating, annoying as hell and will burn you out if you’re not careful.  Just ask my friend Michelle, she’ll tell you exactly how hard it is to be a Qualified Security Assessor.

She’s got a number of good points; we see all too many clients who just want to have their PCI assessment and then ignore the whole thing for the next 8-10 months, until the whole process starts over again.  They don’t want to think about PCI at all during that time, they don’t realize that there are a number of requirements that mandate continuing effort on a daily basis, not just when the assessor is on site.  And we never, ever see clients putting lipstick on the pig just to cover up a deficiency until the assessor is gone.  Oh no, never that.

But there is an upside to being a QSA.  Some security departments have learned to do an awful lot with very limited budgets.  Some clients understand that attaining compliance as a side effect of security is actually cheaper and easier than trying to do it the other way around.  Some clients actually want an honest review of their environment that identifies potential weaknesses outside of a strict interpretation of PCI.  And every so often you run into a client who’s doing something unique and unusual that doesn’t meet the letter of the law of PCI but still manages to exceed the intent of the requirements, sometimes by quite a bit.

These are the clients who keep me from pulling my hair out.  I find it rejuvenating to talk to a client about the security impacts of changes to their environment honestly, rather than trying to argue an interpretation of PCI that doesn’t require them to make any changes or worse, leaves them less secure if implemented.  When a client understands their own environment and knows why their data is where it is, it makes my job, and theirs, so much easier than when clients are doing their discovery while I’m on-site.  And sometimes I’m actually working with a client to secure their environment, rather than fighting to get them to implement basic security controls.

I recognize that being a PCI QSA and consulting with clients on meeting the DSS requirements is a balancing act; we try to balance security against the DSS against budgetary and manpower constraints.  And since we only have two hands, balancing three competing limitations is hard, very hard.  If you’re in this field and you don’t feel burnt out from time to time, it means you don’t care.  And that is probably a bigger vulnerability than most of the technical requirements in any compliance framework.

It’s the clients who view the security of their company as a calling that keep me coming back.  It’s easy to check off a box, go home at night and ignore what’s happening to your business while you’re away.  But some security professionals are intensely passionate about what they do and how well they’re protecting their enterprise.  These are the people who make being an assessor worthwhile.  Because even if you’re arguing with them about an interpretation or commiserating about a requirement that sounds stupid on the surface, you know these people care and at the end of the day, they don’t just walk away thinking their job is done, they worry about bettering their company’s security the next day.

Next post I’ll address Branden William’s post “Why ISA’s are qood for QSA’s”  Can you say “arm chair quarterbacks”?  I knew you could.

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

5 responses so far

May 26 2010

Press Release: Astaro RED

Published by under Encryption,Firewall

It may not quite be VPN for Dummies, but Astaro RED sounds pretty close if you ask me.  I talked to Jan Hichert at Astaro about RED (Remote Ethernet Device) at RSA earlier this year and the way he talked about this new product, it seems like it’s an easy way for companies to add a remote office without many of the headaches this often entails.  I haven’t played with it myself and haven’t talked to anyone who has yet, but at least in theory it sounds like a good product.  Basically, you run Astaro Security Gateway at your central office, when you bring the remote RED box online, it phones home to Astaro, where it receives instructions on how to connect to your central office server.  There is configuration, but it’s mostly handled by Astaro before it ever gets to your office.  I’m sure Jack Daniel can tell you more if you’re interested, but in the mean time, the press release follows after the break.

Continue Reading »

Comments Off on Press Release: Astaro RED

May 25 2010

The Network Security Podcast, Episode 198

Published by under Podcast,Privacy

This episode is brought to you by the letter “P”. We start with a couple of articles about privacy (yes, mostly about Facebook), with a short segue on random security news, before closing with multiple articles on PCI.  We went a little long tonight, but not nearly as long as we could have if all three hosts had really gotten going on privacy.

Network Security Podcast, Episode 198, May 25, 2010
Time: 41:08

Show Notes:

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

Comments Off on The Network Security Podcast, Episode 198

May 24 2010

Will merchants revert to their old ways?

I’m a big fan of tokenization and end to end encryption (E2E2).  Never mind the fact that neither technology is fully developed, nor do we even have a real definition of either technology.  The fact that both of these technologies have the potential to take credit card information our of the general merchant environment and gives the bad guys less reason to attack is enough for me.  It won’t stop attacks against merchants all together, but it will cut down on the value of breaking in and therefore cut down on the number of attacks, at least in theory.  It will also cut down on merchants’ responsibility for meeting with the PCI DSS requirements, since much of environment that the QSA’s have to review will now be out of scope.  But without the threat of PCI (and potential fines/fee increases) will merchants keep up the minimum security safeguards that PCI mandated or will they revert to their old ways and ignore security for the most part?

One of the big questions that comes up over and over again is how effective is PCI in securing the merchant environment.  And the answer is, no one really knows.  Breach disclosure laws prior to 2003 were non-existent, and even once California passed SB1386 and got the legal ball rolling, breach disclosures have been spotty at best.  Now that we’ve got some 40 states that have some form of breach disclosure law, the information we’re able to gather is much more consistent.  Unluckily, we still lost the ability to have any real baseline to measure the success of PCI against and anyone who says that PCI is or isn’t effective is mostly going on their own anecdotal evidence, not hard data.  Verizon’s Incident Metrics Framework may help in gathering statistics going forward, but we’ve already lost the data needed to measure the effectiveness of PCI.  (Disclaimer:  I work as a QSA for Verizon Business)

As tokenization and E2E2 take hold, we’re going to have another chance to see how effective PCI is in securing the merchant environment and whether or not merchants are really going to secure their environment without the threat of PCI hanging over their heads.  There’s almost nothing in PCI that a shop with a good security program shouldn’t be doing in the first place.  Firewall reviews, anti-virus, log monitoring, IDS, etc. are all safeguards that are mandated by PCI but are security measures that any good security shop should be putting in place for their organization by default.  The fact that many organizations couldn’t get the funding for some of these tools until PCI came along is a measure of how hard it is to get the budget for security.  And if organizations start losing the funding for these projects because tokenization and E2E2 have taken the majority of their systems out of the scope of PCI, we’ll know that PCI was the real driver for the safeguards, not any real concerns over security.

PCI is expensive.  Security is expensive.  Not necessarily because the tools are expensive, but because merchants ignored security for years and have had to spend a lot of money and time to implement the tools they should have been running in the first place.  If they can reduce the scope of the systems they have to protect through new technologies and no longer have to be assessed on an annual basis, do you think they’re going to keep paying for the tools that they implemented just for compliance or do you think they’re going to let their IDS and log management tools fall by the wayside?  I know that some of the shops I’ve seen will keep the tools and keep using them properly.  But I think the majority of merchants are going to go back to their old ways and do the bare minimum that their security group can fight to keep.  If your company’s marketing department depends on PCI to make sales, I’d be very afraid of tokenization and end-to-end encryption.

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

5 responses so far

May 21 2010

Rich will be on Science Friday today!

Published by under Family,Privacy

It’s only a couple of hours away, but Rich Mogull will be on Science Friday today talking about online privacy and Facebook.  I don’t know how much time he’ll have on the air, but he’s living a geek’s wet dream by getting on NPR and being asked about privacy.  I’m sure the show will be available as a podcast and online later, but I’ll be sure to listen in live.

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

Comments Off on Rich will be on Science Friday today!

May 21 2010

Are low standards better than no standards?

Published by under Hacking,PCI,Simple Security

On Twitter this morning, @secrunner made the following comment:

“I think it’s surprising that PCI still hasn’t developed a program to certify pen testers or at least standardize the approach”

In reply I stated that given the level of certification for ASV’s (Approved Scanning Vendors), I’m just as happy if the PCI Council would stay out of the business of certifying pen testers or creating a standardized approach.  In reply @secrunner asked the following:

“In the spirit of PCI, isn’t even some standard (even a low one) better than none?”

The answer is, no, it’s not.  To be more specific, my answer was “Low standards for a merchant are better than nothing.  Low standards for a vendor are misleading at best, dangerous at worst.”  Let me explain why I think this way:

When you go shopping, one of the last things on your mind is probably “How does this merchant protect my cardholder information?”.  It’s one of the first things I think of, but that’s what I do for a living.  Most people are just concerned about if their merchant is going to have their size or the best price on the new toy they want.  They just assume the merchant has taken the necessary steps to secure their cardholder information.  And if they haven’t, consumers know that they’re only responsible for the first $50 dollars worth of fraud, and even that is usually absorbed by their bank or credit card company.  Sure, getting a new card issued to you is a bit of a hassle, but for most people it’s something that’s over and done with in a few minutes.

In this case, security is assumed and is not the primary concern of the person doing the purchasing.  A default standard such as the Payment Card Industry (PCI) Data Security Standards (DSS) is important and useful because it gives a baseline level of security for the industry to meet.  It may not be the level of security the company really needs to protect themselves, but all too often this baseline is more than the company was doing prior to the standard.  It may not be perfect security, but at least it pulls you up from the level of ‘low hanging fruit’. 

Certifying a vendor as a ‘compliant’ or ‘certified’ is a completely different story.  When an industry group such as the PCI Council makes a standard for a class of vendor and then certifies these vendors as meeting a certain baseline, this certification becomes one of the primary influencers in the purchasing decision.  Using the ASV certification as an example, a merchant won’t even consider a scanning vendor for their company unless the PCI Council has already certified them.  The merchant has to use a vendor who’s been certified otherwise they can’t submit the scans as part of their own compliance.  A large part of why this works is that external scanning of web sites is a fairly well understood, repeatable and, most importantly, testable process.  It can be easily automated and running the same test against the same site ten times will generally generate the same results every time (okay, maybe 90% of the time)

Penetration testing is an entirely different issue.  Yes, there are automated tools.  Yes, some pen testers don’t go much beyond that level.  But the good pen testers I know treat penetrating a company’s defenses more like an art than a science.  Metasploit and other tools are their paintbrushes, but it’s the person who’s using the tools that is actually making it possible to find the vulnerabilities in your company so that you can shore up your weaknesses and prevent someone else from finding them.  This isn’t a process that easily documented, standardized or testable.  It might be something you can do on a person by person basis, just as the PCI Council does for QSA’s now, but it would be nearly impossible to do for a company.

Let’s be honest, in the PCI-DSS, the idea of ‘penetration test’ is barely even defined.  It has to have a network portion and an application portion, but the how’s and what’s of penetration testing are left up to the QSA to verify and validate.  There’s no agreed upon standard in the industry of what makes a pen test a valid and acceptable pen test, let alone within the PCI community.  If the PCI Council wanted to certify pen testing companies, the first major hurdle they’d run into is making up that definition.  Then they’d have to come up with a way of testing companies’ adherence to the standards and create a certification program.  This would be a huge battle to undertake and the benefits would be minimal. 

Right now, it’s up to market pressures and QSA’s to determine what’s a ‘real’ penetration test.  If someone created a penetration testing certification there’s only one group of people it’d help:  marketing.  Most merchants wouldn’t read the requirements for the certification, they’d just use the certification process as a check box to weed out potential vendors.  And I can guarantee that the marketing teams would love that.  And I doubt it would make the results of penetration tests any better; in my opinion it would simply mean that most companies would ‘dumb down’ whatever they’re currently doing so that it met with the minimum standards and no more.  I much prefer seeing the merchant who’s having the pen test performed ask questions about exactly what’s going to be done and try to understand what they’re getting themselves in for.

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

3 responses so far

May 20 2010

Do you find press releases useful?

Published by under Blogging,General

I receive 4-5 press releases about security products a day on average and many, many more just before a major event like RSA or Black Hat.  One of the advantages of being a blogger of long standing and a little renown is that PR agencies send me these press releases in the hopes that I’ll write about them, which is natural since it’s their job.  The vast majority of these press releases I scan through for information relevant to my interests then file them in a folder marked “Promotional”.  I hate to admit it, but close to 95% of the of the press releases I receive never make it beyond this point.  And given the sparsity of my writing the last few months, it’s probably more honest to say that 99% of the press releases I receive never get much attention.

I know all too many professional writers take the press releases they’re given, pull a couple of interesting facts from it and write a story.  A few of them don’t even necessarily do that much, they simply write a line or two about the press release and post the whole thing.  I’m not sure if that’s an acceptable tactic in publishing circles, but it seems to work for a lot of the professional blogs I read.

Rather than just let the press releases go to waste, I’m going to start posting some of the press releases that are not interesting enough to result in a full blog post but that are still interesting to the security community.  I figure this helps the PR folks a little in getting their message out and may give you a little piece of information you need.  And I’ll occasionally make fun of all the companies that call themselves “market leaders” or “leading organizations”.  I guess it’s technically true, in the same way that I’m the most popular security blogger who’s 6’4″, of a certain weight, with a wife and two kids, living in Northern California.  Define your market narrowly enough and anyone can be a leader.

The first press release for you is from CellCrypt.  They’ve been granted FIPS 140-2 certification for mobile phone applications.  It’s interesting, it’s important to some people, but it’s not close enough to my main areas of expertise to warrant a blog post.  Maybe you can do something with it.

Continue Reading »

7 responses so far

May 19 2010

Symantec bought much of Verisign today

Published by under Encryption

So Symantec bought VeriSign’s Identity and Authentication Business today for $1.28B in cash.  A large part of this is the SSL Certificate service and their Public Key Infrastructure.  So what?  Both SSL certs and PKI are mature, stable technologies without much room for growth at the moment.  I’m not sure how this strategy is going to play out, I don’t see that this something dynamic enough to engender excitement in anyone in the security community.  I’m also not the type of blogger who can look at this purchase and find deeper meaning in it; which is why it’s lucky that I have friends like Mike Rothman to take a longer look at Symantec’s purchase.

PS. Symantec had a webcast earlier today that might have made this clearer to me, but I was unluckily on the road at the time and couldn’t listen in.

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

Comments Off on Symantec bought much of Verisign today

May 19 2010

If you’re going to the Cloud, seek the advice of an expert

Published by under General

I just got back from a lunch put on by Integralis featuring a presentation by Dr. James Ransome, the Chief Security Office and Senior Director of the Cisco Collaborative Software Group.  It was a very good lunch at La Mar and also a very good presentation by Dr. Ransome, but the majority of his presentation can be summed up in one sentence:  If you’re looking to put your company in the Cloud, seek the advice of an expert.  The permutations of what make up ‘The Cloud’ are so varied and complex that you’re either going to have to dedicate resources (which are probably already stretched thin) to understanding the Cloud or you’re going to have to hire an expert to help you navigate the maze of issues and how they affect your situation.  Of course, if you’ve been reading much of what Chris Hoff has written the last couple of years, you probably already know that ‘The Cloud’ a incredibly complex set of technologies that are all lumped under one name by marketing in the hopes you won’t dig deeper and try to understand in the first place.

I’m not going to try to explain all the complexities that make up the cloud; Hoff’s makes a living make presentations on it as does Dr. Ransome.  But I do want to point out some of the issues about the cloud that I hadn’t thought about before that came up today.  I look at the cloud through a rather narrow lens, “How does it affect merchants and PCI?”.  Since that’s where I make my living, I hope it’s understandable.  I’m generally only concerned about storing credit card numbers in the cloud and why merchants shouldn’t be doing so.  And what the Cloud Audit group is doing to make it so that maybe someday merchants will be able to store their payment information in the cloud.  But that’s a ways off and my influence on it has been minimal.

I’d say the areas that Dr. Ransome covered that I’d given the least thought to was first the legal aspects of the cloud, second the incident response and finally the electronic discovery concerns.  Since I rarely deal with legal contracts and SLA’s, I make assumptions about what will be covered, who’s going to be legally responsible for what and how all of this is going to be enforced.  But this is probably one of the most important aspects of moving your corporation to a cloud environment, since every other aspect of your experience in the cloud is going to be driven by the contracts you’ve signed with your cloud provider.  There’s no difference between the cloud and any other form of service you are provided by another company, but it’s likely to be much more complex due to the fact that so much of what makes up the cloud is still being determined.  I don’t know if there are any lawyers out there yet specializing in ‘cloud’ contracts, but I’m sure it won’t be too long before someone catches up to the band wagon.

The idea of secondary uses of data caught me a bit by surprise.  It’s not just the data you’re storing in the cloud that’s important, it’s the data about your traffic patterns, about how much you’re storing and how you’re storing it that become important.  Metadata about your company’s use of the cloud can some times be every bit as important as the actual data you’ve stored.  If you don’t have strong provisions in your contract to make certain that the metadata is yours and can’t be used by your provider, you could find that your cloud provider has found a way to make money off of the secondary data you’ve generated and disclosed more than you’d hoped.

Incident response is another aspect of the cloud that I’ve always taken for granted.  In hindsight, I shouldn’t since even most non-virtualized hosting providers don’t necessarily include a form of incident response by default, it’s something that’s got to be in the contract.  And something you’re probably paying a few pennies for, even if the price is buried within the overall cost of the hosting.  And unlike the usual rackspace environment, a lot of people probably don’t think of building a virtual IDS within their virtual server environment.

Electronic discovery, as a separate responsibility is the final issue that’d never occurred to me; I’d given plenty of thought to it in the form of log management, the legal requirements for discovery had never really crossed my mind.  From a compliance perspective, there’s the requirement to have logs and be able to use them for forensics, but from a legal stand point, how much trouble is your company going to be in if there’s an incident and you have to tell the judge that you can’t produce the evidence because it was all virtualized.  If you’re a merchant and we’re talking about credit card records, there may not be much impact.  But if you’re a major government contractor who lost important files, the situation may be a little hairier than you’d like to consider.

I don’t claim to be an expert in cloud security.  I’m interested in it and I’ve explored my little corner of the cloud, but there’s a whole lot more of it to be explored before moving major portions of any business to the cloud.  The nitty gritty, nuts and bolts technical details are vitally important, but part of what today’s presentation made me realize is that the high level architectural implications, processes and human capital requirements are probably even more important than the particulars of your underlying infrastucture.  Which in a lot of ways applies to security in general.

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

One response so far

May 18 2010

The Network Security, Episode 197

Published by under General

We start by addressing a little listener mail as we talk about how to get started in security for those of you leaving school and joining the work force. All of us started from really different backgrounds, so it is definitely an interesting question. From there we move on into the week’s security news, from Conficker, to Facebook, and hacking automobiles.

Network Security Podcast, Episode 197, May 18, 2010
Time:  46:04

Show Notes:

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

Comments Off on The Network Security, Episode 197

Next »