SecurityCurve Weblog

Pete and Diana at the Western Wall.

How cool is that?

Fear. Oh, it works...

I came across an interesting thing this morning - over at SANS, there's a brief one-pager about using fear as a sales tactic. Basically, it's a cautionary statement about how fear can backfire and it probably isn't the best way to sell product in the security arena. All of which is absolutely true.

The problem though, is that it's so darn effective. It has to be, since so many of the vendors in security use it. It seems to me kinda like spam - if there weren't some percentage of the population that receive spams and actually buy stuff as a result, then it wouldn't continue. So, people must be responding to the fear. Everyone in this industry uses it - journalists use it to get eyes, vendors use it to get sales, salespeople use it get meetings. So, we know it works.

See... take a look at a few of today's headlines:

The Internet's Biggest Security Hole
Most IT Staff Would Steal Company Secrets

and so forth. Now, neither of these articles would be things I'd classify as FUD per se. In fact, they're both interesting and well-written pieces. But the fact of the matter is that there's a *startle* component that makes us take notice. Does that count as fear? Arguably. And it works.

Should it work? Maybe yes, maybe no. But clearly it does. And we're into our second decade of continued effectiveness. So I'm not sure I buy it that there's much of a backlash going to happen soon.

Emergent Chaos Take on TSA Inspector

First of all, I wanted to start out by pointing out the great post over at Emergent Chaos about the TSA foolishness I referred to earlier in the week. Adam's take is always welcome (especially when we agree!) A must-read if you haven't already, in my opinion.

Best Western: Failboat? or just Fail-Canoe?

So, you heard about Best Western, right? The Sunday Herald originally ran the story saying that up to 8,000,000 records were impacted. Best Western says that wasn't the case. So which is it? I'm not sure we'll ever know. We can speculate, or dig around to try to get more data, but at the end of the day, it's going to be hard to figure out.

Not that it matters for where I'm going with this, but my personal take is that Best Western must have some kind of leg to stand on since they put out a press release refuting the Sunday Herald story. Say, hypothetically, that the original story as reported was accurate - can you imagine the world of pain and suffering that Best Western would experience in terms of bad PR? We know from Hannaford and TJX that not much happens to you when you lose a lot of data - but if you say you didn't lost the data and then it turns out you did? That's like a PR bunker-bomb. So it seems to me like the stakes of the press release being false are so high that - in my opinion - it's likely to be almost retentively accurate.

Was Elio Montenegro Right or Wrong?

I've been watching with interest the debate going on over at aero-news about the TSA flight inspector that grounded some planes over at O'Hare. It's kind of a long story, so here's a brief recap:

A TSA inspector (tasked with inspecting planes) was looking over some planes over at O'Hare. Seeing a metal post jutting out of the front of the plane, he tried to climb it (looking to see if surreptitious entrance could be gained to the cockpit that way.) Unbeknownst to him, the post he was climbing was the temperature gauge (which is pretty important, apparently). The gauge broke, they maintenance crew found it, and they grounded the plane. Not a good situation in any light, but here's where it gets freaky.

Now comes some serious aftermath. Airline personnel flipped out. They called the inspector "bumbling", "incompetent", and compared him to Inspector Clouseau. The aero-news article is the most vitriolic (which is, of course, why I selected it), but suffice it to say that there was major backlash.

The TSA responded saying that they encourage inspectors to find issues like this one. This just put more fuel on the fire. Aero-news ran an update to their original story, where they recommended that the TSA be dismantled because they have "the potential to imperil the flying public in myriad ways". Again - major freaking out.

But, as a security professional reading this, *both* the TSA inspector and the airline response creep me out. OK, so the inspector endangering lives - that's never good. But the fact that one guy can do something seemingly minor, out of sight of any ground personnel, that could potentially bring down the plane isn't comforting. Isn't the TSA ostensibly there to stop just this kind of thing?

Think about that for a minute, and put aside the fact that the temperature probe practically begs someone to slap a climbing karabiner on it. If the TSA's job is to look for attacks - and the reaction from the airline pros makes me think this is a pretty good one - isn't this inspector a hero? After all, from a security practitioner point of view, the fact that the TSA inspector was thinking outside the box and looking for a useful point of attack to the plane means he's doing his job.

It comes down, in my opinion, to the fact that there's a disconnect between the TSA and the folks in the airline industry about what the role of the TSA inspector to be. If their role is to find "security issues", they should be encouraged to find problems like this and point them out (so they can get fixed). If their job is something else - well, then they shouldn't be monkeying around with the probes. At the end of the day, if it's true that damaging the temperature sensor prior to takeoff is "an extraordinarily dangerous incident", it seems to me that somebody ought to know about that before somebody else deliberately sabotages one.

