With number 6, I completed my Security Core Concept series:

  1. Security Core Concept 1: Risk Assessment / Business Impact Analysis
    • Management buy-in
    • Examine your business processes 
    • Valuate and prioritise your data assets 
  2. Security Core Concept 2: Security Control Choice & Implementation
    • Perform gap analysis to determine control weaknesses
    • Mitigate control gaps based on priority
    • Think twice before throwing technology at a gap, perform robust vendor diligence if you do buy anything
  3. Security Core Concept 3: Security Management Systems
    • Make sure your controls are working
    • Begin control optimisation and measurement
    • Begin PDCA cycle 
  4. Security Core Concept 4: Governance & Change Control
    • Management buy-in
    • Interdepartmental co-operation and communication
    • Manage all business process and changes
  5. Security Core Concept 5: Incident Response (IR) & Disaster Recovery (DR)
    • Know what your baselines are
    • Standardise, centralise, and monitor
    • Test it, test it again, and keep testing it until everyone knows their part 
  6. Security Core Concept 6: Business Continuity Management (BCM) & Business As Usual (BAU)
    • Management buy-in (yes, that’s the THIRD time I’ve said that)
    • The goal is not security, it’s staying in business securely
    • BAU is where the true value of the core concepts is realised

…and have hopefully expressed in enough detail, the advantages of not only each of these steps, but of a security program ‘done right’.

What I have only alluded to, but will now examine in greater detail, is how the 6 Core Concepts make any regulation / standard / framework related to data security an afterthought.  Not that they aren’t useful, nor can they be ignored, but you’d already be ‘compliant’ with them.  The concepts themselves have been around for generations, and there are many treatises on each and every one.  There are even entire institutions dedicated to perfecting single concepts, but it’s only when you combine them all in a manner appropriate to YOUR business do they make sense.

I’m also talking about the fact that not one regulation the world-over goes deeper, and/or broader in their data security requirements, than you need to go for your business. They can’t, as the very names ‘standard’ and ‘framework’ automatically preclude, provide complete relevance to your organisation.  Nor can they possibly cover every nuance of every business type, sector, and culture.

What these regulations are trying to accomplish – but none state this outright – is a shift in culture away from function/profit only, to security enabled function/profit.  All 6 core concepts are basic fundamentals of security, yet are mostly ignored for reasons innumerable.  I hesitate to use the phrase business responsibility – I have enough issues with sounding like a lecturer – but that’s what it amounts to; you are responsible to protect the data in your possession.

But can you imagine going about your business, secure in the knowledge that no matter what security requirement or regulation gets thrown at you, you are already there!  Maybe not entirely, but the adjustments will be minimal, and will never require the level of effort that even PCI requires from you year after year.

In a nutshell;  If you do security properly, you will ALREADY be compliant with the security requirements of PCI / HIPAA / PoPI / SoX / SSAE-16 / GDPR / Swedish Personal Data Act / …and so on!

No more multiple annual audits / assessments (assuming you have some form of GRC tool), you will not only be compliant ALL the time, you can easily VALIDATE your compliance!

But none of this will be possible if your CEO doesn’t believe in it.  One again this phrase applies;

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 business goal here], it’s the CEOs fault, and no-one else’s.

It does not matter what the goal, from PCI compliance, to great customer service, to an ethical salesforce, to a security culture that enables to business to grow responsibly, it’s the CEO who is responsible. And accountable.

I am pulling the following from where the sun doesn’t shine (no, not Scotland), but I would estimate that any time the CEO spends evangelising an appropriate security culture will be paid back 100-fold in terms of resource / capital / DR cost savings.

And it’s all so simple.  Not easy, but it is simple.

It may take years, even in smaller organisations, but the major costs are all front-loaded, and the long-term savings way in excess of the annual costs associated with constantly reacting.  Security is only effective if it’s mostly pro-active, and that’s exactly what the 6 Core Concepts are designed to do.

