Architecting Digital Audit Capable Product towards GDPR Compliance

We at ERNIT have pushed ourselves to limit when it comes to following microservices architecture by heart, and while following the SRP ( single responsibility Principle) by its intent, we found ourselves aligned on goal to build rich & diverse set of APIs which we can plug with any bank, enterprise CRM, IoT device or other wearables in our journey ahead

All was going fine till we actually hit the major bank deal in our way whose conversations had begun in fall 2016, and we finally had it through and I was thrown open the challenge of security and compliance along with stringent future regulations like PSD2 SCA (Secure Customer Access) and GDPR (General Data Protection Regulation) and their implementation across our offering. I spent my Christmas vacation figuring out utilizing my past experience in secure broadcasting company NDS ( later acquired by Cisco ) by tweaking our data model, attribute justification, PSD2 SCA mandated checks, building the walls where I reached upon having API Hosting Provider, App Server filter, Rate Limited API Access to pose as a series of digital walls plus Private API Token, and User Access Levels as secondary digital passes for our system access along with few other security measures which we would call secret sauce!

But challenge was and is still real, when it comes to GDPR, one of the trickiest provision calls for consumer has “Right to be informed when his personal details might have been POTENTIALLY compromised”. Yes, you read that right, the word POTENTIALLY. Suppose you have Cloud database whose access you generally guard by whitelisted IP addresses alone, and on one fine day while to accommodate an employee working from home, you released that restriction and did not look back again for few hours. Or, in related another scenario, what if Firewall was not up and running properly for about 5–10 minutes previous day.

These are not one off instances anyone in DevOps and Engineering can understand, but rather regular affairs in software products with active life and development. During such intervals, something may or may not have really happened with sensitive data, but as the technical backbone responsible for my organization, do I become responsible to inform all consumers that “something might have happened, we do not know” sort of communication which may incite them to fears of privacy ?

One may argue that, (such coverups do happen, trust me!), newsletters are posted to customers to explain them fears of not changing their passwords often, and taking them to change password page from there.

In ideal world rhyme: Nobody can prove a breach happened earlier and just we realized it, and then w informed consumer to change password, and he did … job done! Really ??

Brief understanding of impact of GDPR for CEO/CFOs

To understand GDPR, it takes not just learning a skill but the mindset that organization need to have dealt with from top to bottom in it operations. For executives to understand financially, the penalties for violations are huge up to €20 million, or 4% of global revenues for the previous fiscal year, whichever is higher! However, if your organization has gone thru ISO 27001 or PCI-DSS audit before, then it should not be much of hassle

Brief understanding of impact of GDPR for COO/VP/Directors

Just read the Cisco Cybersecurity 2017 Report here and we need not discuss anything further, and please come back to read the next below

Are we building a new System Architecture here ?

The answer is both yes, and no ! If you can absorb GDPR as organization wide awareness and process, then answer is No ; otherwise who knows you might need a separate system and it might depend on how certain compliance system vendors might market themselves to you

Still to convince the thoughts here on, one may recollect under Java Community Process, JSR 003 led the development of firstever release of JMX (Java Management Extensions) in December of 1999; and this was done at time when terminology like DevOps did not exist formally but a need was felt to observe, monitor, and understand the deployed product application behavior and JMX fit well to the need at that time. But that development was the response to the need what system administrators had asked for when deployed system orchestration complexity had crossed then comprehendible levels of management

GDPR is result of years of consumers activism, history of thefts of personal data for marketing, and other data breach lawsuits related noise. So if a technology vendor tells it is next big thing after Y2K, he is in a way justified to say so! Just as any law abiding citizen who follows any law of the land, any corporate small or big working in Europe is expected to comply with GDPR at every level of their organization ; hence a new system architecture is NOT the answer if that is what you expected to hear here

“Computers are magnificent tools for the realization of our dreams, but no machine can replace the human spark of spirit, compassion, love, and understanding” — Louis V. Gerstner, author, “Who says Elephants can’t Dance”

Where do We Begin ?

1. Study & conclude what measures you have already to elicit and record Personally Identifiable Information (PII) ?
2. What relationship your organization has with 3rd parties ? How many of those PIIs are exposed to your 3rd party providers ?
3. Have you addressed the transparency that what data points you are saving for an individual, and why you require those?
4. Does your storage system has any risks associated with its security?
5. Have you gotten legal expert advice on if all data subjects are willingly agreed between consumer and your organization ?
6. Create a Risk Based Metrics Report on vulnerability assessment and penetration tests to outline and weakness in your data defence
7. Continuously monitor the data structures and database to ensure your data stays exactly where it is supposed to
8. Encrypt your databases. Easy it sounds, but in reality how many of companies we know who ensure encryption of all PII points ?
9. At ANY time dealing with questions on data, ask yourself question again: Is it just “user data”, or “user financial data” ? Chances are great that for latter you already might be complying to a great degree via regulation like ISO 27001 or PCI/DSS if you ever had such audit. This question asking shall differentiate your focus on GDPR related requirements alone which I am trying to address here