Now, some pilots think the role of the TSA should be more limited. According to the article, some pilots "respond that agents are only allowed to check for unlocked cabin doors" in their inspection. That seems bogus to me. Seriously - checking the door? If that's the role of the TSA, I'd ask what's the point of having TSA inspectors at all? Get the pilots to check if it's locked. Seriously - you reach over, jiggle the handle or whatever, and whamo-blamo, Bob's your uncle (for realz on this one, I do it with my car door all the time.)

Anyway, at the end of the day, I think the fact that this probe can be damaged by a lone person - and that the damage to that probe can jeopardize the lives of the passengers - is a significant threat. Is it the TSA inspector's job to find this threat? Maybe not. Maybe he was totally in the wrong. But shouldn't it be somebody's job to point it out? And how about fixing the issue? Maybe it makes sense to hire TSA inspectors who are also aircraft mechanics so that they know how to look for issues like this; maybe it makes sense to guard the plane when it's on the ground. But seriously - somebody do something.

It seems to me that the TSA and the airline personnel should be working together on this rather than going after each other. In the gap between the pilots' outrage and the TSA's "blue line", there's issues that clearly aren't getting fixed.

Grouchy Smurf Says the MBTA Sux

We in this house love Boston. It's a great place. Especially those little cream pies that they have at the Omni Parker House... mmmmm... they melt in your mouth.

Yep. We love Boston. But the MBTA... that's another story. Maybe you heard, or maybe you didn't, that the MBTA sued three MIT students and had a court issue a gag order to prevent them from publishing their research about how the MBTA system can be defrauded.

Now, a lot of folks have made this about full disclosure. I, for one, don't think it is. I understand the temptation to make the parallel, though. But in this case, we have to acknowledge that the forces at work are different. Full disclosure - at it's core - is about getting product companies to fix their bugs. It works because it embarrasses vendors into fixing their issues.

The MBTA, on the other hand, probably won't be able to fix this issue - at least not in the short term. They're not a product company, so they're going to feel the pressure in the same way that, say, Microsoft would in the event of a Windows bug. So embarrassing them - well, it really doesn't serve much of a purpose (other than intellectual curiosity) than just embarrassing them. They've already got a significant deployment going on and probably quite a bit of money invested. So it's probably not worth their while to fix the issue. Which means, at the end of the day, that their probably right in saying that publishing the details of the issue is likely to encourage people to exploit that issue.

That being said, I think they have a valid point. Even so, however, I still disagree with their decision to take these kids to court. Not because they're argument isn't accurate (which I think it is), but instead for two wildly different reasons: a) because of the precedent that it sets for future research, and b) because it's dumb (counter to their own interests).

Now the question about the chilling effect on future research has been beaten to death, so I won't beat it again here. But the stupidity argument I haven't seen yet, so I'll lay it out. What's the best surefire way to make sure that everybody in the free world hears about the MBTA fraud issue? If you wanted to shine a spotlight on this thing, what would you do? How about suing some college students and making it into a free speech issue? Oh yeah, brilliant idea... we're the government, so let's take some college kids to court over it - that'll go over well. Not. If they had just ignored it, it would have been a blip on the radar - some people out at DefCon would have heard about it, and everybody would have moved on. But putting on a Darth Vader mask and standing on the rooftops shouting that you're the evil empire? Not such good PR.

Stolen Laptops, Redux

I got a question for you. What percentage of corporate laptops do you think have some sort of personally identifiable data on them? Take a second to mull that over while we go over something else.

Now, you may not remember this, but I've suspected for a long time that things are not what they seem in the disclosure space. I.e., do we really think that everybody who actually has a breach is disclosing the way they should?

Now, back in the day, I speculated that at least 10 percent of breaches were going unreported. Where are we now? Let's use the same method as last time and see if the situation has gotten any better in the year or so since I last posted that.

Now, we know that the "stolen laptop" number was up to about 624000 for 2007 (for just airports alone, but let's use that since we don't have any better data.) Now, while we don't know if any of those laptops had PII on them or not, but we *do* know that the total universe of publicized breaches (446) for 2007. If we assume that every stolen laptop with PII lead to a breach disclosure (which it should), then we can accept that - at the very least - the total (446) represents some superset of all the lost laptops.

So, let's churn some logic to see what we can conclude about how many of these laptops have "disclosure-requiring" data on them:

We'll start with the (spurious, but useful for making the point) that every breach was a result of a stolen laptop. Realistically, the number of breaches will include other things as well, but assuming that they're all a result of laptops gives us a "best case" upper bound for how many are responsible for breaches.

To get to where we need to be, we figure out what percentage of the total laptops stolen were reported via breach disclosure. That number is .07% - 7 in 10,000. Which means, 7 in 10,000 laptops have PII on them.