Don’t know where to start?

Ask.

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

This will be the shortest of my blogs on the Security Core Concepts for a number of reasons;

  1. The majority or organisations will not raise their security program to the point that this is even possible;
  2. It will be assumed that this is all covered in the previous steps; and
  3. It’s often only perceived as a nice to have, but not critical.

…and so on.

But the biggest reason I’m not going to focus on this, is because the preceding Core Concepts tell you what you need to know, and reading my additional thoughts should be unnecessary. If you introduce the first 5 Core Concepts, this will be the only logical next step, and the benefits clear.

Business Continuity Management (BCM) is; “…a compilation of processes that identifies and evaluates potential risks to an organization and develops the organization’s resilience by ensuring critical objectives are met the resources necessary to achieve those objectives are available.”

I have emphasised resilience because this is really what it’s all about; staying in business. The Security Core Concepts deal with only one part of what Business Continuity is all about. Yes, a very important part, but your data, and the ability to process that data, is not all your business encompasses.

This is why BCM belongs under your Governance framework. As the gatekeepers of your change control, and focal point for conversations between all departments, they are best placed to manage the never ending adaptation of your resiliency processes in light of internal changes, and the external threat landscape.

It’s shocking just how unprepared most organisations are for this contingency planning. What would have been an inconvenience is now a full blown event, and what should have stayed an event, is now a business crippling disaster. All for the want of a few more conversations, a few additional processes, and an annual test.

Seems a small price to pay for staying is business, doesn’t it?

As for Business as Usual (BAU), it’s; “…the normal execution of standard functional operations within an organisation.”

How can something so blatantly obvious not be the Holy Grail of security? Why is getting to this point so difficult for every organisation I’ve even worked for?

Back to my Ikea analogy from a previous post; Let’s say the instructions to build a bed-side table are lost and it’s your job to work out how it’s put together. You will eventually work it out (unless you’re me), and you’ll be happy. But now let’s say you didn’t write down HOW you did it, will you be able to put another one together as fast as you could if you had instructions? More to the point, could someone else who is new to the task?

BAU is the standardisation of all of your processes to the point that they become second nature, AND are documented in such a fashion that anyone can pick up where the previous person left off. The phase ‘Knowledge Management’, which is intrinsic to BAU, was a big deal in years past, but seems to been usurped by the next security-shiny-thing.

Either way, knowledge management is the difference between doing everything all over again every time (reinventing the wheel), and doing it properly every time. Or being able to safely and quickly transition your business towards innovation and market competition, and away from disaster or obscurity.

And now you know why policies and procedure are so important, and one of The 4 Foundations of Security?

Take a guess as to who is responsible for driving an organisational culture that embraces BAU? Yep, the CEO, and I hope you weren’t surprised.

There is clearly more involved in both BCM and BAU, but we’re keeping things simple.

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

The only established job title I agree with, is ‘Consultant’. They can:

  1. say without fear of repercussion; “I have no idea, but I know someone who does.” They are enablers, not [necessarily] SMEs;
  2. add new projects / functions / experiences to their CVs/resumes because their entire role isn’t defined by a single job description; and
  3. stop someone asking questions about what they do, because the answer; “I’m a consultant.” fulfilled the societal obligation.

Every other title out there tells you what that person does, and to an uncomfortably large [judgemental] degree, WHO they are. Ever taken an instant dislike to someone who told you they were a traffic warden? But how many people really think of themselves as defined by their job? Nurses perhaps, charity workers, priests? Do you really think of yourself as an ‘actuary’, or a ‘receptionist’?

While there are many jobs out there where your personality shines through, most of us are not doing them. We’re working in the information age where we our entire output can easily point to nothing tangible. We’ve ‘made’ nothing, yet we still want to believe that we are making a positive difference, don’t we? How can we possibly put the age old corporate strictures around something so fundamentally different as today’s job market?

