No doubt you are aware of the out-of-band security bulletin issued by the Microsoft Security Response Center today, and like all security vulnerabilities, this is a vulnerability we can learn from and, if necessary, can use to shape future versions of the Security Development Lifecycle (SDL).

Before I get into some of the details, it's important to understand that the SDL is designed as a multi-pronged security process to help systemically reduce security vulnerabilities. In theory, if one facet of the SDL process fails to prevent or catch a bug, then some other facet should prevent or catch the bug. The SDL also mandates the use of security defenses, because we know full well that the SDL process will never catch all security bugs. As we have said many times, the goal of the SDL is to "Reduce vulnerabilities, and reduce the severity of what's missed."

In this post, I want to focus on the SDL-required code analysis, code review, fuzzing and compiler and operating system defenses and how they fared.

Code Analysis and Review

I want to start by analyzing the code to understand why we did not find this bug through manual code review nor through the use of our static analysis tools. First, the code in question is reasonably complex code to canonicalize path names; for example, strip out ‘..' characters and such to arrive at the simplest possible directory name. The bug is a stack-based buffer overflow inside a loop; finding buffer overruns in loops, especially complex loops, is difficult to detect with a high degree of probability without producing many false positives. At a later date I will publish more of the source code for the function.

The loop inside the function walks along an incoming string to determine if a character in the path might be a dot, dot-dot, slash or backslash and if it is then applies canonicalization algorithms.

The irony of the bug is it occurs while calling a bounded function call:

_tcscpy_s(previousLastSlash, pBufferEnd - previousLastSlash, ptr + 2);

This function is a macro that expands to wcscpy_s(dest, len, source); technically, the bug is not in the call to wcscpy_s, but it's in the way the arguments are calculated. As I alluded to, all three arguments are highly dynamic and constantly updated within the while() loop. There is a great deal of pointer arithmetic in this loop. Without going into all the gory attack details, given a specific path, and after the while() loop has been passed through a few times, the pointer, previousLastSlash, gets clobbered.

In my opinion, hand reviewing this code and successfully finding this bug would require a great deal of skill and luck. So what about tools?  It's very difficult to design an algorithm which can analyze C or C++ code for these sorts of errors.  The possible variable states grows very, very quickly.  It's even more difficult to take such algorithms and scale them to non-trivial code bases. This is made more complex as the function accepts a highly variable argument, it's not like the argument is the value 1, 2 or 3! Our present toolset does not catch this bug.

Ok, now I'm really going out on a limb with this next section.

Over the last year or so I've noticed that the security vulnerabilities across Microsoft, but most noticeably in Windows have become bugs of a class I call "onesey - twosies" in other words, one-off bugs. There is a good side and a bad side to this. First the good news; I think perhaps we have removed a good number of the low-hanging security vulnerabilities from many of our products, especially the newer code. The bad news is, we'll continue to have vulnerabilities because you cannot train a developer to hunt for unique bugs, and creating tools to find such bugs is also hard to do without incurring an incredible volume of false positives. With all that said, I will add detail about one-off bugs to our internal education; I think it's important to make people aware that even with great tools and great security-savvy engineers, there are still bugs that are very hard to find.

Fuzz Testing

I'll be blunt; our fuzz tests did not catch this and they should have. So we are going back to our fuzzing algorithms and libraries to update them accordingly. For what it's worth, we constantly update our fuzz testing heuristics and rules, so this bug is not unique.

Defenses

If you want the full details of the defenses, and how they come into play on Windows Vista and Windows Server 2008, I urge you to read teh SVRD team's in-depth analysis once it is posted.

A big focus of the SDL is to define and require defenses because we have no allusions about finding or preventing all security vulnerabilities by attempting to get the code right all the time, because no-one can do that. No one.  See my comment above about one-off bugs!

Let's look at each SDL mandated requirement and how they fared in light of this vulnerability.

-GS

The -GS story is not so simple. A lot of code is executed before a cookie check is made and the attacker can control the overflow because the overflow starts at an offset before the stack buffer, rather than at the stack buffer itself. So the attacker can overwrite other frames on the call stack, corresponding to functions that return before a cookie check is made. That's a long way of saying that -GS was not meant to prevent this type of scenarios.

ASLR and NX

The code fully complies with the SDL, and is linked with /DYNAMICBASE and /NXCOMPAT on Windows Vista and Windows Server 2008. There are great defenses when used together, and reduce the chance of a successful attack substantially. Also, the stack offset is randomized too, making a deterministic attack even more unlikely.

