Security Curve Weblog

More (Hopefully) Useful Questions

Last week, Ross Brown posted his Four Questions to Improve Security over on the Technobabylon blog. I highly recommend checking out the post if you haven't done so already. Now, Ross' questions were targeted toward vendors to help vendors (i.e. they are questions to help a potential customer improve the security of their environment.) Anyway, so you have it without having to go to the original post (although I recommend that you do), his questions were:

1) How are you protecting the network?
2) How are you protecting applications and data?
3) How are you protecting systems?
4) How do you know how you are doing?

Now, these are useful in the context of vendor-client interaction. However, within the enterprise itself, I am oftentimes surprised at the questions that practitioners don't ask themselves. Like:

1) What does the business I support do? And how do I know when they do something that impacts security?
2) Who are my vendors and how do I make sure they handle security appropriately?
3) Where does the data come from and where does it go?

And so on. Very often, I meet individuals in industry tasked with protecting data, tasked with securing resources, and tasked with protecting assets who don't have answers to these questions. Although I'm not sure that it's appropriate for a vendor to ask them (and therefore probably not appropriate for inclusion in Ross' list), I do think somebody should be asking these things.

BugFinding

So, Pete Lindstrom's looking for vulnerability researchers with enterprise experience. Now I think I just barely qualify; not on the enterprise experience side (that I have quite a bit of experience in) - but on the research side (where I have less experience). However, there are a few names that leap to mind; for example, I immediately think of Alex Wheeler who not only punches holes in AV software, but also worked in one of the largest (if not the largest) insurance companies in the world. Now, my objective here is not to gainsay Pete, because I think he has a point; l think it is uncommon for people to have both enterprise and research experience.

But I don't think it's because practitioners in industry have a high moral standard that precludes them from working on vulnerability research; I also don't think it's because they fundamentally believe that vulnerability research contributes to the problem of patch mania and/or increased exposure to the enterprise. Not that Pete is saying any of those things, mind you. However, one could. Instead, I think that vulnerability research and industry do not go hand in hand for a totally different reason - I think it's about time and incentive.

In actuality, vulnerability research is a very time-intensive process. And the truth is that the majority of enterprise IT departments do not reward employees for finding bugs. Now, if you work for a product company (eEye, ISS, etc.), you might be rewarded for finding bugs. Even if you participate in a pay-for-research venue where you can actually sell your bugs, what are you going to earn? A thousand dollars? If it takes weeks to research and write up a bug and go through the rigmarole with the vendor (say conservatively 200 hours), you're talking about 5 dollars an hour. Oooooo, sign me up (not.) However, product companies that use vulnerability research as *marketing* have an entirely different perspective. How much is the front page of google news worth to them? Enough to incent their employees to look for bugs? You bet...

Teacher Convicted for Getting Spyware

I found this to be particularly interesting when I read it this morning. In case you didn't see the story, the rundown is the following:

Her story:

- A school has content filtering software installed, but they don't maintain the license, so it stops working
- A schoolmarm visits a hair-styling website which has advertising content
- Schoolmarm's machine receives a piece of spyware that downloads arbitrary ads
- Advertisements for pornographic websites are displayed on the screen
- Children see pornographics ads

Their story:

- She's an evil schoolmarm; a particularly nasty breed that gets their sick jollies by showing kids pictures of naked people

Clearly showing little kids pictures of couples copulating is totally unacceptable. Now, I have to admit that I'm biased in that I happen to believe her story; of course, there could always be facts that aren't in the press that establish her guilt beyond question. In other words, there could be more to it and it could be that she is a sicko. Either way, though, I'm astonished that this conviction took place. Specifically, even if the woman is a sicko, I don't understand how a jury could hear both the above stories (phrased differently, of course) and come to the conclusion that she is culpable for this. Part of establishing that she is culpable is expert testimony on the part of the prosecution that her active involvement was required to bring up the images. Now, most of us with a familiarity with spyware could debate the veracity of this, but again we don't have the facts in this case. Maybe her involvement was required. Without information about what expert testimony (if any) was on the defense side or what the details of the forensic evidence (if any) there was, it's all up in the air from our point of view. But what if... What if her story is the real one? What if the defense was underprepared and couldn't refute the expert testimony of the prosecution? What if she really didn't do it on purpose?

