Security Core Concepts

Security Core Concepts: Tying it All Together

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!]

Security Core Concept 1: Risk Assessment / Business Impact Analysis

This begins a series of posts related to my theory of The 6 Security Core Concepts. I am assuming that The 4 Foundations of Security are either already in place, or at least being addressed in parallel.

So, in terms of cybersecurity, what is a risk assessment? According to Wikipedia it’s; “…the determination of quantitative or qualitative value of risk related to a concrete situation and a recognized threat.”

NIST SP800-30 Revision 1 states; “Risk assessments are used to identify, estimate, and prioritize risk to organizational operations (i.e., mission, functions, image, and reputation), organizational assets, individuals, other organizations, and the Nation, resulting from the operation and use of information systems.”

Great David, now what? I know what a risk assessment is, I just don’t know how to do one!

There are 5 golden rules of conducting a risk assessment;

  1. Get Management Buy-In – I know, surprising huh?;
    o
  2. Agree on the Scope – region, department, business line, compliance regulation etc. Keep it simple or you’ll never finish;
    o
  3. Agree the Methodology & Deliverables – whether you use something based on methodologies such as NIST or OCTAVE, or a combination of many, agree the method up front and stick to it for ALL of your risk assessments;
    o
  4. Agree the Timeframe – from the beginning to the delivery of the results stick to the agreed timeframe, even if you’re not finished.
    o
  5. Get Started! – don’t get caught in ‘analysis paralysis

Once these are agreed, start your interview process, and again, don’t over-complicate this. Each department is going to have a different take on what’s important, and it’s not your job – yet – to argue priorities. You simply ask them what they consider to be the major threats to the business (from their perspective), and what is the likelihood of that threat being realised.

Bear in mind, this will not just be IT threats – IT does not corner the market – but it IS a big chunk of them; malware, data theft or other loss, network outage, Internet outage, server crash and so. That said, even such concepts as operational resilience have a majority foundation in IT systems, so that’s why the IT department have traditionally – and incorrectly – owned this process (if it exists at all).

Done correctly, the risk assessment will be driven by the Governance Committee (Core Concept 4), and have equal input from both the IT and the business sides. If not, it won’t have the management buy-in I go on so much about.

Once the data is collected, it must be put into some kind of perspective. This is where the words quantitative and qualitative come into play. Only very mature risk management processes should attempt quantitative, it’s simply too difficult for most organisations. Qualitative allows for better adoption by non-technical personnel, and will most likely speak better to the immediate needs of the business; i.e. reducing risk.

Assuming you’ve chosen qualitative, you must still put some value on the identified risks; 1 -5, 1 – 100, high-medium-low etc., as well as some indication of its likelihood of occurrence. For example; a planetary implosion would be catastrophic, but VERY unlikely. The payroll server going down has much less impact, but will occur more often, so should be the priority in this ridiculous example.

Now that you have your risks ranked in terms of impact and likelihood, you need to put some kind of monetary value on each in order to put the final prioritisation against it. It is VERY difficult to put $/£/¢ values against these risk rankings, but unless you do, you can’t prioritise, nor can you set the baselines required in your operational resilience (OR) / incident response (IR) / disaster recovery (DR) plans.

For example, if your e-commerce sites makes 100% of your revenue downtime is not an option. Therefore you not only need full redundancy in your systems and apps etc, and real-time monitoring of system health, you also need extremely robust SLAs against your 3 party vendors (hosting facilities etc.). Only this will ensure that both IR and DR processes are in line with your Business Continuity Management (Core Concept 6) plans.

You have those, right?

If it is determined that the risk is just too great for the organisation to stomach, you will move on to the next step in the process; Security Control Selection & Implementation (Core Concept 2). You will start by performing a gap analysis of your infrastructure to see where the gaps are between your current capability, and the agreed standards accepted by management in the risk assessment phase.

The purchase of technology is always the LAST resort! Business process review is the first, enhancing the capability of existing infrastructure is the second. Rushing to throw technology at gaps can lead to bigger problems as I have suggested in Insecurity Through Technology.

One of the themes I have running through my posts – other than the terrible grammar – is the concept of how not knowing where to start often leads to organisations doing nothing at all. As in every other instance, the way to avoid this issue is to ask the people who DO know. A good consultant will not only be able to help you design a risk assessment methodology for your organisation, they will be able to teach you to run it yourself. Remember, the role of your consultant is to teach, not just do.

Finally, like every other business process, the risk assessment methodology should be standardised across the enterprise so that the results are compatible with the business culture and comparable against each other. However, they should also be reviewed at least annually, or after significant organisational, change for continued suitability. As your organisation changes and adapts to the future business environment, so must your risk assessment keep up in order to stay relevant, and useable.

This post is not meant to tell you how it’s done (there is an infinite variety of risk assessment methodologies), but to ease the confusion that is still prevalent. Hopefully I have done that enough that you at least begin to ask the right questions.

Like all security, the risk assessment is simple, not easy, but simple.

To summarise;

  1. Don’t do ANYTHING until you’ve conducted a risk assessment, and this includes starting your PCI compliance project (if applicable). This is beginning of all security, and the initiation of all future business plans;
  2. Don’t over-complicate it, just choose your target, set a time goal and stick to it. Whether you are finished or not isn’t important, you can always get back to it later and reducing your risk as soon as possible is more important;
  3. Get an expert in the first time, learn from them;
  4. Don’t BUY anything until you know where it fits in, and how you’re going to manage it; and
  5. Unless the solutions you choose costs well under the estimated value of the data, don’t buy them, it’s career limiting.

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