Service Restart Policy

By default the affected service is marked to restart only twice after a crash on Windows Vista and Windows Server 2008, which means the attacker has only two attempts to get the attack right. Prior to Windows Vista, the attacker has unlimited attempts because the service restarts indefinitely.

Authentication

Thanks to mandatory integrity control (MIC) settings (which comes courtesy of UAC) the networking endpoint that leads to the vulnerable code requires authentication on Windows Vista and Windows Server 2008 by default. Prior to Windows Vista, the end point is always anonymous, so anyone can attack it, so long as the attacker can traverse the firewall. This is a great example of SDL's focus on attack surface reduction; requiring authentication means the number of attackers that can access the entry point is dramatically reduced.

Firewall

We enabled the firewall by default in Windows XP SP2 and later, this was a direct learning from the Blaster worm. By default, ports 139 and 445 are not opened to the Internet on Windows XP SP2, Windows Vista and Windows Server 2008.

Summary

The $64,000 question we ask ourselves when we issue any bulletin is "did SDL fail?" and the answer in this case is categorically "No!" No because as I said earlier the goal of the SDL is "Reduce vulnerabilities, and reduce the severity of what you miss." Windows Vista and Windows Server 2008 customers are protected by the defenses in the operating system that have been crafted in part by the SDL. The development team who built the affected component compiled and linked with the appropriate settings as described in "Windows Vista ISV Security" and Writing Secure Code for Windows Vista so that their service is protected by the operating system.

The team did not poke holes through the firewall unnecessarily, in accordance with the SDL.

The team reduced their attack surface, in accordance with the SDL, by requiring authenticated connections rather than anonymous connections by default.

We know that the SDL-mandated -GS has very strict heuristics so some functions are not protected by a stack cookie, but in this case, there is no buffer on the stack, so there will be no cookie. We know this. There are no plans to remedy this in the short term.

Fuzzing missed the bug, so we will update our fuzz testing heuristics, but we continually update our fuzzing heuristics anyway.

In short, based on what we know right now, Windows Vista and Windows Server 2008 customers are protected because of the SDL-mandated defenses in the operating system, and because the development team adhered to the letter of the SDL to take advantage of those defenses.

Chalk one up for Windows Vista and later and the SDL!

As usual, questions and comments are very welcome.

On 13 August, jcorey asked about how to deal with those who firmly believe that the only answer to any security problem is to inspect everything at the edge. This is an important question, and I wanted to give Joe an answer. (You might have to scroll down when you click the previous link, it seems that linking to individual comments is broken.)

Today, 15 October, I wrote a little thesis as an answer to his question. I’m calling it out in a separate post because I want to make sure those of you with aggregators that don’t update when posts receive new comments still have a chance to reply with your thoughts. I’ll also repost it here:

jcorey-- You've nailed the biggest obstacle to deploying something like direct connect. Many security professionals have been taught that there simply is, and never will be, a process or technology that allows you to trust anything that originates from outside your corpnet. These professionals cling to this belief, and have been the cause that allowed the whole “detection” market to bloom.

Let me be clear: this total lack of trustworthiness is no longer absolutely true. Of course there will be times when unknown machines will be used by known and unknown people to access your information. But what about one particular subset -- known humans, with known portable computers -- can't we do something better than treat them as toxic invaders?

Indeed we can. And that's what I'm proposing with direct connect. The technology -- managed, of course, with the right processes -- exists so that you can extend the trust to known computers even though you don't trust the network they're connected to. This is because you have mechanisms that:

1. Allow you to configure the machine according to your requirements (domain join, group policy)

2. Dictate computer and user authentication requirements (IPsec policies, smart cards)

3. Limit what the users of these machines can do (UAC, non-admin, Forefront Client Security, Windows Firewall, even software restriction policies)

4. Validate the health of machines initiating incoming connections and remediate if necessary (NAP, System Center Configuration Manager)

5. Limit the threat of attacks against stolen computers (domain logon, smart cards, BitLocker with TPM)

With the robust authentication, validation, configuration, and control mechanisms available to you, I simply don't see that there's any need to fall back to “detection” now. Detection technologies were -- and remain -- necessary for the times when we have no clue about the health of client computers and when we had no way to gauge the intent of the users. But it is truly reflective of a head-in-the-sand mentality to assume that this is a complete description of what's capable today.

