Separation of System Resources Guideline

On This Page

UC Berkeley security policy mandates compliance with Minimum Security Standard for Electronic Information for devices handling covered data.  The recommendations below are provided as optional guidance for separation of system resources requirements.

Requirement

Resource Proprietors and Resource Custodians must appropriately limit the sharing or re-use of application credentials, service accounts, user accounts, databases, and system hardware across unique systems or environments.

Description of Risk

Sharing between systems or services increases security risk.  A compromise of one system can lead to a compromise of all of systems sharing the same database or credentials.  

Recommendations

Separate Application Credentials

Shared application credentials are user accounts where passwords are known to multiple individuals, allowing these individuals to login using the same account information.  The risk is that when credentials are shared, system changes and activities are linked to the shared user account, but not the individuals using the account.  Thus it becomes difficult to trace problem sources and assign accountability in cases where errors or malicious activities occur.  It also increase the likelihood of compromise since compromise to any one of the individuals sharing the account credential will also likely lead to compromise of the shared account.

  1. Resource Proprietors and Resource Custodians should create one application account per individual, so that there is no sharing of an individual account between multiple people.  The use of shared accounts should only be permitted where necessary for business or operational reasons, and should be approved and documented by resource proprietors.

  2. Application users, including administrators, should use unique credentials linked to their personal identity so all activities can be traced to their source.   

  3. Individuals in possession of credentials with access to covered systems must utilize a passphrase that are significantly different for each separate account under their control.   “Significantly different” means passphrase permutations should not be based on commonly used patterns since modern password cracking software has built-in algorithms to check for these patterns.  

  4. Develop a process to manage and monitor application users accounts based on MSSEI Account Monitoring and Management requirements.

  5. All administrative accounts must be protected by complying with MSSEI Controlled Use of Administrative Privileges requirements.

Separate System Resources

Critical services storing, processing and transmitting covered data should be hosted on separate physical or logical servers to reduce the risk of a compromised service negatively impacting other services hosted on the same server.   Consider the following recommendations when designing system architecture to properly separate system resources:

  1. Operate critical services, such as file, mail, web, and database servers, on separate physical or logical host machines.

  2. Limit the sharing of resources (storage, network and computing) between applications and data from different classification levels.  For example, the same physical server or VM (virtual machine) server should not be used to run a database that stores both protection level 2 and protection level 0 data. Instead, protection level 2 data should be moved to a separate server (physical or VM) that complies with MSSEI requirements.

  3. Ensure that network traffic of covered data between physical or logical host machines adhere to encryption in transit requirements.  

  4. Covered data and critical services should operate on host devices that are logically or physically separated on the network from devices hosting non-covered data and services as directed by MSSEI Boundary Defense requirements.

Note that when a device (server) stores, processes and transmits varying protection levels of data, unless the data is segregated per recommendation #2, the device must comply with the highest level of security requirements.  For example, a device that stores protection level 1 and protection level 2 data must adhere to security standards applicable for protection level 2 covered devices.