Predict, prevent and respond: Building a multi-level approach to GDPR in Office 365.
In this blog, we’re going to explore the first of a two-part approach to effective data protection in Office 365 using our Office 365 reporting solution to bolster your GDPR efforts.
When it comes to security, you need a proactive, preventative strategy at the forefront, and a fast, intelligent, effective response acting as your back-up for if (or when) something manages to get the better of you.
Protection and prevention is your first and best starting point.
As the ICO states: ‘Under the GDPR, you have a general obligation to implement technical and organizational measures to show that you have considered and integrated data protection into your processing activities.’ Make sure your data protection strategy adheres to this. It should be strong but dynamic, with regular reviews built-in. If your security model is built well enough, you will delay (or maybe even avoid) the need for your second-line of defense, which is…
Any security incidents that involve the potential loss of personal data need to be reported to the ICO within 72hrs. Whether it’s an external attack, a system vulnerability, or a simple accident – data loss happens, and identifying the cause is crucial, enabling you to lock down the source, limit the damage, and investigate what happened.
In this blog, we will explore the first-line defense: prevention and protection measures for data protection in Office 365. Our Office 365 reporting software can help to get a clear, full view of your Office 365 environment, and highlight any vulnerabilities that exist across the tenant.
So, what are these preventative measures? Unlike physical security systems, where you have locks, bolts, security guards, and alarm systems, in the cloud, we’re talking encryption, permissions, alerts, and settings.
First, lock down your permissions model
Permissions can be used throughout Office 365 to grant or forbid access to certain areas, documents, sites, folders etc. If you configure your permissions model correctly and apply it carefully across your users, then you can ensure that no one is able to see, edit, delete or configure anything that they shouldn’t be able to.
That said, it’s also important to regularly review these configurations. It’s no good setting these up, then leaving them running – review them often, delegate permissions carefully, adjust them when needed, and keep your security model strong.
We have various reports across three modules that can enable you to review the configurations you have, as well as show where non-standard permissions are set.
Our ‘Permissions’ Report will show you where inherited, or unique permissions have been set across your SharePoint Online environment. Governance and compliance in SharePoint Online can be a real challenge, particularly for large, sprawling estates. This report enables you to drill down into the environment, to review and audit the permissions set. Often a user is given permissions to a certain set of files or area for a project or on a temporary basis, this report can be used to ensure that users only have access to what they need when they need it.
Keep an eye on your Admins
Typically, Office 365 admins have elevated privileges that enable them to take certain actions to manage or monitor activity within the tenant. Users with this role are at a higher risk of taking an action that could result in data loss, such as accidentally assigning incorrect access to the wrong user (for example, adding a new Sales Executive to the HR Distribution List and SharePoint site by accident).
Of course, users that are assigned admin roles are given them for a reason, and should be aware of best practices and the responsibilities they have – but accidents happen. It shouldn’t be taken for granted that these users are always acting correctly or appropriately, they could be cutting corners to save time or hassle, or they may not see the harm in granting elevated privileges for someone who may not need them.
Our range of reports provide insights into admin activity so that they can be monitored, audited (so that an admin is only assigned the privileges they need for their role), and their activities are always visible. Below is the ‘Administrative Roles’ report, detailing all admin roles, the users in the position, and a description of what they are able to do.
In addition to this, we have the ‘Administrator Activities’ report. This report presents a timeline view of all activities made by your admins (across 10 workloads) and can be searched or filtered to show certain information. For example, what if you find that a number of leavers have had their mailboxes soft-deleted as soon as they left. This action breaches your organization’s data retention policy, as the information contained within these mailboxes should have been retained for set timescale and any important content could be dealt with. It might be a simple mistake, and fortunately, the information was easily recovered, but you still need to understand what happened, which admin deleted the mailboxes, and why.
Where your investigation starts depends on the information you have: whether it’s the date range of the activity, the user mailboxes involved, or the admin that you think may have been involved. Configure the workload to Exchange and Azure AD, and add the relevant filters. As you can see below, the view will include actions made by service accounts, these can be excluded in the top right – just click on ‘exclude these users’ and add their details in.
All eyes on DLP
Data Loss Protection is key to GDPR compliance. Comprehensive DLP rules need to be set and their efficiency reviewed regularly to ensure that they are working. We have a number of DLP reports available in our Office 365 reporting tool. The example below is from our Exchange DLP Report. As you can see, this event has matched on the term Credit Card Details, and the subject of the email suggests that a large purchase is being discussed. While this example appears to be a fairly comical discussion of yacht-buying, this DLP rule could also catch sophisticated phishing attempts that may have bypassed a spam or malware filter. Phishing emails often ask employees to pay an outstanding invoice or send over credit card details for a bogus cause. Concerningly, many studies show that if a phishing email manages to get through spam/malware filters and end up in a user’s mailbox, they are likely to interact with it in some way. This doesn’t necessarily mean handing over card details straight away, but it does suggest that they will engage – it could be replying, asking a co-worker, or worst-case scenario, complying with the email’s requests.
SharePoint Online and OneDrive for Business can also contain huge amounts of sensitive data that should also be protected by DLP rules. As you can see below, SharePoint Online/ OneDrive for Business DLP reports will also show any matches across these services too.
Configure alerts for all activities on sensitive or important files/areas
Good DLP policies are a great start for protecting items that pose a known risk of personally identifiable information (PII) data loss, but what about the unknowns? Can you ever be sure that you’ve configured policies for all potentially sensitive terms? DLP relies on identifying certain words or number patterns that could relate to sensitive information and then setting policies on those terms. But what if the contents of a certain document or folder cannot be classified in this way? Any user with the correct permissions can view, modify, delete, or download files in these services. This is why permissions management is important, but there are always going to be users who need access to this data – what happens if their account is breached? What happens if their relationship with the company becomes sour, and they decide to mine for information or collect important information for improper use (taking it to a competitor, for example)?
It’s a difficult situation. You cannot revoke access for these users – the documents are part of their job, they have the privileges to view the information contained within them. In this scenario, it is important that all activities for sensitive or important files such as these are auditable, and alerts are configured for any non-standard activity relating to them. If these documents need to be available, but should not be modified or downloaded, then you could restrict access for these actions. Or, if you just want to monitor their access, why not configure on-event alerting, so that you are able to investigate any activity on said files.
Our solution has sophisticated on-event alerting, which can be configured to your specific requirements. You can receive the notification via email or SMS, depending on your preference. Typical customer use cases for alerting include alerts on certain file activity for privileged documents, notification of failed events, or failed logins (which could indicate brute force attacks), irregular sign-in activity (for example User A signs in to Office 365 in London at 10 am, and New York at 11:30 am).
A final note.
True fact: users make silly errors that compromise data – their own, a customer’s, someone else’s, or (if they’re really going for gold) the confidential details of the entire organization. As an IT/Security admin your job is to stop them, make them aware of the dangers and best practices – but mostly stop them. You can do this by trying to stay one step ahead and creating a system which doesn’t allow these mistakes to take place.
This means that your DLP policies block users from sending their credit card/passport details out, your permissions do not allow an unprivileged user to accidentally send a customer list to an external party, the list of accidents goes on, but you get the point. Your users are the easiest point of entry for an attacker – wherever possible, don’t let this be the case.
In our next blog on this topic, we’ll explore what to do when the worst-case scenario happens. How to respond to a data loss incident quickly, minimizing the damage, identifying the source, and gathering all the details you need to report the incident to the ICO or any other regulatory body.