As we move closer to the May 2018 deadline for GDPR, more and more businesses are focused on ensuring their ability to meet the requirements set out by the regulation. All too often, people assume this requires additional investments, which at some level will be true; but you should also be challenging your organisation as to how you get more from what you already have.
Equally, I hear many looking to data loss prevention (DLP) and encryption tools as primary requirements for protecting data. However, having worked with both for many years during previous stages of my career, I would highlight that these, like every capability, come with their own implementation challenges. Often, adjacent technologies can help reduce the scope of these challenges and the associated costs. To cover all of these would be a mammoth blog; as such I’m only going to pick a couple, just to start your creative thinking and help you on your GDPR journey.
Here, I’m going to focus on how your firewall can help reduce the effort and cost of better securing the personally identifiable information (PII) data lifecycle. How do you validate if you are getting the most from what you have already, and where could you join up security processes that today may be owned and implemented by different teams in the business?
The all too common first thought with PII data lifecycle management is to try and classify all your data – a task that has the potential to take until the end of time – as every day we generate new data or new instances of existing data. Often, much of this focus is on how to bring clarity to the volume of unstructured data.
You need a change of mindset, which is not to try and define where all your PII data is, but instead to define – and then enforce – where your PII data can and should be. This reduces the scope of where you need to then apply DLP controls.
Most organisations already have insight on PII data in known business processes. In practice, this could include customer relationship management (CRM) tools, threat intelligence that may include some form of PII data, and HR systems. However, there is often still a significant gap between where structured data is and where it is thought to be. Being able to truly define where it is will allow you to start identifying the points where it becomes unstructured data.
If you are using good Layer 7 firewalls in your business, you can use these to help map your real-time application usage. This will allow you to see which apps are talking with which others, those that are communicating outside the business, and which users are doing this and at what volume.
The core goal here is to think to the Zero Trust model: can you segment your organisation’s PII data – allowing you to reduce where it can move – into being unstructured and, more importantly, reduce the scope of what you need to apply security to. Likewise, such visibility can help you define at which points you need encryption versus the points where the data should never reside or be accessed to start with.
Now pivot to managing the PII itself: a good Layer 7 firewall will typically include some level of content inspection. If you do have a DLP solution in place that tags data, your firewall should also be able to leverage the tags inserted into the data. You may wonder why that’s of value; well, your firewall can typically inspect inside encrypted traffic, which may give access to data the DLP solution could not otherwise analyse. Also, depending on your configuration, you may be able to leverage your firewall to give you more enforcement points if you have used it to segment your organisation’s system traffic.
If you don’t have a DLP tool in place but are looking to enforce your PII dataflows, once again, a Layer 7 firewall will likely have some content inspection. While not as rich as that provided by DLP, many will allow you to look at regular expressions (words, common structure forms like banking card data, etc.) in common file types that will give you a light version that may suffice, in some cases, to both map and enforce data usage.
So, what are the takeaways here?
Take anything to the Nth degree and it can solve a problem. DLP and encryption are key to managing the PII data lifecycle. However, they can be expensive from both a Capex and Opex perspective. You can use other tools and processes to reduce dependence on them.
GDPR is a rare opportunity to take a step back. It’s amazing to see how many organisations invest in state-of-the-art technology, such as a next-generation firewall, that can do all these things, but then still use it like their 20-year-old port and protocol firewall that works at Layer 3.
Before you spend any more of your valuable budget, challenge yourself and your organisation on what you already have. Ensure you know the capabilities at the core, as well as the additional components. Map them out and then consider how they could streamline your processes to reduce the scope and effort. In this instance, looking at how you zone your traffic or go to a full Zero Trust model is not a specific GDPR callout, but it does align to the notion of what is state-of-the-art best practice and, more importantly, what could reduce where your PII data proliferates. This means less to then secure, and less risk to the organisation.