I’ve been publishing for in various formats for nearly 10 years now, and I have to admit I’m really enjoying some of the features of blogging. Aside from writing in a more personal voice, I actually appreciate the near instant feedback- from anyone- anywhere- of the blogosphere. I actually enjoy having my ideas challenged and debated.

A couple days ago I posted a somewhat lengthy rant on disclosure. Not that I think disclosure is bad, but that we aren’t always willing to discuss the deeper motivations of those involved, on all sides, and admit that in many cases the process can favor the bad guys. In the information security world we often state that “security through obscurity” never works and secrets always leak. I stated:

But in the world of traditional security, obscurity sure as hell works. Not all bad guys are created equal, and the harder I make it for them to find the hole in my security system, the harder it is for a successful attack. Especially if I know where the hole is and fix it before they find it. Secrets can be good.

And Martin Mckeay called me on it here. So did the ever-present Mike Rothman here.

Martin stated:

One more minor issue I have with the article is the use of security through obscurity: while this works for a while, security through obscurity is the most brittle of all types of security. All it takes is one hacker releasing his notes on your security vulnerability and what little security you had because of the lack of knowledge is gone. I sure don’t want my bank relying on security through obscurity to protect my bank account. Not that they’d get much right now, a couple of days before the end of the month

I agree completely. Martin’s bank funds are running a little low Security through obscurity only works for a limited amount of time. Eventually someone will reverse engineer the patch or figure out the vulnerability on their own. Also while it might now be important for every sysadmin to know the details of a flaw, it’s sure important for security vendors to get a peek before the bad guys so the good guys can try and shield any attacks.

Mike says,

Since most of the bad guys would just as soon take the path of least resistance, obscuring information about vulnerabilities is a short term strategy that works.

And that’s the point I meant to make. These days a few weeks can mean the difference between completely shielding and patching your environment, or getting nailed by the early exploits. This wasn’t true a few years ago, but it’s true today. Automated tools are making exploit development much easier and faster- we need to start dropping some obstacles. We’re just trying to slow down the mass exploits and the script kiddies long enough to give us a fighting chance.

That said product vendors need to work more with security vendors on “staged disclosure” (I like to make up phrases, later I’ll make up an acronym just for the fun of it). Security vendors need more detailed vulnerability details to better tune their products before exploits appear. They shouldn’t have to reverse engineer product patches to do this. This also means those security vendors need to share vulnerability details instead of treating them like their own IP. Finally, product vendors need to provide their customers enough information for them to make an appropriate risk decision. Too much information helps the bad guys, but too little hurts the good guys.

Then again, perhaps that’s just responsible disclosure…

(edited 9/1)

Just to clarify- I, in no way, think security through obscurity alone is a meaningful security control on its own. I think it can be a useful tool to buy us time, but we should never rely on it. It’s just too fragile.

I generally don’t discuss “industry” issues here since that’s what I get paid to do at my day job. And if I start offering for free here, what I get paid to do over there, I may find myself offered the opportunity to do it for free on a permanent basis.

Mike Rothman runs one of the better industry-oriented blogs. He and I used to sit across the table when he ran marketing for one of the vendors I cover. I like Mike a lot better as an analyst.

He’s running an interesting debate on the problems with the security market. The debate started with an article in Dark Reading, moves to Mike’s blog here, Alan Shimel responds, then Mike gets the last word (for now). At the crux of their debate is the honesty of vendors and the aggressiveness of their sales and marketing tactics.

My opinion?

I work with many excellent security vendors who are out to protect their customers and fairly make a little money on the way. But, every single day, either directly to me, or relayed by my clients, vendors misrepresent their products or outright lie about capabilities. Usually it’s the marketing or sales teams, not the product teams. Do all vendors lie? No, but the good vendors out there are frequently forced into bad positions by their less scrupulous competition.

Yes, vendors lie. So does your Mom (remember the tooth fairy) but that doesn’t make her the embodiment of pure evil. Probably.

And some of this is simply passion for their products. Everyone thinks their baby is the best looking, smartest, most talented in the world, but there are still a lot of dumb, ugly, couch potatoes. If you don’t believe in what you do you shouldn’t be doing it.

So how do you cut through the crap?

My self serving answer is use your friendly neighborhood analyst. The biggest part of our job, at least for those of us who are end user focused, is to help make appropriate buying decisions and separate hype from reality. Our testing lab is the production environment of our end user clients- if a product doesn’t work, we’ll eventually hear about it.

But if you don’t trust or can’t afford an analyst firm just do what we do. Ask your vendors for customer references in production deployments; if a feature isn’t in production, with a reference-able client, it isn’t real. Then talk to your network and see what other companies like yours are doing and if any have deployed the product.

Let’s be honest- most of you readers are either security-types, or at least have a passing interest in security. It’s not like we trust anyone anyway.

Guess where I spent the day?

I’ll warn you now, I have a bad habit of taking metaphors too far.

Security is like dentistry:

1. It costs more than you think it should.
2. It’s more painful than the providers ever tell you.
3. If you don’t keep up with ongoing maintenance it costs A LOT more and is WAY more painful.
4. It’s really hard to find a good provider.
5. Most vendors prey on fear.
6. Some vendors sell a pretty smile, not that their products actually work.
7. If you make decisions based only on financial Return On Investment you’ll really screw things up.

and finally,

8. No matter how many times you strap someone to a chair, shine a light in their face, and poke them with sharp objects until they bleed you can’t make them any smarter.

Time to go rinse…

(edited 8/31 adding point 7)

As a child one of the first signs of my budding geekness was a strange interest in professional “lingo”. Maybe it was an odd side effect of learning to walk at a volunteer ambulance headquarters in Jersey. Who knows what debilitating effects I suffered due to extended childhood exposure to radon, the air imbued with the random chemicals endemic to Jersey, and the staccato language of the early Emergency Medical Technicians whose ranks I would feel compelled to join later in life.

But this interest wasn’t limited to the realm of lights and sirens; it extended to professional subcultures ranging from emergency services, to astronauts, to the military, to professional photographers. As I aged and even joined some of these groups I continued to relish the mechanical patois reserved for those earning expertise in a domain.

Lingo is often a compression of language; a tool for condensing vast knowledge or concepts into a sound byte easily communicated to a trained recipient, slicing through the restrictive ambiguity of generic language. But lingo is also used as a tool of exclusion or to mask complexity. The world of technology in general, and information security in particular, is as guilty of lingo abuse as any doctor, lawyer, or sanitation specialist.

Nowhere is this more apparent than in our discussions of “Disclosure”. A simple term evoking religious fervor among hackers, dread among vendors, and misunderstanding among normal citizens and the media who wonder if it’s just a euphemism for online dating (now with photos!).

Disclosure is a complex issue worthy of full treatment; but today I’m going to focus on just 3 dirty little secrets. I’ll cut through the lingo to focus on the three problems of disclosure that I believe create most of the complexity. After the jump that is…

(more…)

This has nothing to do with security other than the fact Mike Rothman is a security analyst.

Sometimes it’s worth sitting back and evaluating why you’re in the race in the first place. It’s all too easy to get caught up in the insanity of day-to-day demands or the incredibly deceptive priorities of the corporate and government rat races.

A few months ago I took a step back and decided to reduce travel, stay healthy, and start this blog. I wanted a more-personal outlet for writing on topics and in a style that’s inappropriate at my day job (in other words, more fun). My challenge is running this site in a way that doesn’t create a conflict of interest with my employer, and thus I don’t publish anything here that I should be publishing there.

Mike just went off and started his own company to support his real priorities.

You should really read this.

Believe it or not, despite accusations that that my coverage of the Mac wireless hack is all part of some anti-Apple black PR conspiracy, I’m a Mac user. One that’s so addicted I bought my Mom one and had it shipped to me so I could “configure” it. Okay, really I had to send mine in for service and I needed another Intel Mac so I could run it off an external hard drive with an image of my MacBook Pro. I mean I might have been without it for, like, 5-7 days and that’s just not acceptable. How can I carry out my anti-Apple black PR conspiracy without a Mac to write my blog entries on?

