Secure Version of Windows Created for the U.S. Air Force

I have long argued that the government should use its massive purchasing power to pressure software vendors to improve security. Seems like the U.S. Air Force has done just that:

The Air Force, on the verge of renegotiating its desktop-software contract with Microsoft, met with Ballmer and asked the company to deliver a secure configuration of Windows XP out of the box. That way, Air Force administrators wouldn’t have to spend time re-configuring, and the department would have uniform software across the board, making it easier to control and maintain patches.

Surprisingly, Microsoft quickly agreed to the plan, and Ballmer got personally involved in the project.

“He has half-a-dozen clients that he personally gets involved with, and he saw that this just made a lot of sense,” Gilligan said. “They had already done preliminary work themselves trying to identify what would be a more secure configuration. So we fine-tuned and added to that.”

The NSA got together with the National Institute of Standards and Technology, the Defense Information Systems Agency and the Center for Internet Security to decide what to lock down in the Air Force special edition.

Many of the changes were complex and technical, but Gilligan says one of the most important and simplest was an obvious fix to how Windows XP handled passwords. The Air Force insisted the system be configured so administrative passwords were unique, and different from general user passwords, preventing an average user from obtaining administrative privileges. Specifications were added to increase the length and complexity of passwords and expire them every 60 days.

It then took two years for the Air Force to catalog and test all the software applications on its networks against the new configuration to uncover conflicts. In some cases, where internally designed software interacted with Windows XP in an insecure way, they had to change the in-house software.

Now I want Microsoft to offer this configuration to everyone.

EDITED TO ADD (5/6): Microsoft responds:

Thanks for covering this topic, but unfortunately the reporter for the original article got a lot of the major facts, which you relied upon, wrong. For instance, there isn’t a special version of Windows for the Air Force. They use the same SKUs as everyone else. We didn’t deliver a special settings that only the Air Force can access. The Air Force asked us to help them to create a hardened gpos and images, which the AF could use as the standard image. We agreed to assist, as we do with any company that hires us to assist in setting their own security policy as implemented in Windows.

The work from the AF ended up morphing into the Federal Desktop Core Configuration (FDCC) recommendations maintained by NIST. There are differences, but they are essentially the same thing. NIST initially used even more secure settings in the hardening process (many of which have since been relaxed because of operational issues, and is now even closer to what the AF created).

Anyone can download the FDCC settings, documentation, and even complete images. I worked on the FDCC project for little over a year, and Aaron Margosis has been involved for many years, and continues to be involved. He offers all sorts of public knowledge and useful tools. Here, Aaron has written a couple of tools that anyone can use to apply FDCC settings to local group policy. It includes the source code, if anyone wants to customize them.

In the initial article, a lot of the other improvements, such as patching, came from the use of better tools (SCCM, etc.), and were not necessarily solely due to the changes in the base image (although that certainly didn’t hurt). So, it seems the author mixed up some of the different technology pushes and wrapped them up into a single story. He also seem to imply that this is something special and secret, but the truth is there is more openness with the FDCC program and the surrounding security outcomes than anything we’ve ever done before. Even better, there are huge agencies that have already gone first in trying to use these harden settings, and essentially been beta testers for the rest of the world. The FDCC settings may not be the best fit for every company, but it is a good model to compare against.

Let me know if you have any questions.

Roger A. Grimes, Security Architect, ACE Team, Microsoft

EDITED TO ADD (5/12): FDCC policy specs.

Tags: , , , , ,

Posted on May 6, 2009 at 6:43 AM • 62 Comments

Comments

Thomas • May 6, 2009 7:00 AM

“Now I want Microsoft to offer this configuration to everyone. ”

And I want a pony.

Microsoft hate XP worse than Linux and MacOS combined because it’s a much tougher competitor for Vista/7.

They’ll offer XP-secure to the general public just after Beelzebub wears snow-shoes to work.

marco • May 6, 2009 7:04 AM

We know that security often is a tradeoff with user-friendliness. I also assume that a Windows version that is designed for the Army assumes its users have a certain degree of security awareness.
I’m not sure I want that Windows version, neither if my dad should have it.

Alek • May 6, 2009 7:04 AM

I’m pretty sure the password quality settings are somewhere in the Group Policy editor and are available to everyone.

Paul van Brenk • May 6, 2009 7:04 AM

“In some cases, where internally designed software interacted with Windows XP in an insecure way, they had to change the in-house software.”

Available to the general public, yes… but default no thanks.

It’s ‘easy’ to change in-house software for one company to behave in a secure way… it’s a lot harder for retail software.

Ron Wilhoite • May 6, 2009 7:12 AM

Sounds like a good idea overall. But expire passwords every 60 days? Doesn’t that nearly guarantee a large number of passwords written on sticky notes attached to monitors?

brian t • May 6, 2009 7:20 AM

As Alek noted, a lot of this can already be done by means of Group Policy, and pushed out over Active Directory. May require a bit more coding to implement some of the password-checking etc. Doesn’t have to be XP only, but XP’s looking positively svelte compared to Vista, and I bet the Air Force has lots of older PCs.

JRR • May 6, 2009 7:25 AM

I hate expiring passwords. For systems where the password doesn’t expire, I use a fairly secure password. If it expires every 60 days like the domain password at work does, I pick the simplest password that will pass the rules, and just change one number in it every 60 days. It’s the opposite of what they intend, I think.

Cerebus • May 6, 2009 7:25 AM

It’s not a “special version of Windows.” It’s lockdown called the Federal Desktop Core Configuration (FDCC) and anyone can download it from NIST. (http://fdcc.nist.gov) Make sure you grab the WMI group policy objects as well, they’re a major part of the lockdown.

AF deviations from FDCC are 5 minor settings, IIRC–things like screensaver timeout.

The only special arrangement with Microsoft is the patch release agreement.

Some history:

FDCC grew out of an AF effort to standardize XP configuration beyond what was done in the Army Gold Disk. Particularly the idea was to incorporate the NSA Windows lockdown guide, all the STIG recommendations, and “best practice,” noting contradictions and getting the source documents updates as needed. This was called Standard Desktop Configuration (SDC). When OMB issued its memo that required all Federal agencies to develop a standardized image, all the DoD services collaborated on producing one. AF SDC was furthest along in development and became the baseline. Eventually other Federal agencies got interested, and the effort was moved up the chain until NIST took the helm. Ken Heitkamp was the civilian leading the AF efforts, and was given an award by GCN (I think, or was it FCW?) for this project just prior to his retirement.

— Cerebus

Cerebus • May 6, 2009 7:27 AM

Oh, and the password cycle of 60 doesn’t cause problems because the DoD is up to 95% compliance (depending on the service) with the requirement to use smartcard logon (DoD Common Access Card).

Roger • May 6, 2009 7:36 AM

@Alek:
There are password policy settings in there, but they are not very sophisticated or fine-grained. For example, you cannot specify different policies for different groups, and you cannot specify (as they apparently do here) that a password be globally unique.

There is an option to add a custom DLL to do your own acceptance checks on new passwords, but that’s far too much of a PITA for most organisations and I’ve never come across anyone actually using that obscure feature.

Roger • May 6, 2009 7:42 AM

@JRR:

I pick the simplest password that will pass the rules, and just change one number in it every 60 days. It’s the opposite of what they intend, I think.

There doesn’t seem to have been any formal studies of this aspect of password policies, but the anecdotal evidence suggests that your method is exactly what nearly everyone does!

More specifically, if you have password expiry AND a requirement to mix numbers with letters, the most common response seems to be a weak password appended with the digit 1, replaced by 2 on the first change, 3 on the second, and so on. Some people use the month number (e.g. 5 for May) to help them remember where they’re up to.

hwKeitel • May 6, 2009 8:09 AM

“The Air Force insisted the system be configured so administrative passwords were unique, and different from general user passwords, preventing an average user from obtaining administrative privileges.”

Sounds like a way to seek for admin passwords. If I change my password and the system says: “Sorry, not this password!”, I would search for the belonging admin account.
I hope this won’t be possible.

Anonymous • May 6, 2009 8:09 AM

“preventing an average user from obtaining administrative privileges”
They totally ignoring the fact that average user can still blast a hole into kernel land using a buffer overflow.

Stephen Smoogen • May 6, 2009 8:20 AM

The FDCC is not exactly the Air Force rules… The Air Force rules were used to base the FDCC but as a SANS article recently pointed out.. a system using the Air Force rules is not in strict compliance with the FDCC (or vice versa).

dubious • May 6, 2009 8:21 AM

“Specifications were added to increase the length and complexity of passwords and expire them every 60 days.”

Let me tell you what the 60 days rule does in the real world. First it annoys people, all the people in the system, six times a year. Then it makes them write down the password, because who the hell can remember a new password every two months? And then people start using the simplest passwords that they can get away with. And every two months they get a reminder that they are dumb idiots who shouldn’t be trusted to come up with a decent password. Great for morale.

How does any of this contribute to improving security?

J.D. Bertron • May 6, 2009 8:24 AM

Microsoft makes more money distributing an insecure system than a secure one. If they didn’t they would already have incorporated all the best security practices into their systems and compilers.
Thus, they won’t ever make a secure version of Windows for everyone.
To be fair, it’s not all their fault. People don’t like security because it gets in the way of their experience, so they wouldn’t buy the new ‘Windows’ if they thought it was more annoying to use. On average, people prefer a pop-up that says “You’re special and we’ve reserved a shiny laptop for you” to one that says “You’re not special, please identify yourself before we lock you out of your e-mail”.
Until security becomes easier than insecurity, that problem will never be solved.

Closing Barn Door After..... • May 6, 2009 8:33 AM

Is this not a moot point since XP is no longer supported?

Anonymous • May 6, 2009 8:36 AM

60 days password expiration remembers me of my father. yesterday, he had to change a password and so much problems finding a new one. the policy was: choose a 6-digit password. it was a web access for [my fathers job] in [country we live]. he uses the internet only for two of this web pages and some email, of course he hates things like password changes, security updates, unknown technical terms, …
I think he is the average user 😉

Former USAF Security Administrator • May 6, 2009 8:43 AM

I’m glad I left the Air Force; this product will completely eliminate the last job I had there!

For those saying most of this can already be done, you’re absolutely right. Our job was to co-ordinate configuring machines with these settings, and more specifically, detecting non-compliant computers. Sounds easy, but remember that an Air Force base can have thousands of PCs. The small base I was on in Korea had 3000; one of my stateside bases had 10000.

As for the unique password thing, I don’t think it means what everyone seems to think. We had to maintain two accounts for every administrator: one for general user stuff (e-mail and the like) and one that was a domain admin. We were not allowed to use the DA account for regular everyday stuff, in fact I think our proxy server wouldn’t allow those accounts through. This requirement is probably just to make sure two specified accounts don’t have the same password, so that admins have to maintain TWO passwords.

Windows 7 • May 6, 2009 8:46 AM

It is a pity that Ballfort didn’t apply his interest in security into Windows 7. Imagine if Ballfort said to the Air Force: “Forget XP, Windows 7 will meet all your security requirements.” TANJ.

Windows 7 • May 6, 2009 8:47 AM

Sorry . . . can’t spell. My apologies to Ballmer for calling him Ballfort.

hwKeitel • May 6, 2009 8:51 AM

@Former USAF Security Administrator
two specified accounts -> that makes sense.

anyway, MS won’t create a new windows, they are just delivering an useful configuration.

Current USAF Contractor • May 6, 2009 8:56 AM

As many have said, this is nothing special, it is simply the FDCC lock-down. The main problem Microsoft overcame was getting CIA, DIA, DISA, and NSA to agree on policy settings.

It uses Local Group Policy and a custom Password Filter DLL. The password expiration and length requirements have not been enforced for domain users.

As for usability, who likes to be prompted every time an ActiveX component tries to load.

Nyhm • May 6, 2009 9:07 AM

Instead of going through so much effort to convince the closed-source vendor to (promise to) change their software, why not use Linux and make changes in-house (or at least contract out the changes and verify)?

I know this is a common argument for OSS, but I’ve never heard a convincing explanation why the government insists on using Windows.

bob • May 6, 2009 9:08 AM

The US Government should let a contract to write a GUI OS to be used across all branches. Compete it (what the heck, let MS apply if they want) and then once a company wins it, have them write it. Publish the source code, but have a FIPS version that is trusted/tested for govt use.

Then have a maintenance contract on an annual basis to fix bugs, make patches as necessary, distribute copies to authorized users but otherwise LEAVE IT THE FRACK ALONE. No “new features”, no changes in keystrokes, no different UI; nothing that is not explicitly asked for by the customer (ie USG).

This would probably save more money than even Mr Obama can spend just in upgrade costs (ie purchasing a new version of Windows every year X 80 milllion PCs in USG; not to mention retraining everyone and working around all the new features that keep leaping out and screwing up your work when MS puts in yet another new useless undesirable capability).

ac • May 6, 2009 9:36 AM

@JRR: “If it expires every 60 days like the domain password at work does, I pick the simplest password that will pass the rules, and just change one number in it every 60 days. It’s the opposite of what they intend, I think.”

The minimum complexity can be fine. The only goal is to keep people from cracking it before it gets changed again. Most of the time it doesn’t get cracked anyway, it gets captured. In that case, complexity doesn’t matter at all, frequent changes do. And yes, it sucks but people can remember new passwords, if they have to. A security walk-through should be done periodically anyway, it should include post-its with passwords. Stop whining.

Anonymous • May 6, 2009 10:05 AM

@dubious-

I think that the current theory is that changing passwords automatically stops attackers dependent on the attacker having a password.

At one time, the change frequency had to do with crack time, but these days, if you’re worried about crack time, I’d just make the password requirements longer/more stringent.

eddie • May 6, 2009 10:22 AM

@ac: “Most of the time it doesn’t get cracked anyway, it gets captured. In that case, complexity doesn’t matter at all, frequent changes do.”

This is only true if the time between routine password changes is less than the time between password capture and system exploitation. Which is rarely the case. Which means that neither complexity nor change frequency matters – eliminating dependency on reusable passwords does.

Routinely changing passwords only protects against attackers that want continued access rather than one-time access, and that have not installed or cannot install back doors.

It can also protect against password leakage that has not yet resulted in a compromise – i.e. the password is spreading around in a careless-but-generally-benign fashion and has escaped the bounds of proper controls but hasn’t yet made it into the hands of a malicious actor.

Roy • May 6, 2009 10:35 AM

Why would anyone insist on proprietary over open-source?

Hmm. Kickbacks?

Ahem — free gifts?

This is done in the business world.

Carlo Graziani • May 6, 2009 10:36 AM

OK, someone please educate me about FDCC. Is it something you download, execute, click a few dialog “OK”s, and poof, your box is (more) secure?

I don’t do windows, and when I try unscrewing a screwed-up windows box, I usually wind up several hours later with little to show for the effort except a yearning for the Redmond, WA site to be nuked from orbit, just to make sure.

However, I would like to be able to help lock down the windows boxen of MS-afflicted friends and relatives who are, from a computing perspective, relatively naive. Is FDCC something they could install for themselves? What level of general computing and/or windows-specific knowledge is required to make it useful?

Bryan Feir • May 6, 2009 10:51 AM

@Carlo Graziani:

It sounds to me that much of this configuration is done at the Group Policy level, which is enforced via Active Directory.

Which means that it’s great for organizations with a centralized password database that everybody logs in against, but mostly useless for single machines that aren’t part of an Active Directory domain. So this won’t help your average home user at all.

josh • May 6, 2009 11:05 AM

“They totally ignoring the fact that average user can still blast a hole into kernel land using a buffer overflow. ”

Outside of third party drivers (WiFi drivers are the worst offenders) there are not a whole lot of kernel land buffer overflows in Windows. The SDL has been pretty good about applying a mix of training, coding standards, and tools to prevent new overflows and identify existing ones.

“If they didn’t they would already have incorporated all the best security practices into their systems and compilers.”

That isn’t necessarily true- security is a triad of confidentiality, integrity, and availability. You always have to make compromises to get a fair middle ground between them, and applying a general solution to specific tasks will always be lacking even if “best security practices” were followed. That said, the MS compilers are very good about using both hardware and software security features (Data execution prevention, Address space layout randomization, etc) and VS ships with some decent source analyzers out of the box (Prefast, FXCop). Each progressive version of Windows offers increasingly secure defaults (for example, autorun on flash media is removed in 7). They still worry about usability, especially in light of Apple, but the real blight in Windows security is unsecure third party apps (Acrobat, Flash, Quicktime, etc) and the basic truth that you can’t stop malware if the user intentionally (even if unaware) initiates the install. You can keep it from getting admin priviledges, but who cares, the useful paydirt is user data in their user space anyway.

“I know this is a common argument for OSS, but I’ve never heard a convincing explanation why the government insists on using Windows.”

OSS buys you exactly one thing- code auditability. It makes absolutely no assurance that the code is any good, or that vulnerabilities aren’t present. All it says is you can inspect the code yourself, and change it if you wish (license concerns permitting). The mantra of the OSS “with enough eyes all bugs are shallow” is an admission that the basic philosophy is detective and reactive, rather than preventative. Very few people are good at code review, even fewer people are good at security code review, even fewer are appreciably better than static source code analyzers, and even fewer still have spent any time on the vast majority of OSS. The linux kernal has scrutiny, so does apache, firefox to an extent (their security patching sure hasn’t slowed down, so they aren’t ahead of the curve yet), but Gnome, KDE, and Open Office (among others) don’t get the same scrutiny despite their install base and complexity. I haven’t seen much evidence that outside of a handful of projects having source code available leads to talented security code reviewers actually inspecting the code, nor have I seen any evidence that the average person looking at code can find any but the most obvious security flaws (SQL Injection, some XSS- the stuff that has obvious localized code signatures of flaws and can be detected by Static source analyzers trivially easily anyway).

Software security comes ultimately from buracracy- code can’t just be written. Instead features need to be well defined and documented, and have a security review. Architecture and design need to be specified, well defined, and documented, and have a security review, before code is written. Code needs to be written with strong coding standards that take into account security, and source analyzers need to be used to enforce the standards. Testing needs to be well defined and documented, trained to test for security. And on top of all of that you need overall product policies in place to educate the consumers of the software about security best practices concerning it, and have a strong and well developed mitigation program for when vulnerabilities are still found (you can only reduce, not eliminate, vulnerability- though you can also reduce severity with security spread at every layer).

All of this is a pain in the ass that the average code monkey wants to avoid. They like writing code, not documenting how they are going to write the code, threat model the design, and have people tell them their design is done wrong. It is hard enough to enforce in an enterprise where they can hold a paycheck over someone’s head to get them to agree. It is much more difficult in OSS because most of the people are contributing voluntarily because they like to write code, not because they like buracracy. Unless there is a strong central management enforcing such things in OSS, and unless the project has enough clout that they can mandate contributors abide by development standards, it just doesn’t happen. Hell, just find me a widely used PHP app that even enforces code comments (except for CakePHP- they actually do have code standards), much less security coding standards.

Ultimately Bruce is right, the best way to get software to be secure is for the market to demand it, and companies that want to compete in that market transfer the demands onto their engineers.

Arne • May 6, 2009 11:22 AM

It is madness to use Windows for any security critical application or task. Simply madness.

ac • May 6, 2009 11:44 AM

@eddie: “Routinely changing passwords only protects against attackers that want continued access rather than one-time access, and that have not installed or cannot install back doors.”

I agree with everything you said. But, you pick your battles, persistent threats (what the government is most concerned about) are something that can be addressed that way. Immediate privilege escalation or deeper compromise are not addressed by password changes, true, but that issue needs to be addressed elsewhere and won’t be fixed by passwords no matter the complexity or change frequency either.

Pat Cahalan • May 6, 2009 12:13 PM

@ Josh

You win the post of the day, sir. Thank you for saving me writing time. I like OSS quite a lot, but it certainly has drawbacks, like closed-source proprietary software… just different drawbacks 🙂

old guy • May 6, 2009 12:24 PM

Trying to completely secure systems on the internet as we know it is like trying to put a square block in a round hole. It isn’t ever going to happen. Someone is trying to make a bad business plan work.

Anonymous • May 6, 2009 1:03 PM

“Trying to completely secure systems on the internet as we know it is like trying to put a square block in a round hole. It isn’t ever going to happen.”

It can if you drill out the whole to make it bigger!

David • May 6, 2009 1:14 PM

@Josh: That’s not the only advantage to F/OSS. Some others are modifiability and vendor independence.

The USAF got Microsoft to do a few custom changes, that’s nice. For the same resources, the USAF could doubtless have made more changes to Linux or OpenBSD (which is intended to be secure, and has a pretty good track record). There’s lots of places too small to be worth Microsoft’s individual attention that are still large enough to maintain their own OS modification teams. After all, the NSA came up with SELinux, which can now be used on any Linux system.

The USAF can get new XP installations as long as Microsoft allows it, no longer. They will get security updates (and all the OSs I run get fairly frequent security updates) only as long as Microsoft stays interested in patching XP. If Microsoft isn’t interested in patching a particularly bad vulnerability promptly, well, that’s tough. F/OSS at least doesn’t need to have those issues, since you can always hire somebody to fix vulnerabilities on your own schedule.

I think you’re also behind the times on core F/OSS. The individual enthusiast working nights and weekends still exists, but a lot of the changes are from corporations and bureaucracies these days, such as SELinux.

I’m not real fond of the “many eyes” argument for security, since most of us don’t really know how to recognize insecure software, but it is true that more people who do know software security can look at the code. The NSA did take a hard look at Linux, for example. Further, anything that reduces bugs is likely to increase code security.

Free/Open Source Software certainly isn’t the answer to everything, but the situation is more complicated than you suggest. I think that the F/OSS model is capable of producing more secure software than the proprietary model, but that doesn’t tell us that OpenBSD or SELinux is more secure than Windows 7.

Cerebus • May 6, 2009 1:22 PM

As I said above, the password issue is moot because the AF is virtually complete with smartcard logon compliance. I.e., no-one even has a login password.

Pat Cahalan • May 6, 2009 1:56 PM

@ David

F/OSS at least doesn’t need to have those issues, since you can
always hire somebody to fix vulnerabilities on your own schedule.

This presupposes that you have the budget to do this, right?

Since most organizations (and virtually all individuals) don’t, this sort of makes the point moot. In the drive to market efficiency, you’re going to drop non-core operations in order to focus on what you do best, and hauling resources to patch the operating system you run either on the desktop or the server instead of developing or selling your product just isn’t a market reality.

I mean, I see your point (and I agree with it to some extent) but in the real world, it’s just not really relevant. Yes, you can do this with F/OSS. Hardly anybody does, and hardly anybody will.

The market will punish you for this behavior 🙂

To me, the big driver for F/OSS is the lack of lock-in to licensing schemes and platform portability. I want tech people to work on technical problems, not dropping what they’re doing to make sure we have enough CALs given the number of people who log into the Exchange server or other nonsense.

Josh • May 6, 2009 3:07 PM

@David

I was speaking specifically of security. It certainly has other business advantages (and disadvantages) and I am sorry if you thought I claimed otherwise but from a security perspective I have seen very little evidence that being open source really guarantees any security.

Its great that corporations are contributing, but just because the individual is writing code at a day job doesn’t really change the reality of contributing to the project. I also realize that Novell, Sun, and others actively also manage OSS projects (and that Sun blights every OSS project they touch- poor MySQL and Open Office) but corporate or individual, if there isn’t secure development policy integrated into the management of the project it doesn’t matter.

Yes, technically a company can hire their own developer to fix a vulnerability, and likely the open source model will fix the vulnerability faster anyway (sort of), but I am distrustful of both ideas. Companies really aren’t going to allocate resources to fix third party software (any software they didn’t write themselves is third party) as Pat pointed out, and throwing a developer unfamiliar with a code base at the problem is asking for it to be fixed wrong. As for OSS being fixed faster Firefox is a perfect example of why speed is actually a determent. Again, process is key- once a vulnerability is found a root cause analysis should be performed to identify similar vulnerabilities (if the mistake was made once, it almost certainly was made more than once) and only then all occurances of the flaw should be fixed. It should then be tested to ensure that the fix is sufficient, that similar flaws were not missed in the RCA, and that there is not a regression. Only then should it be released. I have seen this happen only very rarely in OSS and instead you get Firefox patching the same problem repeatedly because they missed another instance of the flaw or they regressed something. As an enterprise consumer of software I want two things with regards to vulnerabilities- an immediate mitigation stategy to cover my exposure and for the vulnerability to be fixed right the first time.

But really, you missed my point. I wasn’t claiming OSS was inherently less secure, or that enterprise software is inherently more secure- I was claiming that the source being made available doesn’t really buy any security other than auditability of the source (which is something- if anyone ever did it) though I will concede that hypothetically it also allows you to address vulnerabilities yourself (I do not think this happens though). Security comes from process, and I do think that process is harder to enforce in distributed open development (not impossible, just harder). Companies and OSS projects that have and enforce good security process throughout the development cycle produce more secure software. Those that don’t, produce less secure software and no amount of distributing source is going to compensate for that lack of development discipline.

In terms of openness and security it is much more beneficial to those that consume software to be able to inspect the secure development policies used in the development of software than it is to be able to inspect the source. Ironically, in this regard MS is pretty much the only really open company out there, as they have almost absolute transparancy into their SDL. I have not seen this with any other commercial or open source project though I think it behooves everyone to try and make this a trend through all forms of software, regardless of the openness of the source.

David • May 6, 2009 4:10 PM

@Pat: If you’ve got a budget somewhere between a medium corporation and the USAF, you can do a bit of tailoring. The smaller guys will, as usual, take what they can get.

@Josh: I generally agree with you, but we still have some differences. Vendor dependence is still a problem, and is at least fixable in F/OSS. Modifiability is not restricted to source code modifications, as can be seen by the numerous Linux distros. If you want something more secure than the standard Linux, use the NSA’s SELinux.

Development policies are very important, as you say, but is anybody outside Microsoft actually sure they use their SDL faithfully? (This is a genuine question. I don’t know one way or the other.) Source code auditing is second best, but you are guaranteed to be able to do it to your heart’s content, provided you have the source and can build from it. (Yes, I can be a suspicious bastard, and was once told on Slashdot that my tinfoil hat was on too tight. It’s a more desirable personality trait here.)

F/OSS produced according to strict standards would be pretty much ideal, the closest I know of right now being OpenBSD. I expect that model to win at some point, but I could be wrong and I certainly don’t know when.

Roger A. Grimes • May 6, 2009 4:20 PM

Bruce,

Thanks for covering this topic, but unfortunately the reporter for the original article got a lot of the major facts, which you relied upon, wrong. For instance, there isn’t a special version of Windows for the Air Force. They use the same SKUs as everyone else. We didn’t deliver special settings that only the Air Force can access. The Air Force asked us to help them to create hardened Group Policy objects and images, which the AF could use as the standard image. We agreed to assist, as we do with any company that hires us to assist in setting their own security policy as implemented in Windows. Most of the settings derive from the desktop security guidance we have published for several years (http://www.microsoft.com/technet/security/guidance).

The work from the AF ended up morphing into the Federal Desktop Core Configuration (FDCC) recommendations maintained by NIST. There are differences, but they are essentially the same thing. NIST initially used even more secure settings in the hardening process (many of which have since been relaxed because of operational issues, and is now even closer to what the AF created).

Anyone can download the FDCC settings, documentation, and even complete images (http://nvd.nist.gov/fdcc/index.cfm). I worked on the FDCC project for little over a year, and Aaron Margosis has been involved for many years, and continues to be involved. He offers all sorts of public knowledge and useful tools (http://blogs.msdn.com/aaron_margosis). Here (http://blogs.technet.com/fdcc), Aaron has written a couple of tools that anyone can use to apply FDCC settings to local group policy: http://blogs.technet.com/fdcc/pages/LGPO-Utilities.aspx. It includes the source code, if anyone wants to customize them.

In the initial article, a lot of the other improvements, such as patching, came from the use of better tools (SCCM, etc.), and were not necessarily solely due to the changes in the base image (although that certainly didn’t hurt). So, it seems the author mixed up some of the different technology pushes and wrapped them up into a single story, along with the out-of-left-field conspiracy theory that only USAF has access to it. He also seem to imply that this is something special and secret, but the truth is there is more openness with the FDCC program and the surrounding security outcomes than anything we’ve ever done before. Even better, there are huge agencies that have already gone first in trying to use these hardened settings, and essentially been beta testers for the rest of the world. The FDCC settings may not be the best fit for every company, but it is a good model to compare against.

Let me know if you have any questions.

Roger A. Grimes, Security Architect, ACE Team, Microsoft
Cc: Aaron Margosis, Principal Consultant, Microsoft

Thuktun • May 6, 2009 4:53 PM

“Surprisingly, Microsoft quickly agreed to the plan”

The only way this would be surprising would be if they asked Microsoft to do it for free.

How could Microsoft turn down a government contract that would lead to deeper penetration of their products into the government?

Josh • May 6, 2009 5:15 PM

“Development policies are very important, as you say, but is anybody outside Microsoft actually sure they use their SDL faithfully”

Yes, actually, because part of their philosophy is to bring in security experts and pen testers to continually evaluate their process and products. They have also consistantly brought in analysts (Gartner and such) in order to convince the world they have changed (MS adopted the SDL out of market necessity, not altruism- make no mistake about that). This is certainly more true for Windows and Office than their smaller products, but there is outside scrutiny and the outside scrutiny corraborates their assertions.

And it isn’t like the company has an iron clad retention on their employees. I worked there several years ago, managing SDL requirements and conducting security testing for my neck of the woods. I can’t claim that I am unbiased as a result, but I am reasonably self critical enough to understand my bias really is a result from watching such a thorough holistic approach lead to marked improvements in security. I’ve since moved on and been in charge of implementing a similar, if less thorough, SDL at two different enterprises and seen similar result when implied. Thus the source of my philosophy should be understandable.

Josh • May 6, 2009 5:20 PM

I really should use the preview option to proof read before posting. That should read something along the lines of “SDL at two different enterprises and seen similar resultS when APplied. “

The Imp • May 6, 2009 6:09 PM

Something I’d like to point out (it’s based on the AU Army standards, but I’d bet it means the same thing):

When they talk about the “Administrator” password, they mean the local Administrator.

What they actually do, is set it to a random value that’s hundreds of characters long.

Because, they don’t want you using a local logon; and if you do (laptops that can’t reach the server for example), they don’t want you having admin rights (where you could, for example, create new local users with insecure passwords, or load drivers, change policies, or do just about anything else that makes root privileges dangerous).

Anyway, it’s a pain… so you just use a ntpsswd CD. You’d think that they’d set a BIOS password so that you can’t boot from a CD, but that’s too much work – it can’t be set by a server at logon, and can be reset with a screwdriver. So, in other words, they still have a hole that anyone with a $0.05 CD-R can squeeze through.

Anonymous • May 6, 2009 8:37 PM

While I am thankful some work hard on making XP secure because its is really needed.

I am also disturbed by present computer security, even OpenBSD can use a lot of mods and hardening, and still will have issues in the internet field.

The internet has become a scary no-mans land. Retreating to the trenches of OpenBSD or Linux/SE, is not safe enough.

Security settings/scripts do not make a pigs ear into a gucci purse, even with OpenBSD.

Only coding for the hardware and making lots of design decisions and compromises can make the chance of an acceptable system. Point: pay computer people for custom work.

hwKeitel • May 7, 2009 3:20 AM

“…The Air Force asked us to help them to create hardened Group Policy objects and images…”
@Roger A. Grimes
A special secure windows only for gov/mil usage would be an affront and a confession. I think it is natural for a company like MS to support hardened policy. I’m totaly with you at this point.

I think the OSS discussion misses the point of the hardening subject a little bit.
The most people/companys never take a look at the code. I think an important point are free and open interfaces and standards. I don’t care about a free operating system as long as it’s good (secure, not expensive, no curious contracts, fast, …).
It think OSS has its strength where a group of people have the ability to spend money, time, know-how to create something they need. Like software for the power supply system, all the companys are interested in a well working system. OSS can also help to create a competition for a monopoly (like Firefox/IE or Linux/Win).

hwKeitel • May 7, 2009 3:25 AM

I’m unaware of software for power networks is open source, but they should think about it.

Ricky • May 7, 2009 4:53 AM

I am thankful some work hard on making XP secure because its is really needed. But I think Microsoft need to improve more security, because there are many cracker software are available, by using everyone can break the administrator password easily.

Anonymous • May 7, 2009 6:10 AM

@Thuktun “How could Microsoft turn down a government contract that would lead to deeper penetration of their products into the government?”

Without getting into either religious wars or speculation on corporate strategies that we can only guess at…I gotta call bs on this.

First – MS already HAS deep penetration on federal space.

Second – This has not been my experience with Microsoft. I’ve worked security issues with their representatives with both military and civilian federal agencies. We used existing contracting vehicles that were set up to facilitate Active Directory implementations.

The people I dealt with were remarkably capable and competent with their technology. And they didn’t phone back to corporate to see if a contract mod had to be added to their task order for my work.

Nyhm • May 7, 2009 9:12 AM

Josh> “Unless there is a strong central management enforcing such things in OSS…”

Such as the US Gov managing its own software projects?

@Josh and David: Thank you both for a very insightful read. There are certainly many complexities to the issue.

Another problem with closed-source proprietary software is dependency. The US Gov is making itself intimately dependent on MS. OSS has higher survivability.

John • May 8, 2009 4:46 PM

From a usability standpoint the SDC is the best/worst thing to happen to the AF.
(speaking from experience here)

Problem is (as with all large institutions) the SDC was designed for the lowest common denominator. Now combine that with typical military thinking. You end up in situations where you have to explain “Why you are special” When in fact you or not “special” but your job requires/utilizes features that are not common.

To expound on this the LCD for 90% of the AF is they can do their job with IE/firefox, Word, PPT, and Outlook. So for the 90% that fit in this category it’s great. God help you trying to accomplish your job/mission if you fall outside this.

Really this leads into the discussion of three critical areas we face in the military.

The first is the complete lack of understanding on the part of leadership of how technology “Actually works” i.e. experience not the vendor’s documentation / propaganda.

Second is the failure to recognize the difference between classes of networks. Secretarial, warfighting, academic, test. And attempting to configure, defend, and secure all the same.

Third is the actual implementation is (often) left in the hands of the lead integrator. Combine that with the first problem; so you have inept requirements going to a contractor who’s likely never worked in the environment their expected to design for. I wonder how well that will turn out!

Gaston • May 10, 2009 12:59 AM

Thanks to all who took the time to post. This thread has been both entertaining and informative.

Steve • April 7, 2012 4:20 AM

I can hardly believe that Military uses MS operating System ! They will be much better of with SecureBSD and there were some others that are even more secure !!! Employee doesn’t need to know of every corner of OS but does need to know how to start log in and use programs that needs to work with ! So from this point of view MS is not necessary otherwise they want to have open and vulnerable system that can be hackable to plant Trojan Horse fake data to hackers – secret services like China KGB and others that electronically sniffing arround ! Win MS nothing is secure !!!! I use MS day to day plenty and having problems to use it with browser only high interrupts system idle app do not getting desired CPU power stalled freeze’d non response app not to mention malware and viruses threads ! And that on hardware that runs blazing fast with open source but MS is playing dumb and dumber ! The only MS thing that works 1000% every time flawlesly is MS bootloader if the hardware is OK !!!! Do Military want to have MS OS to run Jet’s/Space Crafts/Rockets and other critical mission hardware ???

If one wants trouble rich life then use MS but then do not complain if it crash on critical mission taht is MS tendency to do so !!!

And now something abaut MS economic policy to the user: friend of mine have bought brand new custom hardware assembled computer with 5 core cpu and 32 GB ram ! We have installed Win XP 64 bit to have max compatibility and performance ! Guess what now he has even more problem as with old 32 bit hardware !!! That is MS ! Newer enough power and newer enough good os -forcing users to feel to buy new hardware with brand new problems !!!

Just for that we user should sue MS to provide insecure OS and coses economic disadvantage and and additional an needed expenses and day to day problematic use ! I suspect that MS with updates intentionally cripples OS as fresh install runs like hell after some updates installed getting unbelievable slow despite fast hardware !!! I have more than 10 years administrative experience with it and i’m speaking from practical experience with it not philosophizing how great it is. I have seen brand new win 7 so slow as prehistoric old 286 dos box with lack of everything !!!

And now ask me again do i want to have MS in my Car Motherboard and hand-held ???

With Anonymous on other side Military won’t be capable to secure his ass not to speaking loosing battle/war ! Microsoft is most catastrophic OS that have we seen on Earth !

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.