If that's true, it's more likely for Joe Average to pull a full house in his next game of 6 card stud than it is for him to have PII on his laptop. Bullshiz. 7 in 10k? Not likely. In reality, it's gotta be higher. Maybe, if you really want to get all optimistic, you might say that 1 in 100 have PII on them. Which is still an order of magnitude lower than what's being reported.

So, really... where are we now? The only conclusion I can possibly draw is that breaches are under-reported by at least an order of magnitude - for airport laptop thefts alone. And unless I'm totally off base, it's a common enough occurrence that it's only a matter of time before someone gets caught failing to report. As to whether anyone will care or not - well, that's a different question.

Now that the dust has settled, I call shenanigans all around

So, I'm sure you heard about the Super-duper tip-top secret DNS Cache Poisoning issue? In case you haven't, here's a quick synopsis of backstory. For the TLDR ("too long, didn't read") crowd, a synopsis of the synopsis is:

- Researcher finds a big bug in DNS
- Because it's so incredibly huge, non-essential peeps were kept in the dark for 6 months
- The supreme largitude of the patches to be released brought on dead silence for 30 days
- The silence was lifted at BlackHat where the technical details were revealed onstage

Now, throughout this whole episode, people were all kinds of pissed off because the researcher in question didn't go the whole full disclosure route and just ante up what the issue is. Other people were pissed off because of the pressure to go public. Seems like too many people in a huff.

Personally, I'm a fan of natural selection, so I tend to agree with the folks that say that holding back the information was bogus. What do I mean by natural selection? I mean - if product A can't release a patch to address a security issue in a reasonable timeframe, folks should know about that. If that means that they're unprotected against some issue for a few days, maybe that's a small risk by comparison. Small compared to what, you ask? Well - simply put - compared to the risk of keeping the bug on the down low while everybody fixes it. Here's why...

Say, hypothetically, you have a known bug that you're keeping quiet for a year (or 7 months if you want to get all literal about it). How many people do you think know about that bug during that time? The developers? Well, they'd have to know right. In a multiple-vendor alert like this one, you're talking about most of the developer population for all the products that are impacted. Could be a pretty big audience. The security architects at these vendors? Absolutely. Management? Of course. Technical writers? Sure, somebody's got to write the alert.

Do you think that out of all these people, somebody's not going to let the goods out to someone? It seems inevitable to me. Plus, don't forget about human nature. If you tell someone something is super-secret, doesn't that make it all the more compelling for them to tell their friends? Absolutely. So the theory that people are going to keep it under their hat is ridiculous. In reality, there will be people with the data. I guarantee it. So, probably disclosing the details is a good thing.

In this case, I don't think that anybody was motivated by anything untoward. I don't think it was all about "hacking the press" as some people seem to suggest. Instead, I really think the secrecy was an attempt to do something good and keep people safe. Good intentions. However, I think it probably could have been handled better. Personally, I probably would have gone through CERT since they seem to be pretty good at this kind of thing. But hey, that's just me, and it's easy to armchair quarterback

PCI Security Standards Council: Summary of Changes DSS 1.1 to 1.2

Yesterday the SSC released a 4 page summary document of changes to the PCI-DSS. The next version of the DSS is due out on October 1 this year.

So how's it look? Overall, we're pretty encouraged. The core changes relate to wording clarification and will help merchants and retailers to understand available options for compensating controls.

As with any update, though, it looks like this one might have introduced some big questions as it simultaneously answered many others. Let's take a closer look:

Cause for Celebration Changes

Requirement 1 – “…review of firewall rules, from quarterly to every 6 months…”

This one is going to make a lot of happy – though we hope the DSS stresses review for change management assessment and control every time a change to the rules takes place.

Requirement 3 – “Emphasized use of consistent terms throughout, such as “PAN” and ‘strong cryptography’”

Another good move, we can’t tell you how many times we’ve been asked what the council means by “strong crypto” – having clarification will make answering this easier for merchants and retailers.

Requirement 6 – “Added flexibility to the patching requirement by specifying that a risk-based approach may be used to prioritize patch installation”

The end of the 30 day mandatory patch cycle? We can hear the cheers going up around the globe.Consider: retailer “A” who willy-nilly installs a patch into production vs. retailer “B” who wants to test thoroughly,
prioritize, and follow a robust pre-production process. Under the old rules, retailer “B” (who arguably has a better process) would be penalized and retailer “A” would be OK. Now they’re both in good standing. This is a good move.

Requirement 9 – “Provided flexibility in the requirement for cameras to allow organizations to select other appropriate access control mechanisms”

Ah! This one caused many merchants concern, especially in smaller stores and for all POS – this change will be welcome and does not need to impact overall security if the controls in the 1.2 version are robust and well thought out. Now your local steakhouse won’t be out of compliance for not having cameras in the dining room!

