Focus on Security During Cloud Transition
I recently had the pleasure of attending Microsoft’s Pramila Padmanabhan and Michael Epping’s talk Protecting Microsoft 365 from On-Premises Attacks at The Experts Conference (TEC) 2021.“ I then co-moderated the subsequent question and answer period. This session addressed an important challenge facing organizations transitioning portions of their software stack to Microsoft 365: how to avoid weakening the security of Microsoft 365 due to the configuration of legacy on-premises infrastructure. I highly recommend watching their presentation: The advice they give is both clear and wise.
The recommendations break down into five key categories. Over the course of two posts, I will present a summary of their advice and add my perspective as to how these recommendations translate into practice. In my professional role I work exclusively with large organizations in North America, so my background and experience may color my perspective.
The Risk that On Premises Infrastructure Poses to Microsoft 365
Attackers have increasingly used on premises Microsoft infrastructure to attack and breach Microsoft 365 cloud services. The most famous culmination of these is the Nobelium campaign, commonly referred to as the “SolarWinds” hack.
On-premises products such as Windows Server, Exchange Server, SharePoint Server, and especially Active Directory are nearly ubiquitous for organizations with any significant on-premises Microsoft footprint. A key selling point used by Microsoft to drive adoption of Microsoft 365 services is the seamless way that organizations can extend Microsoft on-premises platforms into the cloud – to become “hybrid”.
Being able to use Microsoft 365 hybrid capabilities enables organizations to manage their transition to the cloud more smoothly. But making Microsoft 365 hybrid also adds dependencies and complexities linking the cloud and on-premises platforms. This ultimately puts organizations, as Pradmanabahn puts it so colorfully, in the position of “defending yourself from yourself.”
According to Padmanabhan and Epping, the two main avenues for on-premises security vulnerabilities to affect Microsoft 365 are federated authentication and directory synchronization. Federated authentication is when Office 365 is configured to trust an on-premises component like Active Directory Federation Services for authentication. This is the vector used in the Nobelium hack to transition from on-premises dominance to cloud access.
Directory synchronization between Active Directory and Azure Active Directory creates vulnerabilities when an on-premises account has over-permissioned (or simply unaccounted-for) permissions in its corresponding hybrid cloud account. If attackers can penetrate the on-premises infrastructure and compromise the on-premises portion of the over-permissioned hybrid account, then they can gain access and control over whatever access that account has in the cloud.
Mitigating the Risk that On-prem Infrastructure Poses to Microsoft 365
Given these challenges, Padmanabhan and Epping gave five key recommendations to help secure your Microsoft 365 environment from on-premises threats. I’m going to spend a little time with each of them to talk about how I’ve seen the recommendations implemented and put to the test “in the real world”.
Isolate Microsoft 365 Administrators
Microsoft’s guidance is to make certain that the accounts used to administer Microsoft 365 are both distinct from user’s regular Microsoft 365 accounts and used only from separate “administrative workstations.” This recommendation is the one I see adhered to best by the organizations I work with – with some caveats.
I rarely see “daily driver” user accounts assigned to highly-privileged Microsoft 365 roles such as “Global Administrator” or “SharePoint admin”. And while it is comparatively more common, many organizations that I talk to are also undergoing the process of moving user accounts away from being able to be in the less powerful or application specific roles.
Furthermore, I increasingly see “Just-in-time” privilege management systems being used to secure Microsoft 365 administrative accounts. These systems include Microsoft Privileged Identity Management (requires Azure AD Premium P2) and third-party Privileged Access Management systems from vendors such as CyberArk, BeyondTrust, and One Identity.
While I suspect that the reasons organizations have for not using the integrated Microsoft Privileged Identity Management (PIM) system vary, the reasons I am given when I ask about it usually fall into some combination of two categories. Either the options for approvals are too basic within PIM, or the organization wants to have a single privilege management system that can cover privilege across many cloud and on-premises platforms.
It is less common to see privileged accounts usage confined to Privileged Access Workstations. This isn’t usually the fault of the administrator, but rather third-party applications that need access to Microsoft 365 and require a Global Administrator account starting a consent workflow in the application itself.
As an example, I recently worked with on-premises identity management system that included an Azure Active Directory interface. The service principal required for the integration could not be pre-created but had to be defined and consented to by the configuration utility of the app itself. Even worse, the application would not accept an account with the mere “Application Administrator” role but demanded a full Global Administrator. To be sure, this application is an extreme example, but according to the engineers I was working with not terribly unusual.
Manage Device Configuration from Microsoft 365
This recommendation comes with the tacit admission that the traditional ways to manage end point devices simply can’t cope with today’s security reality. Active Directory Group Policy and System Center Configuration Manager (née Systems Management Server or SMS) are powerful but were devised in a much different IT environment that makes them problematic for securing the endpoint devices that are accessing Microsoft 365 today.
GPOs (Group Policy Objects) and SCCM are designed for centralized networks. Organizations have rapidly shifted toward a much more “work from anywhere” model, so it can be challenging ensuring that devices have the connectivity to get the settings they need.
GPOs and SCCM are also designed for homogenous endpoints – they are fundamentally a Microsoft Windows based technology. Both can be extended to an extent to support other PC platforms such as GNU/Linux and macOS, but neither offer any support for iOS or Android.
And finally, the ubiquity of GPOs and their close ties to Active Directory make them a tempting target for attackers and can themselves be used an attack vector against endpoints.
Padmanabhan and Epping’s guidance is to leverage Intune, Microsoft’s cloud based Mobile Device Management (MDM) product. And to leverage Intune, organizations must migrate end point Windows devices to either “Hybrid AD Join” (in which an endpoint is both Active Directory domain joined AND managed by Intune) or better yet skip Active Directory entirely and be only Azure AD Joined and 100% managed by Intune.
Realistically, organizations I work with that have tried to move towards this model report that they often run up against the limitations of what can be done using Intune. Many have needed to augment Intune’s capability with third party device management systems to get the capability they need. Non-Microsoft application packaging and updates are often cited as a particular weakness for Intune. Another common theme is a lack of remote connectivity for virtual “over the shoulder” support scenarios.
Furthermore, while managing device end points through MDM solutions like Intune may be something that works well for workstation class endpoints, it doesn’t cover server platforms. Padmanabhan and Epping say, “don’t use a server OS for your workstation,” but the reality in many organizations is more nuanced than that. It is not at all uncommon to leverage server platforms for administration as “tools servers” or integrated with privilege authentication management systems as “session management” portals. In my experience, simply avoiding SCCM and Group Policy by avoiding Active Directory is going to be far further off than many organizations might hope for.
Next Step
In this article we took a critical look at the first two points from Protecting Microsoft 365 from On-Premises and the sometimes-messy path organizations are taking to implement them. Please join me in Part 2 of “Protecting Yourself from Yourself” where we will discuss Padmanabhan and Epping’s final three points of guidance.
