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.
- Level 0. I pick up my POTS line and there is no dial tone.
- Level 1. status.twitter.com. Gmail Last account activity.
- Level 2. www.google.com/appsstatus. status.aws.amazon.com
- Level 3. Pick an app that writes to /var/log/messages on Unix. Cisco IOS logging. Amazon S3 Server Access Logging.
- Level 4. Pick an app that writes debug-level messages to /var/log/messages on Unix. Cisco IOS debug logging.
- Level 5. Tcpdump of network traffic. Memory capture and analysis.
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.
Comments
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-)
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.
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
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?