Information security management

Ian Glover, Insight Consulting - RHU London, Information Security Group
5 Nov. 1997

Text by Filip Schepers

Nowadays no computer systems are built without a thorough analysis of the system's requirements. The same definitely goes for a security system where high interests are at stake. This text tries to describe a risk analysis conceptuel model for which a implementation tool was built as part of a European Commission project. It was carried out by Insight Consulting.

There are a different number of approaches to risk analysis. Some include expert systems, others merely provide checklists, some focus on qualitative aspects of security, others on quantitave elements. The best products to support risk analysis will try to approach the subject from different angles and eventually also provide inference techniques for extracting or creating knowledge from knowledge base data. They also differ in the aspects of security they cover: threats, vulnerabilities, analysis, recommendations etc.. A general analysis model includes an organisation's assets and their value to the organisation, the threats it is exposed to and its weaknesses and vulnerabilities. Based upon this information, the risks can be derived for the organisation, different subsystems, databases and data items. Subsequently, it allows for countermeasures to be set up, and codes of practice and the ever returning security policies can be drawn up. In the next paragraph, this model is to be broken down further to see what components are involved that enable us to determine the risks that affect an organisation.

First, a review boundary is set up. At the core of the review are the assets; external elements to the analysis can include the public telephone network, third parties that have access to internal databases and financial systems, etc. These are supposed to be given and they cannot be modified. Assets now are subject to deliberate threats (attacks for instance) and accidental threats (negligence, carelessness,…). Assets can be hardware, software or data. There exist dependencies between these elements and it is important to recognise them: unwanted access to one of these components can imply other crucial systems or data to be exposed. In order to be exposed to a threat however, this threat has to have an impact. Factors that can make a threat come true and hurt you (i.e. have an impact) are vulnerabilities. Furthermore, an impact requires an external or internal action to be taken or an event to take place. Unlike accidental threats, deliberate threats are triggered. Here we can distinguish between motivation and determination: why would someone want to attack the system (how attractive is it) and how far is (s)he willing to go? Other factors include an attackers resources and capability. For the appropriate controls to be put in place, these different impacts have to be measured. Impacts on different assets under consideration can be:

• Disclosure, unavailibility, modification or distruction of data;
• Disclosure, unavailibility, modification or distruction of software;
• Unavailibility and destruction of physical assets.

The goal of the model is to focus attention on the parts of the system that shouldn't be overlooked and to provide for consistent analysis.

Based upon the asset-threat-impact model, countermeasures can be devised. On the side of the assets one can remodel the system to reduce dependencies and communication between systems, or prevent uncompetent people to access systems they have no knowledge of. Letting a third party managing your infrastructure may be a solution. As far as threats are concerned, the idea is to reduce motivation (laws have proven to be rather unsuccessful at this point though) and vulnerability. A common example is the installation of a network firewall. Next one can consider to try and reduce the impact once an attacker has gotten in, for instance by distributing data over multiple machines or by putting different levels of physical protection in place according to the sensitivity of the systems or data. A final step is to think of detection of security breaches, for instance by setting up a decent audit system. Contingency and disaster recovery plans (including backups) are the ultimate precautions you hope you will never need. The closer your measures are to the assets, the more effective they become.

Now how can such a model be implemented? Clearly, it requires management to have a security minded attitude. Security planning and management involves long term strategic security planning and creating a corporate IT security policy. The next step consists of doing a risk analysis. The resulting recommendations are then to be implemented, monitored and tested. The results of the compliance checks should then eventually be used to revise the original analysis.

As mentioned before, doing a risk analysis involves determining the value of assets and their dependencies, doing a threat assessment and identifying the safeguards that are already in place. One aspect of identifying threats is assessing the likelihood of their occurrence and the severity of the impact. For the selection of additional or revised safeguards, one should keep the security objectives in mind. In general, any system's implementation has to consider a number of constraints (time, technical, financial, environmental, sociological,…). These have to be identified and will influence the selection of safeguards.

The life cycle of a security implementation can (partially?) be supported by software tools. They can also help in addressing a number of specific security issues. Here we can think of the wider use of public as well private telecommunications networks, the increased ICT literacy of users as well as attackers and the accreditation of security implementations against various (international) standards. Furthermore, good tools should provide assistance for all aspects of information systems security: personnel (training, management), documents (handling, storage, destruction), technical issues, planning and so on. They should contribute to cognitive ergonomic human-computer interaction, provide good facilities for modelling and representing information and be able to generate documentation and reports. Additionally they can provide backtracking possibilities (for justification, as in "why did we recommend this?") or what-if analysis. The output they generate can relate to varying levels of assessment, from high level policy statements to compatible detailed low level recommendations. A tool that appears to support a great deal of these functions is CRAMM used by Insight Consulting.

As computer systems became more and more mature, system engineers felt the need for good methodologies to build high quality software. The same goes for developing security systems. The conceptual model presented here certainly helps in understanding risk analysis, as well as in building a secure environment to protect an organisation's assets. It can be furthermore be implemented in software tools like CRAMM. In this case the tool not only helps in analysing the security requirements, but also in providing consistent countermeasure recommendations.