Category: Security Good Practices

In direct response to a certain organisation’s ‘Top 10 Cyber Security Technologies to Watch in 2017’, [cough, Gartner, cough], I have come up my own list of bleeding edge security technologies that every organisation should spend millions of $/£/€/¥ on.

Yes, even if you don’t MAKE millions, you should borrow the money and buy them anyway.

Being honest, my fight to bring security ‘back to basics’ has failed – despite my enormous 210 person following – so I have decided to sell-out and promote nothing except buzz-phrases and acronyms. You know, like everyone else.

However, I am convinced that if you buy, implement, and actually take these technologies seriously, you can forget the security basics. The combination of these 10, never-seen-before, shiny new objects will provide the silver bullet you’re looking for:

  1. Directorate Approbation Paradigm (DAP) – Historically, achieving ‘management buy-in‘ was the ultimate goal for anyone attempting to implement a security program. Quite rightly, caring about the future of an organisation was considered naive, and proponents of this stone-aged technology were left begging for work on LinkedIn. Some of these poor souls even became CISOs. Now, with DAP technology, every single person in an organisation will take security seriously, even if their bosses don’t!
    o
  2. Command & Control Commission (CCC) – While not strictly a technology the CCC is responsible taking the output from the EIC below, combining it with the DAP above and obtaining the budget to buy everything else on this list. This is the spider in the middle of the web, making sure that all technologies work together. Called ‘governance‘ in the old days, the new CCC is clearly superior given that you’ve never heard of it, and it’s an acronym.
    o
  3. Protocol, Method, & Archetype Orchestrator (PMAO) – Much as leeches were seen as the go-to technology in medieval medicine, ‘policies, procedures and standards‘ were seen as a foundation for every security program. While clearly nothing more than a quaint superstition, they nevertheless laid the groundwork for the PMAO revolution. Imagine it; a series of artefacts designed to record not only an organisation’s entire security culture, but their process knowledge and system baselines as well! No way just policies, procedures and standards could do all of that!
    o
  4. Exposure Investigation & Computation (EIC) – I almost feel sorry for the poor saps who only had the ‘risk assessment‘ process to measure their risk profile. Can you imagine basing you risk treatment and technology purchasing decisions only on expert opinion and business goals!? Instead, EIC, in combination with AI, big data, The Cloud, and fairy dust, can tell you exactly how many millions to spend on technology! No more embarrassing moments when you try to explain to your boss how you tried to save them money by fixing the actual problem! Like people and process could ever be the problem!
    o
  5. Intelligence Preservation Administration Schema (IPAS) – Can you imagine the nerve of the International Standards Organisation when they came up with the Information Security Management System (ISMS)? A so-called ‘framework’ designed for “systematically managing an organization’s sensitive data” with – and you won’t believe this- “a set of policies and procedures”! How naive! Instead, with IPAS, you can basically ignore the hard work and common sense approach to doing security properly and hide behind an expensive appliance with flashing green lights! Blinking green, you know it’s working!
    o
  6. Transformation Regulation Authority (TAR) – Before the advent of TAR technology, organisations across the globe relied on a ‘change control board’ to ensure that unmeasured risk was not introduced into an environment. As yes, once again, actual humans – apparently those with ‘expert’ knowledge – were allowed to determine what was right for the business. A clearer case could not be made to put this in the safe ‘hands’ of technology written by someone else.
    o
  7. Episode Reply & Adversity Restoration (ERAR) – We’ve all seen those commercials from the 50’s where attractive actors extolled the virtues of smoking? Well, ‘incident response & disaster recovery‘ were just as misleading, and just as dangerous! Like anything involving people and process could possibly help you stay in business! ERAR on the other hand, will not only detect bad things happening, it will keep your business up and running! Surely THAT’S worth a few million all by itself!!
    o
  8. Capital Durability Projection (CDP) – The future of any organisation should never be placed in the hands of those who care. The experiment called corporate social responsibility failed because it was assumed that it’s the people who are the most important aspect of a business. At least now we know it’s money that’s most important, so the old concept of ‘business continuity planning’ can be replaced by EDC and those making the world better with technology. Finally the people can be safely ignored.
    o
  9. Asset Management (AM) – This is one aspect of security where technology is actually sadly lacking. Asset management is the centre of everything, and without it, no other aspect can be truly be done well. Spreadsheets just don’t cut it, and no GRC that I’ve seen gives asset management its due. This much change, even in The Cloud.
    o
  10. Continuous Compliance Validation (CCV) – This is an idea whose time has come, it’s about time technology provides a REAL solution to overly manual processes.

All facetiousness aside, I am a huge fan of technology. Or more accurately, I am a huge fan of the appropriate application of technology. If you buy something based on anything other than 1) the results of your risk assessment, and 2) answers to the RIGHT questions, you have no business being in charge of a budget.

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

Information Security Policies, or more accurately; Policies, Standards, Procedures, & Guidelines (a Policy Set) are the cornerstone of every security program. It is therefore rather odd, that not one client I have ever helped started with any of them in place. Not appropriately anyway. While not everyone is a security expert, everyone can be security savvy enough if, and ONLY if, what they are supposed to do is written down!

That’s what a good Policy Set is; an instruction manual on what to do, what not to do, why, and how.

I have written too many many times on why a good Policy Set is important, and have used the term ‘baseline’ more times than I’ve had hot dinners. I have described what a Policy Set consists of, and even how to manage one, but what I have not done up till now was to describe how to find a Policy Set that’s right for your business.

First, you may be wondering what’s so hard about finding policies. And I agree; type “information security policy example” into Google and you’ll get tens of millions of hits. Universities readily publish theirs for the world to see (e.g University of Bristol), and a whole host of organisations even make editable versions freely available. On top of that, online services with ridiculous promises like “THE ONLY WAY TO GET AN INFORMATION SECURITY POLICY CUSTOMIZED FOR YOU IN AN HOUR, GUARANTEED.” are depressingly common.

The challenge is that if you’re looking for information security policies in this fashion you clearly have no experience implementing them, let alone actually writing one yourself. An overly-dramatic analogy; I found thousands of instructions on emergency appendectomies, would you now trust me to perform one on you? A good Policy Set is one that is appropriate to your business. Not your industry sector, not the prevailing regulatory requirement, your business!

Therefore, if you don’t have security expertise in-house, it is very unlikely that you know the right questions to ask providers of Policy Sets. The vast majority of vendors will sell you what you ask for (can’t really blame them for this), so ensuring you get what you actually need is entirely based on the homework you performed beforehand.

To that end I have written something vaguely resembling a white paper to help you. In the imaginatively named ‘Choosing the Right Policy Set‘ I have broken the choosing of a policy set vendor into 15 Questions. These could easily form the core of an RFI or RFP if you were taking this seriously enough.

Simple questions like; “Can you provide a Document Management Standard and Procedure?” or “Does your service include a mapping of policy statements to the PCI DSS?” are sometimes not even considered. But when you consider that the choosing of a policy set can be the difference between compliance and non-compliance, it makes sense to ask them. Up front!

90% of organisation will end up either throwing something together themselves, or buying the cheapest option available. That’s fine, but when regulatory fines start getting handed out they will realise just how ‘expensive’ their choice was.

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

Have you ever tried to fill a colander with water? Of course not, that would be ridiculous given that it’s full of holes. So why would you try to implement a security program without ensuring that whatever you fix does not get broken behind you?

Do you give your IT administrators permission to change the setting on your personal phone? Again, of course not, so why would you allow them to make significant changes to corporate assets without proper oversight?

While these analogies are flippant and geared toward emphasising my point, I would not be writing this blog if the issue of change control was not an enormously important one. At best, poor change control can cause additional unnecessary work, at worst you could be out of business. It’s bad enough that bad guys want to break in, most organisations I have seen are making it easier for them from the inside.

The definition of change control is; “…a systematic approach to managing all changes made to a product or system.“, and it’s purpose is “…to ensure that no unnecessary changes are made, that all changes are documented, that services are not unnecessarily disrupted and that resources are used efficiently.” Sounds fair, right? No disruption? Efficient? Are these not good things?

