Since 2015, along with the digital transformation, we have seen the Digital and Modern Workplace topic taking a growing place. As a result, Microsoft Office 365 established itself as the leader on the French market (nearly 90% of the CAC 40). Four years later, following recent high profile cyberattacks, the security topic is finally coming to the forefront after having been neglected for too long, in favor of migrations and adoptions of services.
This reflection should cover the main risks of data leakage and access to data by administrators, Microsoft and third parties or applications.
A new governance model imposed by Microsoft
Office 365 is a SaaS communication and collaboration solution. As such, the platform is constantly evolving, unlike the historical “on-premise” solutions: new features or settings appear and are modified, while others disappear (e.g. retirement of Skype for Business planned for 2021, July 31st and the end of legacy authentication support for Exchange Online planned for 2020). This continuous delivery pace is imposed by Microsoft, without control. Hence, a completely new governance model is required.
Changes integration can no longer be done in project mode. It must follow an established process. In this model, the workplace and security teams must work hand in hand and must be represented in all project and architecture committees, starting from the very beginning of the platform use cases design. These teams will also have a common responsibility to ensure the platform efficiency and regulatory compliance.
The security team sees its perimeter evolving: it no longer has control over security tools and can, or even must, play a business enabler role to support the migration to the cloud by proposing new uses (e.g. opening a controlled external file exchange service). An appropriate organization must be put in place. We could even consider having a Security Officer dedicated to the platform very close to the business, with the role of advising projects, ensuring the platform configuration and monitoring security alerts.
Another topic to be addressed is the delegated administration. Even though it is not a rare situation, it is not possible to have nearly 20 General Administrators for an O365 tenant. Indeed, a Global Admin has control over Office 365 services, but also Intune, Azure, AAD, etc. A delegated administration solution must be considered for user accounts and objects, through the implementation of an interface or a connector based on PowerShell or Graph API. This process should allow the company to manage all objects while considering business logic. To define this new governance model, the following security pillars must be articulated:
- Identity management ;
- Mastery of services and uses ;
- Control of compliance to company policies.
Identity management at the core of the model
In a solution designed to enable internal or external collaboration, with an ATAWAD use (Any Time, Any Where, Any Device), identity management (and therefore authentication) is the core of platform management. As with any project, the definition phase of who can access what, when and where is fundamental.
On Office 365, there are three types of users, each with different privilege levels: administrators, internal users and guests (external users invited to collaborate on a file or within an O365 Group or SharePoint site).
For each of these account types, implementing the defined security measures will be challenging. In addition to the unavoidable multi-factor authentication (highlighted by the data leak that affected Deloitte in 2017), there are also other essential issues, such as administrator access control (personalized or predefined roles, permanent or occasional access, etc.) and guest users lifecycle management (nothing being clearly defined by default). The cost of Azure AD Premium licenses or a third-party tool will be a major element of the discussion.
Also note that Office 365 allows external applications to communicate with its APIs. The external application can then act on behalf of a user with its own rights or of an administrator with higher privileges. These applications can come from different application stores (such as AppSource or AAD) or be developed locally. The management of permissions granted to these applications must be highly considered by companies. Indeed, through APIs, it is very easy to imagine a massive data leak in case of a user dupe (e.g. an application requiring unnecessary permissions, such as email access).
An essential but neglected control of services and uses
Once access to Office 365 is under control, the next topic is to manage its use. It is not uncommon to observe that some services, not prioritized during migration to the Cloud (Power BI, Teams, Flow, API access, etc.) are left accessible with their default configuration. The two reasons are generally a focus on adoption and a lack of time devoted to these non-priority services. In addition to setting up the service, it is also essential to define precise rules around uses to clarify who can do what and when (e.g. managing SharePoint authorizations, creating Groups). The best solution consists in implementing technical measures (general settings or configuration via PowerShell) congruent with the defined policy.
However, the lack of security of these services leaves the door open to potential data leaks: automatic transfer to the outside, exposure on the Internet or loss of the data control. As written above, governance must take security into account when designing future uses. Services must be analyzed and tested on small populations. Indeed, it will always be easier to open a feature than to restrict an already widespread use. In that case, it will be necessary to carry out an impact analysis, to tinker with a workaround solution and to raise users’ awareness widely. However, these actions may require significant investment and could be avoided.
The management of the service should not end with user adoption. Security and Workplace teams will be responsible for following Office 365 evolution (Evergreen program, setting up a watch, monitoring Microsoft blogs, etc.) in order to assess new opportunities and threats.
The control of the compliance with company policies
The implementation of the company security policies is the last pillar and includes the implementation of security tools: information protection, anti-malware, supervision and alerting.
Concerning Office 365 security, we can differentiate 3 levels of maturity. The resources put in place will depend on the expertise available (resources being limited on the market) and the budget (depending in particular on the strategy of the Microsoft licensing management company):
- Level 1 – Control of identities, services and use of the Security and Compliance Center: the company implements native Security Center and Compliance Center security solutions (including Office DLP, Exchange Online Protection, eDiscovery) accessible with basic licenses;
- Level 2 – Development of “in-house tools”: the company creates a set of simple scripts or dashboards, using Graph API, Security Graph API and PowerShell, to implement controls and security measures adapted to its context (e.g. life cycle management of guest users);
- Level 3 – Use of advanced security tools: the company implements additional solutions to strengthen the level of security: tools to fight data leaks, analyze malware on emails, review rights, detect abnormal behavior or even harden the use of the platform according to the context.
Mastering Office 365 services, their uses and native security features is essential, and must precede any consideration of adding an additional security tool, which would not cover existing vulnerabilities and would only add complexity.
Sample of controls included in the Wavestone Office 365 Audit Methodology
Conclusion
Office 365 is an interesting case of opening business applications on the Internet through the Cloud. This evolution requires adapting the company historical security model, towards the airport model following the Cloud adoption.
However, Office 365 security must not omit the security of the on-premise bricks necessary for the platform operation, as it is generally the case for the authentication that is carried out by ADFS.
