7 High-Risk Events to Monitor Under GDPR: Lessons Learned from the ICO’s BA Penalty Notice

Hello Security Ninjas,

Today's IT world is complex and can be challenging for security operations teams. Nowadays, more apps are being integrated and interconnected than ever before. Cloud services and SaaS solutions purchased all throughout the organization outside of the IT department add even more complexity.

The Golden SOC Question: What is Mandatory to Monitor First and Why?

Communicating to application and service owners the kind of activities that need to be logged and sent to the SOC can be a daunting task. Moreover, it can be tricky determining which alert is worth to be manually reviewed by the SOC.

Now the Information Commissioner Office (ICO) shows that this task should be taken absolutely seriously and strategically!

I wrote a blog a while ago on the SIEM process and which steps to take first when building a successful roadmap. In the article, I decided to go with a top-down approach. In my opinion, it is still an absolutely valid methodology whether you are applying it to information governance or your SIEM use cases. An alternative could be the adoption of MITRE ATT&CK and the use of known tactics and techniques to determine what to monitor. A downside of this approach is that MITRE ATT&CK does not solve the issue on what to monitor first! You would have to make the decision yourself, plus you wouldn’t be able to monitor the full coverage of MITRE ATT&CK either.

In this blog, I want to talk about key lessons learned from a recent breach. British Airways made the headlines when they were hacked and customer details were stolen. There were rumors of what may have happened and why.

Why IT Security Folks Should Know about Penalty Notices from the UK ICO

The Penalty Notice issued by the UK ICO to British Airways has just been published. The report shares a lot of valuable details that the information security community can learn from.

Penalty Notice - Not just for Practitioners

Being able to see first hand from an independent source what an attack and breach scenario looks like is not only beneficial for practitioners but also proves value for information security management. The Penalty Notice report helps to understand why certain security controls are considered appropriate and why it is necessary to have a proper incident response plan and procedures in place which include notification of legal teams and crisis communications teams. We also talked about these steps in our webinar “A Day in the Life of a GDPR Breach”. While preparing for this webinar, I learned a lot as an information security person. The work with our Splunk Data Privacy Officer taught me that a GDPR breach goes way beyond IT.

From page 17 onwards, the ICO document reads like an engineered demo, when in fact it is based on a real case that has been researched and confirmed by the ICO.

FACTS - The Attack

Step 1: Initial Access

The attacker compromised 5 user accounts assigned to the third party provider “Swissport”. The key user account used was from a Swissport employee based in Trinidad and Tobago. By using those credentials the attacker was able to login with those credentials to a Citrix session.

Step 2: Breaking out of Citrix

The attacker managed to bring external tools for conducting network reconnaissance into the Citrix session and succeeded in launching them by applying the user credentials and some techniques that weren’t published.

Step 3: Privilege Escalation

During reconnaissance, the attacker obtained access to a file containing the username and password of a privileged domain administrator account. It was stored in a plain text file on a server.

Step 4 to Step 6 are blanked out

Even if those steps have been blanked out in the report, we would refer to it as ‘Lateral Movement & Collection’ in the traditional security world. The attacker was able to find the username + password for a database system administrator.

Step 7: Personal Data Breach; XML File.

During lateral movement/collection the attacker found a server with log files from an application used for BA redemption transactions. Unfortunately due to human error, a testing feature that shouldn’t be used in production had been activated. This mistake allowed the application to write payment card details into the debugging log in plain text for a retention period of 95 days. This unnecessary logging had been active and unnoticed since December 2015. The attacker potentially had access to details of approximately 108k payment cards during that time.

Step 8: Personal Data breach; Payment Card Data

During further lateral movement/collection the attacker identified files that contained code for the BA website. The attacker redirected customer payment card data to a different website for a period of 15 days by using techniques that have not been disclosed.

Discovery and reporting of the breach

• Within 90 minutes after being notified by a third party, BA had adapted the malicious code and contained the vulnerability. After a further 20 minutes, all URL paths to the malicious redirected page from the BA networks had been blocked.
• The next day the commissioner, acquirer banks and payment schemes as well as nearly half a million affected customers were informed about the breach.

Failures: Preventative Measures

While multi-factor authentication would have heightened the security bar of an user account takeover according to the ICO, the commissioner adds a few more interesting suggestions and references. Multiple hardening guides from Citrix are referenced, security guides from the ICO as well as threat reports on techniques used from attackers from Mandiant and Citrix in regards to application of jailbreaking and virtualization of security issues. This shows that in today's world it is mandatory for security managers and practitioners to follow and read systematic security research as it is part of the job for which they are accountable.

Failures: Detection Measures

After reviewing the attack storyline, it should become clear what should be monitored. The ICO highlights several best-practice logging statements such as the NCSC - Introduction Logging for Security Purposes. Some key points BA could have monitored and reviewed alerts to detect the breach early on:

• Monitoring not authorized / new usage of applications within a Citrix environment
• Monitoring and logging access to relevant files that include hard coded credentials
• Monitoring the creation and activation of guest accounts
• Monitoring the administrative actions if a user account is added to a local admin group
• Monitoring of failed attempts to log-in using the system admin account
• Usage of privilege accounts should be monitored and audited
• Monitor unauthorized changes to website code on production systems

For every network appliance, operating system, database, business application and every office application - are you able to tick the following off your list?

1. these kinds of events are written into the log (correct logging level configured)
2. stored centrally
3. leading to an alert or being part of your alert pipeline/prioritization chain in order to be reviewed in time

Check out our security essentials app - it contains all of those use cases for adoption! Splunk Enterprise Security will be your best friend if you’re planning to operationalize those use cases, prioritize alerts and create workflows.

On A Cloudy Note

You think that none of this is relevant to you because you’ve got everything in the cloud? Also, you use managed Kubernetes and microservices? Just replace user accounts with API Keys. Keys used, new keys created, new permissions added to existing keys etc.

Information Security Management is not magic or rocket science anymore. And I hope that this guidance and these insights help you to improve your security program for the better!

Best

Matthias

P.s. I've compiled a checklist so you'll know what to look out for when performing proactive monitoring. You can find it here.