Blog

Maskeren is geen complete oplossing voor testdata

Geplaatst op 10/06/2020

Door: Gilbert Smulders, Consultant bij ViQiT

Van GDPR/AVG naleving naar grondig en snel testen

Curiosity heeft vrij veel geschreven over de impact van GDPR/AVG op testen. De onderstaande infographic vat hun denken samen. Het is gebaseerd op nieuws en onderzoek uit 2019-2020 en toont aan dat het nodig is om privacy-problemen met testdata aan te pakken:

De statistieken vertellen een redelijk consistent verhaal: het risico op een datalek blijft toenemen, evenals de bijbehorende boetes en merkschade. Ondertussen is het beperken van gebruiken van gevoelige informatie in testomgevingen de meest effectieve manier om dit risico bij testen te mitigeren.

De bronnen voor de infographic staan aan het einde van deze blog vermeld. Ik raad je aan om eens rond te kijken om te zien hoe hoog de inzet is voor naleving van GDPR/AVG. Maar laten we eerst enkele manieren bekijken waarbij naleving van GDPR /AVG van invloed is op software ontwikkeling en testen. Daarna bekijken we hoe de reactie op deze uitdaging eruit ziet.

Als de voorgestelde aanpak interessant klinkt, doe dan zeker mee met het gezamenlijke Curiosity- en ViQiT-webinar op 24 juni om ‘Test Data Automation’ live in actie te zien. Meldt u vandaag nog aan!

De betekenis van de GDPR/AVG voor softwareontwikkeling en testen

De impact van de GDPR/AVG op softwareontwikkeling en testen kan ver strekken. De specifieke problemen die mogelijk binnen QA moeten worden aangepakt, zijn onder meer:

  1. De logistiek van het vervullen van het “Recht op wissen” en “Recht op overdraagbaarheid”:
    de IT-domeinen van organisaties zijn vaak niet opgezet om alle gegevens van iemand ‘zonder vertraging’ te vinden en te kopiëren of te wissen. Testomgevingen zijn vaak uitgestrekt en slecht begrepen, inclusief verouderde componenten en ongecontroleerde spreadsheets. Organisaties weten daarom zelden op betrouwbare wijze waar gevoelige informatie zich bevindt, en hebben nog minder de technieken om alle gegevens van iemand ‘zonder vertraging’ te identificeren, te kopiëren en/of te wissen.
  2. Aantonen van legitieme gronden voor het verwerken van gegevens binnen QA:
    Structuren ontbreken vaak om aan te tonen dat elk gebruik van persoonsgegevens bij softwareontwikkeling en testen voldoet aan de legitieme gronden voor de verwerking ervan. Deze gronden zijn onder meer actieve en geïnformeerde toestemming, legitiem zakelijk belang en nationale veiligheid.
  3. Naleving van gegevensminimalisatie en -beperking:
    Organisaties mogen bovendien alleen gegevens delen met zoveel mensen als nodig is om te voldoen aan de legitieme gronden voor gegevensverwerking. En die mensen mogen die gegevens niet langer bewaren dan nodig is om dat doel te bereiken. Organisaties zouden dit moeten kunnen aantonen. Maar ook dit is weer een uitdaging aangezien veel organisaties simpelweg niet weten welke data er is en hoe deze wordt gebruikt.

De uitdaging van naleving van testdata

Het is ook de moeite waard om te benadrukken dat de maximale boetes voor het niet naleven aanzienlijk zijn verhoogd. En dat de nationale agentschappen al bereid zijn gebleken om boetes op te leggen voor datalekken.

Uiteindelijk is de beste verdediging tegen het lekken van gevoelige informatie het beperken van het aantal mensen en plaatsen waar gevoelige informatie wordt gedeeld. Testomgevingen zijn een vermijdbare plaats waarnaar PII (Persoonlijk Identificeerbare Informatie) routinematig wordt gekopieerd. Testen is daarom een ​​goede plek om de strijd te beginnen om GDPR/AVG naleving te garanderen.

Het maskeren van testdata is een veelgebruikte techniek om het risico te verminderen dat gevoelige informatie wordt blootgesteld aan minder veilige testomgevingen. Het anonimiseren van productiegegevens kan de impact van nalevingsvereisten bij testen verzachten. Wel introduceert het echter vaak ook belangrijke knelpunten bij het testen en ontwikkelen.

Gegevens op een consistente manier maskeren uit verschillende bronnen is traag en complex, omdat het de complexe relaties moet behouden die binnen en tussen die gegevensbronnen bestaan. Vaak moet een centraal beheerteam overuren maken om aan constante verzoeken om gegevensvernieuwing te kunnen voldoen. En nog kunnen ze nooit snel genoeg gegevens leveren aan parallelle testteams:

