I love ticking boxes, makes me feel as though I’ve achieved something. It’s like a check list, each tick-box is a step closer to completing my list of ‘things to do’. It’s kind of satisfying. It is even more so when I get paid a good hourly fee for ticking boxes πŸ˜‰

Okay, so I’m joking a little. Preparing an organisation for ISO27x certification is a little more complex than purely completing a checklist. Yet, however simple or complex it is, even when your organisation passes its audit, it does not prove it is secure. It does prove that you tried your best, i.e. demonstrated ‘due diligence’. Then if something does go terribly wrong, i.e. one of your user accounts is used to hack into the organisation and access information that if made public can ruin your business. Well you tried your best within the boundaries of your capabilities, so I guess that’s okay? Or is it? I guess not, if you go out of business, or end up spending the subsequent 12 months in a crisis mitigation mode!

The problem as I see it is multidimensional and not limited to this list:

    1. Reactive security – We are so focused on doing the security stuff that we understand, i.e. ticking boxes, that we don’t get to the core of the problem.
    2. Product-focused security – Even if we think it can be solved with a product, there are so many security product vendors out there touting the ‘magic bullet’, nobody knows who or what to believe anymore.
    3. Mis-alignment of security spend with LoB – Every security product implemented often does not address the fundamental business need. Evidence of this is when new security products/services come out of the IT budget, not from the Line of Business (LoB)
    4. BandAid security – Due to point (3), lack of LoB ownership for security spend means no sponsorship. This can result that even if security spend is approved, e.g. security mitigation effort needed to meet compliance requirements, the effort can be likened to a ‘BandAid’ approach to fixing what needs fixing.
    5. Non-contigious defense-in-depth security – Due to all of the above your security infrastructure is not contiguous. The ‘defense-in-depth’ approach to your security programme recommended by security experts maybe deep, but full of holes.
    6. Information that moves – Our digitised society has changed the parameters on how we should be doing security, however in our organisations we are still thinking as though information is static and can be contained. It cannot.

Fixing all of the above is pretty daunting, and it has become generally acknowledged today that no way can it be guaranteed that the confidentiality and integrity of information assets owned by your organisation are fully protected. So what’s my view on this?

Well it is fun clicking boxes and I’ve made a lot of money during my career in this activity πŸ˜‰ But I guess you’ve figured that I feel that it is not quite as satisfying as I made out at the beginning of this post. To try and simplify things I see roughly 2 tracks in my head. The first is business security, and is the linkage from business needs to scoping. The second is how to do this from a technology perspective, and this I’ve grouped as: people-centric, device-centric, and information-centric.This is to reflect the fluid nature of information today, that cannot be contained by building a fortress around it.

BUSINESS Security

    B1. LoB – What is the need?
    Firstly security needs and spend must come direct from the LoB. They know best their business, and know what needs protecting more than I do as the security expert and your IT department. The most important question to be asked is:
    1) “What can ruin your business?”,
    2) and, “What do you need to be compliant with?”.
    Clearly security spend is commiserate with what you want to achieve. For example if a vendor wants to sell you a DLP product across your whole company, think twice, and ask this question what is it needed for (1: to protect from ruin) or (2: to be compliant)?
    B2. Keep it small
    Take one business process at a time and fix it using the following 3 principles.

TECHNICAL Security

    T1.People-centric security
    How we do identity control today is the weakest link in the security chain. See my previous posts on this. I call it identity control not identity management, because it is about control and traceability. For your organisation, and for the identity holders. Your organisation and your employees are continually a part of digital interactions, and all of those that you share together, belong to your organisation!
    T2. Device-centric security
    Take a look at what the Trusted Computing Group is doing with the chip. I normally refer it to putting “security at the ‘chip’ level”. This is not technically accurate, but it confers a meaning around that the security is at the microprocessor level of the device rather than at the Application layer. If you liken it to a house, it means that you have walled in all your windows (Application layer), and the only way in is through the door (ground-level) with high-level security controls linked intimately to your digital identity -that of course follows the people-centric approach to identity control πŸ˜‰
    T3. Information-centric security
    This is all about protecting and adding traceability to your information, wherever it is stored. Examples include your mobile workforce and their mobile devices. Then where is your critical information when at rest, in a public or shared cloud? Well this information should be encrypted using a key-fragment approach. This means, 1) your cloud provider cannot see the contents of your information in the cloud, 2) you hold the key, and 3) a fragment must be collected from a key-fragment central store, that could be owned by yourself, so you have traceability on who is accessing what information in the cloud through key-access patterns.

Now that I’ve finished with my little ‘brain-dump’ on you guys, I guess I should get back to ticking boxes πŸ˜‰