There are many aspects of security that need attention in this troubled world. It is in fact only a matter of keeping the unauthorised out and letting the legitimate users in, but nothing is that simple. Two overriding factors that cannot be ignored are (i) all legitimate users don’t have access rights to all facilities, and (ii) we need to encourage customers to use the new systems, not put them off. We are all aware of how off-putting those awful automated voice response telephone systems are and a lot of current Web systems are equally annoying.
One security model that is being put forward is to split the problem into two parts, inclusion and exclusion. This enables a different emphasis to be placed on the various aspects and to make it more practical to develop specific products. The security of inclusion relies on being able to create a single identity across the enterprise, single sign-on being a key objective. Security of exclusion involves identifying problems and reacting to them before they can cause problems. Virus checking is high on the priority list but filtering of Internet URLs is also now a necessity. Sadly this is to restrict access to outgoing as well as from unsolicited inward sites.
To manage inclusion each individual user should be given rights to access a sub-set of (a) systems, (b) data and (c) applications. Many security products have been implemented over the years to tackle this problem, particularly in older mainframe systems. Thus this is not an entirely new thing but with the growing emphasis on customer satisfaction it is becoming a broader issue. Security must spread across all systems, which is a real problem given the variety of incompatible systems in existence today. Further the older security systems were very good, but were concentrated on a specific subset of the system, so that total security needed to synchronise multiple sub-systems. This made the system either very inflexible or rather lax. A single enterprise wide system is now desirable.
There are of course, as with every new opportunity, a number of products claiming to solve all the new problems. In reality though it is essential to exploit the better of the installed systems by making them elements within a bigger security system. The same approach has been successfully used in other management systems, notably by adding snmp management nodes to most existing products and using them as agents monitored by a single higher level management system with a single point of control with a common operator interface. In many cases this approach has been extended to controlling sub-systems as well as monitoring them. The same concept is the practical solution to security management too.
It is not easy to define the legitimate access rights of users either individually or as members of one or more groups. It requires the maintenance of a detailed repository. This is a dynamic sub-system, since users come and go. New or modified applications will inevitably affect the user profiles as well. Thus the software needed to manage the repository is the third major sub-system needed for full enterprise security.
Choosing and installing the needed security software is a very complex business. So is finding the right personnel to run the system, which must be active on a 24x7x365 basis! The manager in fact could well become the weak link in the security system and could well be a target for ruthless fraudsters.
Identifying the most suitable products and suppliers is a very difficult task and one which few organisations have enough experience with to make sound decisions. Many sites have the basic background from experience with RACF or similar products and with more recent exposure to managing fire walls, but while this is OK for ongoing support, some help is needed in the beginning. The vendors all have a good story to tell, but this is one example where I feel that independent advice is essential. The most telling comment I heard recently came from a Dutch company, CPA. They made the point that before defining product strategies, it is better to define what is needed and what can be achieved in practice. A specification should be drawn up and costed. Some harsh decisions will have to be taken to leave some systems unguarded when it costs more to provide protection than the potential losses. This then gets more problematic because defining the potential cost of security breaches goes beyond direct fraud. A bad reputation can send fickle users to your competitors and a bad reputation can be all too easily and unfairly earned.
Martin Healey, pioneer development Intel-based computers en c/s-architecture. Director of a number of IT specialist companies and an Emeritus Professor of the University of Wales.
