Tag: Regulatory Compliance

You can almost feel it happening, can’t you? Every time there is an introduction of, or a change to some regulation or another, the vultures of the legal, security consulting, and even security product vendors spin up their marketing machines to invent new promises on how they will ‘guide you through the pending minefield’.

The thing is, I in no way blame them. I’ve likened selling security to selling insurance, in that no-one WANTS to buy something that seems to have absolutely no tangible benefit to the bottom line (it does though; How Information Security Enables Transformational Change). This results in a vast majority of organisations taking extreme liberties with the terms ‘reasonable’ and ‘appropriate’, which is as specific as most regulations go in terms of meeting their requirements.

Unfortunately, regulations are written by lawyers, who have a language all of their own. How is an IT Director supposed to translate legal-ese into geek-speak without some help? That’s where a PROPERLY run security program comes in; the translation become almost unnecessary.

I have made statements like this many times; “If an organisation was doing security properly, they would already be [enter regulation name here] compliant.”

Bold statement, but think about it this way:

  1. ALL information security and most compliance regimes relate [at least in part] to the protection of data
  2. The principles of information security have not, and will not ever change
  3. NOT doing these basics is the fault of the organisations, not the regulators (except PCI)

The only thing that’s different from one compliance regime to the next is how you report what you’re doing. PCI requires a very detailed (though mostly meaningless) controls-based Report on Compliance, SoX and HIPAA require something else, and the old Safe Harbor just required a SELF-assessment (and you wonder why it failed…).

Regardless, the underlying validation evidence is the same; policies, procedures, standards, operational integrity, incident response and so on. You are either doing these things or you’re not. And let’s be clear, you should be.

“But they’re moving the goal posts!” is a complaint I frequently hear, and is usually the foundation of an excuse to do nothing. Just because YOU don’t know where the goal posts are doesn’t mean they’ve moved. All that really happened is that every time a regulation comes out and they ask for more and more detail / accountability / transparency etc, it further exposes the fact that you weren’t doing things properly in the first place.

The General Data Protection Directive (GDPR) for example is freaking organisations out with its potentially enormous penalties. Penalties for what? Not using data for its original intent? Not obtaining explicit customer consent? Not LOSING the data in a breach? How is ANY of that unreasonable!?

OK, so the above is a gross simplification of the GDPR, but it’s not far off, and frankly, Privacy Shield will be even easier. If your organisation is not in a position to meet the intent of these data privacy regulations, then you are part of the reason they exist in the first place. And if your security program is in such a state that the vultures have easy picking over the carcass of your IT budget, that’s your fault too.

Non-compliance with any regulatory requirement relevant to data protection is just a symptom of the same underlying problem; a crap security program. Fix that, worry about the reporting afterwards.

In a recent article in SC Magazine; “An Inconvenient Truth: New Customer Data Regulations Coming” Jeremy King of the SSC suggests that Payment Card Industry (PCI) “provides the most complete set of data security standards available globally.” I can only assume he means that the PCI Data Security Standard (DSS) contains a list of basic security controls every organisation should have in place, and not that the PCI DSS in any way resembles real-world security.

Because it doesn’t, and you only have to look at the number of breaches involving ‘PCI compliant’ merchants and service providers to see that PCI, by itself, does little to prepare organisations against the challenges they face.

PCI compliance is a commercial obligation, nothing more, and any fines levied are only paid because the merchant or service provider who was breached wants to keep taking plastic. The Payments Services Directive 2 (PSD2) and the General Data Protection Regulation (GDPR) will be LAW in the 28 countries of the EU, and attract both legal and financial repercussions that could potentially cripple even the largest of businesses. No standard based on a bare minimum set of controls will ever protect personal data in a meaningful way.

Nor will any ISO standard, or COBIT, or any other information security framework for that matter. At least the PCI DSS puts its money where its mouth is and tells you what controls to implement, all security frameworks do is tell you something is a good idea, never how to do it a manner appropriate to your business.

Because they can’t, only the individual organisation can ever provide definition, and business justification, around the horribly inexact – but regulation standard – phrases; ‘appropriate’ and/or ‘reasonable security’.

The implementation of a security program that can meet the intent of ANY regulation includes very specific processes that the PCI DSS does not cover, and if they do, it’s in a very limited fashion with no-where near the emphasis required to express the importance. For example;

  1. The Risk Assessment (RA) is way down in section 12, when it should have been the very first thing performed before PCI compliance was even contemplated. An RA performed in-line with the PCI DSS would not be sufficient.
  2. The only nod to Disaster Recovery and Business Continuity Planning is a single bullet in 12.10.1, when these processes are absolutely central to any organisation staying in business responsibly.
  3. The requirements related to 3rd party due diligence are entirely inadequate relative to the risk involved.

…and so on. I have addressed the inadequacy of the actual PCI controls many times, so I won’t bother repeating them here. Suffice to say, the majority of the controls would be no-where near enough.

There are only 3 main ways to appropriately address the current and new tranche of regulations / directives:

  1. Make the CEO legally responsible for security breaches, and apply criminal penalties in-line with the egregiousness of the negligence – Clearly fines don’t worry CEOs enough, perhaps some jail time would.
  2. Ensure the policies, procedures, and standards are world-class – There is no security program without the application of accurate corporate knowledge
  3. Training & Education – This should be self-explanatory

Compliance with any of the upcoming regulations is no different from any regulation already in place. There is nothing outside of an appropriate security program that will ever be required, so just do the things you should have been doing from the very beginning.

Security is not easy, but it IS simple.

This will be my first blog where I am going to a) plead ignorance; b) ask for your input, and c) actually listed to someone else’s opinion (potentially).

[gasp!]

I have just spent all day today going over parts of The Investigatory Powers Bill (IPB), the Regulation of Investigatory Powers Act (RIPA) of 2000, as well as listening to Theresa May’s statement on Parliamentlive.tv, all in an effort to find SOME evidence that it could “…allow Government to ban end-to-end encryption, technology powering iMessage and WhatsApp“.

OK, so that’s just according to The Independent, but The Guardian has their; “Investigatory powers bill: snooper’s charter to remain firmly in place“, The Telegraph has their; “Internet firms to be banned from offering unbreakable encryption under new laws” and so on.

All I could find in the IPB was this;

189 – Maintenance of technical capability

(4) The obligations that may be imposed by regulations under this section include, among other things—

(c) obligations relating to the removal of electronic protection applied by a relevant operator to any communications or data;

(e) obligations relating to the handling or disclosure of any material or data.

…as well as a reference to encryption as it related to RIPA, which states;

21 – Lawful acquisition and disclosure of communications data.

(4) In this Chapter “communications data” means any of the following—

(b) any information which includes none of the contents of a communication (apart from any information falling within paragraph (a)) and is about the use made by any person—

So, first my ignorance; I do not speak Governmental legalese, so I have no idea is the vagueness of this is just way of saying ‘we can do anything we want’, or it’s an established-by-precedent way of saying ‘this is all we can do’.

I have also not read the whole, thing, it’s 300 pages long and makes the PCI DSS look like the last Harry Potter book,

Which brings me to the second part; your input. There will be those who have read not only the IPB, but the RIPA, the Communications Data Bill of 2012, as well as the Data Retention and Investigatory Powers Act of 2014. You also are likely to fall [mostly] into one of only two categories; for, and against.

I would love to hear reasoned thoughts from both, or at least point me to an unbiased Cliff Note version of each!

Finally, listening to someone else’s opinion; anyone who has been nice / bored enough to read my blogs over the last 2.5 years will not have read even one where I was in any way unsure of my opinion / stance. Even when it comes to security (what’s the font for sarcasm?).

In this case, I am 100% on the fence (mostly because of 1. above), but partially because any talk of ‘investigatory powers’ or ‘interception of communications’ will have significant impact on privacy, and the implementation of my real interest; Identity Management.

While my thoughts on privacy itself are public record, the impact of what these Governmental powers will have on putting true Identity Management into effect are far from clear to me. There will be no secure mobile payments, no Internet of Things, and no hiding from your wife if there is something in the middle capable of ‘reading’ my communications. Not because I don’t trust the Government, but because anything THEY have access to will eventually be available to the bad guys.

We work within established rules of decency, they don’t (the bad guys that is).

Basically, please help, all comments / thoughts welcomed.

If the answer is yes, you have clearly not learned any lessons from years of regulatory compliance, breach headlines, every security best practice, or basic common sense. And if you continue to do nothing, for whatever the reason, you likely deserve the bad things that happen to you.

Yes that’s harsh, but non-compliance is all so unnecessary. Just like PCI, nothing the PSD2 mandates is something you should not have been doing a long time ago, and if 2 YEARS is not enough time to fix what’s broken in your organisation, please let me know so I can stop doing business with you.

If you’re a financial institution, did it not occur to you to stay up to speed with the latest and greatest advances in access control? Data classification and meta tagging? Did not the FIRST version of the PSD have enough hints that the ever-worsening threat landscape was only going to increase the security and privacy burdens?

Worse than this are the two major offenders; 1) Payment Service Providers (PSPs) who thought that they were somehow immune to regulation because “it’s not OUR data”, and 2) the FI’s who used them because they thought they could outsource the responsibility.

Yes, security come at a cost, and very little of that expense will ADD to your bottom line, but if it’s an ROI you’re looking for, how about staying is business? Between PSD2 sanctions and potentially EU General Data Protection Regulation (GDPR) fines/sanctions, and maybe even PCI fines if it’s cardholder data you lose, I would say your responsibility is clear.

But it’s not all doom and gloom, the path towards compliance is actually very simple. Not easy, simple.

First, get the CEO and/or Board of Directors involved. if they don’t care, no-one else will, and any project to achieve ANY form of compliance will either fail out of the gate, take twice as long, or cost twice as much. As I’ve said too many times now;

“Let’s be very clear; The CEO sets the tone for the entire company: its vision, its values, its direction, and its priorities.  If the organisation fails to achieve [enter any goal here], its the CEOs fault, and no-one else’s.”

Second, run a risk assessment to determine 3 things; 1) what business assets and processes are affected, 2) what are the gaps between current and required capabilities and 3) how much should you spend to fill those gaps.

In parallel with the risk assessment, fix your documentation!! The cheapest and most important facet of every security program is the one most ignored, thereby rendering everything else you do somewhere on the scale of sub-optimal all the way to completely ineffectual.

Third, do NOT do this just to achieve PSD2 ‘compliance’, do it for ALL aspects of your business, and do it once. Done properly, any progress toward any form of regulatory compliance becomes a standard operating procedure, and eventually the ages-old cliché; business as usual. Anything other than this was wasted effort irrespective of it’s intended goal.

You wouldn’t ask your doctor for a temporary fix would you, security is no different?

In the end, you really only have 2 choices; throw a patch on a gaping wound and hope that you have implemented enough smoke and mirrors to stay under the radar, or do things properly and avoid the worst of the fines regardless of how long it takes to get compliant. While that sounds somewhat counterintuitive, the regulators do not WANT to fine anyone, but if data is lost, it will be the bullshit artist who will be hurt the most.