The principle of least privilege states that each component should allocate sufficient privileges to accomplish its specified functions, but no more. This limits the scope of the component’s actions, which has two desirable effects: the security impact of a failure, corruption or misuse of the component will have a minimized security impact; and the security analysis of the component will be simplified.
NIST Special Publication 800-160: Systems Security Engineering Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems, November, 2016.
The principle of least privilege (POLP) has long been a best practice for computer security. In practical application, administrative users will use regular user accounts for routine activities, and use a separate, administrative login to perform administrative functions. POLP is a component of many different compliance programs, including FISMA, PCI, CIS, etc.
In the Windows desktop, User Access Control (UAC) performs a POLP function – blocking or requesting access for administrative privileges as needed.
Using “Run As Administrator” also performs a POLP function – programs run with normal privileges unless explicitly requested to run with administrator privileges.
In the Windows Server environment, Microsoft has long recommended using separate administrator and regular user accounts for system administrators. (From The Administrator Accounts Security Planning Guide published in 1999 which is a document no longer available from Microsoft):
Why You Should Not Log On To Your Computer as an Administrator
If you regularly log on to your computer as an administrator to perform common application-based tasks, you make the computer vulnerable to malicious software and other security risks because malicious software will run with the same privileges you used to log on. If you visit an Internet site or open an e-mail attachment, you can damage the computer because malicious code could be deployed that will download and execute on your computer.
If you log on as an administrator of a local computer, malicious code can, among other things, reformat your hard disk drive, delete your files, and create a new user account that has administrative privileges. If you log on as a member of the Domain Admins group, Enterprise Admins group, or Schema Admins group in the Active Directory® service, malicious code can create a new domain user account that has administrative access or put schema, configuration, or domain data at risk.
There are obstacles to adopting this practice of separate accounts for users of cloud services such as Office 365. Creating separate accounts for administrators requires multiple subscriptions for a single user, for example. Managing multiple accounts within a browser context can be confusing, leading to a less safe usage of administrator accounts. Privileges for Office 365 are managed through users, roles, and groups within the Office 365 Admin portal.
Assigning privileges through the use of roles allows limitation of the privileges that are assigned to user accounts. For example, a user account can be assigned the Reports Reader role so that they can view the activity reports in Office 365, but they are not assigned any other administrative privileges. Other examples of roles available within Office 365 are below.
Organizations may find that they need a higher level of granularity and control of administrators. To assist in managing the security of privileged accounts, Microsoft provides Azure Active Directory (AD) Privileged Identity Management (PIM). This is available with Azure Premium P2 licenses. Adding this application to the Azure portal provides a high level of protection for privileged accounts. Azure PIM can secure privileged accounts by requiring Azure Multi-Factor Authentication (MFA), placing time limits on the granting of privileges (like “Just-in-Time Administration” in Windows Server 2016), detect attacks, and allow conditional access. These controls reduce the attack surface, and help maintain the principle of least privilege for the Azure AD administrator accounts.
Cloud and Office 365 administration requires a paradigm shift when compared to Windows server administration.
When our team performs security assessments we are looking for no less than two global (tenant) administrators and no more than 5. Many customers make the mistake of giving the Power BI or Exchange administrator global admin rights when all they require for their job is administration rights to that specific workload.
If you have any questions or would like to schedule a security assessment for your organization, please contact us.
Office 365 vs. Your Information Security Program
Unraveling Office 365 Groups
Author: John Norton
Editors: Alex Finkel and Kurt Greening