But I have something I need to admit.

It’s sort of embarrassing.

But it’s time to share.

You see, I’m a security professional. Not just a security professional, but one that focuses on data security. The kind that gets paid to run around telling the media how stupid everyone is for not protecting their data and doing things like, uh, encrypting their hard drives.

Not that I… um… was encrypting my laptop.

You see I was in a bit of denial. At first it was because I still used my corporate PC and didn’t have access to good encryption software that wouldn’t mess up my configuration. Which was really me just lying to myself. Later I told myself I was so good at physical security, and paranoid in general, that I’d never let my laptop get stolen. Yep, another lie. Finally the ultimate in self deception, “well, I really don’t have anything sensitive on there in the first place”. Right. None of those “not for disclosure” Powerpoint presentations from vendors are really sensitive, are they? I mean how much personal stuff like social security numbers or credit card info could really be hiding in Outlook (in my Parallels virtual machine) or Mail.app? I mean really!

When I decided to attend Black Hat and Defcon (home of the world’s most hostile network) right after an international trip to Australia and China I figured it might be a good time to get off my ass and finally encrypt my laptop. For those of you not familiar with Macs, Apple’s included encryption in the OS X operating system for a few years know in a feature called FileVault. But there’s been a lot of debate on how “safe” FileVault is; not from a security standpoint, but from a reliability/recovery standpoint. But in a recent thread in the TidBITS mailing list it didn’t seem to many people had much experience with FileVault, and perhaps some of the rumors were unfounded. Or not.

Eventually the guilt caught up and it was time to take the encryption plunge. And so far FileVault is working like a 128-bit AES charm.

(details after the jump)
(more…)

Ah Diebold, how we’ve missed you.

In yet another example of gross negligence with our most sacred political process we find our favorite manufacturer of ATMs and voting machines yet again in the news. This time with a series of failures in the Alaskan primary.

From Slashdot: http://rss.slashdot.org/~r/Slashdot/slashdot/~3/15859396/article.pl
From Engadget: http://www.engadget.com/2006/08/24/diebold-machines-fail-in-alaska-primary/

For those of you that don’t follow the twist and turns of this seriously shady company, Diebold has a long history of insecure voting machines, battling any attempt to regulate better voting security, and attacking anyone that suggests they might have any teensy-weensy wittle problem that might let someone, you know, hijack an election. For more on the past check out the work by Black Box Voting and the very respected Avi Rubin.

This really pisses me off. Voting, whatever your political party (except maybe you anarchists and fascists) is the ultimate expression of a democracy. If we can’t protect the voting process, we might as well give up and just sell the country to the highest bidder (and yes, I feel the same way about poll taxes, gerrymandering, and anything else that interferes with the right to vote).

I have two simple suggestions to resolve this idiocy:

1. Require a voter verified paper trail with random audits at the federal level for all elections (right now only certain states require it).
2. Hold voting machines to the same security standards as gambling machines!

Think about how highly secure gambling machines are. I first heard this suggestion from Ray Wagner (a fellow analyst at my day job) and it was so simple in concept it amazes me every time someone claims higher standards are just too hard. Heck, we already have testing labs, protocols, and procedures in place.

I’m not a conspiracy theorist, despite many hours dedicated to watching the X-Files, but sometimes ya just gotta wonder….

One of the advantages of being a paranoid security geek is you slowly acquire a familiarity with consumer security tools to prevent any of the bad nastiness you comment on from happening to your own system. While I’m sure some of my remotely hosted servers will get cracked on occasion since I don’t have full control over them I’ve taken it as a personal point of honor to defend my personal computers from www.youvebeenhacked.ru to the bitter end. Every now and then on slow news days I’ll highlight some of these tools and techniques to help readers protect their own systems. Since I use Macs, PCs, and even a dash of Linux there should be some good nuggets for all platforms.

**Disclaimer**- I do not accept any advertising (or anything else) from any vendor, anywhere, end of story. If I discuss a vendor on this site it’s because I think the product is actually useful. I will also NEVER endorse any vendor I cover professionally on Securosis!

And I’m going to start with spam.

I really hate spam.

Seriously.

And if you want to skip to the end just go buy SpamSieve (Mac only), which is one of those gems very familiar to you Mac geeks.

But for those of you that like to read…
(more…)

On Friday the Mac Wireless hack issue exploded again after Apple PR issued a carefully worded press release. Next thing you know one of my favorite sites, The Unofficial Apple Weblog posts a headline that’s just wrong.

There have been a lot of really bad posts on this topic, but John Gruber at Daring Fireball winds his way through the press and blog hype in a well reasoned article, The Curious Case of the Supposed MacBook Wi-Fi Hack. John’s reasoning is strong, but I believe we can take his assumptions in a different direction and finish with essentially the opposite results.

First some full disclosure- I was at Black Hat and Defcon, talked with Maynor and Ellch, and have followed up with Maynor and SecureWorks since the event. I won’t be revealing any secret information here, but will just analyze John Gruber’s assumptions and see how his conclusions might change. John and I also emailed a bit on this issue over the weekend (he’s on vacation this week, so might not be able to respond).

For those of you with short attention spans I believe that Maynor and Ellch will emerge with their reputations intact and have been trying to do the right thing from the start. If I’m wrong I’ll be the first to call myself on it and apologize, but I really don’t expect that to happen.

John’s first assumption is:

“What’s notable about this disclosure is that it is about the driver. We already know, just from watching the demonstration video, that it was also based on a third-party card. This means that either (a) the exploit they discovered uses neither the MacBook’s built-in card nor Mac OS X’s built-in driver; (b) the exploit they discovered works against both the third-party driver demonstrated in the video and against Apple’s standard driver, and they have inexplicably decided to post this disclaimer to explicitly describe only what is being demonstrated in the video; or (c) that the “experts” at SecureWorks do not understand the difference between a driver and a card. My money is on (a).”

Let’s explore option (b), especially the last part: ‘…they have inexplicably decided to post this disclaimer to explicitly describe only what is being demonstrated in the video’. (bold added) I propose an alternative: that they purposely posted the disclaimer to explicitly describe only what is being demonstrated in the video. Why would they do this? Not all security researchers believe in full disclosure. If you are one of these researchers and you don’t want to disclose the details of an unpatched vulnerability but want to demonstrate the class of vulnerability (device driver exploits) you might choose to demonstrate the vulnerability using an unidentified device. In the background you would notify any affected vendors and give them time to respond. If you show the attack on the built-in wireless device you instantly identify the vendor involved. An anonymous third-party card avoids this exposure.

(more…)

After posting Concerts vs. Airports: The Role and Effectiveness of Security Screening in Public Places I realized it was a tad long and I might bore some of you, so here’s the crib notes:

For about ten years I worked, and eventually directed, security for large events like concerts and football games. There are some lessons we can apply to airline screening since both involve securing public spaces and large crowds:

1. Screening is just one layer of security, but in airports it’s treated as practically the only layer.
2. In concerts we relied more heavily on inside security to fill the gaps of screening.
3. In concerts we used more behavioral profiling, earlier in the system.
4. We never stopped profiling and watching once someone was inside.
4. Technology is only good at catching certain things, and can’t catch everything.
5. Increasing screening, but not the rest of security, will only piss people off and won’t significantly improve security.
6. 80% or more of airport security seems to start and stop with screening. This might look good, but isn’t really secure.
7. Computers suck at profiling and and are much more likely to catch a good guy than a bad guy.

No security is perfect, and a determined and intelligent attacker could probably defeat most security where we allow public access, but by adding additional non-intrusive security controls we can rely less on screening and increase security while improving the flight experience. We need to build more layers into air transport security, not try and build a single really big wall. We have defense in depth at concerts and football games, why not airports?
There’s more in the main post, but you get the idea.