Separation of System Resources Guideline

Implementation Information

The primary intent of these requirements is to protect against lateral movement between systems sharing the same execution environment, database, and/or credentials. IT Resource Proprietors and Service Providers must appropriately limit the sharing and re-use of system resources — specifically servers, databases, and execution environments — across independent applications or systems. For public-facing applications classified at P3 or P4, strict logical separation must exist between the application tier (e.g., web server) and the database or datastore tier.

Separate System Resources & Implement Physical/Logical Isolation

To reduce the risk of lateral movement and cross-application compromise, IT resources must be explicitly isolated based on their function and data classification. Consider the following architectural best practices:

  1. Implement Multitier Architecture for High-Risk Apps (P3/P4): Ensure that web servers, application logic, and databases do not reside on the same physical or logical host machine. The database layer must be isolated from the public-facing Internet layer.
  2. Eliminate "Shared Hosting" Models: Do not host independent applications on the same underlying operating system or execution environment. Utilize dedicated Virtual Machines (VMs) or isolated containerization technologies (e.g., Docker, Kubernetes namespaces) to ensure strict process and memory separation between applications.
  3. Isolate Database Instances: Do not house unrelated application databases within a single shared database engine or instance. Provision dedicated database instances for distinct applications to prevent cross-database exploitation. Ensure database credentials are strictly scoped to the access needed by the application they are used by.
  4. Segregate by Data Classification: Limit the sharing of underlying compute, network, and storage resources between applications handling varying classifications of data. For example, an application processing public UC P1 data must not share a server, VM, or database environment with a system storing highly sensitive UC P4 data. Instead, the UC P4 application and data should be moved to a separate environment (physical or logical) that complies with MSSEI P4 security requirements.
    • Note on Protection Levels: When a system stores, processes and transmits varying Protection Levels of data, unless the data is segregated per recommendation #4, the device must comply with the highest level of security requirements. For example, a device that stores P2/P3 and P4 data must adhere to MSSEI P4 security standards.
  5. Encrypt Network Traffic: Ensure network traffic between these separated tiers is appropriately encrypted and segmented according to MSSEI 6.2 Encryption In Transit.

Separate Application Credentials & Service Accounts

While architectural separation isolates the environments, credential separation ensures that access between those environments remains tightly controlled.

  1. Utilize Dedicated Accounts & Unique Passphrases:
    • Service Accounts: Applications must use uniquely generated service accounts to authenticate to databases, APIs, or other system resources. Never share a single service account or database credential across multiple independent applications.
    • Application Accounts: Application users, including administrators, should use unique credentials linked to their individual identity so all activities can be traced to their source.
    • Unique Passphrases: Passphrases for all accounts must be unique and significantly different for each separate account. “Significantly different” means passphrase permutations must avoid using common patterns because modern password-cracking tools are specifically designed to detect predictable user behaviors. Even if passphrases are long, reusing familiar structures or word combinations allows attackers to guess them quickly.
  2. Apply the Principle of Least Privilege: Configure service accounts with the absolute minimum permissions required for that specific application to function. A service account for Application A should have no read or write access to the tables or datastores used by Application B.
  3. Prohibit Shared Administrative Accounts: Administrative access to these separated servers and databases must be tied to unique, individual identities. Shared "root", "admin", or generic department accounts obscure accountability and increase the likelihood of widespread compromise. Implement strict privileged access controls in accordance with MSSEI 5.4 Privileged Account Security.
  4. Develop a Process to Monitor & Manage Accounts: All accounts must be regularly monitored and managed in accordance with MSSEI 5.6 Account Monitoring & Management.

On This Page