You know, someone once asked me what it takes to be a security professional. I answered that there are two primary elements: become a networking/packet wonk, and be willing to change your opinions when the right evidence comes along. Indeed, I suspect that many security folk have forgotten the need to keep their wonikness updated, which in turn makes them resist new ideas regardless of the strength of the evidence. I'm not very proud of what I just wrote, because I loathe generalities, but I'm not sure what else to think here. Sigh.

Joe’s question is important and strikes at the foundation of what it means to be a security professional today. I’m eager to continue this conversation, because it’s reflective of what I sense to be a radical shift in our jobs—we are, or should be, no longer the wolf-crying propeller-head who sits in the basement and twiddles with the firewall. Instead, our job should be defined as one who’s charged with protecting the organization’s information from attack, while maximizing its utility to authorized users, according to the principles of least privilege. Your thoughts?

h8er:  So, how does it feel to work for a company that has made so many bad security decisions.

MSFT guy:  Well, I feel lucky to be in a position to try and influence good security decisions going forward - are there any specifics you want to give me feedback on?

h8er:  All those prompts irritating people, for example.

MSFT guy:  Oh, so you don't like that aspect of UAC.  We've gotten a lot of feedback on that, but the UAC security changes in Windows Vista encompass a pretty wide range of options designed to make it easier for most users to run as non-admin.  Plus, we've incorporated some of the feedback into SP1 and I think it is a lot better.  Have you tried SP1?

h8er:  <crickets chirping in the silence>

MSFT guy: (still trying) Let me ask it a different way.  A lot of folks have said that after the first few weeks, the UAC prompts tapered off, have you not found that to be the case?

h8er:  <crickets chirping in the silence>

MSFT guy: What about some of the other changes in Windows Vista - I think the addition of ASLR, for example, was a good decision and raises the bars for attackers developing exploits.

non-MSFT guys standing nearby:  He has probably never even tried Vista - I bet you run Linux and just heard the prompt stuff second hand.

h8er:  I don't run Linux ... I run a Mac!

(NOTE: This seemed to rattle him, so he went on the offensive.)

h8er:  Don't you feel embarrassed working for Microsoft knowing that 40% of your customers are infected with Malware?

MSFT guy:  Actually, based upon research in the latest Security Intelligence Report, less than 1% of machines have malware and need corrective action - plus, recent research in the same report has shown that most of that is on older platforms and Windows Vista has an even lower incidence.  40% is a pretty high number, what source did you hear that from?

h8er:  <crickets chirping in the silence>

(NOTE:  Need a new tack, better try something different.)

h8er:  Well, I feel a lot safer running my Mac and knowing the malware writers aren't targeting me.

MSFT guy:  Oh, threat landscape is a different topic than the security of the software, but I can't really agree anyway.  Many of the folks I talk to are more concerned about spearphishing or targeted attacks specifically against their valuable data.  Recent data shows that Mac OS X has quite a higher incidence of security vulnerabilities that other comparable systems.  That means that if an attacker did target them, he'd have a lot more options to choose from.  In that case, I feel much more comfortable using or recommending Windows Vista than I would using your Mac.

He left shortly after that, but not before giving the Microsoft guy an invite to his company's party - I won't tell you which company it was, but it makes the story even funnier.  To cap it, a few minutes later, one of the bystanders came by and said "so, did the Mac fanboy get tired of harrassing you and leave?"

Having lots of fun at Black Hat 2008 ~ Jeff

At TechEd this year, I gave a presentation called "21st century networking: time to throw away your medieval gateways." (Actually, I've given this same talk before, at events in Amsterdam, Brussels, Oslo, and numerous on-campus customer meetings. It's time to bring the knowledge to the masses.)

I described an idea of using IPv6, IPsec, NAP, and group policy to build a pretty slick replacement for clunky VPN gateways. Turns out we've been piloting this very idea on our internal corpnet. Like a good little bunny I got myself enrolled in the thing and -- pardon the unattractive gushing -- this thing rawks! Here's a brief rundown of the parts you'd configure on managed clients:

