IS-3 and related standards call for activities related to system administration to be done using a different user account than ones used for normal activity. The ISO 27002 standard on which UC Policy IS-3 and standards are based is clear on the requirement stating that:

  • 9.2.3.e privileged access rights should be assigned to a user ID different from those used for regular business activities. Regular business activities should not be performed from privileged ID.

Malware comes in many forms. In most cases, it comes from vectors common to unprivileged tasks such as reading email, browsing the web, or accessing social networking sites. Malware generally runs at the privilege of the user. When the user has administrative privileges, the platform is at risk. When the user account can be leveraged to administrative activities, a lot more can be at stake. 

To assuage any doubt, separate administrative user accounts are required on any servers (physical/virtual/cloud) housing P3 or P4 data when carrying out administrative functions. The policy calls for separate accounts for administering workstations as well, and they should be used for all managed workstations. 

In no case should a regular user account, such as a regular netID account, be used to log on to critical infrastructures like network devices and life safety systems. Separate netID accounts created specifically for administrative purposes may be used.

There are differences in the ways that operating systems and services treat privilege context. For example, user access control in Windows is a mechanism designed to make a user aware of a function that requires a higher level of permission than operating as a normal user. It can optionally require the user to authenticate. Mac OS-X has similar functionality. Linux systems use capabilities like the sudo command to permit operations in the context of the root administrator. While these afford some separation, there are still security advantages to using a separate account. If these are used on systems housing P3/P4 data, they must require a positive authentication step involving MFA.

There are some environments where this guideline doesn’t map well to the technology. The Amazon Web Service console is an example. It basically requires an administrator to select roles at the time of login and restricts activities not specifically selected. The campus cloud now requires MFA for access to console services. A separate user account does not appreciably reduce risk. 

There are instances, like with standalone systems, where controls like MFA do not work. There are cases where multiple accounts aren’t possible. IT professionals need to be aware of threat vectors and the controls that provide protection from them. Administrators should always act to protect the resources that they are accessing or managing. 

The requirement to use separate administrative accounts applies to SaaS services. It is better to have a separate account for the configuration and administration of services than to use a regular user account. Where a separate account is used, MFA must also be used when logging in to the account if it is supported by the service provider. The elevation of privilege case discussed above applies to SaaS as well. If a separate account is not used, there should be an affirmative authentication step including MFA when this is supported by the service provider.