Services and Service Accounts Security Planning Guide

Chapter 4 - Summary

Updated: June 30, 2005

In the past, developers based network operating systems on the premise that access was the priority, and in the past, for most organizations, this was true. If users could not access the resources or run the services they needed, they lost productivity. The need for easy access and simple-to-run services outweighed the risks associated with intrusions or attacks. However, the increased prevalence and sophistication of malicious code and virus writers has raised the stakes. Now, for most organizations, security is the top priority.

Previously, applications and services were typically installed in an enterprise environment with the highest possible permissions to ensure full functionality.

Historically, this was due to a number of factors:

Software vendors, including Microsoft, did not have a complete vision of customer network environments.

Customers had products from different software vendors that required interoperability.

Assumption that the users who installed applications and the users who ran them were the same people.

However, these factors also meant that organizations granted service accounts much higher privilege levels than was necessary and meant that applications and services became a prime vulnerability point for attackers to target.

This issue has been somewhat addressed by independent software vendors (ISVs) through the greater integration of role-based security within applications that use the Microsoft® .NET Framework and development environments such as Microsoft Visual Studio® 2005.

Microsoft has also addressed the issue with some big changes in its latest operating system, Microsoft Windows Server™ 2003. The out-of-the-box settings in Windows Server 2003 make the operating system more secure from the outset.

Changes to the operating system include differences in the default permissions for both shared folder and file resources, changes to the membership of the Everyone group, changes to ownership of objects, changes to the default settings for common services and changes in the authentication process.

For more information about the how default security settings in Windows Server 2003 differ from earlier versions of Windows, see the Differences in default security settings topic at www.microsoft.com/resources/documentation/WindowsServ/
2003/datacenter/proddocs/en-us/windows_security_differences.asp.

Services remain prime vulnerability points for attackers, and services that run with too much privilege represent particularly high risks. If you do not need to use a particular service, disable it. If you disable unnecessary services, you immediately reduce the attack surface for the network. Services that do not authenticate clients or that use protocols that are not secure also represent a high risk. For more information, see the Server and Domain Isolation Using IPsec and Group Policy guide at http://go.microsoft.com/fwlink/?linkid=33945.

For required services, identify a process whereby administrators identify which Windows services use elevated privileges, establish the lowest possible privileges needed to run them, and then redeploy them with lower level privileges, as appropriate.

On This Page
Next StepsNext Steps
Further ReadingFurther Reading

Next Steps

If an organization has not yet deployed a program that defines how to run services securely, this planning guide provides a foundation for such project planning.

The main steps that organizations need to take when planning how to run services securely are:  

Define a process to identify the existing privilege levels of Windows services.

Identify a methodical way to establish the lowest privilege level at which any given service will run.

Define a systematic way to lower the privileges given to non-default services with minimal impact on the production environment.

Further Reading

The integrity of a program that runs services securely is dependent on its long-term maintenance. The Microsoft Operations Framework (MOF) covers general information about operational best practices. For more information about MOF, see the Microsoft Operations Framework site at www.microsoft.com/technet/itsolutions/cits/mo/mof/default.mspx.

This guide is essentially composed of a series of best practices. For additional best practice considerations for running services securely, see the following resources:

For more information about system services for Windows Server 2003, see Chapter 7, "System Services," of the Threats and Countermeasures Guide at www.microsoft.com/technet/security/
topics/serversecurity/tcg/tcgch00.mspx.

For more information about how Windows Server 2003 with Service Pack 1 enhances security, increases reliability, and simplifies administration, see the Windows Server 2003 Service Pack 1 site at www.microsoft.com/windowsserver2003/downloads/
servicepacks/sp1/default.mspx

For more information about how Windows Server 2003 uses Group Policy and the Active Directory® services infrastructure, see Group Policy in Windows Server 2003 at www.microsoft.com/windowsserver2003/
technologies/management/grouppolicy/default.mspx.

For more information about MBSA, see the Microsoft Baseline Security Analyzer (MBSA) site at www.microsoft.com/technet/security/tools/mbsahome.mspx.

For more information about Windows Management Instrumentation, see:

WMI: Introduction to Windows Management Instrumentation at www.microsoft.com/whdc/system/pnppwr/wmi/WMI-intro.mspx

Windows Management Instrumentation overview at www.microsoft.com/windows2000/en/server
/help/windows_WMI_overview.htm?id=751

For more information about security in current Windows operating systems, see:

Windows 2000 Security Hardening Guide at http://go.microsoft.com/fwlink/?LinkID=22380

Windows Server 2003 Security Guide at http://go.microsoft.com/fwlink/?LinkId=14845

Windows XP Security Guide at http://go.microsoft.com/fwlink/?LinkId=14839

Service overview and network port requirements for the Windows Server system at http://support.microsoft.com/?kbid=832017


**
**