Wednesday, October 07, 2009

Technical Visibility Levels

It's no secret that I think technical visibility is the key to trustworthy technology. Via Twitter I wrote The trustworthiness of a digital asset is limited by the owner's capability to detect incidents compromising the integrity of that asset. This topic has consumed me recently as relatively closed but IP-enabled systems proliferate. This ranges from handheld computers (iPhone, Blackberry, etc.) all the way to systems hosted in the cloud. How are we supposed to trust any of them?

One of the first problems we should address is how to describe the level of technical visibility afforded by these technologies. The following is very rough and subject to modification, but I'm thinking in these terms right now.

  • Level 0. System status available only by observing explicit failure.

  • Level 1. Anecdotal status reporting or limited status reporting.

  • Level 2. Basic status reporting via portal or other non-programmatic interface.

  • Level 3. Basic logging of system state, performance, and related metrics via defined programmatic interface.

  • Level 4. Debug-level logging (extremely granular, revealing inner workings) via defined programmatic interface.

  • Level 5. Direct inspection of system state and related information possible via one or more means.


Let me try to provide some examples.

There must be dozens of other examples here. Keep in mind this is more of a half-thought than a finished thought, but I've been sitting on it for too long. Hopefully out in the open someone might comment on it. Thank you.

9 comments:

Ramki B Ramakrishan said...

IMO this topic needs a 2 - 3 part series...

Barry Anderson said...

Richard,
Good point, especially given the proliferation of security (and other) "appliances" which are essentially unmanaged (unmanageable?) and also given that the coders of security software don't seem to know much about secure coding! I think another good example for Point 5 would be making the device monitorable/manageable via SNMP (of course v3 - otherwise you have a whole *different* set of concerns!)

B-)

Alex said...

Love the post. Visibility Maturity is a great concept!

Maybe (if there's going to be a part 2-3) you can give justifications -based on usefulness- for each level of segmentation? They're somewhat apparent just by the descriptions you have there, but I'd like to see why you make the distinctions at those points.

Kyle Maxwell said...

You could also relate them to the relationship between effort in detection (scaling roughly from 0-5) and the amount of useful data (scales inversely).

j said...

Love the idea but to expand it a bit at level 5 would be ability to examin the source code. Having that ability can only enhance ones trust in a system/app.

Anonymous said...

The trustworthiness of a digital asset is limited more by the trustworthiness of the owner than tamper detection. An owner with desire of privacy and data integrity has the means to protect digital assets.

Gunnar said...

"The trustworthiness of a digital asset is limited by the owner's capability to detect incidents compromising the integrity of that asset."

great tweet, I would add that the trustworthiness of a digital asset is limited by the owner's capability to *deliver* integrity *to* that asset.

afaik we have never built a single high integrity system, so there is opportunity for improvement there as well

iang said...

I would have started from the point:

The trustworthiness of a digital asset is limited by the asset's ability to be compromised...

And spent all my time reducing that surface area. But maybe this is a luxury not permitted to me?

Anonymous said...
This comment has been removed by a blog administrator.