Security Curve Weblog

GIANT ANTS! (and security emergence)

It's Halloween - or, as we who are fans of cheesy sci-fi like to call it, "the high holidays". What other time of year can you watch a movie like "The Exorcist" on broadcast TV and know that - if you miss it - it'll come around again? I watched it last night (along with "The Village") and let me tell you it scares the hell out of me (pun intended) every time. Now, one could probably make the argument that casting Max von Sydow gave it a tremendous advantage in making it creepy - and I'd tend to agree with that. But it isn't all about Max von Sydow. That's not to do down Max: he goes a long way to making a movie great, but not all movies with him in it are scary (c.f. "Strange Brew", "Flash Gordon", "Conan"). No - I think what makes a horror movie scary is realism. Wait... what? No, really - "The Exorcist" is - at it's core - believable. Not the demon-possession part - but you have to admit that the mother reacts to her daughter's condition like a normal person would: she gets doctors and psychiatrists involved, she authorizes CAT scans, psychological tests, etc. Anyway, I bought it.

The believability factor is a huge one in separating the wheat from the chaff in a B movie. And it doesn't have to be high budget either. Take a movie like "Them!." If you haven't seen it, "Them!" is one of the "giant radioactive [xyz]" films from the fifties. In this case, it's giant radioactive ants that tear up the southwest. What I like about the "radioactive critter" movies is that (with a few exceptions) they tend to have the giant radioactive animals behave exactly like their smaller cousins. Now, "Them!" stretches this a bit, but the principle is still there - the gigantic ants act much like the garden variety; it's just the increased scale that makes them terrifyingly destructive. And ants are even more scary in this context because of the principle of emergence; namely, that ant behavior, while simple at the scope of an individual ant, is strikingly complex on the macro scale. In the case of ants, the resultant behavior is greater than the sum of its parts: there's the emergent property of survivability (the hive as a whole is more resilient) as well as lack of stasis (the hive is always in motion) and hierarchy-free complex behavior (the hive can operate without command and control.) Like I said, scary.

Of course, emergence isn't something that we're unfamiliar with in the technology world. We're accustomed to reading about the ermergent properties of the Internet as a whole. And Dave Fischer and Howard Lipson have been talking about emergence in software and survivability for a decade now. If you haven't checked it out, it makes for interesting reading. But what really gets my juices flowing isn't that stuff so much, but rather coming at it from the attacker side. What I mean is - there are tons of small simple "swarming" agents that are employed by attackers (e.g. worms, botnets) right? We know that small, simple, micro-behavior can have devastating success, survivability, and impact in aggregate, right? We could speculate attackers might desire to have that impact and resiliency in their attacks, right? So how might they do that in future? From a speculative standpoint, useful avenues for exploration are - in my opinion - worms and botnets. Although for some reason I find botnets to be a more fruitful area of speculation than worms (don't ask me why.)

Looking at botnets, I think we've seen a few areas where emergent properties arise; broadly speaking, we know that individual botnets have proven to be remarkably resilient - most folks who have written about botnets have commented on the fact that we seem to be losing the war when it comes to botnets. I think this resiliency is the same "survivability" principle we see in the Internet as a whole - in other words, "We define survivability as the capability of a system to fulfill its mission, in a timely manner, in the presence of attacks, failures, or accidents" (from "Survivable Network Systems: An Emerging Discipline"). Scary stuff. But in my mind, there are other questions - #1, how (besides survivability) are emergent properties in these systems currently aiding the attacker (if at all) and #2, how might we research future properties that could aid them?

One of the unfortunate things about analyzing emergent properties of malware is the fact that one of the things defining emergent properties is the difficulty of predicting them from analysis of the individual objects within the larger system. So, I guess it's pretty hard to say what might be the ultimate outcome or how an attacker could utilize these principles in a scary way. I guess that means no answers will be forthcoming from this side of the peanut gallery today, but if I had thousands of dollars in government grant money, I know what I'd be researching...

Black Swans: Villainy... Romance... Deeds of Daring

Pete Lindstrom posits the question this morning, "Are freak accidents the black swan." Alex over at RiskAnalys.is takes this and runs with it, indicating that the answer is categorically "no." An interesting discussion.

Now, for those of you who are fans of high-seas adventure in the age of sail (think Patrick O'Brian), the black swan they are referring to is not the tale of "Seas Ablaze...with black villainy, with fiery romance, with breathless deeds of daring..." that might have leapt to mind. Instead, they're referring to a logical principle usually referred to as "falsifiability". What the hell does that mean, you ask?

Here's the gist: somebody makes a statement like "dogs can't look up" (apologies to "Shawn of the Dead") or "all swans are white" (apologies to Hume)... How many dogs (or swans) do I need to find to disprove those statements? Just one, right? If I find a dog that can look up or a "black swan", I can disprove the statement. Now technically all this is part of the philosophical discipline of epistemology (philosophy of how we know stuff) or the philosophy of science; epistemology pretty much says that we can't ever really know stuff (absolute truth) because we can't evaluate every possible counterexample to evaluate if a statement is universally true; the philosophy of science (always more grounded in the practical) tells us that empirical statements (hypotheses) must be falsifiable to be scientific.

All well and good, but there's a more targeted application for us in infosec. As Alex points out in "Black Swans and Zero Day", the broader discussion for falsifiability in infosec has to do with how we deal with "black swan" threats that disprove what we've previously known to be true. Example: in 1996, I could have made the statement that phones could not get worms. And that would have been workable as a hypothesis until the "black swan" (i.e. the first cell phone virus) came along that disproved it. So the question of the day is this: how do we in infosec plan for and mitigate the threats that could happen but currently don't? For example: zero day exploits, tivo-borne malware, worms that make your screen explode, telepathic phishing attacks, or any of the other infinite number of things that could potentially happen but don't. In other words, how do we in infosec deal with the black swan threat? In my opinion, we don't.

Not deal with it, you ask? That's right. You see, the black swan is a losing proposition. By definition, the black swan flies in the face of what one knows to be true. For example, consider the case of two different black swans. "Black swan #1": somebody uses a previously unknown (zero-day) exploit against Apache to own your box. Now, somebody could make the claim that you could (or should) plan for this; for example, they might argue that by using defense in depth or by using restriction mechanisms (chroot/permissions/whatever) on the box, you could increase your assurance that the platform is protected in the event of a compromise. Maybe so. But since the "black swan" is (by definition) unknown ahead of time, how many services would you need to harden? All of them? And maybe your hardening technique doesn't close the door to the exploit. What do you do next? And how much money do you spend to do this?

Now consider "black swan #2": the security guard at your collocation facility sneaks his girlfriend in and they happen to be having a picnic (against policy) right next to your corporate email server. The guard makes his move, fakes a yawn and goes for the hug, while simultaneously knocking over a coca-cola onto your email server's power supply (and redundant backup power supply.) It brings down your server. Sound far-fetched? Maybe. Is it more or less likely than the previous black swan? I don't know. Both are certainly possible, right. Both are in the universe of possible things that can happen to impact the confidentiality/integrity/availability of your firm's business. Now, maybe one example is more likely to happen than the other (arguably, I think the second one), but that's not really the point - the point is that there are infinite things that can happen. Worse yet, since the infinite list contains all previously-unknown threats, risk management becomes impossible. Risk management is about analyzing where to spend money based on the likelihood of occurrence and the impact of the outcome; black swans are about new things that we have no foreknowledge of so there is no way to fill in the first part of the equation. How do you determine the likelihood of occurrence for something that's never occurred before? I'm pretty sure you can't - at least in any kind of structured, objective way...

Anyway, that's just my two cents.

Computerworld Attacked By Sharks

When I was a kid, I was afraid of sharks. I'll admit it: I saw Jaws in 3D (I think it was the third one) back in the eighties and for years going to the beach would make me think about people being swallowed whole - I'd go to the shore and start fixating on the sadistic creatures lurking just below the surface and how they could attack at any time. Whew, scary.

To a kid (at least to this kid), shark attack was both common and likely. From my perspective it wasn't a far-fetched train of thought - in fact, it makes perfect sense in light of what I knew: sharks were publicly observed attacking people, people tended to fear them, and they certainly look vicious enough. In other words, there was a confluence of evidence: anecdotal evidence (i.e. JAWS, the occasional attack on a beach-goer) supported shark attack, rational examination of the shark's body (i.e. they're built for a-killin') supported shark attack, and "social proof" supported it (everybody else was afraid, shouldn't I be too?) Given all that evidence, it's a perfectly rational conclusion that shark attacks are common.

Of course, they're not really common. We know that because somebody counted up the number of shark attacks per year and published the results. As it turns out, shark attacks are pretty uncommon. Gee, who knew? Sharks look mean, right? There are stories of people getting attacked, right? Everybody's scared, right? But none of these things make something likely - they're just happenstance.

So how does that relate to security? This morning, I came across an interesting take on the future of malware in the Martin McKeay Computerworld weblog. If you haven't seen it, take a minute to check it out. I took away the following:

- Phone-borne malware is on the rise and will continue to increase over time
- IM-borne malware is on the rise because of the increased popularity of MMORPG's
- Zero-day exploits are on the rise because of increased professionalism of attackers and motivation by profit

Now, I only have time to pick on one of these things, so I'll choose the first one. Everytime somebody tells me about phone-borne malware, I always say "What phone malware?" to which they invariably reply by relating tons of anecdotes about how prevalent phone-borne malware is in Asia and Europe. The describe how popular phones are for micro-payments over there (and correspondingly how attractive they are for thieves.) They tell me about "SMish"-ing, Trojans, bluetooth worms - all things that have been observed in the wild. In short, they give me tons of anecdotal evidence - stories about sad users weeping over their broken phones and of legions of disaffected Asian youth carrying around phones rife with malware.

But, I've learned my lesson about anecdotal evidence; because anecdotes can be the same as folklore and because anecdotes are not always representative of the norm - I tend to disregard them. To prove this, consider your typical urban legend. It's always a story about "a guy my friend knew" or "a friend of a friend" right? Urban legends are true-seeming anecdotes that appear possible (even probable) on the surface, but are pure confabulation underneath. So anecdotes, without scrutiny, may not even be true. But even if true, there's the broader question of how useful the anecdote is for making a generalization; how representative of the norm is it? Like shark attacks, too many things could be going on to rely on it without further investigation. It certainly seems reasonable that there would be phone borne malware. And I have heard about it happening. But just because it seems a certain way doesn't necessarily mean that it is.

Fortunately for us, there are numbers that we can look to to help determine how true (or untrue) the phone-borne malware thing is (or isn't.) If we take a look, for example, at the estimates from SANS released earlier this month. According to them, we're looking at an estimated 100,000 infections in 2007. 100,000? This from the folks saying it is (or will be) a problem... Now, this isn't 100000 infections today, mind you - this is an estimated forecast for 2007 (after it ramps up from where it is today.)

So, to analyze that, let's put that number in perspective. Depending on whose estimates we use, anywhere from 50 to 70 percent of all PC's are infected with some kind of malware, right? Now, I happen to think those published numbers are astronomically high; so to be ultra-conservative, let's cut it by a factor of ten and assume 5% of total machines are infected. As of 1996, one estimate put the number of PC's in the world at 234200000 (trust me, the number is much higher a decade later.) And 5% of that number is 11,710,000. So based on the number of PC's in 1996 (ridiculously conservative) and one 10th of the published percentage of infected machines (way too conservative), the number of phone-borne infections is .8 percent of the total infections. Of course, the percentage will really be much, much, much lower than that - factor in 10 years of PC growth, and use the "real" percentages for malware infections and you're talking about thousandths of a percent.

But maybe comparing it to PC's isn't useful. Maybe it's its own thing that needs to be analyzed separately from PC malware. Let's look at what that 100,000 number is in light of the total cell phone population. In 2005, for example, there were 120 million new cellular phones sold (or thereabouts), right? Let's assume (ridiculously) that's the total number of vulnerable cell phones in the world (which it isn't clearly, but let's give the pro-cellphone-malware people a break and use this crazy low number.) 100000 is .08 percent of the total. By that rekoning, one phone in 1,250 will become infected. Include the number to include phones sold in 2004 (150 million) and 2006 (estimated to be 780 million according to Gartner), and you're talking about .009 percent. One phone in just over 10000.

To put that in perspective, it's roughly the same chance of someone being hit by a Delta II launch vehicle as it re-enters the atmosphere and falls to earth or that someone has of experiencing significant vision loss as a result of LASIK surgery. In other words, it happens - but it's not damned likely.

Sam and Max Hit the 7-11

Courtesy of the "Make your own Sam and Max Comic" over at Telltale games. New Sam and Max in just under 10 days!

Oracle Vulnerabilities and the CVSS

In the past, I've jumped all over Oracle about their vulnerabilty issues. So when I saw folks alleging that Oracle is potentially downplaying vulnerabilities in their software by under-weighing them (in other words, deliberately misrepresenting the seriousness of the vulnerabilities when coming up with the CVSS score), I was very interested.

Here's the background story: this month, Oracle updated how it represents the seriousness of it's vulnerabilities; instead of using their own proprietary method, they've decided to use the CVSS in their risk profile for these vulnerabilities. They've actually even been so open as to expose the underlying weights that they've plugged in to the CVSS calculations so that customers can see exactly why a certain issue has a particular severity (for example. using the CVSS score calculator here.) Now, the argument is that the numbers are too low; for example, on a 10-point scale, the vast majority are 4 or lower. Sounds pretty damning, right? There are over 100 vulnerabilities including buffer overflows, SQL injection, and a host of other "biggies." But if you drill down on how they're coming up with the numbers, it gets harder and harder to find fault with it (believe me, I've tried.)

For example, the CVSS is a ten-point scale, that's true. But the CVSS is designed such that a vulnerability is weighted according to the impact that it has on the system; a vulnerability that only partially discloses data, for example, is scored less than a vulnerability that fully discloses data. This makes sense, right? What oracle did, in the majority of cases, was use "partial" as the value for "confidentiality impact", "integrity impact" and "availability impact" when some say a "complete" would have been more appropriate. But is that really what they should have done?

Let's take Integrity as an example. Take a look for a minute at the CVSS guide to see what these values are supposed to mean; here's the straight dope on "Integrity" according to the guide (section 1.1.5):

None: No impact on integrity.

Complete: A total compromise of system integrity. There is a complete loss of system protection resulting in the entire system being compromised. The attacker has sovereign control to modify any system files.

Now, somebody could make the argument (like Oracle appears to have done) that a buffer overflow in the Oracle software has "partial" impact because it only exposes files accessible to the Oracle account - not the root account. Granted, somebody could escalate privledges after hacking in through the vulnerability, but that's not related to the vulnerability - it's another issue entirely. This interpretation (favorable to Oracle though it might be) seems to be in line with the intent of the CVSS; take a look at the Apache exmaple llaid out in the CVSS guide (section 3.1):

In other conditions, however, the attacker would be able to execute code with the permissions of the web user, thereby altering web content and possibly viewing local user or configuration information (including connection settings and passwords to back-end databases). Therefore, Confidentiality and Integrity Impact metrics are set to "Partial"...

In other words, a literal-minded person, looking at the examples in the CVSS guide, would probably conclude that an application running in a non-root account (e.g. the Oracle database) would have only partial impact to Integrity in the event of a buffer overflow much like was the case with the Apache account in the example. Applying the same logic to all three of confidentiality, integrity, and confidentiality means a difference of three points total for "partial"s rather than "complete"s.

So, if we assume the literal-minded argument, the maximum value for that any Oracle vulnerability could possibly have would be a 10-3=7: or a seven point scale. Is that accurate? Is that the intention of the CVSS? Maybe not. But I don't think Oracle's out of line for interpreting it that way. Sure, the numbers are smaller than you'd expect. And they're probably not reflective of the actual severity of the issue - at least when taken at face value. But is it Oracle's fault? They're applying the criteria as the example; they've been pretty open about "showing their work" so that folks can make their own determinations on risk; and they're using the standard rather than the previous opaque risk value... Maybe they're not in the wrong. Or if they are, somebody should really clarify the intent of the CVSS to make it impossible to mistakenly use the weighting methodology that Oracle did. But that's just my two cents.

The Security Tarot: Trump 1, The Fool

I've decided to have a little bit of fun today, since talking about the same topic every day can be boring without putting different spins on it. And it's Friday after all. Anyway, today I'm kicking off a "Security Tarot" series where we examine infosec through the lens of the tarot. I'll post these as they seem relevant and illustrated by happenings in the industry - maybe they'll get posted quickly, maybe slowly, maybe not at all. Anyway, here goes.

The first trump in our security tarot deck is the "The Fool." Signifying infinite and limitless possibility, the fool is characterized by opposing forces, unpredictability, and anarchy. What the fool lacks is clarity of purpose and direction. Is he walking into danger or on the road to greatness? Who can say: it is the beginning of his journey and the destination is undefined.

The Fool is a force we see every day in security. Lack of clarity? We see it all the time - we don't have clarity around how to analyze the threats we're bombarded with, we don't have clarity about the metrics we gather (if any,) we don't have clarity around the research we do, and we don't have clarity about the terminology that we use to talk to each other. To prove that this force is at work, I don't have to reach beyond today's headlines; consider, for example, the Finjan Web Security Trends Report (published last week) and compare it to the ScanSafe Global Threat Report published yesterday. ScanSafe says, "ScanSafe reported that Web viruses decreased 47% in September, despite recent high profile Microsoft vulnerabilities..." while "Finjan’s position was that the market for malicious code would continue to expand... Recent findings show that our assessment was accurate and that the examples from our previous report were just the tip of the iceberg. This is clearly a growing phenomenon, and we can expect this trend to take on wider proportions in the foreseeable future." So which is it? Is it growing and continuing to expand or is it decreasing over time?

In both cases, the methodology is opaque enough that I can't verify the results; ScanSafe says that they base their assessment on "data generated by ScanSafe from analysis of over five billion individual web requests each month from 20+ countries", but how do they do that? Can I reproduce it here in my lab? Nope, not enough data. Finjan's methodology, though more detailed, still doesn't provide enough information for me to reproduce.

And what is a "web virus" anyway? In general, our terminology is non-standard and unclear. I suppose I could take a guess about what ScanSafe means based on the types of threats that they catalog in the threat report, but guess what - those names aren't used ubiquitously by all researchers either. So I can't categorically determine what those metrics mean. Look - not to do down either vendor - they're both doing what they do well. But security (in my opinion) should be a hard science, and "The Fool" isn't the mode and modus of a scientist. What would happen if a physicists at MIT published papers talking about acceleration in meters per second squared and physicists at Stanford published papers referring to speed-up-itude in cubits-per-year-per-year - or if the folks who claimed they found cold-fusion in the nineties didn't publish their methodology allowing other labs to disprove their findings? In a word, we'd have chaos and unpredictability... in other words, "The Fool."

Not gonna post about Apple

That's right - I'm not going to post about Apple's recent iPod malware incident, their (surprising) blaming of Microsoft for it, or Microsoft's subsequent blunt response. Surprise you? Yeah, me too. But I'm kind of late to the party; Kurt Wismer already wrote about it as did Ed Felten and Mike Rothman. What am I going to add that's new? Do I think it's unfortunate that the virus got distributed? Sure do, but it apparently didn't do much to Apple's incredible earnings so it's no skin off their nose. Do I think they were right in blaming Microsoft? No, I personally happen to think it's petty, but it is (as Mike indicated) in line with their general marketing message so I guess it's pretty much just another day at the office.

However, what I do find interesting is the fallout over the whole HP pretexting debacle. A colleague (thanks Dave) brought up a point that I hadn't really considered before; namely, to what degree are investigators (and auditors, assessors, pentesters, etc.) culpable for the actions they are hired to perform? Now it's one thing if those activities are illegal. But HP claims - and most PI's concur - that pretexting isn't entirely illegal (just dirty). Well, I guess that's more complicated than that - it is clearly illegal for financial records but HP didn't get financial records. It also may be illegal in California - and I guess we'll find out soon enough if it is. And from a broader angle, there are laws in the works for telephone records pretexting to be illegal, but they're not in place yet.

Now, stay with me on this... What if we assume for a minute that HP's right and the methods weren't illegal? But - hypothetically now - if I was a security auditor, and a company hired me to test their call centers against social engineering, that would be OK, right? Of if a company hires me to perform an "information gathering" activity such as a penetration test to see how susceptible they are to attack? Fine again, right? But what happens when that activity - the attack, or the social engineering, or whatever - is initiated at the highest levels of the firm (like the CEO) but was initiated by them for some sinister purpose (like spying on a board member)? Am I on the hook to ferret that out and refuse the job? Is it my job to understand the intent of the test?

In the case of HP, the waters are a little murky because the investigators were doing something that they can get sued for - but if this had been a sanctioned test (like HP trying to see how susceptible it was to corporate espionage by hiring people to dig up info on board members), it would have been "no harm, no foul," right? Cingular wouldn't be suing, it'd be just another day at the office for the investigators, and HP would have learned something about how corporate espionage applies to them. And that's exactly why this makes me nervous... Take pen-testing. Attacking a computer system is illegal, right? A pen-test (and tests like it) are attacks on computer systems, right? If someone in a firm contracts to initiate a pen-test (even if it's the CEO), it's generally accepted that they have the right to do that. But what if the CEO's shady and has nefarious intent? Do I go to jail if it turns out that the CEO isn't on the level? Wow, that's not cool... Now, I'm not saying that the investigators in the HP case should be gaining information in a shady way - that not cool either. But I will say that I think the HP execs are the ones we should be nailing to the wall - not the investigators. But that's just my two cents.

Serious Chutzpah from eEye

Chutzpah, cajones, cheek, liver, gumption, moxie. Whatever word you use to describe it, you have to admit that it takes bucketfulls to put out the kind of marketing message that eEye's sent out this morning. In case you haven't seen what I'm talking about, eEye says they want to build a gigantic honeypot with your machine as the bait. For those unfamiliar with the term, a honeypot is "a computer set up to collect security data by deliberately attracting online attacks". Now, I suspect that eEye doesn't mean by this that they're going to "deliberately attract online attacks" to machines running their client (at least let's hope), and most other client security vendors already collect anonymous data from systems running their client (most ask you first if you want to participate.) But I have to say that I was definitely surprised and a bit impressed by eEye's post-modern, punk-rock, "your machine, our bitch" marketing message.

However, bold marketing aside, I'm not going to participate in the free Blink offer. I've tested this product in the lab and observed a "marked decrease in system stability" on machines running Blink - I'd like to go into more specifics on this, but the research was conducted under contract so I can't. I can tell you though, that we couldn't run certain tests because portions of the performance and stability test harness wouldn't run after installing the product (e.g. cygwin wouldn't run and the COSBI profiler blue-screened the machine) on "vanilla" installs of the OS. So, unless eEye is going to support the hell out of this freebie (doubtful), I'm keeping it off my machine.

Note that our experiences were just that - our experiences; there are always tons of factors in play: maybe new versions of the product have solved this problem, maybe the problem was unique to the specific machines involved in our tests, or maybe there was no problem and we were just using it wrong...

The death of PatchGuard?

Ever write a windows application "the old fashioned way"? For example, does "RegisterClassEx(&myClass)" make you feel
A) happy
B) confused or
C) a sense of angst and overwhelming dread.

If you answered "C", you probably know what I'm talking about. Of course, most folks don't write applications that way any more; ever since the introduction of MFC, ATL, and [insert technology du jour here] there hasn't been much of a need to write this kind of code. Generations of developers have cut their teeth without having to ever worry about window messages or window styles, without ever having to call DispatchMessage() or TranslateMessage(), and without having to wonder about what the hell an HWND is anway. Not that they couldn't write this code if they wanted to - just that there are other technologies available that hide the underlying windowing system from those who have better things to do with their time.

But I digress. The point I'm trying to make is that back in the day, developers were allowed - nay, encouraged - to write to undocumented windows API's. It was a time-honored and glorious tradition; in fact, whole books were published on the subject. Of course, Microsoft never approved of it; they would rename undocumented functions to things like "BOZOSLIVEHERE" and "TABTHETEXTOUTFORWIMPS" to highlight the fact that you shouldn't be doing whatever it is that you were doing. But PatchGuard changes the paradigm. Now, instead of calling you a wimp or a bozo for using undocumented functions, Microsoft is doing something more - telling you that undocumented API's will halt the machine. Not an entirely bad decision in my opinion (although I would argue that maybe halting the app might be a better course of action than the blue-screen but maybe that's harder,) but I've covered that ground before so I won't do so again.

I read a few articles this morning about PatchGuard and about how Microsoft has apparently backed off their position in regard to PatchGuard. They've apparently decided to "allow access" to certain API's that SYMC and McAfee want to use; they've also decided to make an API available to programmatically disable the Windows Security Center. So, here's my question. Are SYMC and McAfee the only ones who can use undocumented API's on 64-bit Vista? Of course not. Are SYMC and McAfee the only ones who are going to be able to disable the security center? Nope. In the interests of fairness, that functionality has to be available to everyone. Small AV players, anti-spyware vendors, HIPS vendors, encryption vendors, non-security application developers, malware authors, old Uncle Jerry who talks to himself... everyone.

So I have to ask myself if this is a victory for security? It's a victory for Microsoft certainly: they get the publicity associated with developing new security features without the pain and inconvenience of having to actually support them; they get the perception of "fostering competition" at the same time that they also get a convenient excuse for insecurities in the product ("we tried to secure it, but were forced to back down"). It's also a victory for AV vendors: they get to programmatically disable the Windows Security Center and secretly replace it with Folgers crytstals - for OEM systems (those that come with either McAfee or SYMC preinstalled,) end users might not even realize that they had a choice of security centers in the first place. Symantec and McAfee also get to use undocumented Vista API's regardless of stability or performance concerns. Sounds like a win to me. But what do users get? One less security feature? Maybe. Lack of choice in Security Centers? Arguably. Increased succeptibility for malware? Could be. Call me inflammatory, but I think this was a zero-sum win: Microsoft made out big, McAfee made out so-so, and users got the short-end. But that's just my opinion...

Monday afternoon humor

If you haven't been there yet, giveusallyourmoney.com is funny. Thanks to John for passing it along... it keeps getting funnier each and every time I see it. Also, courtesy of the Onion, the bogus statement from the National Cryptography and Information Security Council was funny too.

Symantec Business Model 2.0

Wow, all this news about Symantec's Security 2.0: it was covered in the Register, in news.com, in Information Week and so on. Apparently calling the malware problem "solved", John "we're more than antivirus" Thompson is apparently moving the firm in an entirely new direction (for them) - a direction that has them concentrating on transactional elements of information security rather than platform aspects; a strategy of trust rather than a strategy of fear. Interesting. But what's more interesting than that, in my opinion, is the change to the way that Symantec typically does business.

In past, for example, we've seen a typical pattern emerge in the way that Symantec approaches building the enterprise portfolio - we've seen them buy products to round out the portfolio like Veritas or BindView and we've seen them buy service companies like @stake. However, this new strategy of partnership with service companies in combination with development (rather than purchase) of new products is a new one. I'll be curious to see if it works the way Thompson is hoping. I'm also interested to see what type of marketing dollars Symantec is willing to spend to get the kind of adoption that they need for the products to be a success. I guess we'll have to wait and see...

Terror Management Theory

Ever hear of Terror Management Theory (TMT)? TMT is a theory in psychology that basically tries to explain the psychological reaction of people to fear of their own death. For example, TMT predicts (and experiments support) that persons reminded of their own death will tend to cling to concepts, leaders, and symbols of "traditional" sociological values; for example, persons reminded of the threat of death by terrorists are more likely to hold to political and social conservativism than if they are not reminded of their own mortality. Al Franken lays out a convincing argument (personal politics aside) for why repetitions of terrorism strikes helped sway the 2004 presidential elections in his book "The Truth (with Jokes)".

TMT also says something else; it says (intuitively) that individuals faced with the threat of their own demise will cling to ideas that make death seem less likely or less meaningful. For example, individuals have shown under experimental conditions to represent themselves as having a stronger belief in religion immediately after being reminded of their own mortality. Makes sense, right? But I don't think it's just death; in fact, I think that the same principle probably operates (albeit at a lower level) for individuals who are threatened with events that may not be life-threatening. For example, I think if threatened with the prospect of emotional anguish that most folks would react in a similar way; for example, if considering the loss of a loved one. But that's just me; no experiments that I know of have explicitly proved this.

So, as always, we have to tie this back to computer security. Which makes me ask the question of why FUD works as a sales tool. Could it be that the same principles are at work here? Is it the case that individuals, when presented with the prospect of the worst case scenario, become more pliant and succeptible to certain marketing spin that they would otherwise be hardened to. Most folks take their jobs very seriously; is it out of line to speculate that perhaps they would be more likely to cling to "computational conservativism" marketing messages just like TMT predicts with the loss of life? Clearly, I would argue that they are more likely to make decisions that they perceive would make the presented threat seem likely. But how far does that go? I don't have any answers here, but boy would I like to see some experiments done in this area...

Humble Pie: No offense to Tekrati

Time, once again, to eat the humble pie.

The other day, I posted an entry referencing the Tekrati analyst directory in the same breath as invasive AR activities and the "Runaway Jury" movie. It was brought to my attention after the fact that my post could be read as saying the Tekrati service was intrusive. Note that I don't think it is. Researching Tekrati caused me to think about the intrusiveness of AR, but not because it is itself intrusive - just because it made me think of it. That statement, "seeing that made me think of xyz" could be taken (the way I meant it) as "seeing that made me think of xyz [because other people might carry it to an unhealthy extreme]" or (caustically) as "seeing that made me think of xyz [because it is]." I meant it the non-caustic way.

So, sorry to those folks for the slight - really, it was unintentional.

Awesome Stuff on the Daily Incite: Analyzing the Analysts

So, I came across an interesting article today on Mike Rothman's Daily Incite about how Forrester is profiling analysts and sorting them into different categories based on their "archetype" (according to Forrester, the archetypes are Advocates, Strategists, And Evangelists). Anyway, it's interesting stuff...

Seeing this got me wondering about how scientific Analyst Relations is as a discipline and how far AR people take it; for example, when I see stuff like the Tekrati analyst directory, I start remembering scenes from "Runaway Jury" and wondering how intrusive people get. John Simonds had an interesting take on his blog about what makes for good AR. His approach (get analysts what they need and be generally forthcoming about your company) isn't intrusive and seems like common sense to me. On the other hand, Azul Partners' Spark Newsletter recommends vendors "develop an in-depth understanding of the analyst compensation structure at all of the major firms" and claims that AR is a "high stakes game of influence". Now that's waaaaay too intrusive.

Thoughts about McAfee's advertising blitz

Unless you've been living under a rock for the past two days, you've probably already heard about McAfee's full-page ad in the Financial Times doing down the big M and alleging that new features are blocking their ability for their product to function. Even more recently, they've gone on the public record to say that Vista's security will be reduced because of (ironically) two new security features that Microsoft is building into the product.

Here's the argument: Microsoft has built a feature in to Windows Vista for the 64-bit platform that prevents folks from monkeying around with the kernel in unsupported ways (through a technology appropriately called "Patchguard"). Given that there are quite a few companies doing this, Microsoft has elected to target the 64-bit platform first so as to reduce the overall impact. However, probably in future it will expand to the 32-bit architecture as well. Microsoft alleges that by doing this, they can help users ensure reduced rootkit problems and greater stability. Now, McAfee and Symantec allege that by locking down the platform in this way, that Microsoft impedes their ability to sell product. Also, McAfee and Symantec are in a twist because of the fact that you can't programatically disable the Windows Security Center that reports on AV installation status; they say that this impedes their ability to compete because they can't programmatically disable the Security Center.

So, when I first read the press coverage of this, it sure sounded to me like Microsoft was being anti-competitive; but then I decided to educate myself on the various features that are under discussion - now I have a different opinion. Now I think that McAfee and Symantec are grandstanding. Why's that, you ask? Well, here's my take on this stuff:

Patchguard: If you take a look at the technical overview put out there by Microsoft's Patchguard architect, Jeff Jones in his blog or if you look at the Vista kernel protection FAQ, you'll notice that there is a subtle difference between what McAfee and Symantec are claiming vs. what the feature actually does. McAfee and Symantec claim that you can't write certain types of code that interact with the kernel; however, that's not what the technology does. Instead, the technology prevents products using undocumented and unsupported techniques for modifying the kernel. Take a look:

Was this kernel add-on part of the overall design? It can be, and if so, there should be predictable, well-defined interfaces that help it fit into the designed architecture. Otherwise (ie using non-documented methods), behavior is unpredictable at best... Of course, there is a difference between a driver developed by, say Hewlett-Packard, and some unknown code posted for shareware download. The former should be allowed to extend the kernel in defined/designed ways (ie. so your printer works) that the latter perhaps should not. The method for that on x64 is Kernel Mode Code Signing.

So, your options if you're SYMC or McAfee are use defined interfaces and sign your driver. That's not so onerous - HP has to do it for their printers to work, Canon has to do it for their scanners to work, and Western Digital has to do it for their harddrives to work. Seems to me like McAfee should have to do it too. In fact, it's not just about fairness - I *want* McAfee to use documented interfaces. I *want* them to sign their driver. Why would I want anybody - including McAfee - to modify the kernel in a way that's unsupported, undocumented, and untested? And frankly, it scares the hell out of me that they would fight to retain their ability to use the undocumented interfaces in the first place.

Now, somebody at McAfee might say that there are features that they can't do because they can't hook the kernel using "scary undocumented interface X". However, I would ask them what those things might be; without some kind of specific example, I don't believe it. Specifically, I find it hard to swallow that a vendor like Aladdin can write a filesystem driver that filters USB requests to encrypt data on the fly using documented interfaces, that a vendor like CA can write a driver that filters all incoming TCP connections using documented interfaces, and that a vendor like PointSec can write a driver to intercept filesystem calls using documented interfaces; but somehow McAfee can't get it together to grep the filesystem for malware without "going commando" all over Windows Vista in a way that requires them to rewrite the kernel. WTF?! The answer is: they can do it and they will do it. So what's motivating the outrage in the meantime?

Security Center: According to the outrage from McAfee et al, the way that the Windows Security Center is handled in Vista is also a problem; this has been represented in the press as Microsoft "forcing" users to use the Microsoft version of the security dashboard. Well, I guess technically that's one way to say it; of course, another way to say it is that the feature prevents third parties from disabling the security center without user approval. From a user-choice perspective, the security center recognizes and integrates with third party products, was designed with openness in mind to facilitate this, and provides the user the ability to turn it off if they want to. What's causing the ruckuss is that the user will actually have to make a decision to diable it rather than allowing Symantec or McAfee to nuke it for you.

Again, as with Patchguard, I want this. I *want* to make the decision about which vendor controls the security dashboard and I don't want McAfee to take that decision away. I'm not going to use the Windows Security Center because I find it irritating, but I'm not going to use McAfee's or Symantec's either - for the same reason. In general, I don't want McAfee making decisions for me about what Windows features are enabled or disabled just like I don't want Microsoft deciding for me what browser I should use. It seems to me that in this case, Microsoft - by enforcing the user's decision to choose what dashboard to use - is more about openness than McAfee's ire about not being able to dictate to the user what security dashboard they'll use.

A case study in vendor research

I remember once being overwhelmed by an independent product review published in the US Airways in-flight magazine; it was for an energy-boosting supplement that sounded absolutely fantastic. I was ready to go out and buy it; when I happened to mention in coversation how cool this product sounded (and the fact that I had read this review of it), I was informed that the "review" was really an advertisement. And, sure enough, I had missed the small print that said "special advertising section" above the review. In that case, I neglected to fully understand who published the review I was reading, and what the intended purpose was - had I known that it was intended to promote the product, I probably wouldn't have had the same reaction to the positive "review".

Now before I get into how this anecdote applies to security, let me say that it's not my intention to do down any vendor's research; I have *NO PROBLEM* whatsoever with vendors publishing research that benefits them, that helps people look at a product in a different way, or that helps people understand a product's suitability for their enterprise. All that stuff is perfectly grand. However, just like it was important for me to understand the motivation for the review in the US Airways magazine, it's important for readers of these vendor documents not to forget why these things are published. Specifically, vendors are doing this stuff to forward their marketing goals - not as a public service. By the time most of these things reach your inbox, they have been carefully vetted, edited, and redacted to make sure that every aspect of the publication is in tune with the corporate marketing message.

Here's my point: statistics can be represented any number of ways, right? And vendors who manufacture a product are more likely to draw conclusions from data that favor their product, right? Not because they are dishonest, mind you - just because they have skin in the game. And there's nothing wrong with that. But between the malleability of the statistics and the fact that the majority of the research is published without a transparent methodology or intermediate data, you're left at the end of the day with an artifact that (while useful for the vendor) should probably be read and understood by folks with their eyes wide open to the point of the document.

Now, in the past I've ranted about malware numbers from Symantec and McAfee, web application numbers from Fortify, email statistics from MessageLabs et al, and so on. This time, I happened to come across the CyberArk Privileged Password Survey via an article on the Register saying that administrative passwords are "abysmal". OK, I'll bite: how abysmal are they? Well, according to CyberArk, a manufacturer of software for securing administrative passwords, they stink on ice. Check out some of the conclusions from their research and their press release:

- "Approximately half of all enterprises have more privileged passwords than personal ones"
- "Privileged passwords are more powerful but less likely to be changed"
- "...up to 42% [of privileged passwords] are never updated..."
- "A major risk for hacker attacks and failed audits"

OK. So, are these things true? As with most vendor research, it depends on your point of view... For example, if you say there are "more privleged passwords than personal ones" - that's a startling statistic and one that's likely to get press attention. But is it useful as a barometer for the overall security of administrative passwords for our industry? Probalby not. Look, for example, at the support for this statement in the Cyber-Ark research:

* More than 500 employees, and each employee has an Administrator account associated with their workstation (72%)
* More than 500 servers with privileged password accounts (44%)
* More than 100 routers with privileged password accounts (41%)
* More than 100 software applications (71%), most of which connect with other applications (92%)

And guess what? All of these supporting facts are probably 100% accurate. But where it gets murky is not in the data but in the conclusion. For example, the majority of the "privileged accounts" in this analysis are comprised of local machine Administrator on desktops; specifically, the interpretation assumes a 1:1 ratio between workstations and employees with an admin account on every desktop. But where this falls down is in looking at publicly-avialable data conducted at taxpayer expense that suggests that 1:1 for this values is not the case. Instead, the data suggests that 1:1 is the saturation point for the workstation to employee ration and not a typical value. Consider for example, the most mainstream of all American corporations - Walmart. Is it the case that every Walmart employee has a workstation? How about the guy with the iron-lung who hands out the carts, the person putting out the produce, the individual ringing up merchandise... Clearly, they do not.

But moving beyond that... even if every employee did have a workstation, the ramifications of this fact depend on your interpretation of "privileged account". For example, is a workstation's local administrator account at the same level of risk and significance as a Unix server's root account? I happen to think that these two things are very different - but the Cyber-Ark methodolgy assumes they are the same thing. Should they be treated the same in drawing conclusions? Maybe, maybe not. Hmmm.... murky.

Or take the idea that these administrator passwords make it more likely that you will fail audits; where's the evidence for this? Say, for example, you're a government entity regulated under FISMA; you follow - to the letter - the guidance from the NSA for configuring your workstations and you proceed to get audited by your IG. Are you likely to fail your audit or not? I would argue not. Again, the Cyber-Ark numbers are probably accurate, but one would probably be more inclined to disagree with the conclusion than agree with it in that scenario.

RiskAnalysis.is hits one out of the park...

Hey, are you reading RiskAnalysis.is? You should be. Even if you don't read it on a regular basis, go and read Fear and Loathing in OS X Security Land; and then when you're done, read it again. Check out some of the awesome stuff:

Never take a magazine rating at face value. In fact, tell magazine reviewers that they need to put a metric up “How long the sales engineering team spent at our lab trying to get the stupid thing to start right.”

For sure. And keep in mind that not everybody reviewing a product necessarily installs it and runs it; I remember, for example, reading a review of Symantec's ESM for WebServers 1.0 back in the day (I wish I could find the reference) where the reviewer gave it the highest possible rating; needless to say, when I tried to install the product, I had some serious challenges getting it working - and then when it worked, it turns out that it didn't do what I (and probably most people) would need it to do. Clearly the review never actually tried to install and run it... In general, I find that the magazine reviews with a completely transparent methodology are the best ones to read.

(In reference to the ESM product - note that my experience was only that - my experience. Also, that was then and this is now, so I'm sure the new versions work great now and run like a champ.)

Recreation

What's cooler than X2: The Threat? Why, X3: Reunion of course! And what's even cooler than that? Playing them both at the same time...

Hot or Not: SC Magazine's New Feature

So, I got an email the other day from SC magazine informing me that they have a new feature called "Hot or Not" which claims to take the media to task for their hype. That sounded appealing as did the "hot or not" part (because much like Project Runway, in security you are either hot or you are not.)

For background, SC has apparently decided that there's quite a bit of media hype in infosec, and they've apparently decided to separate the wheat from the chaff and tell us if stuff is really a threat - or if it's just hype. Reading the description, I approached the column with cautious optimism: optimism because I'm all for people calling out the media hype, but caution because to do this correctly SC will need to be ready to take the occassional controversial stand on things and cut against the traditional wisdom.

In the first edition of this new feature, SC tells us that laptop theft is, in fact, "hot" and not just wind:

Should I be worried? Yes. Every organization that deals with PII should be concerned about proper protection and potential loss wherever the data resides.

Agreed; I think it's probably "hot" too. Of course, I think you'd be hard-pressed to find anyone who doesn't agree with that assessment. As to what practical things that they recommend that practitioners do to mitigate laptop theft:

Procedures should separate PII from other general user population information. The enterprise should employ hard disk passwords, disk encryption or file encryption for computers that must contain PII. In addition to the built-in (but not automatically enabled) file system encryption that PCs (EFS) and Macs have, there are other hard-drive encryption solutions on the market. Additionally, developers or programmers should not work with live data.

True, true. My only issue with this would be with the degree of difficulty in doing these things. Having implemented EFS, for example, I can tell you with certainly that it is a technology that's difficult to implement (and of questionable utility) in the best of situations and less than useless in the worst of them. Additionally, I have yet to come across an enterprise where developers don't work with production data somewhere in the firm (I'm not saying it's right mind you, just that everybody's doing it - kind of like speeding.) Useful material around this would be a "real world guide to implementing EFS for laptop protection" if somebody would care to write it; of course, SC might not be the best forum for that...

So, I'll remain cautiously optimistic about this new feature; if SC decides they don't mind pissing off a few readers, authors, and sponsors by actually taking the hype to task (consider "hot or not: source code scanners", "hot or not: web application firewalls", "hot or not: phone-borne malware", etc.) then I'll keep reading it. On the other hand, if they stick to topic guaranteed not to stir the pot, then I'll probably stop reading after a few entries.

I just thought this was funny...

Clearly, RSA's marketing has received a serious shot in the arm since the merger. Billing themselves nowadays as the "security division of EMC", they've been sending out all sorts of email invitations over the past few weeks: invitations to view their blog entries, invitations to listen to their podcasts, and most recently, an invitation to attend a live seminar about PCI. Now, normally this kind of thing wouldn't be blog-worthy, but their statistical lead-in caught my eye. Check it out and see if anything about it strikes you as unusual:

FACT: Over 85% of Payment Card Industry (PCI) Data Security Standard audit failures are in the area of data security.

Since it is the "data security standard", I have to confess that it doesn't really surprise me that the lion's share of the issues are related to data security. But the part that does really make me curious is what the other 15 percent are related to...