How to run Services More Securely

The path to success in service security includes understanding the nature of the services available in the networked environment and establishing procedures to protect the use of them. This topic provides some core principles that you should follow when you plan to run services securely.

Know your system

Although this recommendation seems obvious, many organizations are not fully aware of the roles and services that run on all their computers.

Use the principle of least privilege

Most security-related documentation discuss implementing the principle of least privilege. This principle is simple, but the impact of its implementation greatly increases security and reduces risk. The principle of least privilege states that you give an entity the least amount of access it requires to do its job and nothing more. In Windows Server, this principle applies to both user accounts and computer accounts because in Active Directory both user accounts and computer accounts are security principals, which means that they can both be assigned permissions and privileges.

One reason this principle works so well is that it forces you to assess your network resources and potential security risks. You must learn the access privileges that are actually needed for a given computer or user and then verify that only the required privileges are applied.

Running services more securely requires you to deploy services using a least privilege approach.

Apply the security principle of least service

The security principle of least service means, in a nutshell, if you do not absolutely require a specific Windows service, disable it. Note that we say disable the service and not simply set its startup type to Manual.

More broadly, the principle of least service states that the operating system and the network protocols available on any networked device should run only the exact services and protocols required to support the targeted deployment.

By performing this action, you not only conserve system and possibly network resources, but you also reduce the number of attack vectors a malicious user can employ to penetrate your network.

Use separate domain user accounts for services and applications

The main reasons to use dedicated domain user accounts for service accounts instead of the built-in identities are as follows:

• Using domain user accounts consistently makes it easier to manage multi-tier application infrastructures.
• By using domain user accounts as service account logons, you can more granularly audit access locally and across your network.
• Domain user accounts can be more definitively targeted with Group Policy.

Regarding Group Policy, you might want to ensure that your domain service accounts are denied the Log on Locally user right at the very least. This measure will prevent a malicious user from succeeding in an interactive logon attempt by using a breached service account.

Be vigilant regarding the Everyone and Authenticated Users groups

Everyone and Authenticated Users are dynamic security principals, which means that their membership is controlled by your network environment itself and that administrators cannot control membership to these group identities.

The Everyone identity includes all authenticated and unauthenticated network users (this includes Local Service).

The Authenticated Users identity includes all domain user and computer accounts who have successfully authenticated to Active Directory. This group includes the Local System and Network Service built-in service account identities.

Thus, a key point of security is to keep a careful eye on where and how we are assigning access permissions to these two special groups.

You can control which accounts have which system privilege by using Local Security Policy that can be accessed from the Windows Control Panel or directly from the SV Core Management Console using Tools. Local Security Policy. The relevant Local Security Policy path is Security Settings\Local Policies\User Rights Assignment. Show picture