Doctors don’t prescribe leaches and bleeding for every illness, banks don’t process every transaction on paper (though I think Lloyds might), so why do we maintain the centuries old concept of pigeon-holing everyone into a job title? Would it not make more sense to describe all the FUNCTIONS or TASKS a business requires, then let the right individual(s) perform them?

How often does the best person to perform a task actually get to do it? They may be in the wrong department, the wrong ‘grade’, or have the wrong boss, but the effect is the same; the person who is paid to perform the task as part of their defined job description does it, and possibly nowhere near as well as the person best suited.

There is a very good chance that no-one even KNEW there was someone who could do it better. Usually this is a combination of two things; 1) no-one bothered to find out, and 2) no-one volunteered the knowledge. This is not just about employers not providing an environment that embraces change, it’s also about employees that don’t WANT change. Either be the agent for change, or don’t complain about the status quo.

How many times have you had an idea for a process change, and new profit line, a morale booster etc, then had it shot down for one or more of the following reasons:

  • It’s not your job, go back to doing what you’re PAID to do;
  • It’s not the right time – with no indication of when it MIGHT be the right time;
  • We’ve always done it this way – try not to punch this person in the face; and/or
  • It simply won’t work – with no indication as to why.

…or a thousand other reasons that all amount to the same thing; You have your day job, leave it at that. You may even have been made to feel bad about suggesting it in the first place, which means you’ll never do it again.

The reasons for this are as infinite as the excuses. A few are:

  • Your boss has no idea what he/she is doing and you’re humiliating them;
  • Your organisation is led by someone with no imagination, or ability to inspire; and
  • They simply don’t understand the concept.

YOU can be just as much to blame however:

  • You spend all your time at work working on things that you are not being paid for, and your real work suffers;
  • You have put no real thought into the idea, or formalised your plan; and
  • Your idea is crap.

But these examples don’t change the fact that most organisations hire people to fulfil a specific task without taking the individual’s full skill-set into account. They are then either marginalised, or actively held back from developing additional skills, or expanding their function beyond a very limited scope (usually departmental).

Nature doesn’t label, it just is. The strongest in the pack is Alpha, the best hunters lead the hunt, and every living thing just gets on with doing what they were born to do. Not humans. We have to label, compartmentalise, pigeon-hole, classify – I mistyped that as ‘calcify’ which is amazingly appropriate – in order to understand. We have good-vs-evil, up-vs-down, in-vs-out, just so we can explain things to ourselves.

In the workplace, the larger a business becomes, the more disconnected it becomes. There is no room for the individual, let alone the individual’s unique set of talents and skills, but I believe this is exactly where we need to go. It may well be that the guy in accounts payable is a wizard at data analytics, so have him help out in Marketing. The girl working in Research & Development has an uncanny ability to relate to people and “talk their language”, so take her out to close the more complex deals.

Once you know the individuals, titles are irrelevant. People just KNOW who they are. The two people above are “the data guru’ and ‘the closer’ respectively, and are happy because they get to do what they’re good at! Who knows, they may even get appreciation for it, and the organisation is happy because they have a competitive advantage.

Even hiring becomes easier. You don’t hire against a job title, you hire against a required skill-set, which is MUCH easier to interview for. Then when you ask that person what title they would like, they can be creative / unique enough never to feel as though they are just another cog in the wheel.

Of course, to the outside world you will still need to give them known titles. Until this catches on anyway. And some people WANT to go to work 9-5, be anonymous, and that’s OK, every business can’t be full of entrepreneurs and go-getters.

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

A little background first;

My Core Concept series is broken down 50/50 into mostly technical, and mostly business concepts;

  1. Risk Assessment (RA) & Business Impact Analysis (BIA) – Business
  2. Security Control Selection & Implementation – Technical
  3. Security Management Systems – Technical
  4. Governance & Change Control – Business
  5. Incident Response (IR) & Disaster Recovery (DR) – Technical
  6. Business Continuity Management (BCM) & Business As Usual (BAU) – Business

