Minimal privilege: Windows

Do not run as an administrative user

Avoid running Enterprise Server processes under an administrative account. These include well-known accounts such as Administrator and LOCAL_SYSTEM, and other members of the Administrators group.

Micro Focus offers the following specific recommendations:

Windows services

Enterprise Server includes a number of Windows services. These are typically installed to run under the LOCAL_SYSTEM account, which has administrator-level access except for certain network resources. As discussed in the topic Reducing the attack surface, services which are not needed should be stopped and disabled. Other services should be reconfigured to run under distinct user accounts created just for this purpose, with only the minimal required permissions. The service account can be changed using the Services user interface.

It is particularly important to change the accounts for services with web interfaces such as ESCWA and (if the UI is not disabled) MFDS, since web interfaces are often the first point of attack.

If you use either ESCWA or MFDS to start an enterprise server region, all the region processes with run under the same account as MFDS. So if regions will be started using one of the web interfaces, it is particularly important to create a dedicated non-administrative account for this purpose and run MFDS under that account.

Note: Accounts created to run services must have the "Log on as a service" permission assigned to them using the Local Security Policy or Domain Security Policy, depending on whether the account is a local or domain one.

Note: The service setting "Allow service to interact with the desktop" is only available for services running as LOCAL_SYSTEM. Without this setting, the enterprise server region console window cannot be displayed on the desktop unless the region is started from the command line. However, the "Allow service to interact with the desktop" setting is a significant security vulnerability in itself, so this minor usability issue will have to be tolerated.

Running Enterprise Server processes from the command line

When processes are started from the command line, they inherit the account of the shell (Windows cmd.exe, Powershell, etc.) that they were started from. Avoid starting regions and running utilities from "Administrator command prompt" windows.

IDEs

Developers often run IDEs under administrator accounts. Avoid this if possible. However, most IDE operations related to Enterprise Server interact with already-running processes, so the account used by the IDE is not inherited for most of the processing within enterprise server instance.

Check for additional privileges

In Windows, user accounts can be assigned additional security privileges regardless of whether they are members of the Administrators group. Some of these privileges are "administrator equivalent": if a process holds the privilege, it can leverage it to gain administrator-level access. Other privileges can be exploited in ways which are not equivalent to full administrator access but are still dangerous.

The privileges assigned to an account can be viewed and changed using the Local Security Policy and Domain Security Policy user interfaces (and various scripting mechanisms, etc.). This is a standard task in Windows system administration.

Some privileges which are commonly assigned to user accounts and are particularly sensitive:

Back up files and directories

This allows a process to bypass file permissions to read files. It could be used to exfiltrate sensitive data, discover passwords, etc.

Create symbolic links

This could be abused to cause processes to load malicious versions of DLLs, for example.

Debug programs

This is equivalent to having administrator access, since it can be used to inject code into arbitrary processes and run it. It is not necessary to hold this privilege to debug programs running under your own account, so developer accounts should not routinely hold it.

Load and unload device drivers

The ability to load arbitrary device drivers is equivalent to having administrative access if the attacker can put a malicious device-driver module on the system.

Replace a process level token

In some circumstances (how this process interacts with Windows security is complex), this may allow an attacker to start a process under a different user account.

Restore files and directories

Ths allows a process to bypass file permissions to write files. It is equivalent to having administrator-level access, since an attacker can overwrite sensitive program files with arbitrary code.

Take ownership of files or other objects

This privilege is equivalent to having administrator-level access, since ownership implies full access to an object.

Secondary aspects of privilege on Windows

There are additional ways to prevent programs from taking undesirable actions on Windows. These are less critical than administrator access and security privileges, but organizations which are particularly security-conscious may want to review them.

Network file sharing

Windows File Sharing is account-specific. Remove unneeded persistent shares and mounts from the account(s) used for Enterprise Server processes.

Access to devices

Windows Group Policy can be used to restrict access to printers and other devices, in cases where it's not required.

Program path

Set the PATH environment variable to include only the necessary directories. Sometimes a vulnerability lets an attacker control the name of a program being executed, but not the full path to it; or lets an attacker place malware in a well-known directory which may be on the path unnecessarily.