Category: Security Good Practices

I don’t think anyone can doubt that the regulatory landscape relative to data privacy has tightened significantly over the last few years. I also think few will doubt that this tightening will continue, given the enormous growth in things like big data analytics, artificial intelligence, alternative payment methods, mobile, and of course, the Internet of Things.

Most businesses have given considerable thought on how to take advantage of these things, and may even have existing projects in place to exploit them, but without a program of IT Security Governance in place to provide the right input, at the right time, these projects could rapidly become a regulatory and financial albatross.

But what do I mean by Governance? According to Wikipedia, Governance;”…relates to the processes of interaction and decision-making among the actors involved in a collective problem that lead to the creation, reinforcement, or reproduction of social norms and institutions.”

According to ISCA – The Governance Institute, it is; “…the way that an organisation is directed and controlled. It is the toolkit for the processes and the oversight which drives the highest standards of leadership, accountability and behaviour. Strong governance helps boards and organisations to achieve their goals by acting appropriately and fairly.”

I could find 100 different descriptions, and none of them would be wrong, or even inappropriate to my message, but it’s a lack of understanding of what true Governance is that causes so many organisations to ignore it altogether. Without Governance, you don’t have any form of compliance, internal or external, let alone real security. End of story. It is one of The 4 Foundations of Security, and arguably the most important.

I like to simplify, so to me Governance is; “The business side and the IT side having appropriate conversations.” That’s it. The business side will ALWAYS own and control an organisation’s goals, and rightfully so, the ONLY role of IT is to support and enable the achievement of those goals. Nothing more.

That said, exclude IT and IT Security from ANY aspect of the strategy and planning processes and you’re in for a world of hurt. Security is never more expensive or ineffectual than when it’s retrofitted on a broken process. IT is NOT there to say no, they are there to say, OK, but do it this way from the beginning. IT Security are no different, and there is not one regulation on the planet that cannot be met if the proper planning is performed at the beginning.

As an extension to this, without Governance, Legal and IT and IT Security department can and do get in the way. It’s their JOB to protect the organisation! Too often Sales goes crying up to the CEO that someone is in the way of them doing business and an edict comes from on high that completely circumvents the checks and balances that are there for a very good reason.

Governance controls this process and ensures that the needs of all sides, and therefore the entire business, are met with the minimum of delay or inefficiency. It is represented by Legal, IT, IT Security, HR, Sales, Marketing, you name it, everyone must have their say. There is simply nothing more important to a business’s health and future than a well run cross-functional unit that has executive management support.

As an example, think about how important big data analytics has become to some organisations whose very existence is driven by transforming data into information. Harmless content can become personal information, ‘AI’ can create profiles that would attract significant penalties without the collection of appropriate consent. With input from Legal, IT Security, and Data Analytics, a comprehensive strategy can be put in place to develop a product that meets regulatory needs. Then Marketing and Sales can do their thing and everyone wins.

Governance is both the way and means to get these teams in the same room and talking about the same goal, no other function in the organisation has this much influence.

And it’s all so simple.

[If you liked this article, please share! Want more like it, subscribe!]

Don’t get me wrong, I love toys. I’ve had every version of the iPhone since its inception and have, quite literally, a drawer full of the old ones. I also cannot even tell you how many electronic gadgets I have sitting in boxes that I had wanted badly, used once or twice, and eventually packed away after watching them gather dust for months / years on end.

I could start my own eBay with this stuff. Or a museum.

In this context, technology is harmless. Every toy I have is offline, provides no access to sensitive data of any sort, and simply demonstrates that I have more money than sense. Though in truth, I have very little of both.

This becomes a far riskier proposition when organisations throw technology at broken processes, especially when those processes are directly related to some compliance / regulation requirement of some sort. PCI for example, has driven technology purchases (both infrastructure and outsourced managed services) like no other regulation before it.

