BackInformation security management

 

Security: what, why and how ?

Disclaimer:the following text does not necessarily reflect the ideas of the author, but is merely intended to be a summary of a lecture at Royal Holloway University of London, as indicated in the title. Moreover, interpretations can be incomplete or even incorrect and the author can not be held responsible for misjudgements from his side.

 

Security: what, why and how ?

Gerry Cole, Cole Security Solutions – RHU, Information Security Group,
9 Oct. ’97

Text by Filip Schepers

This text intends to give a summary of the presentation given by Gerry Cole on security management and how this is seen by Cole Security Solutions, followed by a number on remarks regarding his discourse. It will first place the concept of security in a wider perspective and relate it to business issues. Next we will have a look at the challenges today’s businesses have to face and the environment in which companies are active. A discussion on how security can alleviate the dangers that threaten a company is then given, followed by a number of personal afterthoughts.

In our traditional model of economic activity, the concern of the management is to ensure that investors and stockholders get an acceptable return on their investments in the company. In order to accomplish this goal, management has to take into consideration a number of risks inherent to doing business. Many of these risks are determined by the different forces of Porter: dealing with suppliers and customers, local and abroad, and be alert for the emergence of new markets and stay observant for competitors.

A number of risks that relate to security issues can affect the continuation of the business (fraud, loss, mistakes, staff safety). Furthermore we can notice a trend towards the proliferation of automated information systems in organisations and distributed processing of data. These evolutions tend to make control of the business processes harder and make companies feel the need for security measurements.

In order to cope with irregularities, an internal control system can be set up by the management. It is well known that management can only be made aware of security issues by relating insecurity directly to loss of income. Managers should therefore be made aware of the threats and costs associated by a possibly insecure business environment. These could be called the cost of insecurity. Problems arising from insecure trading can have a financial impact (theft, loss, recovery, repair,…), but moreover it can do serious harm to an institution’s reputation and staff morale. The subject of control can be people (Barings bank), information (virus protection), processes (the Amex and Natwest tape backup blunders) or even misinformation (Eurotunnel hoax). On the other hand, the installation of a security system and policy also constitutes a cost that is made up by buying the system and managing it.

A hierarchical model with different levels of control and responsibilities can be set up that fits the organisation structure and provides an appropriate level of security, ease of use and cost. A security policy can form the framework for implementing such a model by defining different roles and their associated responsibilities.

In order to set up a decent security system, it is important to determine the threats. Statistics show that the highest computer related crime profits come from different forms of fraud: fraud with stolen information and fraud by false transactions. A striking observation is that the majority of the attackers are people from inside the company that have authorised access to the information, which leads to the general conclusion that everybody can be the problem.

Security controls can be manual or automated and can take different forms, varying from restriction of the use of resources (e.g. by using keys), to indirect controls (e.g. audit analysis) and direct work controls (verification, backups). But no matter how, controls must support the business objectives and must support risk management.

 

Comment

It is beyond doubt that every attempt to improve the awareness of security should be related to the domain that managers are familiar with, and that any implementation of security systems should fit the organisation structure. This remark is not only relevant for security, but is generally applicable to any issue that requires management to take decisions that affect the core of their business. However, apart from fitting the organisation culture, any new system, including security controls, should also fit the organisation culture. This is a very different topic and of primary importance for successful implementation.

Any imposed structures, no matter how rigidly defined by policies or statements, that are not accepted by end users or customers will not be able to unleash their true potential. This makes me wonder if security measures should be transparent to end users and/or customers, or whether they should be exposed. One could make a distinction in securing an end product (that affects the customer, e.g. banking services) and securing the process (that affects that employees manipulating the system, e.g. the usage of password to access information on computer storage). It could be argued that customers of a bank want to feel that their money is safely guarded (exposure of security systems), but it is also clear that rigid security measurements tend to irritate users, leading for instance to passwords or PIN codes being attached to computer screens by post-it notes.

I therefore think that security systems should not only take into account operational cost-benefit analysis, business products and business structure, but also business processes, organisation culture and customer satisfaction. From this perspective, I think different requirements will arise depending on the business concerned (for instance profit versus non-profit sector, high-tech consumer goods markets with short product life cycles versus stable environments, public versus private services, military applications,…).

 

  Ó Filip Schepers, Oct 1997 - Last updated 25/10/98