The biggest issue is that change control requires not only planning, but extra effort. You have to fill out a form, send an email, or log into a GUI of some sort, all of which may take longer than making the change in the first place. Change control is time-consuming and can be seen as a bottleneck, both of which are no-nos in the rapid evolution towards more and more function. But what would you rather have; 1) an insecure service quickly, or 2) a secure service a very short time later?

Unfortunately, given that change control is a primary function of governance, few organisations have the oversight to implement change control well. so how can organisation perform this most critical of processes?

First, it has to be appropriate. There is little point in a 5 person company buying a change control software, but larger organisations should not be using email and spreadsheets. As long as the right people are involved in making the change decisions, this process can be as formal or informal as is sustainable. If this is ever seen as a burden, it will be either circumvented, or ignored altogether.

Often overlooked, but critical to change control success, are a few pre-requisites…

Change Control Pre-Requisites:

  1. Ensure that the asset register contains not only physical devices, but applications, CotS software, data stores, location, unique skill-sets etc.
  2. Assign business criticality and maximum data classification to all assets;
  3. Assign ownership to all assets;
  4. Map all assets to the business processes they support (note: these maps becomes assets in and of themselves); and
  5. Ensure that the change request form includes a list of the affected assets.

Change Control Form:

Every change request must, at a minimum, include these things.

  1. List of affected systems;
  2. Details related to affected users (if applicable);
  3. Criticality of change request;
  4. Indication of additional risk;
  5. Success criteria / test plan;
  6. Back-out or fix-forward plan; and
  7. Appropriate authorisation.

By mapping the affected asset to their corresponding business processes, their owners, and both their criticality and maximum data classification, you can automatically bring the right decision maker to bear to authorise the change.

Too often the business owners have little to no insight to technology changes, when in reality, they are the only ones who should be authorising the change. IT and IS are, and have always been, business enablers, nothing more. First and foremost, change control need to reflect the goals of the business. In the absence of governance, the above minimums are about the only way to see that this happens.

Of course, if you also link change control to your ticketing system and incident response processes you would have the Holy Grail, but baby steps…

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

Ask a lawyer what ‘appropriate’ or ‘reasonable’ means and they’ll come back with something like; “What would be considered fair by a disinterested third party with sufficient knowledge of the facts.”, or “Fair, proper, or moderate under the circumstances.”

Now translate that into what kind of security measures are considered appropriate? How would you justify that what you are doing is reasonable, fair, or proper under the circumstances?

Because that’s what you’ll have to do if things go wrong under GDPR. You’ll have to justify that the measures you took to protect personal data were underpinned by an appropriate program for measuring and treating risk. If your breach was shown to be almost anything other than by a determined attacker, all you’ll have in your defence will be poor excuses. This is no better than negligence.

When you consider that the General Data Protection Regulation (GDPR) – and every other regulatory compliance for the matter – was written mostly by lawyers, should we not be able to work out what ‘appropriate’ means for a security program? After all, lawyers have no problem defining the word ‘reasonable’, they even apply it to their fees!

The good news is that the process is not only well known, it’s simple. It’s called Risk Management, and it’s been around for decades.

Step 1: Complete your Asset Register;

Step 2: Map your assets to your business processes (which should already be mapped to revenue to determine importance);

Step 3: Map your business processes to your business goals;

Step 4: Run a Risk Assessment against all business processes and / or key IT systems;

Step 5: Document the business impact of each risk (mapped against both revenue and business goals);

Step 6: Document Senior Leadership’s risk appetite against each business goal;

Step 7: Perform full analysis of security controls, determine if there are any gaps between the current state and the risk appetite;

Step 8: Fill the gaps (risk treatment);

Step 9: Document everything; and

Step 10: Repeat annually, or prior to any major changes.

Now put yourself in the shoes of an auditor after you have been breached. What are they going to ask you for? What could anyone reasonably expect you to have in place if you were taking your duties seriously?

If I was an auditor I’d ask for 5 things up front, as without them I know there is no way you have an appropriate security program in place:

  1. A mapping of your policies, standard and procedures to whatever security framework you based your security program on;
  2. Your risk management procedure(s), and the results of the last risk assessment conducted;
  3. Your risk register;
  4. Your change control procedure(s); and
  5. Your incident response procedure(s).

