GDPR is defined in 88 detailed pages about privacy rights, and starting May 25, 2018, these rules became enforced law for all data originating in the EU.  This effort comes after a 20-year kick-in-the-pants waiting period to finally acknowledge that we should have known better.  For those in the EU, you’ve probably been debating the “how” and maybe the “if” of planning how to accomplish these specific yet vague goals, as if it were a holy book seeking the interpretation of mortal worshipers (actually, a rather apropos description).  Despite Article 4’s definitions for 26 different terms (some of which have multiple definitions), a lot of room is left for interpretation for what it really means to ensure that compliance is achieved.

 

Achieving GDPR requires planning, changes to business processes, changes to security protocols, and software updates. A fundamental change will be required to the manner in which organizations and its employee’s manage personal data and how business are run to ensure data protection becomes a way of working across appropriate business activities. Changes to roles, responsibilities and processes will in turn drive changes to the manner application and technology is applied to support an organization’s business.  These application and software changes will accomplish procedural change, introduce new controls, and appropriate/compliant security.  The details of the requirements will help determine what tests are needed. While the methods to achieve compliance are varied, the components of testing for compliance is much easier to define in the world of testers to which I belong.  Testers love to ask “What if?” and dream up unusual scenarios which we call “edge cases”.  The “secret sauce” for testers is determining how to test for these marvelous, complex scenarios.  Don’t worry, we’ll discuss that later in this paper.

 

The state of business applications is their data, while the behaviors of software applications are their functionality.  The first step of end-to-end testing of any system is determining the flow of data, as anyone who has heard of ERP is aware.  GDPR requires the business process to understand how data (specifically PII) flows, what parts are accessible where, and what permissions allow or block different kinds of access.  These represent the risks, and the GDPR work includes business process redesign to properly reign in risk.  Application testing is involved later to ensure that application/process updates are designed and verified as being regulatory compliant.

 

By reigning in risk, I am specifically talking about Data Privacy.  At Qualitest, we’ve worked with ensuring that de-identified records lack PII, with large numbers of de-identified medical records, and to ensure website security to protect data by design and default.  Being GDPR, we know that the answer to when records need to be anonymized through encryption is “as early as possible”.  Intentionally limiting exposure by design is key (and mandated by Article 25).

 

Unsurprisingly, these pre-GDPR services of ours map very nicely to the needs of IV&V for a GDPR compliant system.  New functions and screens exist purely because they implement required software changes, and reviewing software updates is a lot of what we do.  Confirming security safeguards (functionally, through code scan, and through pen testing) and observing parameters passed into and out of web services is part of our wheelhouse.  Utilizing POS devices for retail is a common front line of accessing sensitive PII we often work with directly.  So despite the definition of GDPR being barely a year old, QualiTest effectively has many years of practical data compliance regulatory testing experience.  Especially when you include the security and data concern pushes coming from HIPPA and DevSecOps.

 

Let’s take a look at a famous data breach where the target was Target (pun acknowledged), and where security design faltered.  Keep in mind that Gemalto determined that 19% of all data breaches in 2016 were due to accidental loss. The Target breach is truly a thing of beauty that was preventable at many levels, and helps one appreciate the design of the heist.  It also helps us realize (in hindsight) how preventable this whole scheme is, and that Target was just one of many companies caught unprepared.

  1. A phishing scheme infected Fazio Mechanical Services’ system with a suspected Citadel Trojan. Security training and a security system should have prevented this.  At QualiTest, I am physically blocked from making the mistake of double-clicking a hyperlink via Outlook; I am limited to right-clicking Copy Hyperlink where I would hopefully be smart enough to recognize a phony address.  Your company’s security officer (what GDPR defines as a Data Protection Officer) should intentionally manage proper security settings for specific actions (Outlook’s Trust Center, etc.).
  2. Target should have had better access control on 3rd party partners, blocking them from privileged access through Target’s firewall and into their system. QualiTest Cyber Security would be able to verify proper limitations of access here.
  3. Target had poorly segmented its network (VLAN was insufficient), so accessing Target’s business section granted the attackers access to Target’s entire system including sensitive data areas. Oops!  Now the attacker can try installing malware on POS devices … unless QualiTest Cyber Security has had a chance to secure your network.
  4. Target’s POS terminals were not hardened to prevent unauthorized software installation and configuration. The installed BlackPOS malware used memory scraping to find credit card data as if panning for gold through memory chunks. The POS device then used a backdoor username to control a daemon handler to push the data onto the closest of 3 compromised internal FTP servers (concealed by running at peak load times) to begin the journey to the outside world.  This is a retail testing, potential for an IoT  QualiTest has experience in both of these areas, beyond just our security testing.
  5. FireEye security alerts of type=”malware” were logged during this process, but were ignored as false alarms. Other security programs were turned off, including one that had the ability to automatically remove detected malware.  One’s own security staff needs to be made familiar with security risks and properly uphold maintenance by ensuring that functionality is on, and that security logs are heeded.

 

