Control Definition
Control Objective: Restrict and control the allocation and usage of administrator-level operating system accounts.
In-scope components:
Administrator-level accounts defined on the following components:
- systems or virtual machines (VMs) hosting a SWIFT-related component (including interface, GUI, SWIFT or customer connector)
- dedicated operator PCs
- network devices protecting the secure zone
- Local or remote (hosted or operated by a third party, or both) Virtualisation platform (also referred to as the hypervisor) that hosts SWIFT-related VMs
- [Advisory A1/A2/A3: Middleware server (such as an IBM® MQ server or similar) used for data exchange between back-office and SWIFT-related components]
- [Advisory A4: other Middleware server (such as an IBM® MQ server or similar) than customer connector used for data exchange between back-office and SWIFT-related components]
- [Advisory: General-purpose operator PCs]
Risk Drivers:
- deletion of logs and forensic evidence
- excess privilege or access
- lack of traceability
- unauthorised system changes
Implementation Guidance
Control Statement:
Access to administrator-level operating system accounts is restricted to the maximum extent possible. Usage is controlled, monitored, and only permitted for relevant activities such as software installation and configuration, maintenance, and emergency activities. At all other times, an account with the least privilege access is used.
Control Context:
Tightly protecting administrator-level accounts within the operating system reduces the opportunity for an attacker to use the privileges of the account as part of an attack (for example, executing commands or deleting evidence).
Implementation Guidelines:
The implementation guidelines are common methods to apply the relevant control. The guidelines are a helpful way to begin an assessment, but should never be considered as an "audit checklist" as each user’s implementation may vary. Therefore, in cases where some implementation guidelines elements are not present or partially covered, mitigations as well as particular environment specificities must be considered to properly assess the overall compliance adherence level (as per the suggested guidelines
or as per the alternatives).
- Examples of administrator-level accounts are defined as follows:
- Windows: built-in administrator account and members of groups with administrator privileges (for example, accounts with debug or file system privileges). Typically, Enterprise Admins group, Domain Admins group, and Local Administrator group.
- Linux/Unix: root account (User ID = 0) and members of the root group.
- Mainframe: system administrator or system programmer role.
- Network devices: accounts like admin, root, telco, su or cisco.
- Access to administrator-level operating system accounts is restricted to the maximum extent possible unless needed to install, configure, maintain, operate, or support emergency activities. The use of the administrator-level account is limited to the duration of the activity (for example, maintenance windows).
- Logins with built-in administrator-level accounts are not permitted, except to perform activities where such accounts are specifically needed (for example, system configuration) or in emergency situations (breakglass account). Individual accounts with administrator-level privileges or accounts with the ability to escalate to administrative access, (like “sudo”) are used instead.
- Individual administrator-level account access and usage are logged so that activities can be reconstructed to determine the root-cause of incidents.
- Administrator-level passwords are tightly controlled with physical access controls when physically recorded.
Optional Enhancements:
- Systems are configured to not allow logins of built-in administrator-level accounts, except through a maintenance mode (for example, single user mode or safe mode). This effectively prohibits logins to the account as a service, batch job, through remote desktop services, or by escalating privileges from another account.
Considerations for alternative implementations:
New models are emerging to enhance the user experience but also availability as observed with the pandemic. Alternative implementations are raising to give users flexible access to the institutions’ environment: not necessarily through fully managed devices 17 but incorporating also individuals own devices to reach resources
located on premises or in the cloud. That implies moving from a controlled on-premises environment (for which the CSCF mainly provides guidance) to a zero-trust environment requiring to assess and control appropriately each type of access.
Such alternatives have to be considered individually and specifically by users from a risk-based point of view taking into consideration potential risks if some elements are compromised. Those alternatives cannot be described here but would require to consider elements such as those identified below for a secure virtual desktop infrastructure:
- Defining a virtual desktop infrastructure (Citrix or other workspace) with OS privileged account managed centrally and not possibly activated or used by the end users can meet the control (considering the virtual infrastructure is protected in line with control 1.3 and the virtual desktops themselves are protected as a physical general-purpose operator PC in line with control such as 2.2, 2.3, 2.7, 4.1, 5.1; 6.1; 6.4, 6.5A).
- The risks of end-user device compromise must be considered, analysed and appropriate controls deployed to protect the virtual desktop infrastructure and further accessed resources. Those controls must ensure proper authentication, activities authorisation (requesting sometimes additional independent factors) but also appropriate prompt reaction, involving also the end users, in case of end-user device compromise, loss or theft to block potential accesses through such device.
- Confidentiality and integrity of the sessions established towards the virtual infrastructure must also be ensured in line with the standard operator session depicted in control 2.6.