• Windows Vista Business (with Software Assurance), Enterprise, or Ultimate editions
• That are domain-joined
• Users run as non-admin
• Group policy applies numerous settings
• UAC is enabled
• BitLocker is configured to protect confidential information stored offline
• The Windows Firewall is enabled
• NAP is used for checking health
• Forefront Client Security for keeping malware off the box
• Smart cards for strong authentication of users
• IPsec is required for connection authentication and traffic encryption
• IPv6 is required for worldwide Internet connectivity
• A DNS suffix search list represents the data center name space
• Static IPv6 DNS servers provide name resolution for hosts in the data center

What does this give you? True anywhere access, anywhere in the world, directly to corpnet resources from managed and secure client PCs. The Internet has replaced private WAN links for good reason: enormous cost benefits. The only thing holding us back from fully utilizing this development has been a lack of way to enforce and monitor the security of clients not physically located within the corpnet. Well, those days are over. Now you can build PCs that are trusted just as if they were on the corpnet, without knowing or caring anything about the underlying network connections. And let me tell you, it's as addictive as a few other substances I could mention, but will refrain, since this is (I hope) a family blog :)

Maybe you've heard of the notion of "deperimeterization." Taken to its extreme, I think it's a bit silly. To put a SQL Server directly on the Internet is just plain stupid -- not because I don't think I could keep it protected, but simply because that's unnecessary risk. Only my web server -- and no one else -- should be talking to my SQL Server. But that web server will be in the same subnet as the SQL Server, and IPsec policies used also here will govern who can connect to the SQL Server. Warning to any and all network DMZs: your days are numbered!

Shrink your perimeter to that which really matters -- your data center. All your clients live (as we would say in the olden days) "on the outside of the firewall." Now then, there are two kinds of clients. Managed clients, as I described above, establish IPsec-authenticated/encrypted, group-policy-configured, NAP-enforced IPv6 connections directly to corpnet resources without going through any kind of access gateway. The router connecting you to your ISP is fully sufficient for blocking denial of service attempts. Be sure to follow my advice in "Configure your router to block DOS attempts," and then add two more rules to permit incoming port udp/500 and IP protocol 50 over IPv6. That's it. No NATing or other unnatural network acts are required (finally, you can stop lying to your significant other about why you squirrel yourself away in the computer room all those weekend nights).

Unmanaged clients will continue to use IPv4 to access published Web and Win32 applications through a gateway like IAG. Since you can't trust these clients nor can you trust the data they're throwing at you, you have to inspect and validate at the perimeter. You can take advantage of IAG's application-modifying capabilities to "wrap" security around poorly-written web apps; you can even download an ActiveX control to unmanaged clients to perform some basic health checking, policy enforcement, and cache clearing. None of these eliminates the final requirement to continue inspecting and removing malware from servers where users store data: Exchange, SharePoint, Office Communications Server, and file servers.

Machines are mobile, data is mobile. The mainframes and large desktop PCs of the past posses an effective security attribute: the heaviness of the machines. You couldn't easily saunter out the front door with a PC-AT in your pocket! These days, we all line our pockets with tiny little mobile phones stuffed with 16GB of storage. It's now a fact: data moves. And like water, data moves wherever it can, as rapidly as it can, often beyond your control if you don't prepare for that. With properly-configured and managed clients we can enjoy a single access and authentication experience no matter where the computer is physically located. For example: I can sit in my house and enter '"http://internal-web-site-name" in my browser. The DNS suffix search list adds the appropriate suffix, my browser's resolver performs an IPv6 name lookup, and my computer makes an authenticated and encrypted connection, after it meets the NAP policy, directly to that internal server. Very nice. As far as I'm concerned, there's no difference between the Internet and my corpnet. It's all just there.

For a while now many of you know I've been speaking and writing, mostly at the conceptual level, about the day when such a way of remote computing will arise. Well, my friends, that day is now. You can indeed build it now, with the products you have. I won't admit it's all peaches and cream: there's a fair number of moving parts here, it's true. But most of these moving parts are parts you're already familiar with: I'm simply encouraging you to move them in a specific way. You'll need to do some custom scripting for client-side connection diagnostics, but that's about it.

My next step is to create a more detailed guide, which I plan to publish through TechNet Magazine. I'm targeting (but not promising) the October issue. The article will include greater details about configuring your infrastructure to support the managed clients I describe.

I've lost track of the swelling number of individual conference attendees and the plethora of email writers who've expressed a desire to build this in their own environments. The one common thread from everyone is "I want to do it now!" Folks, it's really pretty exciting for me to see so many of you ready to cross the chasm from the perdition of paleo-networking (layer upon endless, complex layer of DMZs) into the paradise of flat, simple, cheap, and secure access to information. If you haven't yet, please take the time to read through some of our information (especially Scott Charney's paper) on end-to-end trust. Friends, the idea I describe above is the plumbing for realizing the end-to-end trust vision.

Sorry for the lack of content yesterday. Due to a PBCAK failure to pay attention I neglected to publish write yesterday’s article. So, they’ll trickle out over the next couple days I’ll try to do better while Dave takes some time off to work on a personal project. Thanks to all of our new subscribers that joined us yesterday. Welcome!

Click here to subscribe to Liquidmatrix Security Digest!

And now, the news…

1. The Science behind 3-1-1 Mental Note - When flying this weekend, do not play the part of a vain astronaut.
2. DeCSS is now illegal in Finland Quick - jam the inflatable boat back into the travel pouch — Hurry!
3. Microsoft Whitepaper: Comparing Features - Windows XP SP3 and Vista SP1 smell the slow burn of a sweaty Ballmer
4. CFP (Computers Freedom and Privacy) Conference Roundup from Wired’s 27B/6 MmmmMmmmm… Cyberdyne me baby
5. RIM will not give Blackberry Keys to India Ahhh yes, but to which national governments (besides the Mennonites) have the boyz in Waterloo given the keys?
6. Elevator disables UAC on a per-application basis Do you want to Allow or Cancel?
7. Nottingham University Student Detained DWB (Downloading While Brown) from the US Gov’t - Go Directly to Secret Detention
8. President Bush Signs Landmark Genetic Nondiscrimination Information Act Into Law Gattaca… Gattaca… Gattaca…

More as I process it all (seriously, where the hell does Dave find the time for this every.single.day?)

Tags: News, Daily Links, Security Blog, Information Security, Security News

I was excited when Dr. Crispin Cowan joined the company a while back - what security person wouldn't be!  As one of the key drivers behind StackGuard, Linux Security Modules and co-founder of Immunix, which produced AppArmor - few people are as qualified as Dr. Cowan to talk about security features and security boundaries.

So, when he asks "Is UAC a convenience feature, or a security feature?", I would say it is worth reading at least twice.  And if my recommendation is not good enough for you, let me share this quote that might entice you to go read the whole thing:

It is correct to say that UAC’s features are convenience features, in that it is much more convenient to respond to a UAC prompt than it is to have to switch to a separate desktop, log in as an administrator to do the administrative tasks, log out and then return to your standard user session. Whether one views a UAC prompt as a convenience or a nuisance depends on whether you compare it against running as a Standard User, or against running as a full Administrator: vs. running as Standard User UAC is a convenience feature that compromises security, but vs. running as an Administrator as was the default in XP UAC is a security enhancement.

But does that mean that UAC is not a security feature? No. UAC, in all of its forms, including Silent Mode, provides some obstacles to attacks, and so so it is always a security feature. UAC in operation does nothing other than to say “no” to some access requests, and so it cannot be anything but a security feature.

Of course, it is always nice when someone shares your own opinion.  As I've said in the past, security features do not have to be perfect in order to provide security value.  UAC definitely falls into that category.  And, as is my wont, I'm now going to go off and see if I can find some (imperfect, most likely) way to measure that value...

Regards ~ Jeff

I am always bemused when Jeff Jones performs in-depth security vulnerability analysis and reports his findings, not because of the content of his findings, but because of the incredible arm-chair commentary that follows.

Jeff and I have seen and heard it all:

• "This is FUD"
• "Yeah, but it's not an apples to apples comparison"
• "How can you believe this guy? He works for Microsoft!"
• "What would Microsoft know about security?"
• "For his next trick..."
• "That chart really hits home the fact that statistics can be used to prove any side of any argument"
• "Of course he says Windows is the best, that's what he's paid to do."
• "Counting vulnerabilities is a natural way to measure security. If you're a retard."
• "The other big reason linux is more secure is many black hats LOVE open source principles"
• "Can someone please slap MSoft in the teeth"
• "I can't actually remember a time when my mac needed a patch to fix a security hole."

You get the picture. I could keep going, but I have a blog post to write!

So let's ignore raw stats for a moment, let's not compare RedHat to Mac OSX to Ubuntu to Windows Vista, because let's face it, no-one can agree on any measurement of security without getting knotted up. So let's just ignore the comparison stuff. Measuring security is a real challenge, and while we may debate the merits of vulnerability counts, right now it's the only concrete metric we have.

When Bill Gates released his Trustworthy Computing Memo in 2002, many people thought it was just a marketing stunt. It was not a marketing stunt: BillG edicts are always taken very seriously inside Microsoft. In fact, I will go one step further; the only way you make big changes in a large software company is when the boss says you have to do so. So why did Bill send the memo to all Microsoft employees? It was simple, he (and the entire senior management team for that matter) recognized Microsoft faced a problem that needed solving; the company needed to shore up the security of its products. So Bill sent his memo to get the ball rolling.

Now let's go back to Jeff's recent analysis. Cover up the Mac OS X and Linux stats for a moment so you can only see the Windows XP SP2 and Windows Vista bars. Windows Vista has had fewer security vulnerabilities than Windows XP SP2. Conventional wisdom (which is often wrong, especially when it becomes urban legend) tends to suggest that the more lines of code you have the more bugs you have. That might very well be true, and Windows Vista is certainly larger than Windows XP SP2; yet right now, we are on track for an approximately 50% reduction in vulnerabilities compared to Windows XP SP2. Think about that figure for a moment: about a 50% reduction (and that does not account for the reduction in vulnerability severity) despite the increase in code size.

So if Windows Vista has more code than Windows XP SP2, why are we seeing a reduction in vulnerabilities? Simple: the SDL! Microsoft decided to change its development practices to enforce greater security discipline. The only way you reduce security vulnerabilities is by focusing on improving code security, design security, reducing attack surface, education, tracking evolving threats, mandatory use of tools, banning known bad functionality, better compilers, better linkers, better libraries etc etc. And that is what the SDL is all about and what our team is laser-focused on.

The reason you're seeing a reduction in vulnerabilities across major Microsoft products is simple:

• Microsoft recognized it needed to improve security.
• Bill said so (as did the rest of senior management)
• Our group swung into action and helped the rest of the company come up to speed on security issues.
• The Microsoft development processes changed to adopt the SDL

You improve security by focusing on security. Not by wishing on a star. Not by believing age-old myths about "given enough eyeballs.... blah blah." If the "eyeballs" mantra were true, we'd have very few open source security bugs. But there are plenty of open source security bugs found after products ship. Hmmm, this would seem to raise some interesting question on the validity of the "enough eyeballs" belief given these hard facts.

Now let's go back to Jeff's chart for a moment. Cover the Windows columns and look at the other columns. However you want to skew or spin it, that's a lot of security vulnerabilities that needed fixing once a product had shipped. Admit it. Come on; admit it, that's a lot of bugs. I don't care how big a Linux distro is, or how many IM clients Ubuntu ships with, or the merits of UAC vs su. That's a lot of security vulnerabilities!

Now ask yourself this question - how many people involved in the development of these other products have you heard say, "Wow, we have a lot of security bugs, we really should do something systematic to fix this problem." I'll be very happy to be proved wrong, but all I hear is crickets. I see no-one else in the industry standing up and saying, "Let's fix this."

I just hear emotion, excuses and dogma.

At Microsoft, BillG's memo was a "we need to fix this" memo, and we are now seeing results, but not perfection. There will be no perfection, because no software is 100 percent secure, but progress is being made across all Microsoft products, not just Windows, because of the SDL.

Let me close with a story. A few years ago I spoke to some senior technical people from a large financial organization about software security. After visiting Microsoft they were off to visit another operating system vendor. I won't name names. The financial company was very interested in our early results, and they were encouraged by what they saw because of the SDL. I asked the most senior guy in the room to ask the other company one very simple question, "What are they doing to improve the security of their product? And by that I mean, what are they doing to reduce the chance security vulnerabilities will creep into the product in the first place? And they cannot use the word ‘Microsoft' in the reply." Two weeks later, the guy phoned me and said his company would buy Microsoft products and nothing from the other company. I asked him why. He said because all they could do was make up excuses (see the list at the start for examples!) rather than admit to having numerous critical security vulnerabilities and no process to reduce their ingress.

Ok, one more comment! I would love to see others in the industry stand up and admit there is a problem that needs solving and start doing something about it. I really, really would, because we need to secure the entire computing ecosystem. Comparing numbers is interesting, but what really matters is this: is progress being made? At Microsoft the answer is "yes" but only because BillG realized there was a problem to be solved and that is what led to the birth of the SDL.