This article is more than 1 year old
Securing Office 365? There's always more you can do
Don't just accept the defaults and hope for the best
Wherever you look there's yet another SME or enterprise migrating to Office 365. This says a lot for the attractiveness of cloud-based office suites, and perhaps it also says something about the attractiveness of letting someone else look after one's SharePoint and Exchange servers rather than having to fight with their maintenance and upkeep internally.
It also says a lot about the security of the platform: if there were any serious concerns there wouldn't be so many people using it (the figure I have to hand cites 60 million business customers as of spring 2016). What this tells us, though, is not that it's the Fort Knox of cloud-based office software: it merely says that it's secure enough for commercial organisations to accept it into their infrastructure. Any system has scope for improvement, or for the user to layer further security mechanisms on top to make the setup even more attractive. So what does Office 365 give us, and what can we do to take it further, security-wise?
Underlying directory services
One of the reasons people tend to trust Office 365 is that it's based on the directory service that everyone knows and is familiar with: Active Directory. Cloud-based AD integrates with its on-premise peer very straightforwardly, and although in the past one tended to use outward federation (that is, AD was hosted and managed in-house and federated/synchronised to an external AD server) the story is now far more bi-directional, so you can manage the AD setup either internally and externally and it'll sync in either direction. Let's face it, it's difficult to criticise the fundamental security capabilities of a cloud-based AD setup because we've all been using it in-house for years and years.
Securing other apps
The other benefit you get if you adopt the Enterprise Mobility Suite on top of Office 365 is the ability to bring the user authentication of a variety of apps into a single user database. Interestingly EMS gives you more than you'd be able to do with an in-house AD setup. So as well as providing native AD authentication you can point all manner of other stuff at it – ODBC lookups, LDAP queries, Web services and of course other native AD servers. But more interestingly there's a pile of specific support for a wide range of popular cloud-based apps (Salesforce is the one that's generally cited, so let's not buck the trend) and so you can move away from your plethora of separate user databases and toward a single integrated directory service.
The problem with centralising your authentication, though, is that the impact of a breach on your central authentication database is far greater than a breach on a single application's own internal user database. So the first thing you'll probably want to add to your Office 365 setup is two-factor authentication (2FA). To be fair to Microsoft they do provide a 2FA mechanism of their own, but many of us already use third-party 2FA (RSA's SecurID is probably the best known, though more recently I've used Symantec's VIP offering) and it's understandable to want to stick with what you know. And without trying to sound disparaging to Microsoft, there's something to be said for picking a different vendor for your 2FA in the interests of putting your eggs in more than one vendor basket. Happily the 2FA vendors are happy to sell you their 365-connectable offerings as they're becoming nicely established and stable.
We mentioned earlier that managing your own in-house Exchange setup can be something of a chore, and quite frankly who can blame you for wanting to ship it off to the cloud for Microsoft to look after it? I've seen it done more than once, and the relief on the faces of the mail server admins was palpable. But I also wouldn't blame you for considering persevering with and potentially even expanding some or all of the edge protection you have for inbound email – it's been common for many years to adopt a hosted anti-malware and/or anti-spam offering and to funnel all your inbound email through it on its way to the Exchange server. So of course Microsoft's mail infrastructure has its own anti-malware mechanisms (and they're very proud of it) but again, by sticking with a third-party offering layered around it you can bring an additional layer of security, visibility and reassurance to yourself and your management.
Going in the other direction, Data Leakage Protection (DLP) is also something that you're increasingly likely to need these days, what with the tendency toward accreditations such as PCI-DSS and ISO 27001. Again there's a selection of DLP tools and policy features with Office 365, but a third-party approach is very much an option.
Regardless of whether your installation is on-premise or in the cloud, security monitoring is absolutely critical if you're serious about security. The market to be in these days is selling Security Information and Event Management (SIEM) software and appliances: storing, collating and analysing log data and the associated response and remediation brings massive benefits, particularly if you're aiming toward some kind of formal security or similar accreditation. Office 365 provides APIs into which SIEM platforms can hook in order to deduce what's occurring in the cloud installation and alert you to potential issues; and as with the likes of DLP and 2FA the vendors of SIEM products are now commonly supporting Office 365 to pretty much the same extent as they support on-premise kit. Does Office 365 have in-built SIEM? Yes, there are tools that provide you with forensic analysis features and of course there's event logging, but SIEM isn't a core concept for Microsoft and so unless you have a very small setup you'll look to third-party SIEM offerings for the functionality you need, either in a dedicated, targeted SIEM solution from someone like LogRhythm or Splunk or in a multi-function package from the likes of Proofpoint.
One of the big differences between the cloud-based world and the on-premise setup is the need for and the implementation of backups. It's common to decide that the requirement for backups to protect against complete system failure (i.e. disk crashes causing data loss) is much reduced in the cloud thanks to the robust physical implementation of the underlying storage layer. But remember that physical crashes are just part of the need for backups: the risk of inadvertent deletion of data doesn't go away when you shift the installation into the cloud. As with some of the other concepts we've mentioned there are built-in tools such as version control and rollback, automatic retention of items in recycle bins, and so on. But again you're likely to want more, and again you can look to the market as there's a growing selection of options out there.