From personal experience at ERNIT implementation of step 6, I would say the metrics can grow manifold the size if role-based abstracted access is allowed in the system for the same PII data item, and that must be ascertained in the framework you pick to deliver this metrics report

Solution ? What the heck !!

More often, restatement of problem and iterating over it leads us to many of the solutions, as one of my favourite book also suggested. So lets begin all over again to restate the problem statement and build a divide-and-conquer solution

1. I need a system to record all PII items in separate, more secure, encrypted data structure — Is that any rocket science ?
2. I need to restrict access of PII — Get a suitable database design and system admin
3. I need to justify each data point I am saving for a user and letting him/her know about it — Get a lawyer to draft such privacy policy and be honest about what all information about user you are going to save. That could including his/her home wifi name, or his/her last few IP address locations as long as you can “justify” the need. Is there any real need to to frown over it?
4. In case of requests for user profile deletion, I must be able to choose what data points to keep here on and to justify those — Get a lawyer to certify what data points you would still like to keep for auditory legal purposes. Familiar ?
5. At any point of time, know who is coming into system and doing what, and logging out. — To ensure your product success, haven’t you already invested in marketing A/B tests or other growth hacking to monitor system feature usage ? Do you not see building a bigger picture audit system on top of it all ?
6. Trickiest of all — Article 5 and Article 32 of GDPR — Follow above 5 steps for each and re-state the problem statement for each bullet point of these articles. Otherwise come back in 3 months time to read sequel of this article as I publish it today on 2nd April 2017, before 13 months of GDPR becoming a reality :-)

APIs … Huh I knew they Always are an Answer

Wait, I am not done yet — Lets revisit points 1–5 yet again :) and concretize problem defining once again!

“If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.” — Albert Einstein

After building strict micro-services based architecture system, then delivering suitable security gating and penetration test readiness, NEXT is here how I am building our GDPR compliance and internal governance system it to throw little hint here ( To get you started and motivated )

• Investing in suitable internal APIs building where all available PII items can be mined ( Question you should ask is who can execute such API?)
• Investing in APIs that can reflect at any stage difference between agreed data items, and additional ones taken up, which should then feed to trigger an alert for end-user to sign new terms-of-use with additional data point persistence consent
• Investing in operational intelligence APIs building who can reflect any time overall state of affairs related to particular user’s interactions with our systems
• (Futureproof) Investing in APIOps i.e. building internal systems that “monitor” all incoming queries for PII items and requesting system monitor/threads/user details and reasoning captured from request context. And specifically , are our 3rd party providers getting hold of any of that information ? (Article 46)

I have not decided yet how our GDPR Compliance & Internal Governance dashboard will look like which will be based on above 4 bullet points to begin with, and would love to hear your comments around it !

And more on concretizing implementation steps towards Article 5 and Article 32 you may hear from me in sequel to this article

Do not let Perfect to be Enemy of Good

Strassen algorithm of nxn matrix multiplication was published in 1969 with execution efficiency of O(n 3), and it took 2010 for for Coppersmith-Winograd to propose an algorithm to make it more efficient to O(n 2.37). Building a solution sometime will require you make use of available data items and existing (un-optimal / less accurate) level of smaller solutions you already have, than perfecting those micro-solutions first, and we are just 13 months away from 25th May 2018; plus since your organization’s data points and handling is not going to match with any other, therefore there is uniqueness element also involved for everyone to bake their own GDPR cake. Needless to say therefore I advocate for a GDPR Compliance initiative in every European enterprise to begin ASAP while tomorrow is step of delay

DISCLAIMER: I am not legal expert, nor anyone appointed or educated me to be expert on GDPR. Only by my experience of implementing trickiest regulations prior, I can say that it is not going to be straightforward ride of implementation for anyone. Making of this article did require me reading, implementing, experimenting lot of stuff and also sittings with 3 CEOs and inputs considered from 2 of country’s very exclusive Regulation expert lawyers; but I request you to do your own research on the subject. Careful security building blocks and microservices architecture could be technical preconditions for you, plus a lot of street-smartness and compliance thinking need to groomed at your organization (Article 40) as well. Read one example here and ask yourself, are you ready for stepping up and set example for others?