Kostbare QA-tijd wordt dan verspild door het wachten op verouderde kopieën van productie, terwijl tests mislukken vanwege verkeerd uitgelijnde of verouderde gegevens. Testers en geautomatiseerde tests strijden bovendien om dezelfde gegevens, wat leidt tot verdere vertragingen omdat gegevens beperkt zijn of opgebruikt zijn.

Het kopiëren van productiegegevens doet verder niets om de kwaliteit van productiegegevens te verbeteren.

De historische datasets missen per definitie de gegevens die nodig zijn om nog niet uitgebrachte functionaliteit te testen. Bovendien is de productieactiviteit bijna uitsluitend gericht op “happy flow” activiteiten in het systeem. Productiegegevens missen daarom de uitschieters en negatieve scenario’s die nodig zijn voor voldoende testdekking. Daardoor worden systemen blootgesteld aan schadelijke productiefouten:

Een complete oplossing

Een complete testdata oplossing moet verder kijken dan alleen het verwijderen van PII uit testomgevingen. Het moet er ook voor zorgen dat de data die testers nodig hebben, direct beschikbaar is waar en wanneer zij dat willen. Dat betekent dat allerlei gegevenscombinaties beschikbaar zijn voor iedere test in bepaalde testomgevingen. Bovendien moet dit gebeuren met de snelheid die wordt vereist door geautomatiseerde tests en iteratieve softwareontwikkeling.

Het goede nieuws is dat deze benadering, die Curiosity ‘Test Data Automation’ noemt, voortbouwt op veel van de vaardigheden en technologieën die momenteel worden gebruikt in Test Data Management. De volgende technieken kunnen gemakkelijk worden toegevoegd aan bestaande maskeer- en subsetprocessen:

  1. Synthetische testdata genereren:
    het genereren van combinaties van gegevens die niet in productiegegevens worden gevonden, dicht de hiaten in de testdekking als gevolg van testdata met een lage variëteit. Bovendien kan tegenwoordig het genereren van gegevens gemakkelijk worden geïntegreerd met gegevensmaskering. Ontbrekende combinaties worden daarbij automatisch toegevoegd wanneer geanonimiseerde gegevens naar testomgevingen worden verplaatst.

Dit is een quick win voor het verhogen van de testkwaliteit met behoud van GDPR/AVG naleving voor testdata. Het produceert testdatasets die geen gevoelige productiegegevens bevatten, maar wel de uitschieters, randgevallen en negatieve scenario’s die nodig zijn om nieuwe of aangepaste functionaliteit te testen.

  1. On-the-fly testdata toewijzing:
    Testdata allocatie kan tegenwoordig de levering van volledige data kopieën vervangen, waarbij exacte datacombinaties worden toegewezen op basis van gespecificeerde testgevallen. Deze toewijzing is bovendien ‘just in time’ mogelijk; het vinden en maken van gegevenscombinaties terwijl testen worden gegenereerd of uitgevoerd.

In deze benadering is elke test uitgerust met een up-to-date en unieke gegevenscombinatie. Gekloond en toegewezen terwijl deze wordt uitgevoerd. Dit lost de vertragingen op veroorzaakt door handmatige gegevensverstrekking en ongeldige testdata. Bovendien voorkomt dit frustratie door concurrentie op gedeelde gegevensbronnen. Elke test en elke tester heeft in plaats daarvan zijn eigen geïsoleerde dataset, beschikbaar op aanvraag en parallel aan elkaar.

  1. Gestandaardiseerde, herbruikbare TDM-processen:
    Om QA echt wendbaar te maken, moet de afhankelijkheid tussen testers en testdata beheerteams worden weggenomen worden. De silo tussen het verstrekken van testdata en het uitvoeren van tests moet worden geëlimineerd. Daardoor wordt er toegang tot uitgebreide testdata verkregen.

Een manier om dit te bereiken is door de processen die worden gebruikt in de datavoorziening herbruikbaar te maken voor de testteams zelf.

Gelukkig kunnen deze processen gemakkelijk worden geautomatiseerd. Ze zijn per definitie op regels gebaseerd, omdat ze de relaties moeten weerspiegelen die in complexe gegevens bestaan. Ze kunnen daarom worden gestandaardiseerd en op verzoek beschikbaar worden gesteld aan testteams.

In deze benadering kunnen testteams herbruikbare testdata processen parametriseren en inbedden in hun geautomatiseerde test- en CI/CD pijplijnen. Gegevens worden vervolgens gevonden, gemaakt en voorbereid terwijl de tests worden uitgevoerd. Hierdoor wordt de afhankelijkheid van een overwerkt beheerteam weggenomen.

