Loop back security

This is a classical step-wise view of the conventional ISO27k approach to managing information risks:
  1. Identify your information risks;
  2. Assess/analyze them and decide how to treat them (avoid, share, mitigate or accept);
  3. Treat them - apply the chosen forms of risk treatment;
  4. Monitor and manage, reviewing and taking account of changes as necessary.
    As an example, most organizations have some form of user registration process to set up network computer accounts (login IDs) for workers. The controls outlined in ISO/IEC 27001 Annex A section 9.2.1, described in more detail in ISO/IEC 27002 section 9.2.1, are part of the suggested means of mitigating the risks associated with inappropriate user access to information and information systems, one of the four forms of risk treatment at step 3 in the risk management process.

    Ah but what happened to steps 1 and 2? Oh oh.

    Working backwards from step 3, management appear to have decided that the A.9.2.1 controls are required in step 2. So how did they reach that decision? Is there any evidence of that decision ever being taken, other than the fact that the controls are now in place? What drove the decision? What were they hoping to achieve? Were the  alternative risk treatment options considered and rejected?

    Prior to that, someone presumably identified the information risks in step 1. Great! Let's see them, then. Go ahead, make my day, show me the risks that are addressed by, say, your controls under A.9.2.1. Let's talk them over. What is the organization hoping to achieve with these controls? What would be the predicted business consequences if the controls weren’t in place, didn’t work as planned, or failed for some reason so the risks eventuated? How drastic would such an incident be to the organization: would it be terminal, very costly and disruptive, somewhat costly and disruptive, or merely annoying and of little real consequence? Relative to other information risks, are these risks high, medium or low? Are these risks a major concern for the organization, a clear problem area that has maybe led to a string of nasty incidents or near-misses in the recent past, or are they just theoretical concerns, perhaps things that might conceivably be a problem at some future point?

    Posing such questions is not simply a matter of me being an awkward bugger, a stickler for process, trying to prove an hypothesis that you didn't get to where you are by following the route prescribed by ISO27k, instead assuming that “Of course we need access controls! Everyone needs access controls!”. The real reason is to explore your organization's understanding of its information risks, since that implies a level of care over designing, documenting, implementing, operating and managing the controls, relative to all the other controls and risk treatments in scope of the ISMS - and not just the user registration and access controls: there are loads of controls relating to loads of risks. Do you have a good grasp of them, or have you jumped directly to The Answer without understanding the Question? Show me your workings! 

    There are implications for step 4 as well. If the A.9.2.1 controls are absolutely vital for sound business reasons relating to the associated risks, clearly management needs to be certain they are strong, which implies a lot of care and assurance, close monitoring and urgent action if they look likely to, or do, fail. If they are necessary, somewhat less care may be sufficient, with some assurance. If they are nice to have, then the amount of effort and assurance may be minimal … saving the resources for other more important matters. [Evidently, since they exist, someone has already decided they are not unnecessary!].

    The approach I'm waffling on about here is an illustration of a far more general point about rational, systematic or even scientific management. We often do things 'just because'. We follow convention. We adopt 'good practices' and prefer not to 'buck the trend' or 'stand out' ... but that's not always the best approach, and with a bit of thought we may be able to do things better.

    Looping back and forth through any sequential process gives us the opportunity to review and revise our understanding, deepening and extending it on each pass. Identifying and challenging our assumptions can lead to valuable insight.

    Of course there is a near infinity of loops to loop and it's neither practical nor advisable to attempt to review everything, implying a process to decide which loops to loop, addressing the why, when, how and who questions. I'll tackle that aspect another time.