Privacy and metrics of testing and staging environments

One of the most vital aspects of building any system is the testing stage. With wide demographic, complex Customer Identity Access Management (CIAM) systems, this is arguably even more crucial. Testing is the development equivalent of proofreading. Developers make mistakes, they are, after all, human beings, and we all make mistakes – that’s why testing has taken on an almost religious air in some environments. Many years ago, I used to do security software testing, and there always seemed to be an uneasy tension between testers and developers. My defect reports created a raft of arguments, disbelief, followed by slow acceptance. Things have thankfully changed, well, at least they are changing. Testing, code quality, and staging environments are much more part of a holistic process and this is partly down to DevOps which has blurred the lines between the developers and QA.

In the past few years, the notion of devops has changed the way products and solutions make it into production. This is a discipline that recognizes how continuous testing, throughout product development, creates better products for all. However, although this is a positive step forward and one that should improve not only production level product but the process to get it there too. However, there is still a hurdle to overcome and this is data security during the testing process.

Security in staging environments in CIAM, the last QA frontier?

Data breaches have become ever more present in our day-to-day business. In 2017, we had announcements, yet again, of massive customer data breaches from the likes of Equifax, Uber and Yahoo. These breaches were seemingly in production systems, but staging environments also pose a potential weak point for data exposure. Staging environments are often built around real data, sometimes real but old data, but whichever, this is still personal data. It contains information such as the user’s name, address, date of birth, and so on. The risk matrix includes inadvertent admin access of personal data to emailing of these data to testers for review to actual external hacks.

CIAM platforms, especially those that actually verify the user, have to be tested using data that represents the user demographic, and that mimics the list of user journeys the system supports. In a CIAM system, these data are often old, but real, or even in some cases, live – this is especially the case when testing complicated user journeys that are difficult to replicate using emulators.

What you want to avoid at all costs is letting untested code get into production or even into final staging environments. Even in SIT, if real data is used, even old data, then you must ensure that it is afforded the same protection as you would in live production.

Things to consider to protect data during SIT testing:

1. Data quality: Sometimes you just have no choice but to use real data to test against – this also includes real, but old data. If possible, you can also look at de-identification of data to avoid exposure. If you can use emulator data/data-masking, then do so. It may mean some extra coding and maintenance, but it avoids personal data exposure.
2. Data storage: The same data protection afforded to your real customers in production needs to be replicated in your test and staging environments. This means encryption for data in transit and at rest.
3. Code security: Secure coding practices should be a design remit before the developer even begins. Insecure coding techniques are behind many threats as they build vulnerabilities into the code. Code metrics and testing using external code analysis can help to build secure code, but your own internal test metrics should also become part of the ongoing test environment – Sealights has a good resource you can read on test metrics.
4. Hardening endpoints: The same security measures you take in production, such as robust authentication for administrators, should be used in the staging environment.
5. Good security policy and best practice: I have witnessed with my own eyes, an administrator email my own personal data out to all and sundry after a test I carried out threw up a defect. Make sure that you have security policies in place to prevent this sort of thing happening.

2018 looks set to be a year that many organizations change or add to their internalized IAM systems to offer a more broad CIAM solution. This will mean changes to the way the systems work, making them more open, using self-registration, and integrating with external verification services. Your CIAM system will be highly likely to need extensive SIT testing with these external systems, and in doing so the risk of exposure of personal data will increase. With the tightening of compliance and regulations like GDPR and PCI-DSS around data privacy and protection, you will be expected to protect data across all parts of the process into production. Let’s not let cybercrime win the data war before we even get our IAM platforms into production.