So, the other week we discussed (cursorily) the ongoing fallout from Dave Litchfield’s report regarding the security of Oracle vs. SQL Server. One of the interesting reflections on this comes from Illuminata; if you get a chance, I highly recommend that you read through their discussion on this.

Now, the Illuminata position is that the security of Oracle has eroded over time (that they have more vulnerabilities now than they have in previous versions of the product) while the security of Microsoft’s SQL Server has increased. I think this is a useful observation… The only thing that I would point out would be the fact that proving their assertion would be difficult; for example, we’ve had an uptick in the amount of research activity across the same time window as the increase in Oracle’s vulnerabilities. Given that, it could be that the security of Oracle hasn’t eroded – it’s just that there’s more research nowadays. But, normalizing the increase in vulnerabilities against the research growth curve is more math than I feel like doing this morning, so I’ll buy in to their assumption for the sake of argument.

Their next assertion is also interesting – which is that other Microsoft products like IE and Windows have also had an increase in overall security, but because of holes in the existing product base, users have not yet begun to pick up on the improvements. Interesting, too. I would tend to agree with this. However, I think there’s more going on than just interaction with legacy products that increase the perception of Microsoft products as having security problems. Specifically, there is pressure from competitors, marketing dollars from Apple and others to paint the products as insecure, as well as third-party apps that detract from the security of the individual products.

So, go read this post if you haven’t yet. Pay special attention to the part where they tell Oracle that their customers are starting to take notice of issues in the product, and also keep in mind that Illuminata is not a security-specific analyst firm so the fact that they are interested in this means that it’s of interest to the IT community outside of just security.

The other day, I was listening to NPR (i think it was “Marketplace”) in the car and for some reason they were talking about Vista. I can’t remember the exact context, but one of the gentleman being interviewed raised an interesting point – he said (paraphrasing here, since my memory is not so good), “Microsoft has so much riding on Vista that if they can’t control the spyware/malware problem, it won’t be very good for them.” Of course he was right, and it’s something that quite a few of us have been commenting on in the security space for quite some time; however, what really struck me about this particular discussion was the fact that it was on NPR – meaning, in my opinion, that the interest in this has been raised significantly (it seems to me that something has to be particularly entrenched in our collective discourse if it gets coverage on the radio – even if it is NPR.) So in my opinion, this means that all sorts of individuals who would otherwise be less than interested are now watching Vista to see how it plays out from a security perspective.

Now, in my opinion, Microsoft has painted themselves into a corner; they’ve written a number of checks that I don’t think any product could possibly cash. Here’s what I mean: They’ve made the claim that it’s the most secure MSFT product to date. Couple this with a perception on the part of many that they are seeking to “own” security going forward (I don’t think they are, by the way – but there is that perception.) Now throw in the recent press that the SDL has received and the vocal message that they’ve put forth about the security features built into the product (this is from BusinessWeek, for Pete’s sake). All those things combined and you have some very high expectations on the part of consumers. At the end of the day, Microsoft will have to eat some major crow if it turns out that the security is not perceived to be significantly better than previous operating systems. And for the crux of the matter, notice that I didn’t say “is significantly better” in that last sentence but instead “perceived to be significantly better”… in actuality, it doesn’t really matter all that much whether the security actually is better or not – it just has to be seen as being better by the community at large.

And that won’t happen. Period.

Why not? First, Microsoft has to fight the marketing of other firms with a vested interest in painting the OS as insecure. Don’t believe me? Does “I’m a Mac” ring any bells? If Mac doesn’t spin the security issue, how about the AV software vendors? How many millions of dollars in “Microsoft is insecure” marketing dollars do you think will get spent to herald in the age of Vista? I’m thinking quite a few. Second, there are a ton of researchers chomping at the bit to test their mettle against Vista. It is going to be “target #1″ for the foreseeable future for bug-finders, vulnerability researchers, tool makers, spyware manufacturers, etc. Batten down the hatches, because a squall is a-brewin’. Not to mention that they’re fighting the natural order – it is the nature of software products to have bugs. And Vista will – I guarantee it. And last but not least, Microsoft is up against a bias in the marketplace the extent of which they have no conception. In other words, they have a matter of weeks – maybe a few months – to change everyone’s mind about their software. I think it’s pretty unlikely, don’t you?

