Microsoft Security Templates and Group Policies

Microsoft security templates are text files designed to apply specific policies to individual computer systems. Templates are great tools for hardening Microsoft servers to a specific standard. Templates may also be used to analyze the server’s configuration, providing an audit report of where the server’s configuration does not match the template. The tool for applying the text template (stored as an *.inf file) is the Microsoft Management Counsel snap-in called “Security Configuration and Analysis” (SCA). With SCA, you may import a template, then either apply it to the computer or perform an analysis.

Unfortunately, the ability to export or print the results of the audit is very limited. While the graphical output of the security analysis lists the computer and template standards separately, the log file only lists the fact that a discrepancy exists. If the server is actually more secure than the template, it is still a discrepancy. If the names in a list are in different orders, it is shown as a discrepancy, even if for all practical purposes the result is identical.

Superficially, security templates function a bit like Bastille for Linux. It’s a standard template for applying policies to a single system. It can also audit for compliance with those policies.

In Windows, the options specified in the template end up being applied to the local security policy. You can see this by looking at the Local Computer Policy snap-in after applying the template. All the values in the template are now part of the local system policy.

Now suppose the machine is part of a domain. The domain policy will overwrite the local system policy! The template that has just been applied to the server will vanish. If the domain policies are weaker than the template policies, the template policies will be rolled back. The same holds true if the server is part of an organizational unit – though an OU must be deliberately created, while every Active Directory implementation has a domain with a default domain security policy. The policies in the template must be consistent with those in the domain and the OU.

Standard security templates are available from a variety of sources. I advocate using those provided by Microsoft. I make an assumption that these have been reasonably well tested and will likely not break applications. The templates are provided in the Windows Server 2003 Security Guide, found at :
http://www.microsoft.com/technet/security/prodtech/windowsserver2003/W2003HG/SGCH00.mspx.

The templates are actually not designed to be applied to individual servers. They are intended to be applied to the domain and to various OUs holding servers of different types. An OU is defined for IIS servers, another for file servers, and so forth. A server can have three templates applying security policies – a domain policy, a member server OU policy, then another OU for the type of server. If your environment does not have this domain and OU structure, you can still apply the templates by hand, one at a time, to individual servers.

Security templates are not really the equivalent of the hardening scripts used in the Unix world. The cannot be applied to servers at once, one at a time, in isolation from other servers – at least not if the servers are members of a domain. Active Directory provides flexibility and power to enforcing policies. You will be assured that every server in the OU follows the same security policy. If the policy changes, it will automatically change for all applicable servers. The disadvantage is that it becomes harder to isolate changes to a subset of servers. You may not want to change the policy for all servers in a domain or OU – you may only want to change one server’s policy.

Gartner Over Hypes Insecure Technologies

The latest news is that the renowned pundits, the Gartner Group, believe that the security community has "over hyped" several security threats. The fear of security risks, in Gartner's opinion, is causing companies to avoid deploying technologies with clear business benefits.

