GDPR and cybersecurity: it's EU smackdown time!

Well, April showers may bring May flowers but this May you also get two new EU regulations that might wet your spirits: GDPR and new cybersecurity standards.

Note: I'm not a lawyer nor do I play one on TV. These regs are far-reaching and still a little ambiguous, as big regulations usually are (remember HIPAA?). It's up to you to figure out how to comply.

Now back to our regularly scheduled program.

GDPR

The General Data Protection Regulation goes into effect on May 25, 2018, so you don't have a lot of time to get this sorted out. This is from the European Union but it covers all data on EU citizens, regardless of where that data is kept, or where the organization holding or processing the data is located. So in effect it's worldwide.

The underlying purpose of GDPR is to protect the private data of EU citizens, basically anything that could be used to identify someone, including PII like social insurance numbers, addresses, pictures, and so forth. The intent was aimed at social networks and cloud providers, but it spills over into applications that process records about people, whether financial transactions, HR records, CRM data, or what have you. I think it's safe to say if you have any databases or apps with objects that model actual human beings, you should review these regulations carefully.

Some of the regs clearly impact your data layer, as the use of encryption or tokenization is suggested in order to achieve what they refer to as "pseudonymisation;" i.e., if the data is hacked it's not very meaningful. And clearly they want you to store encryption keys separately from the encrypted data.

Cyber Security

The UK, meantime, has decided after the WannaCry mess, that it's had enough and will open up a big can of whoopass on companies that don't address cybersecurity vulnerabilities. The EU passed a directive on network and information security (NIS) in 2016 with an implementation deadline of May 2018. Boy howdy, May is looking like a Big Month for compliance stuff. Of course, since these directives and regs were published years ago, I'm sure everyone has long since put full implementations and audits in place.

OK, just kidding.

Her Majesty's Government (HMG) (as a Yank I love saying stuff like "Her Majesty" because Downton Abbey and The Crown and let us not forget Sir Sean Connery, the Real James Bond).

Anyway HMG have already shown their teeth with respect to lazy cybersecurity measures--in 2016 British ISP TalkTalk got slapped with a £400,000 fine for failing to prevent a massive 2015 data breach resulting from a simple SQL injection hack. (You are forgiven for asking how on Earth people are still getting in via SQL injection in the 21st century.)

All things must converge

These two directives converge at the level of app security and design, at least for the purpose of this blog post. I'm not implying that things like network edge security, physical infrastructure, employee policies, and similar measures aren't vital: I'm just not going to talk about them. 

Instead, think about your legacy apps. The ones written in VB6 or PowerBuilder. The ones that have been around for years and years, that you still need and use, that have been added on to, modified repeatedly, worked on by succeeding generations of developers long out of touch with the origins of the code base, swollen into hideous monstrosities of endless if..then..elseif blocks.

Those apps are the open window next to your triple-locked front door.

Did you check every field?

I asked that question to a lead developer recently about a forms-intensive app with >1MLOC. Most of those forms were just constructing SQL queries and the code was pre-.NET, so maybe they were using something smart like home-grown parameterized queries or escaping all the user input or maybe they were (gasp) constructing SQL queries on the fly. You only need one field with a opening for a baddie to inject a SQL trick like "105 OR 1=1" which gets turned into a SQL string: 

SELECT * FROM Users WHERE UserId = 105 OR 1=1;

And that returns all rows since 1=1 is TRUE. Because that's actually how SQL injection is still a thing.

It's the framework, dummy

There's nothing inherently wrong with VB6: it taught a lot of non-programmers to fall in love with writing code and building apps. But it was Early Days in the world of client-server computing, and many of the hacks that are well known today just weren't widely recognized or understood back then. So the VB runtime didn't have native support for things like parameterized queries. It's not that they couldn't be added later, as this link shows, it's just that you probably didn't have them originally and someone had to party on a lot of code to put them in. 

Whereas .NET makes it simple to do it right the first time.

And now GDPR

The cool/terrifying thing about GDPR is that it reaches globally to companies that have any PII on EU citizens. Recently I had the chance to look at a customer app that, on occasion, used PII in forms & reports.

Here was a perfect example of where roles and permissions needed to be established at an app level for controlling visibility of such sensitive data. For example: You have a large DB of people records, including social insurance numbers for identification (perhaps you are in public sector where those ID numbers are required). Because you have to be able to find a single unique individual, it's not enough to match on name (possibility of many duplicates) or even, say (as is common in the USA) the last 4 digits of the social security number (many possible duplicates). You can always try to match on other things (address, phone) but your app may just show the entire social insurance number for the user to match on. Now you're displaying PII for someone: are you sure they are not a citizen of the EU? If so, are you in compliance with GDPR or are you in violation? Is the PII kept in plain text in the database, or is it encrypted? 

There are, of course, a myriad of ways to get around all these problems (you could compare a hash of the social insurance number, requiring that the user knows that number rather than retrieving it from the DB and showing it). Not my job to teach you--not my field of expertise, frankly, although it's a great place to play "whatabout" games.

No, the point is that legacy code is inherently problematic, and as more and more requirements and regulations surface it gets increasingly more expensive to keep investing in old crappy code instead of biting the bullet one time to modernize it and just getting on with it. 

Want to find a way to make getting off legacy affordable? Talk to us. Otherwise, you might wind up like this guy: