Security Core Concepts

The 6 Security Core Concepts

In my White Paper on Selecting the Right QSA, I liken security to the law, in that it is becoming increasingly complicated, specialised, and inaccessible to businesses too small to afford in-house expertise. Unless you’re Fortune/FTSE 100, this is most likely your business.

I also introduce these core concept in the form of a highly artistic and creative Word table (what’s the punctuation for irony?).

With the plethora (one for you Three Amigos fans) of regulations, enforcement bodies, and good practice standards out there, it’s no surprise organisations are stuck in the mode of analysis paralysis. Every requirement for data protection cares only for their specific data type / jurisdiction / use / retention etc, so who is supposed to make sense of this for a business that just wants to sell their widgets?

Unfortunately, only the business concerned can put the necessary commercial perspective on this. However, seeing as ALL security boils down to the same core concepts or common denominators, this is likely easier than you think. Yes, you may still need professional help, but if all you are doing is talking about your business goals, you can leave the security part up to your consultant.

In my experience, there are only 6 security program core concepts:

1. Risk Assessment (RA) & Business Impact Analysis (BIA) – If you can’t (in some form) qualify/quantify your business risks related to your sensitive data, and then determine an estimated cost-of-loss related to data theft or unavailability, how will you know how much to spend on security? Put simply; if the cost of security outweighs the value of the data, don’t do it (this includes compliance). This does NOT mean you should do nothing at all, it just means you need to re-evaluate how you perform some of your business functions. The first question is not “How do I protect it?”, it’s “Do I need it?”

2. Security Control Selection & Implementation – The RA, done correctly, will show you where you can make improvements in your security posture. This does not necessarily involve capital expenditure – which should always be the LAST resort – it can be something as simple as destroying every instance of redundant data. Regardless, at some point you will probably purchase technology, but even here you should be careful (In Security, Technology is Always the Last Resort) and ensure that this new technology meets all of the business needs defined in the RA.

3. Security Management Systems – There’s not much point putting security controls in place if you don’t manage them properly to keep them in place. This is where standards like ISO 2700X come into play. This includes the day-to-day procedures used to maintain the operational aspect of your security infrastructure. Obviously this will vary dramatically by organisation; from a simple check-list for your corner sandwich shop, to a full time job for larger more complex organisations. The trick is doing only what’s appropriate without going overboard.

4. Governance & Change Control – Ask 100 people what Governance is, and you’ll get 105 different answers. I believe governance provides a function that trumps all others; it allows the business side of an organisation to talk to the IT side in the same language. Business: “I want this new functionality.”, IT: “Sure, but do it this way.” is the perfect conversation. IT, and especially IT security, are typically seen as roadblocks, but this is just a symptom of immature Governance processes. As for change control, that’s just common sense. 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 as well?

5. Incident Response (IR) & Disaster Recovery (DR) – Fairly self-explanatory; what’s the point of being in business if you don’t intend staying in business? For example; if you are an e-comm company, you should know from the RA what your maximum downtime is, and both your security controls and IR & DR processes need to fit according.

6. Business Continuity Management (BCM) & Business As Usual (BAU) – You may ask why this is broken out from IR & DR. I do this because BCP and BAU are more related to the business side of the table, and IR & DR are on the IT side. IT never leads, IT enables, it’s the business side that needs to lay down the plans for staying in business, as well as how to do so efficiently, and cost effectively.

I know its a bold statement, but if you follow these core concepts, it won’t matter the compliance regime, the data type, of even the type / location you’re business is in, you’ll be covered …mostly. These are the concepts on which I founded Core Concept Security, Ltd.

Yes, this is a lot of work, and the up-front costs in both capital and resource terms can be significant, but it’s a damned sight cheaper than the cost of non-compliance, fines, and particularly; being breached. In the extreme, what if it’s the difference between you being in business at all?

As the Americans say, it’s a no-brainer.

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

2 thoughts on “The 6 Security Core Concepts

  1. Governance, Change Control & Incident response should be covered as part of the security management system surely? 27001 covers them as mandatory requirements. The purpose of an ISMS is not just to manage the controls its to manage the process of mitigating and accepting risk to the business in more general terms.

    What if data values can’t be accurately determined, how would you put together a business case for significant capital expenditure? Would you recommend using compliance as an enabler?

    • Nice Fight Club reference Tyler 🙂 And thank you for your comment, it’s my first on my new blog!

      While I agree 100% re: ISO 27001, I have found that if you don’t break out Governance and IR/DR into their own ‘core concepts’, they are neglected. As you know, unlike PCI compliance (for example), with ISO you can choose WHAT you look at, and that may not be what’s best for the business overall. Security is non-linear, cyclical, and never ending, so unless you draw a line in the sand and compartmentalise, the business side tends to see nothing but a money pit.

      Can compliance be used as an enabler? Absolutely, but only if the end goal is to include compliance in the overarching security programme.

If you think I'm wrong, please tell me why!

This site uses Akismet to reduce spam. Learn how your comment data is processed.