Back 
Roy Keane. Patrick Vieira. Martin Johnson. Marshawn Lynch. Whether it’s football, rugby or NFL, most sports with a physical element have famous “enforcers.” These tend to be known tough guys who break up the play and disrupt the opposition, often making use of their physical prowess to help their team by stamping their authority on the game (hopefully not literally, though…)
At some point on the journey towards compliance, IT has to do something similar. It’s all very well to ask employees nicely to do the right thing, but for a range of practical reasons, that tactic alone won’t be enough to ensure compliance. When the regulation is as complex and far-reaching as the GDPR – and the ramifications for non-compliance are so severe – then at a certain point, it’s time for IT to get tough.
Which brings us to the “enforce” stage, the third step in the GDPR compliance process. Everything up to this point in the first “audit” and second “rationalise” stages can be classed as “non-intrusive” in that it didn’t actually affect how people work. But now it’s time to examine the direct connections between users and cloud services, and how these can be used to help ensure compliance.
Where the audit stage looks at log data from the user and the organisation’s firewall, which shines a light on the data flowing between the user and any cloud services in play, the enforce stage typically involves inline devices. In the case of an example where a cloud access security broker (CASB) solution is employed, this would sit between the user and the cloud service, steering traffic to and from the app.
Using an inline service enables IT to become far more involved with the user and their activity, developing a far more granular picture in the process. IT can now see details of all activity – whether that’s an upload, download, edit, create, share, IT will be able to see everything in the log data. Following on from the second rationalisation stage, IT would have enough information simply to block offending cloud services, but that is not desirable because it will likely hamper productivity and annoy employees.
For those reasons, at this point, it’s time to switch to the enforce stage, in which IT becomes more of a gatekeeper. Sitting inline between the user and the cloud, IT is able to monitor the data and prevent access to cloud services which don’t meet the criteria listed in the GDPR which were examined in the rationalise stage. By monitoring the data in real time, IT can also examine the type of data involved, which can influence decisions. For example, does the data contain personally identifiable information (PII)? If not, it might be perfectly appropriate to use a consumer-grade cloud service without the safeguards which would need to be in place for more sensitive data.
By using a data identifier such as a data loss prevention (DLP) engine, the IT team can overlay GDPR-specific policies which will enforce an appropriate response. The DLP engine will examine the cloud service in use and the data itself for conditions which would run contrary to the terms of the GDPR. For example, the DLP engine will ascertain whether the cloud service in question has a data processing agreement (DPA) in place, and would also examine the data itself using pre-set GDPR templates.
In this way, the DLP engine can classify the data to examine whether it contains details such as a date of birth, religion, gender, place of birth and more, and report back to IT. That report will also show the action the user was trying to carry out – is it a download, or an attempt to share, or a request to send/transfer the data to another cloud service?
Let’s say a user pulls up a customer’s record in a cloud storage service and attempts to download the file. That attempt is flagged to IT in real time, with the DLP engine specifying that the file contains PII as defined in the GDPR. IT could block this request automatically at this stage, or simply record the action in a log. Data retained in the log could record the user, their location, and the type of data in an incident management dashboard, which will also show more detail on the user including the device being used, along with previous activity and other pertinent details.
These details are important because they provide rich context to help assess any request. If IT notices a request is coming from a device which is not owned or provisioned by the organisation, IT might block the request because the security status of the device is unknown. Equally, if the device’s location seems to be anomalous in that it does not tally with the user’s location, that may also be a red flag and a reason to block the request.
Blocking activity might sound draconian, but it’s not the only option. IT teams can also employ softer but equally effective tactics, such as quarantining data or putting it into a legal hold, encrypting the data, running a malware check before allowing the action or delivering a pop-up message to help coach the user away from potentially risky behaviors.
The use of inline, real-time security policies is vital to achieving GDPR compliance around the use of cloud services in an organisation. By using real-time monitoring, IT can block potential breaches or risky activity before they happen – effectively shutting the door before the horse has bolted, thereby avoiding a data breach and the potential for a huge fine. Better still, by using pre-set templates for DLP engines, this stage doesn’t have to represent a huge addition to IT teams’ workloads.
Blocking activity is not universally popular. Roy Keane, Patrick Vieira, and co were strongly disliked by other teams, but are still viewed as legends by the clubs for which they plied their trade as midfield enforcers. IT teams can look at this work in the same way: employees might not like it if their download is blocked, but it’s for the greater good of the organisation. By using an enforcement strategy and tools to avoid a major breach, the IT team will win plaudits from the C-suite and more importantly will protect the organisation and its data from exposure. It’s not a pretty job, but someone’s got to do it.
Read the blog