I’ve done this because the majority of consultants fall [mostly] into one or the other camp. There are very few true generalists, even though the majority of regulations require just that.

PCI for example requires a fairly in-depth knowledge of everything from policies to encryption, and from software development to access control. If no one consultant can possibly know all of this stuff – in a depth sufficient to provide true guidance – , why do you more often than not only get one assessor?

A Consultant is not the same as a Subject Matter Expert (SME), and these should not be confused. A consultant knows enough about everything to tell you what else you need. Or the old, but VERY relevant cliche; I don’t know, but I know someone who does.

I have taken DR / IR out of Business Continuity Management, so that it can be addressed by the relevant technical SMEs.

OK, enough background, what is Incident Response and Disaster Recovery?

Incident Response can be defined as; “The reaction to an incident that could lead to loss of, or disruption to, an organisation’s operations, services or functions.”

Disaster Recovery therefore is; “The recovery from an incident that caused loss of, or disruption to, an organisation’s operations, services or functions.”

What does this mean in reality? It means that whatever your business, you must know enough about its processes that anything out of the ordinary is either prevented outright, or detected soon enough to stop the incident from becoming a disaster. While you absolutely must have formalised DR capability, your IR should be robust enough to – hopefully – negate its use. In theory…

In practice, it does not work that way. Organisations generally do not have sufficient knowledge of the normal workings of their systems (infrastructure and applications) to detect when things go wrong. Or if they do, it’s probably too late to do anything about it except initiate DR.

The whole point of the Security Core Concept series is to help you stay in business, otherwise, why bother? The first 4 Core Concepts help bring your environment into a baseline that can, and must, be maintained;

  1. The Risk Assessment told you what was most important to you, and put a value on it;
  2. The controls you put in place mitigated the risk from threats;
  3. The ISMS forces you to continually optimise your systems in a way that supports their baseline functions; and
  4. Governance hopefully removes (or at least reduces) the internal threats.

What IR does is force you standardise, centralise, and simplify.

You will only have the ability to baseline your systems if you have a few ‘known good’ templates. If you have 10 flavours of Windows, and 10 more *nix, all configured differently, you really don’t stand a chance of baselining anything. You must therefore develop standard templates for all systems, wherever possible.

How do you manage 1,000 devices if not centrally? You don’t. Without a way to centralise the management and monitoring of your disparate systems, again, you will never have a baseline.

IR becomes self-explanatory in the face of known baselines; anything NOT within the baseline is an event to be investigated. The process for this investigation must be rapid, comprehensive, and above all PRACTICED! You can have 11 of the best football players in the world and still lose if they don’t play as a team. That’s the simplification.

As for DR, that too is fairly simple, IF, and ONLY if you know what your limits are. Back to the e-commerce example; If you need 100% up-time, forget it, it’s not possible, but 99.9% should be. However, going from 99% – 99.9% is exponentially more expensive, so you need to understand the VALUE of your business assets to define what is acceptable downtime for your business. That’s what the Risk Assessment is supposed to do; provide the input into your IR/DR plans and components.

OK, so I really haven’t given you anything to work on, have I? But like most aspects of security, there are no standards / frameworks / good practices that will fit YOUR business exactly. Everything that’s written down for you to follow can only EVER be a beginning, the rest is up to you.

Your business is unique in some way (probably in many ways), so you must take only the parts that are appropriate from each of the guidance frameworks or you’ll wind up with a security program that is unsustainable, and most likely ignored. Your security program becomes as unique as your business, and even saying that is ‘based on’ something is probably stretching it to the point that Hollywood bases its movies on books.

Security is simple, it’s not easy, but it is simple. Your IR and DR processes must be just that if you hope to stay secure.

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

You are probably wondering why I have taken a single aspect of the security program; change control, and raised it to the importance of a Core Concept. You are then probably wondering why I placed it under Governance, and not just an ISMS.

