GDPR: Why Notification Shouldn’t be the Biggest Challenge

While notification may be new for some, those in countries such as the USA have been doing as such since 2002, when California first introduced SB1386[1].  In Europe the requirement as part of the upcoming General Data Protection Regulation (GDPR) is causing much discussion and debate, often due the timescale and penalties it sets out.

Interestingly, this is definitely not new territory, as there are websites dedicated to tracking the scale and volume of data breaches today[2].  And while GDPR includes new more substantial penalties, when you read industry reports it’s apparent that the bigger commercial impact is expected to be the loss of customer business associated with breaches.  There are plenty of instances in which this is highlighted, such as the Ponemon “Cost of a Data Breach 2017[3].

From the discussions I have had over the last 12 months, the most common point of focus is the time to respond to a breach, which is very understandable - under Article 33 it implicitly defines a timeline for notification of the appropriate authority, stating that this must be “without undue delay and, where feasible, not later than 72 hours after having become aware of it”[4]

However, come back to the industry data in the reports mentioned and it’s evident that it takes longer to find a breach than it does to fix it.  Yet it’s apparent that the quicker we can find the breach, it’s typically possible to reduce the scope, and the associated effort and costs to remediate it.

As such, the first step I would encourage anyone looking at GDPR in their own organization to take is to benchmark not just your own ability to respond to a breach, which is the natural response to GDPR Article 33, but how quickly you can detect the incident in the first place.  For if you can impact this significantly, you can potentially reduce or remove the need to contain and notify.

So how do you achieve this?

As I look at the different annual industry reports relating to breaches, I see different perspectives on whether the cause of a breach was an insider or an external attacker.  My perception is that many breaches are the result of credential misuse, which means this is reported in differing ways, which leads to such confusion.

If I work backwards from a breach, excluding human physical error (data left behind or  physically lost) and focusing on the intentional theft.  To have a breach requires credentials to be misused.  As such, the question becomes how you can spot this.

User and entity behavioral analytics tools have evolved to meet this need, looking at norms of how accounts are being used and flagging anomalies.  This may be as simple as connectivity profiling, or how credentials are being used once authenticated.   Like so much in cybersecurity, the challenge is weeding out the false positives from the real alerts, which can be down to the quality of the indicators and the machine learning between them. However, this also falls into the next stage in the chain, which is whether users should actually have that access to start with.

Adversaries are typically looking to leverage accounts with broad permissions, so whether it’s an internal or external adversary, the more you understand where your personal data is in your business, and which users and applications need access to it, the more you can restrict access to only those accounts. This reduces the scope of risk of credential misuse.  As part of this, you can also look at how to filter access by access type.  In Palo Alto Networks OS-8.0, the team added in a clever new capability to allow your next-generation firewall to work with multi-factor authentication tools.  The goal here is that if you can identify from where the connection is being established, you can enforce policies via the device to define whether access should be granted and, if so, if additional authentication is required (such as Octa or PingID).  This is an additional way to ensure that sensitive personal data is only used on systems inside the organisation’s core secured systems, but more importantly means that stolen credentials have limited value for the adversary, as multi-factors of authentication are required.

Credential theft and escalation typically occur mid-way through the attack lifecycle, so we would be remiss if we didn’t look early in the attack lifecycle.  Why does it typically take so long to find the breach to start with?  This is due to the reality that we have so many disparate security tools that require humans to collate different indicators into something that is a whole attack.  Better automated integrated security solutions are required to join together these artifacts, and this is something that has been discussed in previous blogs.

However, one critical aspect should be highlighted here that applies to both the time to detect and also the time to respond to incidents: whether you have all the information required to complete the analysis. The point here relates to information retention – the period of time for which you are keeping the logs, packet captures and other forensic artifacts.  If you challenge your own organisation how long are you typically taking to discover and respond to an incident today? If you don’t have the relevant evidence then you are hampering your own abilities.

Takeaways

Breach notification may be a new requirement for some, and is undoubtedly an area for concern in relation to GDPR.  It’s worth noting that it typically takes as much as three to four times as long to find a breach then it takes to gather the evidence to make the right decisions to remediate it.  Typically, the longer it takes to find the breach, the greater the impact.  As such, if we can get better at finding a breach, we can reduce its impact. Furthermore, by doing so we can reduce the scope of what would need to be analyzed before notification can be completed, and - more importantly - can strive to intercept the incident before it gets to the exfiltration stage of the attack lifecycle.  Visibility and implementation of better credential management are key contributors to success here.  The thing to conclude should be whether you want to focus on responding to the problem or stop the problem from occurring in the first place.  Yes, you will still need to have a response process in place, but by focusing on the right objectives, it’s possible to be better armed to deal with a smaller problem.

[1] https://en.wikipedia.org/wiki/Security_breach_notification_laws

[2] http://www.informationisbeautiful.net/visualizations/worlds-biggest-data-breaches-hacks/

[3] https://www-03.ibm.com/security/uk-en/data-breach/

[4] https://gdpr-info.eu/art-33-gdpr/