Rule 7: Applying the Principle of Least Privilege
What can you expect from this document:
This document covers some basic security best practices that, if combined with other security measures, will help to increase the overall security of your system.
What is the threat?
Recent advances in networking technology, such as permanent connectivity to the Internet, have brought enormous opportunities to organizations of all sizes. Unfortunately, a connection between a computer and any network, especially the Internet, increases the level of risk associated with malicious software (malware) and external attackers. As old and well-known risks are managed, new ones are discovered or created.
A significant factor that increases the malware risks is the tendency to give users administrative rights on their client computers. When users or administrators logs on with administrative rights, any programs they run will have administrative rights, too. If these programs activate a malware, that malware can install itself. Furthermore, it can manipulate services such as antivirus programs, and even hide from the user. Users can run malware unintentionally and unknowingly, e.g., by visiting a compromised Web site or by clicking a link in an e-mail message.
Malware poses numerous threats to organizations, from intercepting a user's logon credentials with a keystroke logger to achieving complete control over a computer or an entire network by using a rootkit. Malware can render websites inaccessible, destroy or corrupt data, and format hard disks. Malware infection can cause additional costs for disinfecting computers, restoring files, or re-entering lost data. Virus attacks can also cause project teams to miss deadlines, leading to breach of contract or loss of customer confidence. Organizations that are subject to regulatory compliance can be prosecuted and fined.
The Least-Privileged User Account Approach
A defense-in-depth strategy, with overlapping layers of security, is the best way to counter these threats. The least-privileged user account (LUA) approach is an important part of this defensive strategy. The LUA approach requires that users are given only those privileges which are essential for their work. This strategy also aims to limit the use of administrative credentials to administrators.
The LUA approach can significantly mitigate the malware risks and the risks associated to incorrect configurations done accidentally. On the other hand, the LUA approach can generate significant costs and challenges, because it requires you to plan, test, and support limited access configurations.These costs can include the redevelopment of custom programs, changes to operational procedures, and the deployment of additional tools.
Least Privileges for You
Only use the permissions you need for accomplishing a specific task. Example: create a user with limited privileges for daily tasks and only use an administrative account when really needed.
Least Privileges for Services
The Service Control Manager (SCM) component assigns service privileges according to the privilege information specified in a service’s RequiredPrivileges registry entry. The SCM ensures that only the privileges specified in the service’s RequiredPrivileges entry are enabled in the access token of the process that hosts the service. The SCM also enforces the RequiredPrivileges settings beyond system startup by ensuring that a service can't be given additional privileges while it's running. All services’ configuration information is stored in the registry's
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services key, which has a subkey for each service that runs on your system.
Example: You create a service called MyService and set it to execute in the security context of the local system account (i.e., MyService’s service account). On Windows Server 2012, you can specify that MyService requires only the ‘Backup files and directories’ user right by including this right in the service’s RequiredPrivileges registry entry. When the SCM starts MyService, it will enable only the ‘Backup files and directories’ user right in the access token of the process that hosts MyService. In earlier Windows versions, the hosting process had an access token that enabled all the default privileges granted to the local system account. The local system account is is a predefined local account used by the Service Control Manager. It has full access to the computer. Services have complete, unrestricted access to local resources if they run under the local system account.
To set a service’s RequiredPrivileges registry entry and specify the rights that the service should have, you can use the SC commands. To restrict MyService’s rights, enter the command:
sc privs MyService SeBackupPrivilege
To get an overview of the required rights as they are specified in a service’s RequiredPrivileges registry entry, enter the command:
sc qprivs service_name
Note: service_name is the name of the service whose rights you want to see. This example illustrates the required rights as they are specified in the registry for the IIS webserver (W3SVC) service.
To observe the effect of filtering the SCM’s rights, you can use the Windows Sysinternals Process Explorer tool.
- Start Process Explorer.
- Right-click on a process.
- Click Properties.
- Click the Security tab.
The next example shows the security properties of the winlogon process, as they appear in the Process Explorer. Note that although Winlogon runs in the security context of the local system account (NTAuthority\System), its access token contains several rights that are disabled thanks to the least-privilege restrictions.
To gain a solid understanding on this subject, it is highly recommended to read the articles listed in the section below.
- rinciple of Least Privilege: https://en.wikipedia.org/wiki/Principle_of_least_privilege
- Securing Windows Server 2012R2: https://technet.microsoft.com/en-us/library/hh831360.aspx
- Windows Service Hardening: https://blogs.technet.microsoft.com/askperf/2008/02/03/ws2008-windows-service-hardening/
- Implementing Least Privilege Administration Models: https://technet.microsoft.com/en-us/library/dn487450.aspx
- Process Explorer: https://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
The contribution provided by Microsoft is intended to serve general information purposes and the content is AS IS without any express or implied warranties of any kind with respect to the accuracy, correctness or reliability. The information is provided without any warranty of fitness for a particular purpose. The information is compiled with the necessary care, however no liability is assumed in this respect, in particular with regard to the absence of errors, topicality with regard to the specific state of knowledge or use as the basis for the responsible decisions of the user.
Content provided by 1&1