So this is all titillating and stuff, but there's really a reason that I'm bringing it up. Specifically, I've made the point in the past that the legal community and the information security community are being drawn more and more closely together. The FRCP, Zubulake, breach disclosure laws, and so on are all making it so that information security professionals have to understand something about the law and lawyers have to understand something about information security. And if they don't? Then you get cases like this... or maybe this teacher's just a sicko. Could go either way.

Defeat - The only thing standing between us and victory

(with apologies to that great orator and statesman Roderick Spode)

So, I came across, via the Spire blog, the followup commentary from Noam Eppel to his Security Absurdity: The Complete, Unquestionable,
And Total Failure of Information Security article.

In case you don't remember the original article, the premise was that information security as a discipline has already failed, and the follow-up is more of the same. The argument is predicated on the observation that there are demonstrable failures of security in the world - quite a bit of them as a matter of fact. In other words, his argument is that security (as the applicable discipline) has failed and that we (as practitioners therein) have also failed because of the vast number of security breaches, security issues, and snafu's that occur on a day to day basis. Fraud? We've failed. Phishing? Failed again. Lost luggage? Depends on who lost it, but if it's the TSA - probably our fault.

Now the point that I made the first time around was that it's not productive to define success/failure based on whether or not incidents occur or even by whether or not it's possible for incidents to happen. For example, traffic accidents occur - does that mean that the traffic laws in this country have categorically failed? Could be... or not depending. But folks would never get away with saying this (at least with anyone taking them seriously) until/unless you could prove that the laws were directly related to the number of accidents. In other words, that there was a demonstrable cause and effect between these two things *and* that the particular success criteria used to define "success" (in this case, less accidents) is both relevant and applicable.

In the traffic safety example, the success criteria might be having a low number of accidents. Once you define what it means to be successful, it's possible to measure how people stand up to the yardstick. For example, by comparing the percentage of increased accidents in one area vs. another area with different laws, you can extrapolate as to whether or not the laws in area A are more able to satisfy a given goal vs the laws in area B (for example, maybe there are less accidents.) In this case, the success criteria is whether or not there are incidents; well, if you take a risk management approach, aren't incidents unavoidable? In other words, if I'm only going to spend money protecting resources commensurate with the value of the resource, isn't it implied that there are going to be areas that are less protected than others? For example, if I have ADT in my home, and somebody comes and hits the mailbox with a bat, did ADT fail? *Should* I hire an armed guard to protect the mailbox? Probably not. But if you define success as living in a world where punks can't hit the mailbox, it's a failure.

Maybe we should define success or failure based on something provable and something that works within the context of risk management. Well, I'll stop going down this road, since I covered it all in the original reaction, but I thought it was useful to point out that when you say somebody failed you have to say "what at?" Did the security industry fail at making the world risk free? Unquestionably. Is that the primary goal that we as an industry should be after? Not in this lifetime. How about "reduce the number of incidents to the point that customers are well-served, that money spent by the organization protects resources commensurate to their risk and value, and that we spend enough to ensure that our personal safety is ensured in contexts where it's applicable?" I think that's a pretty good goal... I'm going with that one.

Month of Apple Bugs... Does it Matter?

So, you've probably noticed that the month of Apple bugs is going on even as we speak... Much like the month of browser bugs, the month of kernel bugs, and the month of Oracle bugs (which kinda petered out), the plan is to post a full month's worth of bugs impacting Apple at a rate of one per day.

Now I saw that this Apple bug thing was going on and I didn't write about it 'cause I figured "ho-hum"... and then came the wall of controversy. Thomas Ptacek weighed in early, saying that there's no reason for a "bug a day" release schedule.

HD Moore to Dark Reading: “[A MOXB scheme] seems to be the answer to a ton of denial and hubris about whether Apple products are more secure than any other vendor.” It’s hard to criticise HD; he’s both nicer and smarter than me. But, here goes: “denial and hubris” about Apple security is not a problem that we need HD Moore to correct...
There are arguments to be made in favor of publishing exploits. There are arguments for going public with a finding immediately. What’s the argument for a bug-a-day release schedule?

