You Owe Them

Last week I attended a conference and listened to a talk by Aleth Gueguen about GDPR. A recurring theme on the talk was maintaining a reasonable level of security and keeping the end user’s data private. Most GDPR talks tend to go over the list of things you need to comply with, and how to do everything by the book, but this was a bit different. Aleth showed more concern for the users and less for the risks for the organization.

Later on that week, on a long layover, I had a chance to sit down with Aleth (over a Vienna Schnitzel). One of the things we talked about was the spirit of the GDPR compliance.

The spirit of the regulation is to keep your user’s data private and safe. It is not about checking boxes and sending out annoying emails about policy changes.

That got me thinking about security practices in general, especially after a few long client meetings that seemed to be missing the point.

We tend to focus on the tools, process, best practices and what we do daily, but our motives are “selfish” and aimed for the company’s interests. The actual people whose data we hold usually comes in second if at all. And even when we do, it’s because of legal liability and not so much from concern for the users.

The same goes not just for security experts, but for developers and DevOps engineers. You are not implementing security just because you need to, or because a big client had you to go through a due diligence process.

When you are writing new code, be mindful of the end users, the people whose data you will be processing and serving. It’s not about the shiny new UI, or a neat feature, or a fully automatic deployment that runs 100/day in production. In most cases, your work is not as crucial to the user, or your client’s user’s, as having their trust breached. By you.

I believe that in the future, we will see more litigation related to data breaches, and more directors will and should be found accountable. In most cases, I can’t honestly say that tech leaders are doing the minimum required, and now highly available security measures to protect their users.

So the next time you read new compliance guidelines, try to understand the spirit of it, not just how to implement it. It is a way to peek into the future (if only that was the case for new JS frameworks).

What can you do about it?

• Keep the users in mind
• When retaining information think — Do I really need to keep it?
• Try to map out where you are keeping personal information.
• Think about some non-obvious data that could be used for exposing your customers.
• When possible — use encryption.
• When there is an opportunity to improve security — do so, don’t brush it off for later.
• Don’t have a — this is the way it’s always been, why change now?
• And my all time favorite — “We don’t have time for security, we need to release it asap”. Get it out of your vocabulary. Unless you do proper risk assessments.

Want to learn more about DevSecOps and Security? Join the DevSecOps Thursday list.

Originally published at pinesec.com on November 12, 2018.