Quoting from the SC Magazine article (http://www.scmagazine.com/news/index.cfm?fuseaction=newsDetails&newsUID=549bd799-f520-4ee1-a411-bcb45b81620f&newsType=Latest%20News):

Unsafe Internet Protocol (IP) telephony, dangerous mobile malware, "Warhol worms", regulatory compliance and unsafe wireless hot spots were named by the company as the security threats that caused users most problems, because vendors exaggerate the dangers.

In most cases, Gartner argued that the benefits of adopting new technologies, such as IP telephony, far outweighed the actual dangers.

Gartner then goes on to say these technologies can be properly secured and, if so, businesses can realize the benefits without taking undue risks. Well, duh, properly secured of course these technologies are likely not to present any unusual risks. I remember a comic making a point about ads claiming certain dessert products were delicious with strawberries and cream. Replied the comic, "Even old mattress tacking would taste good with strawberries and cream".

The problem is that companies implementing these technologies are not properly securing them, that efforts of information security professionals to enforce proper security are ignored, stonewalled, or overridden by management. By downplaying security concerns, Gartner is effectively encouraging company management to continue implementing these technologies with inadequate protection.

I will look at the specific examples of wireless 802.11 LANs (“wireless fidelity” known as Wi-Fi) and of Voice Over IP (VoIP).

Running Wi-Fi with IPSec has always been considered secure, as far as eavesdropping and traffic modification goes. Actually setting up and managing IPSec can be difficult, it and certainly requires some technical background in the subject. The reality of organizational Wi-Fi deployment suggests most installations are blindly ignoring security practices. Most new Wi-Fi deployments are maverick installations, where someone just goes to Best Buy, gets an access point, sets it up on their desktop computer, and hopes nobody from IT notices. No WEP, default SSID, etc. - perfect for war drivers. Even when deployed by IT, configuring IPSec (or other secure transports) can be difficult, and is often skipped in the interests of getting it running. Management wants their laptops to work in conference rooms without cumbersome wires, and they want it NOW!

I am very concerned about Gartner's dismissal of wiretapping concerns with VoIP. Tools for re-assembling this traffic and creating audio files are out there (one with the appealing name of "VoMIT" is part of standard BSD port trees). Putting voice traffic in its own VLAN is an obstacle to eavesdropping but not a protection measure. VLANs can be compromised and their misconfiguration can expose VoIP traffic without an actual attack. VLANS were meant to separate traffic for collision management purposes. VLANs were never intended to be a primary security protection measure. FYI, a good paper from Cisco on VLAN security best practices may be found at http://www.cisco.com/warp/public/cc/pd/si/casi/ca6000/prodlit/vlnwp_wp.pdf.

There are secondary concerns with VoIP that must be addressed in terms of the authenticity of calls, and the extent everyday business trusts certain types of phone communication. Thanks to VoIP, anyone with a DSL line and a bit of Linux expertise can set up a PBX, spoof caller ID information, and generally have a lot of fun with call routing functions. I suspect we are on the verge of a new phishing epidemic, where social engineering attacks are supported by sophisticated telecom technology. All the old 1970's phone phreaking tricks may suddenly become popular again. An article in New Scientist (March 5, 2005, http://www.newscientist.com/channel/info-tech/electronic-threats/dn7136) addresses these issues.

Security problem with new technologies often do not manifest themselves until many years after the technology has been adopted. The prototype of the information gathering Trojan horse program was demonstrated by the German Chaos Computer Club in 1996 (see http://www.iks-jena.de/mitarb/lutz/security/activex.pe.clari.html). Using a rogue ActiveX program, they were able to devise a Web site that would steal end user information from Quicken. The theoretical danger from this program was well demonstrated. It took a few years until these malicious programs became a serious concern. Any new technology requires a certain critical level of installed base before mass exploitation becomes feasible. Until then, it looks like security concerns are over hyped.

New technologies are often the ones that organizations have the most difficulty in securing. There is an urgency to deploying new technologies that counters the thoughtful, deliberate approach necessary for good security. New "must have" technologies are often driven by non-technical business groups, who are motivated to downplay threats. Even where an IT group is implementing the technology, proper security requires "out of box" thinking that is rare to find. A voice telecom group familiar with traditional PBX technology likely is not familiar with the security threats in an IP-based VoIP product that uses shared media.

By calling security concerns "hype", Gartner is doing a dis-service to legitimate security concerns.

Server Hardening thoughts

I'm developing hardening procedures for various types of Windows and *nix servers - specifically Win 2000 server, Win 2003 server, AIX 5.3, and Red Hat AS 3.0.

A hardening document is part procedures "cookbook" and part standards document. The procedures consist of a core of technical procedures for reconfiguring the server. Surrounding this core are the pre-hardening procedures for server inventory management and the post-hardening procedures for deployment, secure management, and periodic security assessment. I consider the asset and inventory management to be just as important as the technical hardening. If you don't know where it is, you don't know if it is secure or not.

The technical hardening piece relies on published, reputable security standards. Good sources for these include SANS, the NSA, NIST, and the Center for Internet Security. As much as possible, I like to use standards provided by the server's vendor. Vendor-provided standards have credibility with server administrators. This helps in acceptance of the standards. Vendors presumably know how hard to push hardening before commonly used applications "break". I assume if Microsoft says to configure something in Windows 2003, then most Microsoft applications can live with this. Finally, in large organizations, there is a support contract with the vendor. If there is a problem with a vendor-recommended security setting, then a trouble ticket can be opened up to resolve the issue.

As much as possible, I make sure the hardening recommendations reflect the most current operating system version. I noted some significant differences between Red Hat Enterprise 3.0 and the version 4.0. The hardening documents for these two reflect these differences. For example, version 4.0 allows for enabling SELinux in the installation procedure, while 3.0 does not.

I make each step in the hardening document as clear as possible. If certain services are to be disabled, I list every single one of them, along with the relevant command. I avoid vague generalities, such as "eliminate unnecessary services". I want to eliminate wiggle room for the system administrator. System administrators are under tremendous time pressure, and often are forced to make performance and flexibility their priorities rather than security. Specificity is necessary to ensure the job gets done.

Along with specificity must come an escape valve for cases where the standard hardening configuration will not work with specific applications. The reason for a variance must be documented and approved by the information security manager. The exception process should discourage trivial variances, but should not be so onerous that there is a strong temptation to ignore or bypass the requirements. Ultimately, the purpose of exception documentation is to maintain known security configuration documentation. In the event a new vulnerability is found, the information security manager can establish which servers are vulnerable and how they must be corrected.

I see the purpose of hardening standards as not so much providing the best security as providing consistent, documented security. Servers do not need to be impenetrable, they need to be manageable.