Thumbing A Ride…

The DailyBreeze tells us about how Lorna Herf discovered South Bay BMW in Torrance’s sales policy of “No fingerprint, no car.” The dealership claims that this is an effort to prevent identity theft, though how this would help the customer is unclear. Additionally, this effort is being actively supported by the sheriff’s office. I think Ms Herf said it best:

They’re going about this with the best of intentions, but in the wrong way. A private dealer shouldn’t take the law into their own hands.

Things like this and the nonsense at Disney World add no discernible security or protections and serve only to get people used to having their privacy further invaded.
As always, all non-trivial privacy fears come true.

A Different X-Box Hack

Back in the day, I was a member of FIRST. (Btw, rumor has it Chris and Adam are presenting at their annual conference this summer). At the time, one of the more prolific posters to the mailing list was Robert Hensing from Microsoft (Adam, if you haven’t met Rob, you should look him up).
Anyways, I recently re-discovered that Rob has a blog, and I found this entertaining post about about resurrecting a dead x-box. I love solutions to problems like this. Not only is it ingenious, but it would also have made Douglas Adams proud.

DoS == Vulnerability?

I think that a Denial of Service condition is a vulnerability, but lots of other people don’t. Last week Dave G. over at Matasano posted a seemingly very simple explanation that nicely sums up the way I’d always been taught to think about these sorts of issues:

The ability to halt or shutdown most modern operating systems usually requires credentials (you must hava an account or be on console) and privilege (you must be in the wheel or admin group). If you can bypass authentication and authorization requirements and cause a machine to panic (let alone gracefully shutdown), then I think we have a security problem.

Security being the contentious field that it is, plenty of folks didn’t agree with his assessment. The discussion in comments (now up to 32) is well worth reading and brings up some great alternative viewpoints. Where do you stand on this issue?

Why BitLocker Won’t Help Most Companies

A couple of weeks ago, Mike Rothman linked to an article by George Ou about using EFS and BitLocker under Vista. There he made an extraordinary claim:

Since BitLocker won’t encrypt additional hard drive volumes, whether they’re logical partitions on the same physical disk or additional disks, you must use EFS to encrypt those volumes by selecting all the folders and files from the root.

I said to myself. “Surely this must be wrong, Microsoft would never do anything like that….” So I set about Googling and I discovered that I was in fact, wrong. According to the technical overview of BitLocker on technet (Section 3.4.1):

Volumes other than the operating system volume and the system volume are called “data volumes”. BitLocker encryption of data volumes is only supported in Windows Server “Longhorn” in v1.

We’ve now confirmed that BitLocker only works on the system volume. This makes it completely useless for a huge chunk of corporate America. Why? Because in most companies tend to configure their machines with at least two partitions, a systems partition where all of the OS and software goes and a data partition where all documents, emails and what not are stored. This is done for both ease of backup as well as giving IT the ability to reinstall the operating systems without the worry of overwriting users’ data. Additionally, companies are increasingly giving users external hard drives of one variety or another so that they can do their own backups.
So either companies won’t use BitLocker because it doesn’t give them anything, or worse will deploy BitLocker and think they are protected when they aren’t. I’ve already harassed Adam about this, but I’m curious about why this design decision was made.
Update: Sean from MS provided a link in the comments to the command line magic incantation to enable BitLocker on any NTFS volume. Thanks Sean!

From the Heresy Desk

Theatre Security

Before Bruce Schneier started using the term, “Security Theatre” was a term I heard from what I call Real Security People. I was designing a security-oriented NOC, and I interviewed people who built secure sites for a couple of governments, banks, and others. They said that what The Adversary thinks you can do is more important than what you can do. I was told that perception is the majority of security: “Maybe not two-thirds, but definitely more than half.” As the team built the system, we took this to heart, which made it more fun, at the very least. But I also heard from someone I know who nmapped our system and received an nmap in return that he decided it wasn’t a good idea to go further. In that case, at least, the security theatre worked.

We also used a bit of security-through-obscurity. We tweaked some of our network protocols so that they were merely incompatible with the off-the-shelf stuff. Our protocol banners lied. We particularly enjoyed having them declare that they were known vulnerable in odd ways. It was at least informative that the random attacks that came by were not tailored. No one ever tried Sparc vulnerabilities on that server claiming to be SunOS 4 with Bind 3. They hit it with the Windows buffer overflows anyway. That was disappointing, but we also learned an important lesson — the only people who care what your banners say are the good guys. The bad guys find it more economical to just spray you with whatever exploits they have in their bag of tricks. Or at least most of the bad guys.

Security through obscurity has gotten a bad rep in part because there are people who think that merely by being obscure is being secure. There are also people who think that a mediocre security system can be made secure by being obscure. If, however, you start with good security and then put a bit of obscurity on the top, it’s a bonus. Think of security as armor and obscurity as camouflage. Camouflage is not armor; obscurity is not security. People who tell you it is are trying to sell you something. However, if an attacker is faced with armored things that are also camouflaged, their job is harder. If you back up the camouflage with good log analysis, then you can take the element of surprise away from the attacker. The total effect is good security theatre, a theatre that might result in deterrance. Just be honest about it, especially to yourself. If the attacker discovers you have no armor behind the camouflage, then you have a well-prepared opponent.

There are other reasons to eschew obscurity. It isn’t scalable, and it doesn’t lead to market solutions. You can’t shop around for the best obscurity. The notion of a global secret is somewhere between ironic and silly. This is why DRM systems don’t work against determined attackers. However, not everything needs to be open, scalable, and market-driven. If you are building a system that is closed, proprietary, and local (such as the secure NOC I was working on), obscurity can be a valuable spice in the dish that makes a tasty meal tastier.

We are also seeing changes in the threat model that justifies a revision in our defense model. A few years ago, the attackers were using broadcast attacks. They didn’t look at the lies we told them because they were unskilled attackers throwing all the handy exploits they had. They wouldn’t see embarrassments that didn’t fit their model. I have a story about that I’ll post soon.

The trend in attacks is that they are becoming slow, targeted, and with a clear goal — money. They also want not only to succeed, but to succeed undetected. A measure that increases the attacker’s uncertainty increases the attacker’s risk of being caught.

Here’s an informal example. Suppose I divide my system into an external “red” network and an internal “black” network. All connections use TLS with AES-256, but on the black network, we are not using standard AES, we’re using a modified AES that real cryptographers agree is as secure, just incompatible with AES; call it AEN for Advanced Encryption Non-standard. Cryptographers have a formal notion of this that they call “family keys.” AEN is my spice. On the black network, you’re expected to use AEN. We just compiled it into OpenSSL where AES was supposed to be. The resulting system is just as secure as one that uses AES everywhere, but has this extra little twist. It makes the attacker’s job harder, and makes our job of detecting an attack easier. It has costs, of course, which you can think of as well as I can. But in my system, which is not only closed, but I want to be closed, they’re not bad costs to pay. Even better, if I publicize that I’ve done this, I might convince an attacker to target someone else.

If you remember that obscurity is not security, that it is camouflage rather than armor, that it is not scalable, that it is only as good as the obscurity itself is, there might be places you can use it effectively. Also, not all security theatre is bad. What is bad is only having theatre and not backing up obscurity with real security.
Photo of theatre security courtesy of Luigi Rosa.

Anarchy in the UK?

big brother congestion.jpg
Via Silicon Strategy, we learn that “Pressure grows for UK data loss disclosure:”

The UK is in desperate need of revisions to laws that govern the disclosure of information relating to data loss or theft, according to security experts.

Currently UK organisations that lose sensitive customer or employee data, or expose it to others, do not have to disclose details of the breach – even to those affected.

Martin Carmichael, CSO at McAfee, told silicon.com: “I think companies should be accountable. Accountability is a vital part of security and if a company has a data breach I think they should be prepared to talk about it.

My take: they monitor everything else in the UK, why not?

Photo: “Big Brother Congestion” by Jeroen020.

Ptacek scores, Pre-Blogging Department with the assist!

Matasano’s Thomas Ptacek had a Groucho-like reaction to being included as a “Top 59″ infosec influencer in ITSecurity.com’s recent list.
EC’s Pre-Blogging Department was initially caught flat-footed on this, but predicted in an update that Tom’s view would gain traction. And it has.
Meanwhile, Mark Curphey has stirred the pot by leaving the Security Bloggers’ Network and explaining why he chose to do so.
I hadn’t heard of the SBN until news of the top sekrit security bloggers’ dinner at RSA started to hit the intertubes, although EC is on it. Bejtlich, even though he doesn’t read EC (come on, buddy!) has a view essentially identical to mine on this subject.
One aspect of the ensuing discussion that I think is great comes from a CSO who emailed Mark, and whom Mark quotes as asking about:

…the guy who does nothing but conferences and magazine columns, but mysteriously nobody can actually recall him/her actually being a meaningful contributor, holding a senior infosec management post, or similar real world qualification?

I’ve heard this archetype discussed over beers, as I suspect many of us have. Nice to see that there’s a sense out there that while a “real list” of influencers may be a matter of opinion, we can profit from discussing it. Again, Curphey gets it right when he writes of mysterious omissions from the Top 59:

Dan Geer, Mike Howard, James Gosling, Andy Jaquith, Phil Venables, Spafford, and so on.

I might quibble at the margins (No Wietse Venema, Ross Anderson?). Just finger @matasano.com for some influential but lesser-known names, tending toward the vuln research end of things.
I don’t know what the point of all this is, but to the extent that it stirs things up and adds a little chaos into the mix, it’s good. Speaking of stirring the pot, Alan “BalrogShimel has weighed in, too:

Fighting over whether the list is accurate, is the list full of crap or who should be on the list, is just frigging asinine.

Hey, don’t hold back, dude.
Finally, it would be remiss not to credit InfoSec sellout for providing a handy taxonomy.

Backus Having Drinks with Hopper

John Backus

John Backus, leader of the Fortran team has died at the age of 82, according to The New York Times. Fortran itself celebrates its fiftieth birthday this year, and you can still write it in any other language, even Haskell. Even Lisp.

Back in the days when I would rather have died than work for IBM, in part because of their dress code, but also in part because of their dress code, but also because of the influence that Ted Nelson had on me, I remember being impressed with Backus’s way of flouting form. IBM employees were required to wear suits; Backus always wore a denim suit. I remember the picture of him in the newspaper. It’s a little thing, but it meant a lot to me. I’m glad that the photo I found of him on IBM’s site has him in denim, and glad that I can explain why dressing in denim was at one time radical.

I also think it important that even the NYT today wrote “Fortran” and not “FORTRAN.” Writing it as a proper noun and not an acronym was an annoying eccentricity of mine in those days as well.

Emerging at the Intersection of Art and Commerce

dollar-art.jpg

I never really thought much of Hamilton, either.

I’m glad this wasn’t done on one of the New Ten Dollar bills. If it was, the Constellation EURion might have prevented me from scanning it for your amusement. (Today, that “feature” is mostly in copiers, but expect it to spread.)

In other looking at money news, Steven Murdoch notes that the UK has introduced a new 20 pound note. It’s entertaining advice of what to do if you think you have a counterfeit note ends “If the note is genuine, you will be reimbursed.” I can’t think of a better way to get people to want to not notice counterfeits.

Posted in art