Protecting against Rogue Administrators

Occasionally I am asked the following question – how can I protect the messaging environment from a rogue administrator? There are essentially two concerns being asked in this question:

1. How do I protect the data from being deleted by a rogue administrator?
2. How do I protect the data from being accessed and/or altered by a rogue administrator?

Sometimes this discussion leads to a discussion about only the chosen backup architecture. The reality is that whether you implement Exchange Native Data Protection or a third-party backup solution, a backup, by itself, does not protect you from rogue administrators; it only mitigates the damage they potentially cause. Any administrator that has the privileged access to the messaging data (whether it be live data and/or backup data), can compromise the system. Therefore, some operational changes must be implemented within the organization in order to reduce the attack surface of an administrator who has gone rogue.

Important: This article is not intended to be a comprehensive set of instructions on how to restrict administrators. Instead, this article will highlight the principles and techniques that can be used.

Immutable Laws of Security

The Microsoft Security Response Center published the Ten Immutable Laws of Security. They are:

• Law #1: If a bad guy can persuade you to run his program on your computer, it's not solely your computer anymore.
• Law #2: If a bad guy can alter the operating system on your computer, it's not your computer anymore.
• Law #3: If a bad guy has unrestricted physical access to your computer, it's not your computer anymore.
• Law #4: If you allow a bad guy to run active content in your website, it's not your website any more.
• Law #5: Weak passwords trump strong security.
• Law #6: A computer is only as secure as the administrator is trustworthy.
• Law #7: Encrypted data is only as secure as its decryption key.
• Law #8: An out-of-date antimalware scanner is only marginally better than no scanner at all.
• Law #9: Absolute anonymity isn't practically achievable, online or offline.
• Law #10: Technology is not a panacea.

These guiding principles are a cornerstone in how we secure Office 365 and are equally applicable to on-premises deployments.

Active Directory

Exchange relies on Active Directory, storing configuration data within the configuration partition and storing recipient data within the domain partitions. The forest administrators, who are members of either the Enterprise Admins group or the root Domain Admins group, control all aspects of the directory and control data stored in the directory (though they sometimes delegate specific rights to others so others can perform very specific actions that are usually narrowly scoped within a forest). Likewise, domain administrators in each domain partition own their respective recipient data. Companies normally restrict forest-wide and domain-wide actions to be exclusively performed by forest administrators because of the risk that configuration changes can have broad adverse impact.

Many organizations today operate an Active Directory model with a least-privilege administrative model. If you are not operating in this fashion, this should be a top priority for your organization. Remember, any member of the Enterprise Admins or Domain Admins can alter messaging configuration settings on recipients and/or the Exchange configuration, without utilizing the Exchange Management Tools. For more information, see Best Practices for Securing Active Directory.

In addition to operating Active Directory in a least-privilege manner, it is important to implement background checks and other processes to determine the trustworthiness of your administrators, otherwise Law #6 cannot be mitigated. In addition, you may want to consider investing in an identity management solution, like Forefront Identity Manager, to manage and audit administrative permission requests and approvals.

Permissions

Exchange administrators have a wide variety of tools that they potentially can utilize to manage a messaging environment. The preferred method is via Remote PowerShellas Exchange can then authorize access and audit any actions performed. However, if an Exchange administrator is granted additional permissions in Active Directory (e.g., the ability to modify any attribute on a user), then the administrator can utilize other tools (e.g., LDP, ADSIEdit, local PowerShell, scripts, etc.) to modify recipient and/or configuration data, bypassing the authorization and auditing checks built into the system.

To effectively mitigate any possibility of modifications that could occur outside of the Remote PowerShell framework, it is imperative to follow Best Practices for Securing Active Directory, as previously mentioned. Often times, Exchange administrators are not evaluated with the same rigor as Active Directory administrators; therefore, Exchange administrators must not be granted permissions in Active Directory that allow them to circumvent Remote PowerShell (e.g., recipient modification).

If Active Directory privileges are accurately and narrowly scoped, a rogue administrator will have difficulty making unauthorized changes no matter which tool he/she tries to use.