Let’s take look at security a little further and consider scenarios that might expose data to a dangerous or indifferent world, each of which can be tested.  Many scenarios fly around my head:

  • Are web services exchanging unencrypted data, where a sniffer could grab them?
  • Are temporary files made that hold the unencrypted form on our server where someone might read them?
  • Are records anonymized before being put in a database or sent to other departments where they might be read later?
  • How is 3rd party access to data controlled?
  • PCI DSS: If someone brings a receipt for a refund via POS, is data exposed that makes more than the last 4 digits of the credit card public, or is proper tokenization used to disguise PPI?

Data privacy is only one of the many areas of GDPR.  What about right to erasure?  We want to make sure we delete every piece of what we intend to delete while keeping all other records intact.  Right to rectification will have many of the same concerns, where the only the right records must be found and dealt with.  Again, we must ask ourselves what scenarios might be problematic:

  • Where do all copies of the record live that must be deleted? Is there a place that tracks all prior accessing of that record, and is it necessary to do so (perhaps identifying external locations)?
  • What happens if you delete a record, but then someone restores from a prior backup?
  • How do you make sure that the record(s) have been deleted from 3rd party locations?
  • How do you handle records that have been cloned, where deletion needs to properly identify whether or not the clone is to be deleted as well?
  • How do you handle change databases which are designed to show the prior version?
  • Can a blockchain transaction be erased, given permanent incorruptible digital ledgers?
  • Imagine a transaction runs twice and one needs to be cancelled. How do you ensure that only one gets cancelled?

For data portability (Article 20), a standardized format must be used.  However, in a world of medical records where switching between ICD-9 and ICD-10 lack 1-to-1 translation, what happens if you start throwing in LOINC codes from US federal agencies and CPT from the AMA?  What about UPC codes used for inventory, which may split into other formats like EAN?  And what about languages used in comments in stored data, with so many national languages across Europe?  The existence of multiple standards that by definition are incompatible complicate the tester’s role in determining if data portability can be guaranteed.

 

Age of consent for data privacy is 16, although member states can choose to lower it as low as 13.  How do you test if they can give their own consent, which may vary if they travel?  What happens if someone calls in or uses the internet from a member state with a different age limit?

 

Will the U.S. take GDPR seriously?  While the EU and UK are required to comply due to location, the U.S. must only comply regarding data tied to the EU and UK.  Based on 2016 BreachLevelIndex’s data breach records, over 75% of the world’s reported data breaches occurred in the U.S. – that’s a lot of potential exposure for Europe to risk.  Of course, this may just mean that the U.S. is better at detecting data breaches, and may not prove actual prevalence.  On Indeed.com, the world’s largest job seeker website, Data Protection Officer U.S. job posts currently (done on August 17, 2017) only exist for Agfa, Starbucks, WIRB-Copernicus Group, Zendesk (although other advertised positions liaise with the DPO).  Expand your Indeed search to include all U.S. jobs that mention GDPR and the query (done on August 17, 2017) yielded 247 hits, including 3M, Accenture, Adobe, Ancestry.com, Apple, Dun & Bradstreet, Fed Ex, GoDaddy, JP Morgan Chase, Microsoft, Paypal, PricewaterhouseCoopers, Royal Caribbean Cruises, SanDisk, SAP, Starbucks, Tinder, United Airlines and Walt Disney.  This suggests that the U.S. is aware that GDPR concerns exist for the U.S.

 

So, what should we do in Europe, the U.S. and elsewhere to ensure that your business is GDPR compliant?  What business, process, organization and technical changes will be required to achieve compliance?  We’d like to suggest you do a little research with a no obligation GDPR High Level health check, a 2-3 hour meeting or a call with you, to let us scope out what an engagement would look like for you.  For a little bit of your time and no financial commitment, you can help prevent the potential loss of fines of the greater of up to €20 million or 4% of global annual turnover, and being banished from doing business in Europe.

 

Many companies are not sure how to best start establishing a plan to ensure they are regulatory compliant.  We recommend a rapid high level GDPR health check to kick start your planning process and to create the required changes to achieve the May 2018 deadline.  We also have a webinar and live UK event.