Sysadmin blog Holistic IT is hard. There are those among us who want to purchase hardware, software, services or so-called turnkey "solutions" – as vendors call them – bearing logos and stickers and otherwise don't require any architect-level thinking. None of us wants to dive deep into compliance regimes to understand what we need to do.
Unfortunately, however, most IT compliance isn't about having certified or validated hardware, software or services, but about practicing sane approaches to IT.
These approaches to IT emphatically aren't "be the most conservative you possibly can" in large part because if you followed that advice you wouldn't be keeping up with modern security practices, or embracing new technologies that can simplify existing deployments.
Compliance isn't about grabbing a fist full of whitepapers and blindly lashing together some tin. Compliance is about being able to stand in front of a judge, explain your architecture, and defend the decisions that led to that design. Think of it like passing your VCDX, but if you fail you might go to jail.
All this will come into sharp relief in on May 25, 2018, when the European Union's General Data Protection Regulation (GDPR) takes effect.
GDPR is a beautifully vague document full of inane blither that doesn't actually do something helpful like spell out explicitly what IT teams need to do in order to become compliant. It contains phrases like "implement appropriate technical and organisational measures" and "take into account the state of the art".
Get it wrong and the consequences are serious: today's fines of up to £500,000 now at £17m – or 4 per cent of total annual worldwide turnover.
Fear not. The broad strokes of the document can be boiled down into something comprehensible if you've read enough of these things. First up, baking data protection into all aspects of IT design at the point of design. Not bolting things on after the fact, nor relying on tickbox IT measures that supposedly deliver benefits and don't require you to actually think about things (also, the number of people who buy a tickbox widget capable of enhanced security and then never turn that feature on is staggering).
A tickbox IT admin might, for example, believe that using a database (or storage) that claims to provide encryption is "good enough" to meet GDPR standards. In truth, it probably isn't. Even a lobotomised security practitioner would tell you that, eventually, the keys to that encryption will get out, or a flaw will be found, etc. The database contents will get out eventually, they always do.
So the "state of the art" can be argued to include things like pseudonymisation of personal data. Alternately, it might require the encryption of data rows within the database separately and in addition to the encryption of the database as a whole. It probably also means you have to have processes in place to regularly test how appropriate and secure the data really is, and augment your approach if it fails to meet modern standards.
What data is appropriate to collect is really also a matter opinion, with the general rule being "the minimum required to do the job". It is also implied that modern data protection standards could require the deletion of data when there is no good reason to keep it. Unless some other regulation requires that you keep it.
Marketing and sales are going to hate GDPR a lot more than IT.
The GDPR's discussion of the "state of the art" also means you can't sit in the corner and cultivate ignorance. A great example of the kind of person this targets are those who feel the very concept of automated incident response is a type of professional affront, that their ability to defend their network perimeter is unquestionable.
In today's security circles, the guy babbling about how nobody can possible penetrate his network is the equivalent of the racist uncle that makes everyone uncomfortable at Thanksgiving. Under the GDPR that fellow becomes a liability.
This isn't to say organisations must constantly adopt the bleeding edge. It means that they must know what the new hotness is in order to be able to explain why they chose to implement it (or not). "It threatened my cushy job" is, sadly, unlikely to be an acceptable response.
Somewhere in there organisations need to have adult discussions about notification standards for when data breaches occur. They will occur, despite all the effort put into preventing them, and under the GDPR there's no excuse for not having a plan for when that day arrives. A personal data breach is "a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed."
The Americans, of course, consider data breaches only worth mentioning if it is felt that the information lost can lead to fraud or identity theft, a significantly laxer standard. This will complicate notification where data is held in the US and the company the data was outsourced to is complying with their local laws and not GDPR standards. Good times.
We could all have endless debates about which specific technologies to use, but what's important is that nothing is really banned. If you wanted to roll your own DIY data centre and weld together a bunch of open-source packages, that's great. Want to build a whitepaper wonder? Go hard.
What matters is that you can explain in detail what you did, why, and you have a snowball's chance in a neutron star of having other IT experts not tell a judge you're a raving lunatic. Oh, and that you take into consideration all the right things during the design phase. And that you have enough influence to ensure marketing and sales aren't collecting more info than they need, storing it inappropriately, or for too long. Plus all the rest of it.
Compliance has always been more than just stickers or labels. GDPR will mean, more than ever, you need to think – and act – holistically. ®