So what happens if Vista is not perceived as secure? I’m not sure, but I’m thinking nothing good (for Microsoft) can come of it when it doesn’t happen.

If you follow the

same blogs that I do, you’re probably already aware of the fact that
Microsoft is hosting a

series of discussions with

their OEM partners about the

SDL (Security Development Lifecycle.)  First of all, let me say that
I’m seriously jealous of these OEM people, since it would be awesome to
participate in this training.  However, references to the green beast
aside, I think it’s an interesting exercise to stop for a moment to consider
where Microsoft is going with this whole SDL thing.  Why are they doing
this, what are they doing, and what does it mean to security as a whole?

So, for some background…  If you’re a developer, you’re probably somewhat
familiar with the "software development lifecycle" (SDLC.)  For the sake of
folks who haven’t spent much time in development shops, there are a variety of
approaches and techniques for how software development gets done.  All
software development shops operate within a spectrum of what CMM calls
"maturity", what some might call "formality", and what I call "discipline." 
In other words, the process that developers adhere to vary from "undisciplined"
shops (usually startups) that try to rush to market without any kind of
structure whatsoever.  At the other end of the spectrum, you have shops
that use a formalized process that defines how requirements are developed, that
ensures that users are invested, and that accountability is assigned.  Of
course, there are all sorts of processes along the spectrum:   RUP
(Rational Unified Process,) XP (Extreme Programming), SPICE, and so on. 
Microsoft even developed their own called the "Microsoft Solutions Framework"
(MSF).  I’m not going to go into a bunch of detail here on why it’s a good
idea to be disciplined – the most I’ll say is that (though most developers feel
too much process is a pain in the ass) the process really is there to make the
developer’s life easier.  Although I don’t have direct evidence for this,
I’ve informally noticed that the "getting woken up in the middle of the night
for some issue" factor is inversely proportional to the maturity of the
development shop.  Really, it’s true. 

Anyway, the overall goal of maturity (read: "discipline") is to increase the
quality and reliability of development.  And it works.  In point of
fact, I find that the dynamics are such that there is additional up-front
investment in development time for a disciplined approach, but that the
long-term gains are quality, alacrity, and reliability.  Now, Microsoft has
picked up on something else that I’ve argued as well – which is that a
disciplined approach (if designed intelligently) can also lead to increases in
security as well; check out this text from the

MSFT overview of SDL:

…there are three facets to building more secure software: repeatable
process, engineer education, and metrics and accountability…. If
Microsoft’s experience is a guide, adoption of the SDL by other
organizations should not add unreasonable costs to software development. In
Microsoft’s experience, the benefits of providing more secure software
(e.g., fewer patches, more satisfied customers) outweigh the costs. The SDL
involves modifying a software development organization’s processes by
integrating measures that lead to improved software security.

Now, for anyone who hasn’t familiarized themselves with the SDL, I highly
recommend that they do so.  It’s a great read.  Unlike some folks, I
haven’t swallowed all the KoolAid…  The Microsoft approach is heavy on
the documentation (documentation of attack surface, documentation of threats,
etc.) and heavy on the education of developers.  I disagree that this is
the most effective approach over the long term; the point I’ve made in the past
is that some activities (such as developer education) require continued
investment over time; by contrast, standardization of the development process
through the use of a framework is self-enforcing and therefore costs less over
time.  To make it really simple, you can educate developers about why they
shouldn’t do this:

void doNothing(char * somefoolishness) {
    char a[5];
    strcpy (a, somefoolishness);
}

or you can do this once and make everybody use it:

