Build Visibility In
Visibility has been a constant theme for this blog. Elsewhere I've used the phrase build visibility in to emphasize the need to integrate visbility requirements into the build and design phases of any technology project. Visibility should not be left as an afterthought. Building security in is required as well, but how can you determine how security is working if you have no visibility?
Based on my experiences with technology deployments since the late 1990s, I've realized that the following cycle defines just about every project I've ever seen.
The cycle is Feature -> Management -> "Security" -> Visibility.
I am seeing this cycle at work in the mobile device space right now. Hardly anyone is thinking about how to determine if a mobile device (Blackberry, etc.) is compromised. The best we can do is imagine the sorts of attacks that might be happening to our mobile infrastructure, without visibility regarding how those devices might already be under attack.
I call this operating only within the Decide -> Act part of the OODA loop (Observe -> Orient -> Decide -> Act). We do it all the time in digital security. I called it Soccer Goal Security in 2005.
Does this cycle resonate with anyone?
Based on my experiences with technology deployments since the late 1990s, I've realized that the following cycle defines just about every project I've ever seen.
The cycle is Feature -> Management -> "Security" -> Visibility.
I am seeing this cycle at work in the mobile device space right now. Hardly anyone is thinking about how to determine if a mobile device (Blackberry, etc.) is compromised. The best we can do is imagine the sorts of attacks that might be happening to our mobile infrastructure, without visibility regarding how those devices might already be under attack.
I call this operating only within the Decide -> Act part of the OODA loop (Observe -> Orient -> Decide -> Act). We do it all the time in digital security. I called it Soccer Goal Security in 2005.
Does this cycle resonate with anyone?
Comments
Sounds like software design patterns. Its "lets build something, the define what we want to build after the first thing fails".
Every tech start-up does this. Great idea, get it working! Oh wait, poor mgmt/performance. Oh, crap, more time has gone by and we need to think about security...and so on.