Thursday, August 13, 2009

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?


John Ward said...

Ready, shoot, aim?

Sounds like software design patterns. Its "lets build something, the define what we want to build after the first thing fails".

Alex Hutton said...

Great post, it very much resonates with me. I'd like to understand how we might be able to best measure "visibility" if not for particular InfoSec processes, but also in aggregate for threat, control, impact and asset landscapes in aggregate.

LonerVamp said...

I also concur, and it fits with microscopic apps as well as macroscopic global trends.

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.

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