In principe kan elke techniek die momenteel door dat beheerteam wordt ingezet, op verzoek beschikbaar worden gesteld aan testteams. De voorkeursaanpak van Curiosity creëert selfserviceportals waarmee testers deze gegevensprocessen kunnen gebruiken in hun geautomatiseerde tests:

Bekijk Test Data Automation in de praktijk

Test Data Automation bouwt daarom voort op de technieken die tegenwoordig gebruikt worden om GDPR/AVG naleving voor testdata te waarborgen. Het integreert deze processen in een holistische testdata oplossing die ook het gronding en Agile testen mogelijk maakt.

Klinkt dit te mooi om waar te zijn? Kom en bekijk Test Data Automation in actie. Doe met Curiosity en ViQiT mee op 24 juni. Zet uitdagingen vanuit GDPR/AVG om in een kans voor beter en sneller testen!

 

References:

[1] Danny Palmer (ZDNet: 20/01/2020), GDPR: 160,000 data breaches reported already, so expect the big fines to follow, Retrieved on 15/04/2020

[2] Luke Irwin (IT Governance: 09/03/2020), Infographic: Cyber Attacks and Data Breaches of 2019, retrieved on 15/04/2020/

[3] BBC (08/07/2019), British Airways faces record £183m fine for data breach, retrieved on 14/04/2020.

[4] British Airways faces record £183m fine for data breach

[5] British Airways faces record £183m fine for data breach

[6] Greg Sterling (Marketing Land: 04/12/2019), Nearly all consumers are concerned about personal data privacy, survey finds, retrieved on 15/04/2020.

[7] Thomas C. Redman and Robert M. Waitman (Harvard Business Review: 28/01/2020), Do You Care About Privacy as Much as Your Customers Do?, retrieved on 15/04/2020.

[8] Infographic: Cyber Attacks and Data reaches of 2019

[9] Infographic: Cyber Attacks and Data Breaches of 2019

