Companies think they own their reputation, but in reality they don’t. A reputation is the aggregate of the popular opinion about you. Opinions, or thoughts, belong to an individual, true or not, and a company doesn’t own a person’s thoughts, therefore a company doesn’t own its reputation. QED.

Yes.  Absolutely.  In fact, there are already changes in the works to the FAIR model that reflect this line of thinking that will allow us to approach reputation damage in a much more rational manner that anything else I’ve seen to date.

Second, RE:  Hansei & Kaizen, Richard left the following comment.

I don’t agree with your view on Gemba even if we live in a virtual world. Look into any company’s wiring closet and you’ll immediately see a reflection in its maturity from the state of the equipment, the labeling / documentation and overall neatness. “Man with messy wiring closet, will have messy virtual servers.”

However, the true benefit in Gemba is not in the actual visual inspection. It is in in the journey from your desk to the data center / wiring closet.

I agree that the benefit is in the journey.  I can’t see the wiring closet as the main destination (I just don’t see it as a useful prior).  Maybe I wasn’t clear, or was taking for granted that you guys have been reading the blog for the past 2 years, but the journey needs to be to the LOB that owns the application.  The example most given when describing Gemba is going to the production line to look at the issue that causes a problem in the ability to create and sell a car.  The “security” journey is not to the wiring closet, but to the system itself and the logs that we have for the system and whatever network-based controls might be applicable.  And we, as an industry, are just starting to understand that this “security” is only part of the picture.  The whole picture is represented by the factors that create risk.

And for our “risk journey” that security journey is only a one of serveral useful pieces of prior information for use in analysis.  For risk we have to also journey back to the “production line”, or, in our case, to the application/LOB owner.  It may also be to corporate counsel, to marketing, to all sorts of other places in the enterprise because probable losses (a necessary measurement we need in order to understand risk) may come from many different sources in the organization.  For those with FAIR knowledge, think of the six forms of loss to get an idea of what sorts of journeys we need to make.

This is why tomorrow’s post is designed to look at what should we be reflecting about, and what is needed for reflection.

Hint:  our models for risk & risk management can give us an idea of how to create structure around Hansei for the IRM program.

HANSEI - WHAT IS “RELENTLESS REFLECTION?” - And why we’re talking about it in the context of Risk Analysis.

Recall from yesterday’s post about how I got to thinking about the concept of Hansei-Kaizen, “relentless reflection” and “continuous improvement” and how we might apply that to risk management.  It’s a concept born of Toyota and is, in some way, the foundation for “Lean” production.

Call me biased, but I think that Hansei - the act of ‘relentless reflection’ made structured is the analytical function.  And I hate to debate (post-mortem) the father of Toyota quality success when he says that Hansei is the “check” in Plan/Do/Check/Act, but I think that Hansei also applies to the “Plan” of the P/D/C/A or Deming cycle.

You’ll recall the P/D/C/A cycle can be thought of even as an implementation of Scientific Method, in that it is Observation & Hypothesis Creation (P), Experiment (D), Analysis (Check), and Act (Revise/New Hypothesis, etc…).  Well then as such, the Hypothesis creation involves creating a model or creating an expected outcome for data using the currently accepted model.

So in our industry there is an opportunity for Relentless Reflection in both the Observation and Hypothesis (Plan) creation steps, and the Check step.  We create an estimate for control strength, or probable losses in the context of risk- then we go to Experiment step.  That hypothesis can be put it into production, have an audit, have a penetration test, whatever, in the context of the Do step.  BTW - using Hansei/Analytics in Plan is one way that strong analytical functions can really make penetration testing more useful - as a means to test the estimates and inputs into a model.  It’s Penetration Testing 2.0!  (<- tongue fully in cheek, yes)

Those who are versed in the reasons to merge Six Sigma and Lean together are probably already seeing where I’m going with this today.  But before you think that a simple DMAIC function is all that is needed to create proper “Hansei”, let me encourage you to keep reading.

Now if the analytical function can said to be “reflection”, why must it be relentless?

One word.  Change. There are essentially four separate “landscapes” or sources of change that we face (more on those tomorrow).  But anyone who has tried to manage system compliance, log management or policy exceptions knows that change is possibly the most difficult thing we security professionals must manage.  And when you think about it, there aren’t too many other business functions like information security where significant visibility and insight about the environment is needed for “complete” information (get bullish on Log Management is my recommendation).

HANSEI STEPS ADAPTED TO INFORMATION SECURITY

This is one of those quality control concepts that we can mangle adopt.  At Toyota, Hansei-Kaizen includes the following basic steps:

1. Initial problem perception
2. Clarify the problem
3. Locate area/point of cause
4. Investigate root cause (using an ask why 5 times approach)
5. Countermeasure
6. Evaluate
7. Standardize

Now it’s important to note that part of this includes the concept of Go See For Yourself, called “Gemba“.  Gemba can be translated as “the actual place” or “the place where virtue or truth is found.” At Toyota this might mean going to the shop floor to see the issue at hand in the production line.  But for us, that’s a problem because we live in the virtual world.  There’s usually not much use in hanging out in the wiring closets to try to see the problems.

But if you combine the concept of Gemba with the concept of “Nemawashi” –the process of discussing problems and potential solutions with all those affected- we can forge a similar concept using risk analysis.  That is discussing the issue and the risk associated with an issue (what some people would call “risk management”) with the business/LOB/data owner and let them accept authority and the risk decision.  We, the risk analyst, our goal is simply to perform items 1-5 (presenting countermeasure options that include transferring or accepting risk).  By going to the line of business and involving them, responsibility is shared.  Also, if you structure organizational behavior right, personal risk is transferred!

This sort of approach is also in harmony with concepts like “mutual ownership of problems,” or “genchi genbutsu,” (solving problems at the source instead of behind desks), and the “kaizen mind,” (an unending sense of crisis behind the company’s constant drive to improve).

One of the criticisms I have with the way most people try to implement DMAIC into “Lean”

REQUIREMENTS

Now to get this done, I really see three significant requirements.

1.)  A change in political structure.

2.)  Models that provide consistent, defensible analysis.

3.)  A Quantitative approach.  This means using actual units of measurement (not just amorphous percents, ordinal scales, etc.)  for risk and it’s subsequent factors.  Sure there are times when Q&D qualitative approaches are acceptable, but policy should be to have quantitative analysis whenever and wherever possible.

That last item - the quantitative approach - is really quite important.  And the reasons why will be discussed further in tomorrow’s post:

“What should we be reflecting about? & What is needed for reflection?”

P.S.  Your comments and suggestions, as always, are welcome.

P.P.S  Those who may be familiar with Lean/SixSigma/Kaizen sorts of mashups may be thinking - “hey, an Analytical step is built into SixSigma”.  Well, yes there is some prevision for analytical functions based on statistics, but I find SixSigma geared towards creating a State of Knowledge about operational processes, not towards creating a State of Wisdom for CISO’s around security & risks “big questions”.  In otherwords, the analytical function in DMAIC is in the context of Kaizen, and a different step than “reflective” analytics.

Think for a moment about the very simple, used-to-death castle analogy with its walls, gates, guns, guards, etc. and how these parts related to early network security. The analogy certainly had its shortcomings already back then – but it nevertheless got popular because of its inherent simplicity.

In today’s complex data and identity driven world of security and risk management, the old castle simply doesn’t cut it any longer. Just think of examples like the skyrocketing amount of data “crown jewels” all over the place (not just in the tower), the almost constant transport of these assets to places in and mostly outside of the castle, and the fact that insiders/peasants pose a much bigger risk than external attackers. Also, there is not just one king today, everybody has something protect-worthy (data, identities, etc.) and the same person can in fact have multiple identities. Sure, you can add bits and pieces into the old castle metaphor, but it quickly becomes too complex and therefore useless as an analogy.

So, while most members of the security academia have given up on the castle some time ago, the question is: Can we provide a simple, yet somewhat holistic concept of modern security and risk management?

Fact is, that we as security professionals struggle to explain to non-security folks what it is we are doing and why we are doing what we are doing. A bit of insurance talk, a sprinkle of metrics, lots of tech explanations, and certainly a huge portion of scare tactics are still our most often applied tools. But we all know – and experience on a daily basis – that we are not making ourselves clear to LOB managers, executives, and other non-technical people.

So, is there a single, all encompassing metaphor any longer? Or will we inevitably end up comparing the complexity of today’s security and risk landscape to, well the “real” world? But then again, wouldn’t that ‘metaphor’ fall short of the main reason for why we use analogies – namely simplification? Hence, wouldn’t that be utterly useless?

Or, instead of trying to construct a next-gen analogy, do we simply have to become better at articulating ourselves? Are a non-tech language, simple words, and context going to be enough to get our message across? Or should partial analogies be thrown into our new communication mix? Or does everything ultimately boil down to K.I.S.S.?

As noted, the DOT alone accounted for this lion’s share of this year’s increases, but that increase is not in any way explicitly related to the relative security posture of DOT’s IT environment. It takes a search through the esoterica of DOT’s  budget line items to identify what security priorities are being addressed, and they do not appear at a glance to be related to current federal ISS mandates, such as FISMA or HSPD-12.

Partly to address this problem, a new Line of Business (LOB) was added to the federal IT budget last year: the Information Systems Security LOB. But OMB itself has yet to work out how to identify systems security spending in the departments that should be allocated to the ISS LOB, so it is still too early to try and assess federal security spending and security posture improvements. But one hopes the OMB’s establishing the ISS LOB portends more coherent budgeting of security investments in the future.

However, since most current federal security spending is related to either government-wide mandates such as FISMA and HSPD-12, and department-specific operational requirements there is as yet no mature federal strategy for national cybersecurity. The Department of Homeland Security has responsibility for formulating this strategy, so the assignment of DHS as the “Managing Partner” of the federal ISS LOB presents the opportunity to harmonize federal security spending with a strategy, once one is established.