If you've been following this blog series on improving the security of collaborative work - congratulations.  You're still here!  I am well aware that the ideas presented so far not only run counter to accepted IT wisdom, but challenge assumptions so basic that no-one even bothers to voice them.

The assertion outlined in the previous postings is that securing work carried out across a "distributed network" - a network owned by no single participant in the work, like the Internet - is not being approached in the right way at present.  Why?  Because the nature of such a work process is to change as it goes along.

Securing any IT system at all is an immensely hard problem, for a number of reasons - the varied nature of possible attacks (ranging from "social engineering" to cryptography), the resource cost involved (both human and technical), the fact that new attacks are constantly being devised (by a highly efficient hacker community), and more.  However, in spite of this, if you are willing to try, it is possible to secure systems and keep them secured - unless, that is, the systems in question are changing under your feet the whole time.  And this is the exact nature of collaborative work.

As I have discussed on many previous occasions, both in this blog and elsewhere in my writing on Human Interaction Management, collaboration between humans involves repeated change to the process itself.  Much of what we do when we work with other people is to ask, "how should we proceed from this point forwards?", agree a means of doing so, and start putting it into practice.  We go through such a cycle again and again - in most work processes involving more than one human, it will happen several times.  Further, each time may involve a different group of participants - people come and go from projects, teams, ventures, negotiations, programmes, etc - and even those that stay the course generally find that their role in the proceedings changes subtly or dramatically as time goes on.

With regard to IT systems, this means that any IT systems geared towards support of collaborative work must be able to support such constant change.  However, current enterprise technology is not in a position to do so.  Databases, project management systems, time recording systems, billing systems, document storage systems, communication systems, ERP applications, portals, ... the developers, administrators and controllers of such systems fight off change requests tooth and nail.  Why are these IT folk so resistant to the true needs of their business users - who are, of course, the only justification for having the systems in the first place?

Because mainstream technology available to IT folk to build systems makes the constant change required for business collaboration almost impossible - especially if you wish to provide secure, reliable systems.

OK, you might say, I know that old-fashioned monolithic application development, with its lumbering release cycles, was like this.  But surely, these days, there are better ways - ways that offer more dynamism and agility to the business?

Well, no, actually.  Despite the claims of vendors and analysts, if anything the situation has just got worse.

Business Process Management (BPM), for example, is often touted as a means to "keep the business agile", yet in fact it acts in almost exactly the opposite way - to bind people into a set of predefined processes, drawn up by analysts and implemented by programmers at great expense.  Changing such processes may well be harder and more expensive after implementing BPM than it was when everything was handled manually - especially as BPM in itself provides no formal way to guarantee the security and reliability of a process.  OK, you can encrypt XML messages sent as part of that process, and put up a firewall in front of your "demilitarized zone" - but any security professional will laugh if you offer this as a security policy.  With current tools and techniques, change a process defined in a BPM system, and any confidence you may previously have had about its integrity goes out of the window.

Similarly, Service-Orientated Architecture (SOA) will not help either - like BPM, it will only make the situation worse.  Many companies are investing massive effort into building hundreds of inter-related, inter-operable, and inter-dependent "services" to act as their IT backbone.  What they are doing is creating an immensely brittle infrastructure - one that is in unstable equilibrium, to draw an analogy from physics. In such an IT environment, who can say what impact changing particular services will have?  All sorts of cracks could open up - not only systemic breakdowns (crashes, deadlocks, livelocks, etc) but loopholes for hackers.  Best to leave well alone as long as you can ...

TAKE AWAY

Collaborative human work cannot be (and therefore is not) safely supported by enterprise systems in their current form.  What is the result?

People are doing such work informally - using telephone calls, text messages, emails, word processor documents, spreadsheets, whiteboards, and so on - just as they always have.  And this is about the most insecure way imaginable of carrying out what is, in the end, the most important work done by any organization.  Any and all of the previous ways of working are open to any number of attacks or compromises.  We've all heard about the laptops left in taxis.  At present, the whole business community is scattering information about carelessly, for want of any better way of proceeding - any computer systems that support the true nature of collaborative work, and do it responsibly.

In the last post I promised to describe what a different system might look like - but this has turned out to be rather a long post already, so that will have to wait for next time.  For now, suffice it to say that the answer lies in a redistribution of processing - to better mirror the real world.  Just as an organizational HQ is mainly concerned with setting strategy, monitoring its progress and providing resources to the people on the ground, so should enterprise servers adopt a less interactive and more supportive role.  And just as workers in any field need, if they are to work efficiently, to be empowered to get on with things without asking permission from their superiors for every tiny action they take, so should enterprise clients become more self-sufficient.

If you'd like to understand more about how this can be achieved, stay tuned to this blog.

Posted by keithhb in Business Process Management • Internet • Security | Permalink | Comments (1)

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 | Permalink | Comments (0)

One thing on which most people involved in business would agree is the need for some mechanism for collaboration with partners.  What does this mean in practice?

Go to your software vendors for an answer and you will hear something like this: "ah, what you need is a means of implementing distributed, transactional processes".  In other words, start using our Business Process Management (BPM) tools - i.e., get ready for a very serious investment of time and money in a series of long-running IT development projects.  The aim of this exercise will be, for example, to create a networked, just-in-time supply chain or to set up automated delivery logistics.  Such processes may require humans to be involved here and there - for example, to make decisions at key points, or enter data taken down from a telephone conversation.  But the work involved is largely about automating things, at least as far as possible.

This is powerful stuff.  But does it genuinely answer the original question?

Surely collaboration is about rather different things; things such as:

• Negotiating with others - both inside and outside your own organization - to arrive at a set of shared, agreed goals, together with working processes designed to achieve these goals
• Putting in place mechanisms to decide on who will be involved in the work, help them get started, and support them while they see it through
• Integrating the work with management practices and executive policies
• Continually revisiting all the above to ensure that it meets current business needs.

It is fair to say that the latter form of collaboration - that we might call "human-driven" as opposed to "mechanistic" - corresponds more closely to what, in the minds of most people, business is all about.  It certainly makes more of a difference between success and failure.  You can have the best supply chain in the world, but if no-one is buying your products, it won't do you any good.

I have written before in this blog about what it means to support human-driven processes.  In this next series of postings, I will try to address a particular aspect of this question.  How can one ensure that personal collaboration across the Internet is secure?

Many people have addressed issues of securing back-end systems, even if access to these systems is provided via (for example) Web services.  Andrew Townley provides a useful summary in his blog, for example.  Yet such techniques do not help at all when it comes to a world in which interpersonal work processes are distributed across the Internet.  In such a world, no-one "owns the process" - and what is more, no-one can prevent it from changing, continually.  This brings issues of authentication and authorization that are beyond the scope of current approaches to system security.

TAKE AWAY

In this next blog series, I will show how the root of this massive security problem is that organizational applications (and data) are mostly located on servers - whereas they should be located on clients. 

Does this sound crazy?  If you are locked into the perspective of current tools and techniques, you may be thinking that it sounds far-fetched.  But my guess is that, in a few years, we will be wondering how anyone could possibly have thought it was a sensible idea to try and centralize such controls over working life.

If you want to succeed in the new economy, you have to let go of some assumptions.  The main one of these assumptions is that individuals are not suitable guardians of a trust store.  By contrast, the only way to create a safe, Internet-scale computing fabric is to give people (as well as organizations) 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.

If you are interested to see why this is true, how it can be implemented, and how it can be safely controlled - stay tuned.

Posted by keithhb in Business Process Management • Internet • Management | Permalink | Comments (0)