"Clarified that the requirement to secure media applies to electronic and paper media that contains
cardholder data”

This might be a good news/bad news one. We’ve long counseled that the DSS refers to electronic and paper – some companies have tried to ignore the paper protection requirements. For security professionals, we do feel this will be welcome as it will clarify the requirements and help explain procedure and control decisions to executives who may have thought the DSS applied to e-data only.

Cause for Consternation Changes?

Wireless must now be implemented according to industry best practices (e.g., IEEE 802.11x) using strong encryption for authentication and transmission.

Wait – is 802.1X* now required for transmission? Does this mean SSL/TLS and IPSec are no longer viable options? This could cause problems for retailers with large legacy wireless networks and that may not support 802.1X without a forklift upgrade.

“New implementations of WEP are not allowed after March 31, 2009… Current implementations must discontinue use of WEP after June 30, 2010

This is going to hurt. Keep in mind that a number of “out of the box” PoS packages rely on WEP for proper operation. I’m wondering what the blowback will be from retailers who have to replace their entire at every retail location before March 2009. I wouldn’t want to be on the other side of that conference call.

Requirement 5 – “Clarified that requirement for use of anti-virus software applies to all operating system types”

*Really*? Vendors with AV/AS for *Nix and Z/OS get your sales forces ready! Again, this is lame. I don’t understand why they’re bothering to change this – under the old rules, only systems that could get malware were
required to have AV. Under these new rules, every system under the sun has to have it – even those platforms that don’t necessarily have readily-implementable AV. Again, I’m not sure what the motivation here
was, but I’m not sure this is a good move.

And finally a couple of special call-outs:

Score one for the Wireless Experts

"Removed requirement to disable SSID broadcast since disabling SSID broadcast does not prevent a malicious user from determining the SSID”

Yee-haw! This is a poorly understood reality of the wireless networking world – reps to the DSS writers who got this right. Now if they’ll convince AirMagnet to stop reporting on it…

Copy Editor Finger Wagging:

*Requirement 4: “Wireless must now be implemented according to industry best practices (e.g., IEEE 802.11x”

802.11x is sort of the “Gen-X” of the 802.11 world. There’s no IEEE standard for it – perhaps the Council meant, “the IEEE for changes to 802.11”? More likely, the Council meant 802.1X – the IEEE standard for authentication and key management on Wired and Wireless networks.

Requirement 6: 6.6 is now mandatory. All public-facing web applications are subject to… installing
an application-layer firewall”

There again is the “application-layer firewall. The fact that they called it an “application layer firewall” the first time around caused so much confusion the first time around that they had to issue specific guidance on it. Since they’re
changing the document anyway, why not just change it to say “web application firewall” and get rid of the additional guidance? It’d make all our lives easier.

Pirates of the Burning InfoSec

Woo doggie. Man I feel refreshed! I guess a year-long blogcation will do that to you. Well, anyway - I won't say much about my prolonged absence other than to say that it was a long time, I realize that it was a long time, and probably anybody who used to read this blog has since went away. Well, that's OK - we'll think of it like an experiment. If there's anything of use over here, than folks might come back. Otherwise, I should probably shut up. :-)

Moving on. I saw today an article from last month about Security Policy Considerations for Virtual Worlds by Jeff Surat over on HelpNet. Now, maybe you remember (from back in the day), that both I and a colleague did some research on this a year or so ago. Now, I like where Jeff is going with his discussion. He mentions the grey goo infestation, which I thought at the time was fascinating as hell, and he alludes to security (and business) risks that you can open yourself up to by participating in these communities. All interesting stuff.

The only thing I was disappointed by with Jeff's article was that he didn't go into some of the broader fraud impact of these communities. Consider, for example, the following scenario:

Goal: Someone wants to bring 10,000 dollars into the US without filling out any nasty paperwork, alerting the authorities, or having to answer any uncomfortable questions. Can they use SecondLife to do it? Sure... check it out:

Step 1: They sign up for Second Life and get an account.
Step 2: They use the Lindex monetary exchange to exchange their native currency into Linden Dollars.
Step 3: They trade that currency to their associate "in game"
Step 4: They withdraw that currency in the US as USD

Sweet, huh? What if they wanted to launder drug money? Do you think legions of semi-anonymous virtual transactions like a Second Life nightclub might be a good strategy to launder that money. Hmmm... Jeez, ya' think?! I seriously doubt that Linden Labs is keeping meticulous records of currency exchange in game unless somebody in authority (hey Secret Service and OCC, you listening?) requires them to. It'd sure be nice for someone to notice this completely unregulated, borderless, and anonymous monetary exchange.

Oh well. Anyway, interesting stuff over there at HelpNet.