If you’re NOT wondering these things, I suspect you are new to security, or a friend of mine who’s reading this just to be nice.

However, if you accept my interpretation of what Governance is, it may make a little more sense; “Governance is where the IT and Business sides have appropriate conversations.” It’s a communication facilitator, where historically the business side rules and the IT side must do as it’s told, often without question.

You must also accept the concept of cybersecurity as a business enabler, and NOT a roadblock to profit or innovation. As I rather facetiously put it in The 6 Security Core Concepts;

Business: “I want this new functionality.”;

Security:“Sure, but do it this way.”

The business side is responsible for maintaining business growth / profit / market standing and a host of other objectives.This is far from easy, so they will do almost anything to meet those goals. It is up to IT and Security to encourage this innovation and out-of-the-box thinking, but do it in such a way as to ensure that the IT and security needs are built in from the beginning.

In a company with a well run Governance program, any ideas the business have will be run by the Governance Committee (or equivalent), which will include at least one, or more likely several members of the IT / Security teams (security, infrastructure, development etc.). The ideas will be discussed, input accepted EQUALLY from all participants, and a specific risk assessment report put together for senior leadership to review.The IT side’s input needs to include not only the risks, but the viability of the concept based on capital cost, resource allocation, outsourcing and so on.

That’s why they are enablers, because they are the ones who put the ideas into practical application. The greatest ideas in the world are useless if they stay on paper, and are potentially destructive if applied incorrectly.

Assuming I’ve made my point on Governance, and that you somewhat agree, I’ll move on to change control…

Change Control is defined by Wikipedia as; …”a formal process used to ensure that changes to a product or system are introduced in a controlled and coordinated manner.”

This needs no simplification, that’s EXACTLY what change control does …if it’s implemented properly. And that’s the issue in many organisations; the concept may be understood, but there are so many exceptions, and / or ways to circumvent the process, that you may as well not have change control at all.

Again, in The 6 Security Core Concepts I said; “If things don’t change, the only increase in security risk is from external sources. The threat landscape changes almost daily, why make things worse by screwing up internally?“

That’s really what it boils down to; known, and acceptable change. If you’re following the Core Concept series, you have:

  1. Given Governance full responsibility and maybe some accountability for the institution and maintenance of the security program;
  2. Performed your Risk Assessment with the full knowledge and blessing from senior leadership;
  3. Made all appropriate adjustments to your processes and infrastructure based on the RA’s finding and accepted priorities, and
  4. Initiated the Check and Act portions of the ISMS function to ensure that the controls work, and are on their way to being optimised

So why would you now undo all of that work by changing something without the Governance committee’s blessing?

Change Control includes EVERYTHING that changes; systems, applications, data stores, patching, policies, procedures, new functionality, people …EVERYTHING.

Of course Governance can turn some changes into operational norms; patching for example. As long as the process for testing new patches, and rolling them out across the enterprise is appropriately formalised, the Governance committee does not have to discuss it.

But what about firewall rule-set changes? The business side is demanding the testing of some new functionality that involves “Turning off the firewalls for a couple of minutes.”? The answer is of course, no, or HELL no to be more precise, but who has the authority to tell the business that? Right, the Governance Committee.

The institution of a change control culture is painful and slow, as new processes will always meet with resistance. But this is one area where there is no room for half measures, you either do it (and make the negative consequences clear to all), or don’t bother starting.

Finally, I have not gone into any detail of who should actually be ON the Governance committee, and what its charter should be, but that’s because it varies too much between organisations of difference size, complexity, and function. As long as you have equal representation from the IT and business sides, the individuals themselves will make themselves obvious over time. A limited tenure is important though, or the committee may either stagnate, or be controlled by the most forceful individual.

Governance is the heart and soul of your security program, and change control it’s most potent weapon, neither can be ignored.

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