Standard Operating Environments
Allowing users to setup, configure and maintain their own workstations or servers can create an inconsistent environment where particular workstations or servers are more vulnerable than others. This type of environment can easily allow an adversary to gain an initial foothold on a network. A Standard Operating Environment (SOE) is a standardised implementation of an operation system and applications and is designed to ensure a consistent and secure baseline.
When SOEs are obtained from third parties, such as service providers, there are additional supply chain risks that should be considered, such as the accidental or deliberate inclusion of malicious content or configurations. To reduce the likelihood of such occurrences, organisations should not only obtain their SOEs from trusted sources but also scan them before use to ensure their integrity.
As the configuration of operating environments will naturally change over time (e.g. patches are applied, configurations are changed, and applications are added or removed) it is essential that SOEs are reviewed and updated at least annually to ensure that an updated baseline is maintained.
Security Control: 1406; Revision: 2; Updated: Aug-20; Applicability: O, P, S, TS
SOEs are used for workstations and servers.
Security Control: 1608; Revision: 0; Updated: Aug-20; Applicability: O, P, S, TS
SOEs provided by third parties are scanned for malicious content and configurations before being used.
Security Control: 1588; Revision: 0; Updated: Aug-20; Applicability: O, P, S, TS
SOEs are reviewed and updated at least annually.
Operating system versions
Newer versions of operating systems often introduce improvements in security functionality over older versions. This can make it more difficult for an adversary to craft reliable exploits for security vulnerabilities they discover. Using older versions of operating systems, especially those no longer supported by vendors, exposes organisations to exploitation techniques that have since been mitigated in newer versions of operating systems.
The x64 (64-bit) versions of Microsoft Windows include additional security functionality that the x86 (32-bit) versions lack. Using x86 (32-bit) versions of Microsoft Windows exposes organisations to exploitation techniques mitigated by x64 (64-bit) versions of Microsoft Windows.
Security Control: 1407; Revision: 3; Updated: Sep-18; Applicability: O, P, S, TS
The latest version (N), or N-1 version, of an operating system is used for SOEs.
Security Control: 1408; Revision: 3; Updated: Sep-18; Applicability: O, P, S, TS
When developing a Microsoft Windows SOE, the 64-bit version of the operating system is used.
Operating system configuration
When operating systems are deployed in their default state it can easily lead to an unsafe operating environment allowing an adversary to gain an initial foothold on a network. Many options exist within operating systems to allow them to be configured in a secure state to minimise this security risk. The Australian Cyber Security Centre (ACSC) produces guidance to assist in securely configuring various operating systems.
Security Control: 1409; Revision: 1; Updated: Sep-18; Applicability: O, P, S, TS
ACSC and vendor guidance is implemented to assist in hardening the configuration of operating systems.
Security Control: 0383; Revision: 6; Updated: Sep-18; Applicability: O, P, S, TS
Default operating system accounts are disabled, renamed or have their passphrase changed.
Security Control: 0380; Revision: 7; Updated: Sep-18; Applicability: O, P, S, TS
Unneeded operating system accounts, software, components, services and functionality are removed or disabled.
Security Control: 1584; Revision: 0; Updated: Aug-20; Applicability: O, P, S, TS
Standard users are prevented from bypassing, disabling or modifying security functionality of operating systems.
Security Control: 1491; Revision: 1; Updated: Oct-20; Applicability: O, P, S, TS
Standard users are prevented from running script execution engines in Microsoft Windows, including:
- Windows Script Host (cscript.exe and wscript.exe)
- PowerShell (powershell.exe, powershell_ise.exe and pwsh.exe)
- Command Prompt (cmd.exe)
- Windows Management Instrumentation (wmic.exe)
- Microsoft HTML Application Host (mshta.exe).
Local administrator accounts
When local administrator accounts are used with common account names and passphrases, it can allow an adversary that compromises these credentials on one workstation or server to easily transfer across a network to other workstations or servers.
Security Control: 1410; Revision: 1; Updated: Sep-18; Applicability: O, P, S, TS
Local administrator accounts are disabled; alternatively, passphrases that are random and unique for each device’s local administrator account are used.
Security Control: 1469; Revision: 1; Updated: Sep-18; Applicability: O, P, S, TS
Unique domain accounts with local administrative privileges, but without domain administrative privileges, are used for workstation and server management.
While the ability to install any application may be a business requirement for users, this privilege can be exploited by an adversary who can email a malicious application, or host it on a compromised website, and use social engineering techniques to convince users into installing it. Even if privileged access is required to install applications, users will often use their privileged access if they believe, or can be convinced that, the requirement to install the application is legitimate. Additionally, if applications are configured to install using elevated privileges, an adversary can exploit this by creating a Windows Installer installation package to create a new account that belongs to the local administrators group. One way to manage this security risk is to allow users to install vetted and approved applications from organisation-managed software repositories or from trusted application marketplaces.
Security Control: 1592; Revision: 0; Updated: Aug-20; Applicability: O, P, S, TS
Users do not have the ability to install unapproved software.
Security Control: 0382; Revision: 6; Updated: Aug-20; Applicability: O, P, S, TS
Users do not have the ability to uninstall or disable approved software.
An adversary can email malicious code, or host malicious code on a compromised website, and use social engineering techniques to convince users into executing it. Such malicious code often aims to exploit security vulnerabilities in existing applications and does not need to be installed to be successful. Application control can be an extremely effective mechanism in not only preventing malicious code from executing, but also ensuring only approved applications can be installed.
When developing application control rules, defining a list of approved executables (e.g. .exe and .com files), software libraries (e.g. .dll and.ocx files), scripts (e.g. .ps1, .bat, .cmd, .vbs and .js files) and installers (e.g. .msi, .msp and .mst files) from scratch is a more secure method than relying on a list of those currently residing on a workstation or server. Furthermore, it is preferable that organisations define their own approved list of executables, software libraries, scripts and installers rather than relying on lists from application control vendors.
Security Control: 0843; Revision: 8; Updated: Apr-20; Applicability: O, P, S, TS
Application control is implemented on all workstations to restrict the execution of executables, software libraries, scripts and installers to an approved set.
Security Control: 1490; Revision: 2; Updated: Apr-20; Applicability: O, P, S, TS
Application control is implemented on all servers to restrict the execution of executables, software libraries, scripts and installers to an approved set.
Security Control: 0955; Revision: 6; Updated: Apr-20; Applicability: O, P, S, TS
Application control is implemented using cryptographic hash rules, publisher certificate rules or path rules.
Security Control: 1582; Revision: 0; Updated: Aug-20; Applicability: O, P, S, TS
Cryptographic hash rules, publisher certificate rules and path rules used for application control are validated at least annually.
Security Control: 1471; Revision: 2; Updated: Apr-20; Applicability: O, P, S, TS
When implementing application control using publisher certificate rules, both publisher names and product names are used.
Security Control: 1392; Revision: 2; Updated: Apr-20; Applicability: O, P, S, TS
When implementing application control using path rules, file system permissions are configured to prevent unauthorised modification of folder and file permissions, folder contents (including adding new files) and individual files that are approved to execute.
Security Control: 1544; Revision: 1; Updated: Apr-20; Applicability: O, P, S, TS
Microsoft’s latest recommended block rules are implemented to prevent application control bypasses.
Security Control: 0846; Revision: 7; Updated: Apr-20; Applicability: O, P, S, TS
All users (with the exception of privileged users when performing specific administrative activities) cannot disable, bypass or be exempted from application control.
Security Control: 0957; Revision: 6; Updated: Apr-20; Applicability: O, P, S, TS
Application control is configured to generate event logs for failed execution attempts, including information such as the name of the blocked file, the date/time stamp and the username of the user attempting to execute the file.
Enhanced Mitigation Experience Toolkit and exploit protection
An adversary who develops exploits for Microsoft Windows will be more successful in exploiting security vulnerabilities when Microsoft’s Enhanced Mitigation Experience Toolkit (EMET) has not been installed. EMET was designed to provide a number of system-wide mitigation measures while also providing application-specific mitigation measures. From Microsoft Windows 10 version 1709 and Microsoft Windows Server 2016 onwards, EMET functionality has been incorporated directly into the operating system as part of exploit protection functionality.
Security Control: 1414; Revision: 1; Updated: Sep-18; Applicability: O, P, S, TS
If supported, the latest version of Microsoft’s EMET is implemented on workstations and servers and configured with both operating system mitigation measures and application-specific mitigation measures.
Security Control: 1492; Revision: 0; Updated: Sep-18; Applicability: O, P, S, TS
If supported, Microsoft’s exploit protection functionality is implemented on workstations and servers.
PowerShell is a powerful scripting language developed by Microsoft to provide an integrated interface for automated system administration, and is an important part of system administrator toolkits due to its ubiquity and the ease with which it can be used to fully control Microsoft Windows environments. However, it is also a dangerous exploitation tool in the hands of an adversary. In order to prevent attacks leveraging security vulnerabilities in earlier PowerShell versions, PowerShell 2.0 and below should be removed from operating systems. Additionally, PowerShell’s language mode should be set to Constrained Language Mode to achieve a balance between functionality and security. Finally, logging functionality available in PowerShell, such as module logging, script block logging and transcription, can provide invaluable information for incident responders following cyber security incidents that involved PowerShell being used for malicious purposes.
Security Control: 1621; Revision: 0; Updated: Oct-20; Applicability: O, P, S, TS
PowerShell 2.0 and below is removed from operating systems.
Security Control: 1622; Revision: 0; Updated: Oct-20; Applicability: O, P, S, TS
PowerShell is configured to use Constrained Language Mode.
Security Control: 1623; Revision: 0; Updated: Oct-20; Applicability: O, P, S, TS
PowerShell is configured to use module logging, script block logging and transcription functionality.
Security Control: 1624; Revision: 0; Updated: Oct-20; Applicability: O, P, S, TS
PowerShell script block logs are protected by Protected Event Logging functionality.
Host-based Intrusion Prevention System
Many endpoint security solutions rely on signatures to detect malicious code. This approach is only effective when a particular piece of malicious code has already been profiled and signatures are current. Unfortunately, an adversary can create variants of known malicious code, or develop new unseen malicious code, to bypass traditional signature-based detection mechanisms. A Host-based Intrusion Prevention System (HIPS) can use behaviour-based detection schemes to assist in identifying and blocking anomalous behaviour, such as process injection, keystroke logging, driver loading and call hooking, as well as detecting malicious code that has yet to be identified by antivirus vendors.
Security Control: 1341; Revision: 2; Updated: Sep-18; Applicability: O, P, S, TS
A HIPS is implemented on workstations.
Security Control: 1034; Revision: 6; Updated: Sep-18; Applicability: O, P, S, TS
A HIPS is implemented on high value servers such as authentication servers, Domain Name System (DNS) servers, web servers, file servers and email servers.
Network firewalls often fail to prevent the propagation of malicious code on a network, or an adversary from extracting important information, as they generally only control which ports or protocols can be used between different network segments. Many forms of malicious code are designed specifically to take advantage of this by using common protocols such as Hypertext Transfer Protocol, Hypertext Transfer Protocol Secure, Simple Mail Transfer Protocol and DNS. Software firewalls are more effective than network firewalls as they can control which applications and services can communicate to and from workstations and servers. The in-built Windows firewall should be used to control both inbound and outbound traffic for specific applications.
Security Control: 1416; Revision: 2; Updated: Sep-18; Applicability: O, P, S, TS
A software firewall is implemented on workstations and servers to limit both inbound and outbound network connections.
When vendors develop software they may not use secure coding practices. An adversary can take advantage of this by developing malicious code to exploit security vulnerabilities that have not been detected and remedied. As significant time and effort is often involved in developing functioning and reliable exploits, an adversary will often reuse their exploits as much as possible. While exploits may be profiled by antivirus vendors, they often remain a viable intrusion method in organisations that do not have any measures in place to detect them.
Security Control: 1417; Revision: 2; Updated: Sep-18; Applicability: O, P, S, TS
Antivirus software is implemented on workstations and servers and configured with:
- signature-based detection enabled and set to a high level
- heuristic-based detection enabled and set to a high level
- detection signatures checked for currency and updated on at least a daily basis
- automatic and regular scanning configured for all fixed disks and removable media.
Security Control: 1390; Revision: 2; Updated: Sep-18; Applicability: O, P
Antivirus software has reputation rating functionality enabled.
Device access control software
The use of device access control software to prevent the connection of unauthorised devices (e.g. unapproved smartphones, tablets, Bluetooth devices, wireless devices, 4G/5G dongles) to workstations and servers, via external interfaces such as USB ports, adds value as part of a defence-in-depth approach to the protection of workstations and servers.
It has also been demonstrated that an adversary can connect devices to locked workstations and servers via an external interface that allows Direct Memory Access (DMA), and subsequently gain access to encryption keys in memory. Furthermore, an adversary can read or write any content to memory that they desire. The best defence against this security vulnerability is to disable access to external interfaces that allow DMA. External interfaces that allow DMA include FireWire, ExpressCard and Thunderbolt.
Security Control: 1418; Revision: 2; Updated: Sep-20; Applicability: O, P, S, TS
Device access control software is implemented on workstations and servers to prevent unauthorised devices from being connected.
Security Control: 0345; Revision: 5; Updated: Sep-20; Applicability: O, P, S, TS
External interfaces of workstations and servers that allow DMA are disabled.
Further information on authenticating users can be found in the authentication hardening section of these guidelines.
Further information on the use of removable media with systems can be found in the media usage section of the Guidelines for Media.
Further information on patching operating systems can be found in the system patching section of the Guidelines for System Management.
Further information on logging and auditing of operating system events can be found in the event logging and auditing section of the Guidelines for System Monitoring.
Further information on securely configuring Microsoft Windows operating systems can be found in the following ACSC publications:
- Hardening Microsoft Windows 8.1 Workstations at https://www.cyber.gov.au/acsc/view-all-content/publications/hardening-microsoft-windows-8-1-workstations
- Hardening Microsoft Windows 10 version 1909 Workstations at https://www.cyber.gov.au/acsc/view-all-content/publications/hardening-microsoft-windows-10-version-1909-workstations.
Further information on end of support for Microsoft Windows operating systems can be found in the following ACSC publications:
- End of Support for Microsoft Windows 7 at https://www.cyber.gov.au/acsc/view-all-content/publications/end-support-microsoft-windows-7
- End of Support for Microsoft Windows 10 at https://www.cyber.gov.au/acsc/view-all-content/publications/end-support-microsoft-windows-10
- End of Support for Microsoft Windows Server 2008 and Windows Server 2008 R2 at https://www.cyber.gov.au/acsc/view-all-content/publications/end-support-microsoft-windows-server-2008-and-windows-server-2008-r2.
Further information regarding implementing application control can be found in the ACSC’s Implementing Application Control publication at https://www.cyber.gov.au/acsc/view-all-content/publications/implementing-application-control.
Microsoft’s latest recommended block rules to prevent application control bypasses can be found at https://docs.microsoft.com/en-au/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-block-rules.
Further information on Microsoft’s EMET is available at https://support.microsoft.com/en-au/help/2458544/the-enhanced-mitigation-experience-toolkit.
Further information on Microsoft’s exploit protection functionality is available at https://docs.microsoft.com/en-au/windows/security/threat-protection/microsoft-defender-atp/exploit-protection.
Further information on the use of PowerShell can be found in the ACSC’s Securing PowerShell in the Enterprise publication at https://www.cyber.gov.au/acsc/view-all-content/publications/securing-powershell-enterprise.
Further information on implementing PowerShell logging is available at https://www.fireeye.com/blog/threat-research/2016/02/greater_visibilityt.html and https://devblogs.microsoft.com/powershell/powershell-the-blue-team/.