PDCA for IT InfoSec, much assembly required

"But ignorance, while it checks the enthusiasm of the sensible, in no way restrains the fools." -Stanislaw Lem, His Master's Voice

A lot of the tech industry worldwide have turned to the ISO 27k standard as guide for getting their hands around IT security.  I say "getting their hands around" because I don't think as a whole, we're up to the challenge of actually measuring and managing IT risk (but that's a post for another day).

The heart of ISO 27K is the Plan-Do-Check-Act (PDCA), or the famous Deming Wheel Some even call it the Hamster Wheel of Pain because the process can be endless and ineffective if implemented sloppily.  Alex Hutton has recently pointed out that the ISO 27k standard doesn't say very much about whether your processes improve your security or not.  I'm inclined to agree, as the standard is primarily about the bureaucratic process of managing risk as opposed to defining the "real" work that needs to be done.   It can be wielded as bluntly and ineffectively as a SAS-70.  (hint: like a SAS-70, you actually need to read an ISO 27K certification report and keep a close eye on the scope and how decisions were made).

As a former IRCA Certified Lead Auditor for ISO27k (my cert expired this past November), I was fortunate enough to get both deep and wide training in the standard from some very experienced and gifted practioners. It led me to a deeper understanding of the standard, far beyond the page, and what it was trying to accomplish.

It also revealed to me how right Alex is in saying the standard is too rough to be applied with significant training and additional material.
In fact, many apply the standard as the same old laundry list of "shoulds" and "musts" of controls (aka the 27002 list). In fact, the toughest but most important piece of the standard is based on Deming's base concept.  Again, PDCA.   I have seen many skim organizations skim through Plan and race right to "Do".  Without a strong and detailed Plan, every other step is futile.

Do what? Why? And how much?  Check against what?  Act to correct back to what plan?  The essence of planning as I see it is something that is hard to define as a hard-coded procedure, which is perhaps why it is so watered-down in the standard.

A fallacy in management is that what works for some organizations may not work for others.   Cargo-cult mimicking of management processes is not only ineffective but dangerously misleading when certifications start getting thrown around.

Planning involves coordinating with the business of the organization to discover the information flows, data repositories, business rules and critical objectives.  Then working with upper-management to define priorities and trade-offs.   After that is done, a thorough risk analysis of the dangers to those objectives has to be done.  The standard does offer a risk analysis method, but it simplistic and shallow compared to more in-depth methods like FAIR or FMEA.

The final piece of planning is to decide how to treat those risks.   In the standard, this is documented in the Statement of Applicability or SOA.   The SOA is a mapping of objectives to risks with the selection of a treatment method.  The list of controls in 27002 is suggested but not mandatory.  You can drop controls to your list, if your analysis supports it.  The standard actually says "Note: Annex A contains a comprehensive list of control objectives and controls that have been found to be commonly relevant in organizations.  Users of this International Standard are directed to Annex A (ISO 27002) as a starting point for control selection to ensure that no important controls are overlooked."   Let me repeat that, you do not and probably should not take the list of 133 controls in 27002 at face value, implement them all and think you're done.   Here you have the flexibility to choose what works to deal with the risk to your organization's objectives.  That's "applicability" part of the standard.

I am really excited that Verizon is now giving us a more accurate picture of risk and controls in the real world.  I, for one, welcome our new Evidence-based Overlords. Especially as an more in-depth list of control deployment tactics instead of ISO 27002.   As said in medicine, half of what we know is wrong, but we don't know what half.  This is a step in moving towards knowing and the key is learning from other's mistakes.

You can see that a solid foundation is how the PDCA begins.   And as you move through the Deming Wheel, you "Do" and "Check" to see how well your controls are doing.   Not only are they being implemented correctly (which is where most people and auditors stop checking) but how appropriate and useful are they to the risks to the objectives.  You also should be "Checking" how accurate your original analyses of the business and risks are.  Then you "Act" to revise them appropriately.

But almost none of this is very explicit in the standard. Especially to those who used to the world of checklists and to-dos, and have a tough time with deep business analysis and strategic planning.  But that is where the real value lies.  My problem is that if you know how to plan your infosec well, what do you need the standard for?  The ISO implementation guides do help a little (at an extra cost), but the hard stuff is to be found elsewhere.The rest of ISO 27k just defines the paperwork format that is certifiable to the standard. 

TLDR; If you understand IT strategy and analysis, you probably don't need the standard except for certification. If you don't, the standard isn't enough to help you.