[10 Rob Davies and Dominic Rushe (The Guardian: 14/07/2019), Facebook to pay $5bn fine as regulator settles Cambridge Analytica complaint

 


IN ENGLISH

 

Masking is not a complete test data solution: Moving from GDPR compliance to rigorous and rapid testing

Curiosity have written fairly extensively on the impact of the GDPR on testing. The below infographic summarises our thinking. It draws on news and research from 2019-2020 to show the need to address test data privacy issues today:

The stats tell a pretty consistent story: the risk of a data breach continues to rise, as do the associated fines and brand damage. Meanwhile, the most effective way to mitigate this risk in testing is to limit the sharing of sensitive information to test environments.

I’ve listed the sources for the infographic below and I recommend that you take a look around to see just how high the stakes are for GDPR compliance. But first, let’s consider some ways in which GDPR compliance might impact testing and development, before considering what a good and bad response to this challenge looks like.

If the proposed approach sounds interesting, be sure to join the joint Curiosity and ViQiT webinar on June 23rd to see “Test Data Automation” in action.

The significance of the GDPR for testing and development

The impact of the GDPR on testing and development can be far-reaching. The particular issues that might need addressing in QA include:

  1. The logistics of fulfilling the “Right to Erasure” and “Right to Portability”: Organisations’ IT estates are often not set up to find and either copy or erase every instance of a person’s data “without delay”. Test environments are often sprawling and poorly understood, including legacy components and uncontrolled spreadsheets. Organisations today therefore rarely know reliably where sensitive information resides, and even fewer have the techniques to identify/copy/erase every instance of one person’s data “without delay”.
  2. Demonstrating legitimate grounds of processing data in QA: Structures are often lacking for demonstrating that each use of personal data in testing and development fulfils one of the grounds for its legitimate processing. These grounds include active and informed consent, legitimate business interest, and national security.
  3. Compliance with data minimization and limitation: Organisations must furthermore only share enough data with as many people as are required to fulfil the legitimate grounds for data processing, and those people must keep that data for only as long as required to fulfil that purpose. Organisations should be able to demonstrate this, but this is again a challenge when many organisations simply do not know what data resides where, nor how it is being used.

The challenge of test data compliance

It’s worth emphasising also that the maximum fines for non-compliance have increased substantially, and national agencies have already shown willingness to impose them for Data Breaches.

Ultimately, the best defence against sensitive information leakage is to limit the number of people and places to which sensitive information is shared. QA environments are an avoidable place to which PII is routinely copied, and testing is therefore a good place to begin in the battle to ensure GDPR compliance.

Test data masking is a common technique deployed to reduce the risk of exposing sensitive information to less secure test environments. Anonymizing production data can soften the impact of compliance requirements in testing; however, it often also introduces significant bottlenecks in testing and development.

Masking data consistently from numerous sources is slow and complex as it must retain the complex relationships which exist within and across those data sources. Often, a central Ops team must work overtime to fulfil constant requests for data refreshes, but they can never deliver data fast enough to parallel test teams:

Precious QA time is then wasted waiting idly for out-of-date copies of production, while tests fail due to misaligned or outdated data. Testers and automated tests further compete for the same data, leading to further delays as data is either constrained or has been used up.

Copying production data furthermore does nothing to improve the quality of production data.

The historical data sets by definition lack the data needed for testing unreleased functionality, while production activity focuses almost exclusively on “happy path” journeys through the system. Production data therefore lacks the outliers and negative scenarios needed for sufficient test coverage, leaving systems exposed to damaging defects in production:

Moving to a complete solution

A complete test data solution must look beyond the removal of PII from test environments – it must also ensure that the data testers need is readily available when and where they need it. That means data combinations for each and every test, available in particular test environments at the speed demanded by automated test environments and iterative delivery.

The good news is that this approach, which Curiosity call “Test Data Automation”, builds on many of the skills and technologies used currently in Test Data Management. The following techniques can be added readily to existing masking and subsetting processes:

  1. Synthetic test data generation: Generating combinations of data not found in production data plugs the gaps in test coverage stemming from low variety test data. Today, data generation can furthermore be readily integrated into data masking, adding in any missing combinations automatically as anonymized data moves to test environments.

This is a quick win for increasing testing quality while retaining test data compliance. It produces test data sets that do not contain sensitive production information, but do contain the outliers, edge cases and negative scenarios needed to test new or updated functionality.

  1. On-the-fly test data allocation: Test data “allocation” can today replace the provisioning of full-size data copies, allocating exact data combinations based on test case definitions. This allocation is furthermore possible “just in time”, finding and making data combinations as tests are generated or executed.

 In this approachch, each test comes equipped with an up-to-date and unique data combination, cloned and allocated as it runs. This eliminates the delays caused by manual data provisioning and invalid test data, as well as the frustration of competing for shared data sources. Each test and each tester instead has their own isolated data set, available on demand and in parallel.

  1. Standardized, re-usable TDM processes:
    To enable true QA agility, the dependency of testers on a data provisioning team must be removed. The silo between test data provisioning and test execution must be eliminated, providing on tap access to rich test data.

One way to achieve this is to make the processes used in data provisioning re-usable by test teams themselves.

Fortunately, these processes can be readily automated. They are by definition rule based, as they must reflect the relationships that exist in complex data. They can therefore be standardized and exposed to test teams on demand.

In this approach, test teams can parameterise and embed re-usable test data processes within their automated testing and CI/CD pipelines. Data is then found, made and prepared as the tests run, removing the dependency on an overworked Ops team.

In principle, any technique currently deployed by that Ops team can be exposed to test teams on demand. Curiosity’s preferred approach creates self-service web portals to enable testers to re-use these data processes in their automated testing:

See Test Data Automation in practice

Test Data Automation accordingly builds on the techniques used today to ensure test data compliance. It incorporates these processes in a holistic test data solution that also facilitates testing rigour and agility.

Sound too good to be true?  Come and see Test Data Automation in action. Join Curiosity and ViQiT on June 23rd for our joing webinar, Turn GDPR Compliance into an Opportunity for Better, Faster Testing.

References:

[1] Danny Palmer (ZDNet: 20/01/2020), GDPR: 160,000 data breaches reported already, so expect the big fines to follow, Retrieved on 15/04/2020

[2] Luke Irwin (IT Governance: 09/03/2020), Infographic: Cyber Attacks and Data Breaches of 2019, retrieved on 15/04/2020/

[3] BBC (08/07/2019), British Airways faces record £183m fine for data breach, retrieved on 14/04/2020.

[4] British Airways faces record £183m fine for data breach

[5] British Airways faces record £183m fine for data breach

[6] Greg Sterling (Marketing Land: 04/12/2019), Nearly all consumers are concerned about personal data privacy, survey finds, retrieved on 15/04/2020.

[7] Thomas C. Redman and Robert M. Waitman (Harvard Business Review: 28/01/2020), Do You Care About Privacy as Much as Your Customers Do?, retrieved on 15/04/2020.

[8] Infographic: Cyber Attacks and Data reaches of 2019

[9] Infographic: Cyber Attacks and Data Breaches of 2019

[10 Rob Davies and Dominic Rushe (The Guardian: 14/07/2019), Facebook to pay $5bn fine as regulator settles Cambridge Analytica complaint, retrieved on 15/04/2020.


Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *