Unified Hardening Guidance for the U.S. Government

All U.S. Government computers are finally required to conform to one of two configurations. White House Memo M-07-11, further clarified in M-07-18 directs all government agencies to use a single hardening guide. M-07-18 clarifies that it is to be the NIST guide.

Overall, this is welcome news. The agencies finally will have an argument against the army of Nessus-armed "auditors" they have been battling with for years. Finally, they can point to something when said "auditor" claims they would be negligent unless they replace Everyone with Authenticated Users throughout the file system, and disable the netlogon service. 

Of course, there is one thing that bothers me a bit. There are only two levels in the NIST guide. The Enterprise level (let's hope that's what they all chose to use) and the Specialized Security Limited Functionality (SSLF) level. Notwithstanding the warnings about the SSLF level breaking things, it is a sure bet the "auditors" will demand that it be used throughout. Whether a system is embedded Windows running a gas pump at Baghram Air Force Base, or the receptionist's computer at the Bureau of Indian Affairs office in Winnebago, or a signals processing computer in one of the unmentionable intelligence agencies, you can bet that the report will require the SSLF configuration. That's a battle that still remains.

Still, this really is a good thing all around. The U.S. Government today has hundreds, if not thousands, of configurations, and lose thousands, if not hundreds of thousands, of computers every year to unsupportable security settings and attacks that were successful because of bad settings. It is also a dream come true for Microsoft, which can now focus support for the largest set of customers it has on two well-defined configurations. It also is wonderful to see recommended language in M-07-18 that specifies that users should run with least privilege and sets requirements on applications for how they should work. Finally, two of the biggest sources of security headaches have a mandate to be fixed.

The only thing one might wish now is that the Vista Security Guide were cleaned up a bit. For instance, the settings which do not exist on Vista could be removed. That would mean we finally have a government configuration that makes sense.

Published 03 July 2007 05:51 PM by jesper
Filed under: ,

Comments

# ITG said on 04 July, 2007 05:17 AM

Hi Jesper and thanks for all your valuable insights in information security. I always find your posts very interesting.

This time, however, I find it quite in contrast with what I understood from your presentations with Steve Riley and from your excellent PYWN (e.g. chapter 12, Security Configuration Myths). I've always thought that you are not fond of one-size-fits-all security solutions and that configuration guides were among them. Am I missing something?

# jesper said on 04 July, 2007 07:26 AM

You're right. I do not believe in one-size-fits-all security guidance. That is why I comment on the fact that there are only two levels in the guide, and that those two levels will not provide optimal security for all computers.

However, in this case, I think that the drawback of using one (or two) different security configurations for millions of computers is greatly outweighed by the benefits of clear requirements. The current state is that there are hundreds of different configurations used in the U.S. government, most of which have no grounding in realistic threat analysis. Many of these cause the systems to not function properly in some way, and most create unsupported configurations. The free-for-all in the current state means that everyone who fancies themselves a security expert is free to invent their own configuration, far too often without significant experience or understanding of neither the threats nor the operating system itself.

At least this way there will be a known state for all computers, and system administrators, application developers, and support personnel, know what to expect.

You will never get an optimal security configuration from a one-size-fits-all guide, like the one now required in the U.S. Government. You will always get a better configuration if a competent analyst performs detailed analysis on the threats facing the systems and the risks you are willing to accept. The problem is finding those competent analysts. If there is one thing I would like to see it would be what the characteristics of such a competent analyst would be. It is decidedly NOT someone with no more experience than just finishing his first week at a security conference and passing a certification exam.

You need to weigh the one-size-fits-all problem against where else you can spend your time in security. As bad as the one-size-fits-all really is, it frees us up to do more important things. The fact is that most of the interesting attacks are no longer against systems or configurations. They are based on missing patches, users who run as admins and click on everything, and poorly managed networks. My hope is that by removing the arguments about which set of security configurations individual systems should have the focus will shift to those areas instead, which will have a far larger impact on security than one or two additional registry tweaks. In essence, I would say requiring a single guide is good because it has the potential to refocus the discussion to much more important areas.

It was also encouraging that the second memo made specific recommendations regarding least privilege, patches, and how applications should work. Those things are good, and have much more potential impact on security than the arguments about whether the RestrictAnonymousSAM setting should be set to 0 or 1.

# Jack Sweeney said on 06 July, 2007 07:49 AM

Jesper, you make a good point with the two configurations, only having two. Before we were working we had no real guidence other that our network team would run hacking programs against our machines and would send us reports on the vulnerabilities. Working for the government I have a good insight to the different configurations we have to deal with.  I am looking at the guideline configuations as a base point to start with to secure the equipment. We setup a machine, apply all patches and security configurations befor applying the application configurations. Any special configurations based on the function of the equipment can then be considered before making the change to the security.  Just as our firewall is set up, special applications must have a justification to open ports or protocols and so should we be doing with the security configuration.  Sometimes the security settings can be a little tricky, allowing acces to one thing and blocking from another with current settings in place.  

# Karl Levinson said on 26 July, 2007 08:01 PM

The first paragraph of the second OMB memo seems to state that it applies not to all Federal computers, but only to those that are running Windows XP or Windows Vista workstations.  Other workstation and server OSes are exempt for now.

You mention concern about protecting competent government system owners from incompetent auditors... the reverse is just as often true.  Certainly what is needed is more specific guidance to both protect the system owners and to guide them in the right direction.  Unfortunately, the NIST guidance such as SP800-68 for XP does not provide enough clarity.  Many items are optional recommendations, or the specific settings are left up to the agency to decide.  Page 7-18 of this guide seems to suggest disabling TCP 445 as being an unnecessary service, I'm not sure that's sound advice.  

Maybe worst of all, Nessus auditors will turn to using the NIST group policy template to audit workstation compliance.  Every difference with that template will register as non-compliance, even when settings are more restrictive than required.  Nessus at least is more accurate in detection, and it checks for missing patches, which the NIST document and template do not.

Leave a Comment

(required) 
(required) 
(optional)
(required)