« Collaborating safely with business partners | Main | Securing enterprise systems »

In the last posting to this blog, I discussed a massive security problem for the modern organization: how to collaborate safely with business partners, in what might be called "human-driven" processes. I went on to propose that the root of this security problem is that organizational applications (and data) are mostly located on servers - whereas they should be located on clients.

This may seem contrary to common sense - especially since many organizations have set out over the last 10 years deliberately to remove all client-side "User-Developed Applications" (UDAs) in the belief that this would reduce overheads. In nearly all cases at present, organizational software applications run on servers - including of course all "Web 2.0" apps, in which only the user interface is run locally - and once a hacker gets in to such a server-side system, they've won the lottery.

Whether or not this approach has actually reduced overheads is another question, of course, especially when you balance maintenance overheads against the increased productivity many users experienced from their own hacked-up spreadsheets and databases. But that's a side issue.

By contrast to the current approach, let's suppose enterprises were to switch to a truly decentralized model, in which all data, services, etc are supplied by clients, with servers being used only for non-interactive archiving/monitoring/analysis purposes. The hacker has a much harder problem - not only finding a target to attack (since properly built client software could be run from anywhere), but in making use of any access gained (since they will only ever see a small part of the complete picture). This supposes standardized, interoperable clients, of course, not a return to the mess of standalone UDAs.

Further, it is commonly believed in the security community that security policies based on "Role-Based Access Control" (RBAC) are the most promising approach. Ross Anderson, in his authoritative survey of computer system security techniques, wrote in 2001:

the policy model getting the most attention at present from researchers is role-based access control (RBAC), introduced by David Ferraiolo and Richard Kuhn ... This sets out to provide a more general framework for mandatory access control than [Bell-LaPadula] in which access decisions don't depend on users' names but on the functions they are currently performing within the organization. Transactions that may be performed by holders of a given role are specified, then mechanisms for granting membership of a role (including delegation). Roles, or groups, had for years been the mechanism used in practice in organizations such as banks to manage access control; the RBAC model starts to formalize this. It can deal with integrity issues as well as confidentiality, by allowing role membership (and thus access rights) to be revised when certain programs are invoked. Thus, for example, a process calling untrusted software that had been downloaded from the Net might lose the role membership required to write to sensitive system files.

(Anderson, R., 2001, “Security Engineering: A Guide to Building Dependable Distributed Systems,” Wiley Computer Publishing, p.145)

So RBAC may be the way forward from a security viewpoint. However, implementing RBAC in a way that meets true business needs is much harder than it seems. This is because most people do not need static Roles, and static assignment of Roles, but truly "dynamic" RBAC.

A very common business situation is that the parties to a collaborative work process may change as the process unfolds - not just the assignment of identities to Roles, but the Roles they play and the nature of these Roles. Think about any work process you personally engage in. By and large, the nature of your work (and that of each of your colleagues) is likely to change at some point during the process, often repeatedly. This is what I mean by "dynamic" RBAC. We are moving to a world in which work processes are distributed across the Internet, so we need Internet-wide dynamic RBAC systems to secure these processes.

However, current RBAC systems - which tend to be server-based - do not provide for this situation. They may allow for identities to be set dynamically, and sometimes for their assignment to Roles to be updated in use (though this can be cumbersome and poorly managed), but generally you must pre-configure the system with a set of Role definitions on deployment.

To date, there is no operating platform in widespread usage that implements RBAC in a dynamic enough fashion to support the kind of adaptive business processes typical of modern human working practice. Witness, for example, the J2EE authentication model, which is useless for such purposes - and other collaborative mechanisms such as email that depend on authentication and authorisation are fundamentally broken for the purposes of static RBAC, let alone dynamic RBAC. Anyone can edit email headers before sending a message to make the email appear to have been sent by someone else, and anyone that has worked in a large company knows just how useless email address groups are for the purposes of collaboration.

Similarly, dedicated attempts at providing Internet-wide security may have some claim to solve issues of authentication, and even in some cases static RBAC, but fall down completely when it comes to dynamic RBAC. In a 2005 article for ebizq, Identity and Human Interaction Management, I discussed the emerging federated identity systems Liberty Alliance and Shibboleth. Whether or not these ever gain traction, it is interesting to consider what they can and can't do. In particular, while they claim great security strength for authenticating users, they pay only lip service to the assignment of Roles to process participants - and have no dynamic RBAC mechanism whatsoever.

TAKE AWAY

Without "dynamic" Role-Based Access Control (RBAC) there is no way to safely collaborate with business partners. Yet at present, the IT industry has completely failed to implemented dynamic RBAC.

The reason for this failure is that modern business processes are inherently decentralized - so you need a supporting platform that is similarly decentralized, i.e., client-side. The business environment of the 21st century demands a safe, Internet-scale computing fabric in which people (as well as organizations) have the ability to create and manage their own trust stores; trust stores in which your working partners are assigned not just an identity but also Roles in specific business processes, and in which the users are empowered to control the security of the process from within, as part of the work itself.

In the next postings to this blog, I will discuss just such a platform.

[Declaration of interest: part of my work is building client software to implement organizational work processes]

Posted by keithhb in Security |Digg This|Add to del.icio.us