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:
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/ 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 StepsIf 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:
Further ReadingThe 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:
| In This Article
|