class SafeString {
    SafeString(const char * somefoolishness) {
        myVal = (char*)malloc(strlen(somefoolishness));
    }
    const char * getValue() const {
        return myVal;
    }
//and blah blah blah

or whatever.  (Please don’t try to compile that and complain about it, bust my nads about the strlen(), complain about the malloc, or the lack of error checking…  this is a blog for Chris’sakes so cut me
some slack and just let me make the point.)  Now, one could argue (and
they’d be right) that most of the "secure framework" concepts that I’m talking
about are implemented in the .NET System classes (aha!).  If you ask me,
MSFT has some master plan over there that accounts for both .NET and SDL. 
Or maybe not…  

But anyway, small differences in philosophy aside, I think the fact that MSFT
is even going here is impressive.  After all, application security is a
topic that most of mainstream security (unfortunately) doesn’t care about all
that much.  They should, mind you, since I think it’s where the majority of
the issues are – but the fact that they don’t is clear.  Example: do a
search for "+application +security +sdlc" in your search engine of choice and
compare the results with a search for "+mobile +malware +phone" – notice how the
phone-malware stuff eclipses application security by an order of magnitude? 
That’s my point. 

So why is MSFT going there?  All told, I think it’s twofold – internally
to them, I think it’s motivated by reducing their long-term security-related
costs – which it probably will.  So, they’re probably investing in their
internal processes to realize some efficiency and maintainability gains (and
therefore lower costs.)  Smart move.  Externally, though, is where I
think the strategy gets brilliant.  Brilliant?  For sure.  Think
about the marketing potential here…  can you think of a better way to
displace their (unearned in my opinion) reputation for being insecure?  How
much marketing would it take for them to give them an image as being a "secure"
solution?  Millions?  More, probably.  Not to mention that people
would be loathe to take that marketing seriously.  But by becoming the
de-facto thought leader in application security – a space that is directly
applicable to their product and that is underrepresented in the field? 
That’s the path right there. And the cost?  a few whitepapers, a book or
two, a few pro-bono education sessions with partners.  I’ll make a
pilgrimage to bow at the feet of whoever’s idea that was. 

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…

In a pretty strange move, Microsoft may be requiried to remove some security features from Vista based on a warning from EU regulators. The thinking is that if Microsoft includes additional security features, that other companies who sell security products may not be able to compete as effectively; check out the logic:

“…computer security depends on diversity and innovation in the field of security software, (and) such diversity and innovation could be at risk if Microsoft was allowed to foreclose the existing competition in the security software markets… [this] would ultimately harm consumers through reduced choice and higher security risks.”

Their position is both true and alarming at the same time. It’s true because, in some ways, they’re right: Microsoft offering certain types of security software – like antivirus, personal firewalls, and/or spyware protection – could impede the ability of some of the niche players in that space to compete. Moreover, this isn’t a point the EU folks have made only recently; it’s a continuation of what EU regulators have made before about Microsoft’s role in the security software space – it’s been at issue ever since MSFT acquired GeCAD.

On the other hand, it’s alarming as well. Alarming because while it makes sense for AV and (potentially) spyware, the extent to which they expect Microsoft to “leave security alone” in other areas is unclear. Would, for example, Microsoft be required to exclude technologies like stack layout randomization because it reduces the efficacy of HIPS solutions? Not to mention that there are some who would argue that the courts are preventing MSFT from cleaning up their own mess. For example, you’ve heard folks who think that the festival of malware is because of poor engineering on Microsoft’s part right? For example, many users say things liek “[Microsoft] shares some blame here, especially for creating such a swiss-cheese virus delivery client” and “Microsoft is responsible for this mess and we all know it.” So, if MIcrosoft is responsible for the problem, shouldn’t they be allowed to fix it? I don’t know the answer, but it’s an interesting question.

I’ll also admit that I don’t think that I buy the argument from EU regulators that Microsoft adding security features “would ultimately harm consumers through reduced choice and higher security risks.” Or, at least, I think they should clearly specify which features they’re talking about; for example, I’m not sure that features that we’ve had around for ever like auto-update, EFS, heap protection services, and autheticode (which all arguably have security benefit) reduce choice or increase security risks. And after all, there are tons of products that compete with those features: CA Unicenter’s SDO for example arguably competes with Autoupdate and PGP’s Full-Disk Encryption arguably competes with EFS. It seems to me that an argument could have been made about these features before they were released about competition issues; but yet, at the end of the day, there was none.