To be fair, there was a well drawn-out argument in the above (where the ellipsis is) that he uses to justify the point; it's worth reading if you're interested in debating the usefulness of the MOAB (month of apple bugs), but too verbose to include it all here. Then Ross Brown weighed in too; both about the MOAB and about the reaction to it:

Having a hard time seeing the point of this exercise, but it seems somebody wasn't held enough as a child. Thomas isn't tied to vendors and asserting it just makes the whole project a lot sillier.

So, two folks who don't see how this is useful. Is it? First, let's get the elephant in the room out of the way. Which is that the ONLY reason there could possible be for doing a "month of xxx bugs" is to get attention... in other words, for the press. The press loves this stuff, they are sure to cover it, and you can use any ol' bug you find to fuel it. In terms of "bang for the buck" to get media attention, there's absolutely nothing better you can do. So the question becomes not "what's the point of the month of Apple bugs", but "what's the point of drawing press attention to Apple bugs?" And that's where I disagree with both Ross and Thomas. Because I think there is a point.

Specifically, I've argued all along that Apple's marketing does a disservice to Mac users. They put out a strong pro-security marketing message, and there's nothing wrong with that. However, one could argue that some of their marketing could lead users to believe things about the Mac that aren't entirely true. For example, one could interpret the Apple marketing to claim increased resistance to security vulnerabilities. If that were the case, it would put users in a dangerous position - they might be less inclined to apply updates or they might be less inclined to monitor their systems for intrusion. So, is that the case? Do Apple users have the perception that there are less bugs?

Take a look at the comments from Mac users in response to this article about the relative security of Mac and Windows;

- You can "believe" all you want about the Mac OSX having security flaws, but that won't make it so. Keep dreaming.
- If you talk with hackers, they'll tell you that at this point the Mac is considered THE prize, because everyone keeps claiming that it can't be done. Still, they don't succeed.
- What you need to do next is apologise for your ignorance and complete lack of understanding as to what makes a Mac (and by extension any Unix-based operating system) so much less vulnerable than any flavour of Windows.
- Arguing that gaping flaws like this are equivalent to as yet undiscovered flaws in Mac OS X is simply unsupportable.
- So, hackers *are* trying to crack the Mac, they just suck at it.

Need more? I got bored after page 3; feel free to have a gander yourself. There are pages and pages of Mac users saying that Mac doesn't have vulnerabilities. Not saying that there are *fewer* vulnerabilities... not saying that *maybe there are less*... saying that there are none...

So, is it useful for someone to get the press to point out that Apple has vulnerabilities? In general, I would prefer to know the truth about something rather than believing a lie. For example, as a Mac-owner (which I am one), I would rather know that there are Mac bugs so I can take action and be vigilant as opposed to not knowing about them and getting burned. Now, even if it is less likely that I'd get burned vs. somebody else, that's small consolation if it happens and it was avoidable had I known the facts. But maybe that's just me.

TSA: it wouldn't be so bad if there were a point