PowerShell

Exchange leverages Remote PowerShell which is a feature within PowerShell that lets admins run commands on remote systems. Remote PowerShell enables the functionality utilized by Exchange to audit cmdlet execution and enforce authorization through RBAC.

One way to ensure that administrators can only manage the messaging environment through Remote PowerShell is to not allow the installation of the Exchange Management Tools on administrator workstations. Administrators are then forced to use the Exchange Admin Center or to connect to Exchange using Remote Shell.

In addition, PowerShell 3.0 and higher provides robust audit capabilities when module logging is enabled. PowerShell Module logging captures pipeline execution events for specified modules, and records this data in Windows PowerShellEvent log. Among the events logged, Event ID 800 (Pipeline Execution Details) provides command line commands and a script name if one is used. If a script was used, the ScriptName value will be populated with the file name of the script that was executed and an event will be logged for each line in the script, with each event including the command from that line. The data recorded in the event log can be collected, analyzed, and provide auditing data by which an organization can determine what PowerShell operations are occurring in the environment.

Mitigating Data Destruction

An Exchange administrator has the necessary privilege to access and destroy Exchange data. The best way to protect the messaging data from an administrator is to:

1. Shrink the window of opportunity for administrators to perform malicious activities. The mechanisms that can be implemented include removing local administrative access, deploying Applocker, removing access to destructive cmdlets, and deploying lagged database copies.
2. Ensure all administrative actions are logged and implement alerting and reporting based upon monitoring of logged activities.
3. Implement a least-privilege access control model whereby the elevation process grants access only to perform the intended activities. Even more effective is implementing an access control model whereby most or all administrative activities are done via a ‘control plane’ that is used by administrators to request that actions be performed against Exchange and the control plane can then implement business logic upon the request that will determine if the request will actually be executed. The business logic might include a request to a second person to review and approve the action or it might check an employee work scheduling system to see if the original requestor is on vacation, for example.

Removing Local Administrative Access

The majority of Exchange management tasks are accomplished via Remote PowerShell. As a result, the only time an Exchange administrator needs local administrative access to the Exchange server is to perform system updates (installing driver updates, installing Exchange cumulative updates, operating system updates, etc.). Therefore, local administrative access can be restricted and granted only when needed, for a specific period of time, after which access is revoked.

Without local administrative access, administrators will be unable to obtain certain information about the Exchange server health that they may need to appropriately manage the environment. Therefore, administrators should be granted access to the following:

• File shares (secured via read-only access to the appropriate security groups) can be created to enable access to Exchange diagnostic logs (which by default, are located at %Program Files%\ Exchange Server\V15\Logging and %SystemDrive%\inetpub\logs).
• Read-only access to the event logs can be granted by adding the appropriate security groups to the member server’s local Event Log Readers security group.
• Access to performance counters can be granted by adding the appropriate security groups to the member server’s Performance Monitor Users security group.
• To allow administrators to schedule performance counter logging, enable and collect tracing, the appropriate security groups can be added to the member server’s Performance Log Users security group.

In addition, local administrative access on the administrator’s workstations should also be removed. This ensures that administrators can only run approved applications and cannot bypass any security mechanisms you may put into place to audit and monitor their actions. For more information on running Windows in a least privileged manner, see Applying the Principle of Least Privilege to User Accounts on Windows.

By removing local administrative access, Laws #2 and #3 are mitigated.

AppLocker

AppLocker provides organizations with a strong defense in the prevention of malicious software and unapproved applications from affecting your server environment. AppLocker can be used to limit the software that Exchange operators can use so that only an approved list of applications (e.g., Exchange Management Tools, approved PowerShell scripts, etc.) will run on a server where AppLocker policy enforcement is in effect. For more information, see the TechNet article on AppLocker.

AppLocker allows you to mitigate Law #1.

Removing Access to Destructive Cmdlets

Both Exchange 2010 and Exchange 2013 include Role Based Access Control (RBAC), a mechanism by which administrators are authorized to perform certain administrative tasks. RBAC provides the capability for very granular control of managing the messaging environment – for example, restricting access to a particular cmdlet or to a particular property of a cmdlet.

For more information on RBAC, please see the following articles:

• Understanding Role Based Access Control
• RBAC and the Triangle of Power
• RBAC: Walkthrough of creating a role that can wipe ActiveSync Devices

While Administrator Audit Logging will record the actions taken by administrators, it does not prevent the administrators from performing destructive actions if they are authorized to do so. Using RBAC, organizations can reduce the attack surface area by removing access to destructive cmdlets. A destructive cmdlet is any cmdlet that can access, modify, or delete messaging data.

The below table identifies cmdlets and parameters that may be considered destructive (e.g., Remove-Mailbox). Each cmdlet should be evaluated to determine how it is used in your environment and whether it should be removed from day-to-day usage.

Note: The above table does not include the cmdlet list identified in the section “Removing Access to Data Access Cmdlets” below, but they should also be considered as those cmdlets provide access to messaging data.

For example, if I wanted to ensure that my administrators cannot remove database copies and manipulate the lagged database copy’s configuration, I could remove those cmdlets by using RBAC in the following manner:

1. Create two new role groups: Protected Organization Management and Protected Server Management.

   $ORoleGroup = Get-RoleGroup “Organization Management"
    
   New-RoleGroup "Protected Organization Management" -Roles $ORoleGroup.Roles
    
   $SRoleGroup = Get-RoleGroup “Server Management"
    
   New-RoleGroup "Protected Server Management" -Roles $SRoleGroup.Roles

2. Remove the Database Copies role from the protected role groups.

   Get-ManagementRoleAssignment -RoleAssignee "Protected Organization Management" -Role "Database Copies" -Delegating $false | Remove-ManagementRoleAssignment
    
   Get-ManagementRoleAssignment -RoleAssignee "Protected Server Management" -Role "Database Copies" -Delegating $false | Remove-ManagementRoleAssignment

3. Create a Protected Database Copies role.

   New-ManagementRole –Parent "Database Copies" –Name "Protected Database Copies"

4. Remove the Remove-MailboxDatabaseCopy role entry from the Protected Database Copies role.

   Remove-ManagementRoleEntry "Protected Database Copies\Remove-MailboxDatabaseCopy"

   Additionally, you can also remove access to the ReplayLagTime parameter from the Protected Database Copies role, thereby ensuring administrators cannot disable the lagged database copy.

   Set-ManagementRoleEntry "Protected Database Copies\Set-MailboxDatabaseCopy" –Parameters ReplayLagTime -RemoveParameter

5. Add the Protected Database Copies role to the protected role groups.

   New-ManagementRoleAssignment –SecurityGroup "Protected Organization Management” –Role “Protected Database Copies"
    
   New-ManagementRoleAssignment –SecurityGroup "Protected Server Management” –Role “Protected Database Copies"

6. Add users to the protected role groups.

   $OrgAdmins = Get-RoleGroupMember "Organization Management"
    
   $SrvAdmins = Get-RoleGroupMember "Server Management"
    
   $OrgAdmins | ForEach {Add-RoleGroupMember "Protected Organization Management" –Member $_.Name}
    
   $SrvAdmins | ForEach {Add-RoleGroupMember "Protected Server Management" –Member $_.Name}

7. Remove the desired users from the Organization Management and Server Management role groups.

You can repeat the appropriate steps for each destructive cmdlet that needs to be restricted. Use the following cmdlet to determine which roles contain the desired cmdlets:

Get-ManagementRoleEntry "*\<cmdlet>" | fl name,role

Lagged Database Copies

A lagged database copy is a rolling point-in-time (up to 14 days) copy of the database. Lagged database copies were first introduced in Exchange 2007 and have evolved considerably since then. Lagged database copies are part of The Preferred Architecture. While the primary reason for deploying a lagged database copy is protection against rare, catastrophic logical corruption events, lagged database copies can be used to recover mailboxes and/or items that have been deleted by a rogue administrator. By implementing the access control mechanisms previously discussed, the lagged database copy is protected from destruction by a rogue administrator.

Mitigating Data Access

There are several mechanisms you can implement to mitigate unwarranted data access within your messaging environment. These mechanisms include auditing, using Bitlocker to encrypt the disk drives, and removing access to certain cmdlets that enable administrators to gain access to user data.

Auditing

There are several different forms of auditing that can be implemented in the messaging environment. Within Exchange, you can enable Administrator Audit Logging. Administrator Audit Logging captures all operations that are performed within the Exchange Management Shell (EMS) or Exchange Admin Center (EAC).

By default, all cmdlets, except Get- or Search- cmdlets are logged in the audit logs. You can change the cmdlet logging via Set-AdminAuditLogConfig; for example, since Search-Mailbox includes the ability to delete content, you will want to add that cmdlet to the list. Audit logs are stored in an arbitration mailbox. Reports can be accessed via the Search-AdminAuditLog, New-AdminAuditLogSearch cmdlets, or via EAC.

In addition to auditing the actions taken by Exchange administrators managing the service, you will also want to audit server operation events (e.g., logon events). For more information, see the Windows Server Security Auditing Overview article and the Audit Policy Recommendations article for securing Active Directory.

Bitlocker

Another way to reduce the attack surface area is to use Bitlocker to ensure that operators with physical access to the servers cannot remove disk drives and access the data contained on them.

As mentioned previously, separation of roles is imperative, otherwise Law #7 cannot be mitigated. As Bitlocker recovery information is stored in Active Directory (specifically the msFVE-RecoveryInformation attribute), delegation of this data must not be granted to Exchange administrators.

Removing Access to Data Access Cmdlets

Using RBAC, organizations can reduce the attack surface area by removing access to cmdlets that allow access to mailbox data. The below table identifies cmdlets that grant access to data, or enable administrators to hide their tracks. Each cmdlet should be evaluated to determine how it is used in your environment and whether it should be removed from day-to-day usage.

To remove access to the above cmdlets, follow steps 1-7 from the “Removing Access to Destructive Cmdlets” section.

Requesting Elevation

Over time, administrators will require access to restricted cmdlets to perform a necessary operation (e.g., disabling mailboxes, removing unnecessary transport rules, etc.). There are many ways you could go about this. For example, you could simply build RBAC roles for each individual cmdlet (and/or property) that you restrict; when elevation is required, you add the administrator to the appropriate role group, granting them access, and then remove the administrator when the task is complete. Or you could develop a process and workflow that includes the following:

1. A means by which an administrator may submit a request for elevated access. The request needs to include specifics like the cmdlets being requested, the targeted servers/users/etc., and the length of that time elevated access is required.
2. The request can either be implicitly approved based on the requested action, or it can require human approval.
3. All actions must be logged once elevated access has been granted.
4. Elevated access must be removed once the time period has expired (either based on the request or based on a default time period for access elevations) or the task has been completed.

How is this addressed in Office 365?

Exchange Online implements a variety of mechanisms to prevent rogue administrators from accessing or destroying data.

Perry Clarke and Vivek Sharma recently discussed Lockbox, a mechanism we use to enforce no standing access, in the article From Inside the Cloud: Who has access to your data within Office 365?

In particular, Exchange Online personnel do not have persistent access to the service or servers; instead, administrators (who have undergone background checks) have to request specific access (to servers, cmdlets, etc.) and can only perform the requested tasks during a specified timeframe. Additionally, for requests for elevation to a role with access to customer data, approval must be performed by another human being and the ability to approve this type of request is restricted to a smaller set of more senior personnel.

We also use other mechanisms to protect the service and customer data. For example, Bitlocker is used to encrypt all disks that contain customer data. When the disks are end-of-life they are shredded, thereby ensuring the data cannot be accessed.

Conclusion

While this article covers the basics, there are many other mechanisms you can implement in your environment to reduce the surface attack area within your messaging environment. For more information about security mechanisms protecting Exchange Online that can be used in on-premises deployments, see the MEC session Exchange Online service security investments: you CAN and SHOULD do this at home.

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience