IT Directions

Keith Harrison-Broninski

Securing enterprise systems

Vote 0 Votes

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 ...


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.

1 Comment


Nice post. By taking it completely out of context I wholeheartedly disagree with much of it! (but that's not a reflection on what you've said). I absolutely agree with your parting comments though:

"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. "

I wanted to respond to you in a comment here, but it got too long, so I posted it here:

In essence, I agree that collaborative tools are necessary and disagree that collaborative tools and approaches should be artificially used in non-collaborative environments. A company's travel expense process is for example not too collaborative (though it could be fun if it was!).

I'll be following your posts to see where you thoughts are going on this.


Keith Harrison-Broninski cuts through the hype in his hands-on guide to where enterprise IT is really going

Keith Harrison-Broninski

Keith Harrison-Broninski is a researcher, writer, keynote speaker, software architect and consultant working at the forefront of the IT and business worlds.


 Subscribe in a reader

Recently Commented On

Monthly Archives