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.

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

Technorati Tags: open source risk RSS security service composition SOA sociotechnical trust