This is because the DSS called for technologies by name; firewalls, anti-virus, intrusion detection/protection systems, file integrity monitoring and so on, and instead of performing a risk assessment FIRST, most organisations went straight out and spent money on things that likely provide no security benefits whatsoever. It takes significant expertise to extract value from technology.

And no technology related to information security can ever provide benefit unless:

  1. It was purchased to fulfil a properly defined business need (via risk assessment, business impact analysis, and Governance)
    o
  2. It is appropriate for the current needs, but can scale for future growth, or reduce in the case of managed services (speaks to controls selection and vendor due diligence processes)
    o
  3. It was purchased with full understanding of who is responsible for the following, and how they are to be accomplished:
    i.   Installation and integration with established processes
    ii.  Ongoing maintenance and updates
    iii. Monitoring and incident response
    0
  4. It has properly defined metrics to measure its production capability against the originally defined requirements, and those resulting from a changing threat landscape (via vulnerability management and ISMS)
    o
  5. It is constantly baselined against an established ‘known-good’ state. If it’s not simple, it’s not secure. Period / Full Stop.

Think about this another way; every appliance you buy is just a server, with an operating system, running an application, and regardless of how much effort went into hardening this system against an attack, the bad-guys get smarter every day. Secure today is no indication of security tomorrow (just ask Juniper about their backdoor challenges).

The purchase of any new technology is always the last of these three options:

  1. Examine your business processes to determine whether or not you really need to process / keep the sensitive data in the way you currently do. i.e. can you tokenise, truncate, delete entirely, or outsource etc?
    o
  2. Examine your current infrastructure and procedures to see if adjustments here can fill the gaps exposed by the risk assessment and gap analysis
    o
  3. Buy an appropriate technology in-line with the above 5 pre-requisites above.

Equal effort needs to go into maintaining current capability using existing technology and decommissioning obsolete technology as buying new capability, and not one of these decisions falls outside of a properly run security program in-line with business goals.

You really must ask the right questions, or you’ll get what you asked for, not what you need. Security vendors will not help you here, it will be up to you.

[If you liked this article, please share! Want more like it, subscribe!]

If you’re a security professional and there’s a new phrase or product going around with which you are unfamiliar, there’s a better than even chance you won’t need that thing. Ever.

The reasons are myriad, but the major offenders are:

  1. It’s something that product vendors invented to scare you into thinking you’ve missed something; [e.g. Advanced Persistent Threats]
    o
  2. It’s something Gartner was paid to promote into a magic quadrant of some sort, [e.g. most of Gartner’s output]
    o
  3. It sells column inches, or;
    o
  4. It’s something you already have but now it has a sexier name. [e.g. Logging and Monitoring is now Security Incident and Event Management (SIEM)]

For me, this pet peeve started with ‘The Cloud’. Suddenly everything had to be “In The Cloud”, that adoption of Cloud-based services was the only way to stay up with your competition …blah blah blah. Basically The Cloud was the only way you were going to stay in business in the digital age.

“But wait David!” I hear you gasp; “Isn’t The Cloud just an application on the Internet? Haven’t we had this capability for, I don’t know, DECADES!?!” Why yes Dear Reader, we HAVE had this capability for decades, but clearly you didn’t know you needed it until it had a fancy name and had vendors shoving the concept down your throat!

I know of organisations who quite literally renamed their ‘Managed Security Services’ to ‘Cloud Security Services’ without changing a SINGLE piece of infrastructure or a single process. And yes, this hid all manner of sins, but for some reason the new name stopped clients asking difficult questions like; “Can you tell me how it works?”

By sheer coincidence, I gave a webinar last week titled “Ignore Future Attacks, Fix Your Broken Security Program First”, it could just as easily be called “Ignore Buzzwords, Fix Your Broken Security Program First” and the content would be almost identical. We need to stop focusing on the new when we usually don’t even know what assets we’re trying to protect, who has access to what, or what any given system should look like from a normalised perspective.

