NOW AVAILABLE The draft of my book on Organizational Intelligence is now available on LeanPub Please support this development by subscribing and commenting. Thanks.

Monday, September 12, 2005

Technical Security and Context

There is a kind of security that can be provided by technology alone, but it is a very limited kind of security. Real security involves people and organizations as well as technical devices and technological services. So how do we evaluate technologically based statements about security?

Labelling a technology or protocol as "secure" can be meaningless or dangerously misleading. Technologies and protocols can only be secure for some purpose in some context. And we typically have to compose a number of complementary security mechanisms (social as well as technical) to arrive at anything remotely resembling a secure system / solution.

Several vendors are currently talking about RSS Security and/or Secure RSS, including Andrew Nash (Reactivity), Mark O'Neill (Vordel) and Greg Reinacker (NewsGator). These vendors are among those flogging a range of security mechanisms that are available for RSS-enabled business solutions - including authentication, authorization and encryption.

These mechanisms have no business value until they are composed with other complementary mechanisms to produce a specific business solution in a specific business context. So the important question is not whether RSS is secure or not, but how secure a particular composition is, in a given context.

Security analysis then shifts from Performance Risk (a component service not working as specified) towards Composition Risk (the component services not working together as a whole as intended) and Implementation Risk (the solution not working in its context-of-use).

So who benefits from standardized compositions? Does it help the attackers to possess details of the composition (a Marauder's Map)? Does it help the defenders to publish/share details of the composition? Do standards create a false sense of security ("lots of clever people have looked at this, so I don't need to bother")? Questions like these are well-known in the security domain.

So we appear to have three routes to a secure solution (for RSS-enabled or anything else), corresponding to three of the four types of trust.

Adopt an off-the-shelf package of security mechanisms offered by the vendors.
Suitable for low/medium security requirements
Quick and cheap?
Develop a specific security solution for this particular requirement. Suitable for high security requirements
Expensive & slow?
Adopt industry standard or "Open Source" composition.

Technorati Tags:

No comments:

Post a Comment