At this stage I would care nothing for your technology, or how much you spent on it. A technology purchase outside of a properly defined business need is nothing more than smoke and mirrors. Besides, no regulator has ever tried to qualify how much you spent. It’s up to you to show why you spent what you did.

The thing to bear in mind here is that the validation of ‘appropriateness’ is not a conversation, it’s documentation. It’s not even evidence of the technologies you have running, it’s showing that the technologies you do have meet the risk you have defined. While from a lawyer’s perspective, appropriate is demonstrated by precedent, in cybersecurity, appropriate is demonstrated by the extent and capability of your security program.

Complying with the cybersecurity elements of the GDPR is simple, every step is written down for you somewhere. There are a few things to bear in mind though:

  1. GDPR is 95% about how you get the data, and what you then do with it when you have it. Anything you spend on security should be justified against the business goals, not a compliance requirement;
  2. There is no cyber insurance against loss of reputation, this should not be about the money; and
  3. Any security vendor offering “GDPR Compliance” is at best telling you 5% of the story, at worst, is lying to you.

While I agree it may be difficult to sort through the good advice and the crap when it come to this stuff, there is no excuse for doing nothing. GDPR and every regulation to come will not change the basics, security will be the same regardless.

The issue is not regulation, it’s that organisations still aren’t asking the right questions.

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

In the vast majority of organisations for whom I’ve provided guidance, the security departments are seen as something to work around, not alongside. In not one of those organisations was security actually seen the critical and intrinsic-to-the-business asset is can, and should be.

While I have written incessantly about this all being the CEO’s fault for not creating the necessary culture, the fact remains that most security professionals do themselves no favours. However good intentioned our actions may be, most of us completely miss the point. Like it or not, our entire existence is predicated on achieving the following:

“To provide the business with all the information, and as much context, as we can to enable them to make the best decision they can.”

Yes, that may include decisions that we in security would consider completely unacceptable, and would likely never make ourselves. It also may even include decisions that turn out to be really bad ones, but that’s just as much our failure as theirs.

The bottom line is that if we cannot speak the business’s language, if we are unable to convince them of the risks, we have failed them. There is no room for towering egos or hubris in security, it does not matter what we want, it only what the business needs. This will never be our decision, and we should never expect the business to speak our language.

I’m not saying that if you’re a cybersecurity professional that you have to say yes all the time, but you should avoid saying no whenever possible. Frankly, it’s not your job to do so. And as much as we would love to believe that as security experts we’re here to help, and that we have the best interests of our clients at heart, we will never be anything more than enablers. What’s more, if we’re anything less than that, there’s little point in having us around.

In the movie Office Space, one of the most cringe-worthy moments was when Bill Lumber reveals the “Is this good for the Company” banner. I remember laughing at the ridiculousness of the message, and laughing again when our hero tears it down. Almost 18 years later, here I am expounding the exact same message as that banner.

Why?

Because in security, we rarely have enough knowledge of the company’s big picture to put our guidance and recommendations into the right context. Even if we know that the company’s long-term goals are, unless we sit on the board we are in no position to appropriately address the risk appetite. A Sword of Damocles scenario to us, may well be a necessary gamble to keep the business competitive.

That leaves us only 2 things to do:

o

  1. Explain risk in the format they respond to best; detail the impact of not doing what we suggest; provide suitable alternatives; and
    o
  2. Cover your arse by having THEM sign-off on the residual risk.

The business does not need our approval to proceed with even the most egregious risks, but that does not mean we have to like it. Legal have far more power than we’ll ever have, but even they have to compromise. That said, we are fully entitled to document our objections as part of the final sign-off, but we should never take this personally.

As a corollary to the last paragraph, never, EVER say “I told you so”! Given that it’s likely partially your fault that senior leadership didn’t make the right decision, your only focus should be to help mitigate the negative impact. Take the high road, you’ll be employed longer.

In the simplest terms, map everything on your Risk Register to the business’s goals, and only worry about the things that impact them. Doing the right thing in security is rarely, if ever, measured by security metrics, it’s measured by the company’s success.

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