Business needs information in context in order to compete, and the data that makes up that information is stored somewhere on a physical system. I don’t care if it’s virtualised, containerised or whatever-ised, it’s still a piece of hardware running an operating system sitting in a room somewhere (yes, I know it can be distributed). Nevertheless, there is NOTHING you need outside of an established good security practice to protect this data from what’s out there now, and what will be out there in the future. REGARDLESS of its name!

Segmentation, configuration standards, access control, logging and monitoring and a host of other old fashioned and boring names all boil down to one thing; baseline. What should a system look like all day every day, and how do I report anything different. No innovation in security capability (i.e buzzword) will be of any use whatsoever if you don’t have the basics right, because you’ll have no idea what you have, let alone how it should normally behave.

Ignore the hype, ignore the press, ignore Gartner and their ilk, focus on the stuff that you’ve likely relegated to a ‘previous generation’s problems’. They are still your problems too.

Not feeling very creative today, but luckily the Payment Card Industry can always be relied upon to dish out plenty of blodder.

With a stunning twist, the SCC announced the potential release of the DSS v3.2 as early as March. It was greeted by the industry with a resounding; “Meh”. And quite rightly, have you read the potential changes? They are;

“…evaluating additional multi-factor authentication for administrators within a Cardholder Data Environment (CDE); incorporating some of the Designated Entities Supplemental Validation (DESV) criteria for service providers; clarifying masking criteria for primary account numbers (PAN) when displayed; and including the updated migration dates for SSL/early TLS that were published in December 2015.”

While I understand this is part of their new program to; “…[move] towards a system of smaller, more incremental modifications to address things like the EMV roll-out in the US, rather than larger, wholesale updates.“, when was the last time you saw a large update? You could point to the change from v2.0 to v3.0, but you would only be showing your ignorance of the ‘ROC Reporting Instructions for PCI DSS v2.0’, the incorporation of which accounted for 95% of the difference between the 2 versions (take a look at this if you don’t believe me; PCI DSS v3.0 – Mapping to v2.0_v07NOV13).

But let’s handle each of these ‘changes’ in turn:

  1. Evaluating additional multi-factor – Note the use of the word ‘evaluating’, meaning nothing will actually change for some time. Is multi-factor auth a good idea for all privileged access? Yes, so let’s hope they actually enforce this one properly.
    o
  2. Incorporating some of the Designated Entities Supplemental Validation (DESV) – For ALL service providers, or just the ones to whom the DESV already applies? If the former, great, but the DESV is mostly a paperwork and process requirement, not additional controls. Not necessarily a terrible thing, but it depends on which requirements.
    o
  3.  Clarifying masking criteria – This one stumps me, how do you clarify the exposure of ‘first 6 and last 4’ only?
    o
  4. Migration for SSL and early TLS –  For to new date of 2018 to make ANY sense they should have left the requirement for offering TLS 1.2 by 2016, but allowing backwards compatibility until the later date. The way it’s written, merchants don’t even have to offer v1.2 of TLS until 2018 which is absolute nonsense.

The PCI DSS has always been, and will always be entirely inadequate to protect critical data assets, but frankly, what choice do the card brands have? They are fully aware of the inadequacy of their plastic in the face of current payment innovations, and the only saving grace delaying their rapid decline is the ignorance of the end consumer themselves. Henry Ford is often attributed the best phrase that sums this up perfectly; “If I had asked people what they wanted, they would have said faster horses.” The average consumer simply has no idea what could replace plastic, but when they do, the changes will be incredibly fast, and permanent.

The PCI DSS can never change dramatically, or the multi-billions spent on compliance to date would all be thrown away. Every organisation on the planet who is currently compliant (or reporting as such to be more accurate) would have to spend countless more billions to bring themselves up to the new standard. There is no way the card brands would survive the backlash. They have painted themselves into a compliance corner that cannot protect their 50 year old technology from the current threat landscape.

Yes of course implementing the PCI DSS controls on all forms of data is better than doing nothing, but barely, and can never and will never represent real security.

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.