Data Security

Hacking cyber security for GDPR in three steps

ISSA-UK members have collaborated and got straight to the heart of GDPR to identify the five hidden articles relating to technology. This will help you form a pragmatic approach to the cyber security of personal data. Andy Burston explains why

Why attack people, property and premises when, with minimal programming knowledge, a little malice and a tool from the dark web paid for with untraceable crypto currency, attacks can be launched at any time and from any place, destroying public confidence, causing failure and attracting scrutiny.

Personal information, records and data are the hot target for attackers, be they a determined hacker, the disgruntled employee or simply the user who inadvertently jeopardises security through ignorance. In all cases, data needs to be treated with the same care as money, goods and services. It has taken the advent of EU General Data Protection Regulation (GDPR) to focus the mind on this for many.

Cinderella’s pumpkin PC
Not since the Y2K ‘Millennium Bug’ have we seen a similar level of public interest as GDPR has created in the strength of UK systems. High profile events, such as the Wannacry ransomware in 2017, have occurred but the short-term media focus there was on inadequate IT maintenance and poor response, not readiness.

Rewind 19 years and Y2K was largely seen as a challenge for the IT department to resolve alone. Disappointingly for some media types, Cinderella’s PC running Windows 95 failed to transform into a pumpkin at midnight, the party went ahead and Y2K has subsequently been unfairly seen as something of a damp squib. The moment the Y2K threat passed the interest evaporated. This ignored the many checks and fixes deployed into older mainframe systems to ensure the availability of what then formed the backbone of many critical UK services.

The Y2K lesson for GDPR
GDPR is only a threat to those who choose to ignore it and the most valuable Y2K lesson is that ‘doing nothing’ is not an option. Organisations that see GDPR as a point in time to pass are relying on a similar ‘evaporation of interest’ to occur that won’t on this occasion. Those who simply add ‘GDPR compliance’ to the to-do list of the new Data Protection Officer (DPO) are making only a token effort to demonstrate adherence to the regulation.

Those who have taken GDPR seriously have already adopted multi-departmental approaches that recognise the value of personal data to the business and operations. However, as with most multi-disciplinary strategies, the requirement for stakeholders and departments to collaborate and communicate as never before can be the root of solution complexity.

For us in cyber security, knowing and agreeing where to start with data protection for IT systems and bringing others along with us, is one of the more challenging aspects.

99 GDPR articles but no technology
The sheer weight of 99 articles, coupled with a fairly dull narrative, dissuades even the most avid reader. ISSA-UK members who have achieved this feat have made surprising findings when it comes to requirements for IT and cyber security.

The first is that very little GDPR text and few articles directly relate to the protection of personal data within IT systems. Aside from the mention of implementing ‘appropriate technical’ measures, the regulation mostly avoids technology. In fact, depending on your perspective and role within information and cyber security, only 19 articles relate to broader information security and management systems (e.g. an ISO 27001 compliant ISMS) and arguably only five truly shape cyber security.

Five essential articles for cyber ops
Before we consider the five articles, there is a quick and inescapable truth for IT and cyber security personnel, as well as those in the wider business. The accurate mapping of information assets containing personal data, to the systems where those assets are stored and processed is essential. If the business cannot identify the purpose for which data is held, cyber security measures to protect information assets will likely fail.

Following this mapping, the consideration of these five articles, the summaries and three key questions offered will help establish GDPR cyber readiness and continuity.

Article 5
Requires the security and protection of data against unauthorised and unlawful access, data loss and the implementation of appropriate technical measures. It asks: have we identified the IT systems where information assets containing personal data are processed by our users? Can we identify IT privilege escalation to these systems? And, how do we identify attempts of illegitimate privilege escalation to systems containing personal data (e.g. escalation sponsorship, Windows security group monitoring etc.)?

Article 24
Requires implementation of technical measures to demonstrate that processing is performed in accordance with GDPR. It asks: how do we identify if data security policies (e.g. retention schedules, security classifications etc.) are respected and applied within IT systems? Can we retrieve the processing activity logs that will be required during an investigation? And, can we accurately report on the information risk profile change of personal data to risk owners and information asset owners?

Article 32(2)
Requires appropriate levels of security in order to prevent unlawful disclosure or loss, bearing in mind that some personal data is more ‘sensitive’ than others. It asks: can we identify where ‘sensitive personal data’ is processed within our systems (e.g. personal data relating to religious belief, ethnicity or sexual orientation)? Can we identify when personal data is exchanged or exported by the users of our systems (e.g. the connection and use of removable media)? And, do we make use of encryption (e.g. password protection of USBs and files)?

Article 32(4)
Describes a ‘natural person acting under the authority of the controller’, which translates to consideration of steps to protect against insider threats. It asks: can we identify our Privileged Users and their access to our systems? How do we enforce ‘least privilege’ within systems, providing users with only the information necessary to complete their operational duties? And, can we monitor and report on the modification (e.g. edit and deletion) of personal data records by users within systems and databases?

Article 33
States the need to notify any breach within 72 hours of discovery with disclosure regarding the nature, size and scale of the breach. It asks: how easily can we identify the scale of a breach (e.g. the number of records lost)? How would we identify how many people are referenced within any lost data? And, how would we identify the different types of data affected?

Beware the road to GDPR compliance
Few can argue that organisations should not spend time factoring GDPR into business processes, training, inductions etc. However, our findings suggest that the cyber requirements do not need to be treated as yet another step or hurdle to cross (or fall over) along the same linear GDPR path once information asset mapping to systems has been completed.

For cyber personnel charged with data protection responsibilities, there are arguably only three strategic IT activities to absorb into existing cyber operations and run in parallel with wider GDPR objectives.

Three key activities for GDPR cyber security
Monitoring: The protective monitoring of information assets within systems to collect the evidence of data processing. This will require the use of Security Information and Event Management (SIEM) applications to harvest, analyse and store activity logs from personal data systems such as databases, file shares, emails etc.

The best prepared organisations can identify how data is used and alert on security events as they occur. This includes the ability to monitor modification and deletion of data records and correlate this to the user account responsible and their network location.

Detection and response: You can’t have one without the other. This is monitoring that delivers active security to detect the indicators of a breach or compromise and enable early intervention. This is a clear move away from any manually driven extraction and audit of system logs by an administrator – a risky data protection activity in itself!

Look for security technologies or service providers that are able to detect and flag events that would otherwise be missed by the human analyst. Capability should include behaviour anomaly detection, as well as detection of the subtle tell-tale signs of cyber attack in progress hidden within communications and masses of network traffic.

Demonstrating compliance: This is providing the risk owner with assurance that the risk profile associated with personal data within their systems is measurable, known and acceptable. This considers your information assets (definable sets of business data), the vulnerabilities posed (potential weaknesses) and the effectiveness of any controls to prevent the vulnerabilities from being exploited.

As an added bonus for GDPR, the same evidence of routine assurance and risk visibility to risk owners, will prove extremely valuable should the ICO (the UK regulator) drop in. It will demonstrate a clear focus to deliver continuing data protection and information risk management even if you are unlucky enough to suffer a breach.


View the latest
digital issue