So, the other day I was going from Seattle to Manchester. And believe me, it was one hell of a trip... The day was kicked off by finding out that SeaTac had no power in Terminal A, and ended 20 hours later (finally) in New Hampshire where I found out that the TSA had searched my luggage. Now, I don't know about you, but in past when people have searched my belongings, they didn't wind up breaking stuff. This time, however, the gloves were off. Those guys did it all - wrinkled my suits, made little "snowballs" out of my shirts, pulled matched socks apart, and finished it off by breaking stuff; specifically, by breaking the zipper on my suitcase and by breaking my belt. Now I got the suitcase for free from LL Bean, but it retails for a hundred and change; the belt I bought at Banana Republic for 80 dollars (don't ask - I was at a conference and needed a belt.) So, almost 200 dollars worth of damage. They did, however, leave a little courtesy form-letter telling me they had "inspected" (read: gone apesh*t on) my luggage.

Now, I'm usually pretty calm about stuff like this. They're just doing their job, right? And all of this stuff has a security benefit, so it's worth it, right? Um... Well, maybe not. Now, you all have had to hear me gripe about why this stuff doesn't do anything for security - like why it's "good marketing" for TSA to put on a show of checking for stuff when the security benefit it provides is basically nil. I've had countless conversations with security folks, the majority of whom believe that the TSA security measures are useless. And now yet another respected news outlet is saying it too. And you know what? He's totally right. The security measures are a show... And underneath the show? Continued incompetence.

Incompetence like the fact that they have yet to fix the problems with the Watch List. Now, you might say that inconveniencing a few thousand people is worth the price of increased security; and maybe you'd be right - if this watch list did anything. But it doesn't - in fact it does the opposite. It wastes money that could be spent efficiently on terrorism prevention, it wastes cycles that could be spent on doing something productive, *and* it makes travel more painful all around thereby accomplishing the terrorists' original goal of disrupting our way of life. Wanna get pissed off? Take a look at the TSA fact sheet for 2006 where the DHS lists their "highlighted" accomplishments for 2006. Accomplishment number one is this BS about the liquids... They "trained over 40000 people" and "conducted extensive explosive testing" (all at taxpayer expense) for a threat that we all know isn't feasible. And when TSA finally clued in to the fact that it's bogus? They "proved their flexibility" by "modifying the ban". And what did that cost us, the taxpaying public? Hundreds of millions that could have been spent on developing automated approaches to baggage screening that won't leave innocent travelers with wrinkled clothes and no belt.

Now that's progress.

An HNS Must-Read

So, in case you're not a regular reader of Help Net Security, there's a great article by a friend and colleague on risk mitigation for Windows NT 4.0 legacy systems that I highly recommend. It's surprising how many of these you actually come across in industry. Anyway, it's a must-read.

P.S. If your network has more than a thousand machines and you think you don't have NT 4.0 in some dusty nook and cranny... It's there - you're not looking hard enough.

What exactly does software activation accomplish, anyway?

Hey, so happy new year, welcome to 2007, and all that other jazz that people say around this time of year. It was a great holiday; spent some quality time with Diana and the pups, visited some relatives in New Jersey, and totally ignored the phone and email. Awesomeness. Totally stress-free... with one small exception.

The one island of stress in an otherwise unbroken island of relax-itude was when my father asked me for help setting up his new laptop. You see, my dad doesn't have Internet connectivity. So when the time came to install all that new shrink-wrapped software he bought with the machine, I experienced a whole world of pain that I hadn't before: telephone software activation. You ever experience this? It's painful. Microsoft, at least, has it down to a science: you call them up, read of punch in the 6 groups of 5 digits, they read it back to you, then they read you the 6 groups of 5 numbers that you type in. At the end of the process (about 20 minutes... I kept track), "blammo" it's registered. Now, that's for Office. You need to go through it again for Windows, again for the OEM software that comes with the laptop, again for the other software that he bought... again and again and again. Of course, most of the places aren't open 24 hours - some of them don't expect you not to have Internet connectivity so they're not prepared to activate the software. One guy had to figure out how to do it and call me back. All at their expense, mind you.

So, here's my question. Why do this activation at all? The reason that we're always given is that it's a piracy-prevention measure. Now I contend that it doesn't for a number of reasons - for example, there are tons of groups out there that love to crack software for the intellectual challenge of the reverse engineering experience. But even if it does protect against piracy, is the cost associated with it worth the benefit? For example, one of the places that I called made a piece of design software that was used in combination with a mechanized wood carving tool. In order to support the activation process, my call cost them the following:

- toll-free connection charges for me to call in and activate
- long-distance charges for them to call me back with the activation code
- approx. 30 minutes of customer-rep time to deal with me
- approx. 5 minutes of the rep's manager's time to figure out how to register

So, is that worth it? If he wants to install the software on another machine (which he will), he'll have to call back and go through the process again. If his laptop crashes (which it will), he'll have to do it again. Each and every time, at significant expense to this company. Usually you don't hear this from security professionals, but I'll go on record - what's a little trust worth? In this case, it's worth hard dollars - and it's easier on customers. I'm wondering what the incentive is...