Information security management and modelling

Lam-for Kwok City University of Hong Kong, Department of Computer Science, Kowloon, Hong Kong Dennis Longley Information Security Research Centre, Queensland University of Technology, Brisbane, Queensland, Australia

Keywords

Computer security, Data security, Information systems, Modelling, Risk management, Standards

1. Introduction
1.1 Role of the information security officer

The awareness of potential information security vulnerabilities among senior manageInformation security management ment often increases as a result of media has been placed on a firmer footreports, or changes in the information proing with the publication of stancessing systems. Sometimes it is due to dards by national bodies. These standards provide an opportunity external pressures from clients, business for security managers to gain partners or new legislation, e.g. data protecsenior management recognition of tion or computer crime acts. Thus the Morris the importance of procedures and Worm produced initial strong reactions mechanisms to enhance information security. They may also place among senior management and a consequent demands on security managers to profitable business in antiviral software. provide convincing demonstration More recently proposed organisational conof conformance to the standards. nections to the Internet often raise the The risk data repository (RDR) computer model described in this spectre of international hacker attacks, and paper was developed to manage trigger security audits. The increasing conorganisational information securcerns of clients, particularly in Internet ity data and facilitate risk analysis commerce, have compelled companies to studies. The RDR provides a form adopt at least a public stance of information of computer documentation that can assist the security officer to security. If organisations decide to co-operate maintain a continuous record of with network links, or exchange electronic the organisational information sedata, each company may well express a curity scenario and facilitate concern on the danger of importing the system security development, business continuity planning and other's vulnerabilities. The past decade has standards conformance audits. also seen the introduction of legislation that often places a responsibility on organisations to demonstrate a requisite level of care when handling computer data. It is clear that senior managers in many large organisations are now expressing a much greater interest in information securThis study was conducted ity than their counterparts of five or ten under the auspices of the ARC Collaborative Research years ago. There is high demand for information security courses in information Grant: An Information Security Model for Finance technology (IT) faculties, and an increasing and Banking Sector, level of information security training within Reference No. organisations. Information security officers C195301033. are now being appointed, or more commonly current employees are being asked to assume responsibility for information security. This latter trend often, however, results in the Information Management & shift of information security responsibility Computer Security 7/1 [1999] 3039 down the organisation, and such security # MCB University Press officers can find themselves in a difficult [ISSN 0968-5227] situation.
Abstract

The problems commonly faced by such security officers are: . lack of full commitment from senior management; . lack of authoritative source of guidance; . difficulty in deciding how much security is required; . conduct of security audits/risk analysis; . convincing demonstration of the current level of security to auditors. Information security is a difficult entity to measure, and the security officer may not be able to create convincing performance indices. Often the security officer can promise at best: some bad event that has never occurred in the past is now, due to effective information security, less likely to occur in the future. In these circumstances the security officer may find it difficult to justify a budget for more extensive access control, or even the authority to require employee conformance to demanding security procedures, particularly if such procedures are seen to impact upon productivity. When the security officer is confronted with resistance to his attempts to improve security, the dialogue may simply take the form of a disagreement on the likely cost effectiveness of the proposals in relation to the likelihood of the threat event. In such circumstances an authoritative document or publication can be of considerable assistance but in the recent past the most commonly quoted sources such as TCSEC (Department of Defense, 1985), ITSEC (Commission of the European Communities, 1991), or banking standards (International Organisation of Standardisation, 1994) were of limited validity in many organisations. This situation has been ameliorated with the publication of Information Security Management Standards (British Standards Institute, 1995; International Organization of Standardization, 1995; Standards Australia/Standards New Zealand, 1996), and this topic is discussed in detail in this paper.

[ 30 ]

Lam-for Kwok and Dennis Longley Information security management and modelling Information Management & Computer Security 7/1 [1999] 3039

The above-mentioned debate is often part of a more a more fundamental problem: how much security is required anyway? The traditional response conduct a risk analysis study raises many more questions than it answers. Attempts by government bodies to impose risk analysis studies and methodologies on their own departments (Federal Information Processing Standards, 1974; 1979) often created risk analysis antibodies that spread into the private sector, and survive to this day. If the security officer does embark on a risk analysis study or security audit then the first major problem will be to ascertain the current security/risk scenario. In many cases it can be difficult enough just to locate reliable information on the current state of the system and protective measures. Attempts to determine the probability of threat events, and the ``value'' of assets, are likely to require an expenditure of management time and effort lying well outside the project budget. The crunch for the security officer may come, however, if a decision is taken to submit the organisational unit to an external audit. In this case the security officer may be faced with the responsibility of demonstrating conformance of organisation information security to externally imposed standards.

The Information Security Management Standards, first published by the British Standards Institute in 1995 and recently adopted by the Australian and New Zealand Standards Association, provide an authoritative statement on the organisational need for information security, and the procedures to be adopted for baseline security. They can thus represent a major step forward for the security officer. If used and interpreted effectively they can help to overcome some of the inherent problems identified above. These standards require a careful interpretation for current organisational environments, since on first reading they appear to be biased towards large computer centres. Nevertheless they do provide an important authoritative statement for senior management, and extensive checklists of security measures. Security officers would be well advised to develop local guidelines, based on an informed interpretation of the standards, customised to the organisation, and then submit an initial report for senior management. Such a report should detail the extent to which the organisational level of information security management is, or is not, consistent with the guidelines.

1.2 Information Security Management Standards

The recommendations in the standards are, as indicated above, geared to a baseline level of security. Once the requirements at this level have been addressed, the local scene should be reviewed to determine if the level of perceived risk justifies a more extensive study and more stringent countermeasures (Kwok and Longley, 1997). Even if such a study is not deemed necessary, the security officer may well be required, at some future time, to satisfy external auditors that the organisational level of information security is in conformance with internal or external requirements. Such risk analysis and/or security audits will involve documentation of the current organisational security scenario and this is likely to be a major task when undertaken on the first occasion. The major problem is that the task is likely to be equally demanding on any future occasion; if security audits checking conformance to standards or external imposed requirements become regular events then some careful forethought is required on the manner in which the security officer records the local scene. Commonly existing organisational documentation, even for large corporate bodies, is not in a form suitable for the security officer's purpose. In many cases the information resides in scattered filing cabinets or hard disks; often it is part of the oral history of the corporation. When the information is collected from its various sources, it will be difficult to glean security-relevant features from a vast mass of operational/administrative procedures and guidelines. Much of the information will be outdated. When the security features have been gleaned then there will be a major task of cross-referencing material from its various sources. The task of data collection is likely to be so demanding, and the resultant set of refined security information so incomplete, that the results of any risk studies may be viewed with scepticism. It is suggested in this paper that the problem described above arises because the data collection task is normally considered the first phase of a security audit or risk analysis. It is recommended that the security officer develops and maintains a security model of the organisation, so that it is available when required for future risk analyses and security audits. The maintenance of the model should, as far as possible, be organised in such a way that changes in the organisation that impact on security should be captured and included in the model as a matter of routine. With such a model in existence the security officer is in a less hazardous situation. The security officer can at least demonstrate to

[ 31 ]

Lam-for Kwok and Dennis Longley Information security management and modelling Information Management & Computer Security 7/1 [1999] 3039

external audits that he has a clear understanding of the current state of information security, and its potential weak points. If he/ she is wise he/she will also be able to produce records of his/her recommendations to senior management and their responses. As was stated above, in most organisations current documentation does not provide the model required by the security officer. Given the rate of change of information processing systems it is unlikely that paper documentation can easily handle model updates, and cross-referencing. This paper describes a model of organisational security suitable for the proposed purpose and indicates how it may be used to demonstrate conformance with current standards.

model, providing an essential level of cross reference, often omitted from paper documentation. It is postulated that the RDR could serve as an auditing conformance tool for the information security management standards, in addition to its role in risk modelling. The model is hence described below in its current form, and then in relation to its potential role in information security management auditing.

2.2 Risk data repository

The RDR essentially comprises three domains (see Figure 1): 1 Environment. All those features that effectively host or support the operation of the information processing system: equipment, buildings, staff etc. 2 Platforms. The logical description of the information processing system and its defences. 3 Assets. The data and processes that are to be protected because misuse of these assets would have a deleterious effect on the business operations of the organisation. From a risk viewpoint the model depicts the fact that: . an external threat will impact on the information processing system's environment thus, . causing some potential effect on the operation of the system and if the defences are inadequate then, . causing some potential effect (disclosure, corruption, loss of availability) to the information assets which will, . have some business impact. The model should contain sufficient information about its entities, and the links between the entities, to provide the best available information on the risks in relation

2.2.1 Overview

2. Information security modelling

The information security management standards have highlighted the requirement for collection and documentation of security relevant data. Such a requirement becomes obvious when extensive risk analysis studies are undertaken; indeed a major aspect of most such studies is the collection of data describing the risk scenario. However, many organisations do not possess good security documentation, either because the effort of data collection is so high that they are inhibited from undertaking the risk analysis study, or if such a study is undertaken the resulting documentation is not in a format that lends itself to ease of updating and use. The Information Security Research Centre at QUT developed an information security model as part of a consultancy study for a banking organisation, and this model has been extended in a collaborative research project with the National Australian Bank, funded by the Australian Research Council. As part of this project a prototype software version of the model, written in Visual Basic, has been developed. A hypertext version of the model has also been developed in a study on the security of a university student admission scheme (Kwok, 1997). The model was developed for risk analysis studies but experience with the model, and with security audits conducted for various organisations, indicates that the model may serve as the essential security documentation for a security officer. An essential feature of the model is that it represents, at any one time, the best set of security information available, and is therefore useful even when incomplete. When information is added to the risk data repository (RDR), it may be linked to existing components of the

2.1 Overview

Figure 1

Risk data repository

External Threat

Environment

Platform

Assets
Business Impacts

[ 32 ]

Lam-for Kwok and Dennis Longley Information security management and modelling Information Management & Computer Security 7/1 [1999] 3039

to postulated external threats. In this role the model not only represents the best set of information currently available to the security officer, it also highlights the entities that are relevant to the security officer, but which are not currently available in the organisational RDR. An essential feature of the RDR is that information is captured and then represented in its most natural form. The model may encompass very large organisational systems but the information collected and represented relates to the security characteristics of the entities. The format of the various parts of the model depends on the entities in the various domains. The advantage of a computer model is that linkages between entities may be easily represented and activated. The hypertext version of the model is particularly amenable to following the identified links e.g. from: . a building subject to flooding to . the floors that may be affected to . the items of equipment therein located to . the information processing node relying on that equipment to . the business impact associated with assets, stored, processed or communicated by that node. Each entity in a domain is represented as a text/graphics on a hypertext page, or a Visual Basic screen. Icons allow for the display of more detailed information on the entity, or switching to a linked entity along the lines described above. 2.2.3.1 Platforms. The platform domain is a graphical representation of the logical components of the information processing system coupled with threat countermeasure diagrams representing the defences to postulated threats. The icons for each node of the platform represent an information processing component, e.g. server, workstation, or in the case of a complex node a subplatform, e.g. a communications network. Descriptive information is associated with each such node and there are also linkages to other RDR entities (See 2.2.6 Mapping), e.g. the data assets stored at a computer, the roles allowed access to a workstation. 2.2.3.2 Threat countermeasure diagrams. An essential feature of the platform domain is the threat countermeasure diagram, used to represent the total set of appropriate countermeasures as described by Caelli et al. (1992). The threat countermeasure diagram is a tree of countermeasures with a postulated threat at the root of the tree (see Figure 2). A countermeasure may be in place to deal with

A countermeasure to a threat may cause residual or transformed threats

Figure 2

residual threat threat

2.2.2 Representation of the model

Countermeasure
transformed threat

2.2.3 Platform domain

this threat and this countermeasure may take the form of an explicit or implicit defence. Hence a countermeasure against the threat of unauthorised access to data stored on a workstation may be encryption of the file (explicit countermeasure) or location in a secured area (implicit countermeasure). Countermeasures may fail to provide a complete defence either because they may be bypassed, or attacked so as to negate their effectiveness. In the first case there is a remaining threat termed a residual threat, in the second case it is termed a transformed threat. Hence a cleaner, without authority to view the file, may bypass the physical access control (residual threat), or a cryptanalyst may break the encryption algorithm (transformed threat). In some cases the probability of the attack, e.g. cracking a strong algorithm, may be considered to be negligibly low. In other cases the residual threat may be sufficiently high for additional countermeasures to be deployed, e.g. all cleaners are supervised while in secure areas. The threat countermeasure diagram is thus a tree, each node of the tree taking the form shown in Figure 2. The leaves of the threat countermeasure diagram tree for a set of intersupporting countermeasures may comprise significant uncountered threats, or nulls, if the remaining threat is considered to be negligible. Given a measure of the strength of each countermeasure, it is possible to compute the overall effectiveness of the total threat countermeasure diagram.

2.2.4 Assets domain

The assets domain represents the information assets of the organisation that are of sufficient ``value'' to merit inclusion in the model. The purpose of the information system security is to protect the confidentiality, integrity and availability of information assets. The RDR assets domain stores data assets and processes. Business impacts are associated with: . loss of confidentiality of a data asset; . loss of integrity of a data asset; and . loss of availability of a process. A significant feature of the model is the allocation of impacts derived from management policy or statements and the

[ 33 ]

Lam-for Kwok and Dennis Longley Information security management and modelling Information Management & Computer Security 7/1 [1999] 3039

determination of inferred impacts based on the structuring of the data assets and the associated transfer of impacts (Anderson et al., 1994). For example, records may be structured into their components. A bank account record will have fields relating to the customer details, bank details and account details. If there is a high impact associated with revealing the details of the bank account, mere disclosure of the name and address would have no such impact. On the other hand if disclosure of customer names and addresses would cause damage to the bank, then disclosure of account records would have the same impact. Availability impact statements are only associated with processes, hence management may be required to indicate the potential impacts of being unable to perform a given business process for certain time periods. Processes are linked so that if a process calls another process then the called process inherits the availability impact of the calling process, i.e. if the called process is not available then the impact on the organisation is that arising from the loss of availability of the calling process in addition to that of the called process. Linkages are also made to data assets so that: . the impact arising from the corruption or loss of a data asset can be ascertained from the business impact of loss of availability of the processes accessing such assets; . it is possible to illustrate coupling of processes; hence if two processes access the same data asset, then a error in one process may cause another critical process (i.e. with high loss of availability impact), accessing the same data, to abort. 2.2.5.1 Overview. The environment domain comprises security information on those entities that host or affect the operation of platforms. This domain comprises: . buildings and sites; . equipment; . services; . roles and procedures. 2.2.5.2 Buildings and sites. Information on buildings and sites is essential for a security model since these entities may provide physical access control to equipment items implementing sensitive platform nodes. They may also have vulnerabilities to: illegal access, fire, flooding, water pipe leakage, vehicle/aircraft impact, terrorist attacks etc. Such vulnerabilities are a critical factor in the security model if the building hosts sensitive information processing components. The juxtaposition of rooms hosting

2.2.5 Environment domain

equipment and potential hazards is a particularly significant feature. The buildings and sites of the RDR may thus store building plans, details of perimeter fences, physical security details, floor layouts etc. This information may be linked to services, equipment housed, offices of operating personnel etc. 2.2.5.3 Equipment. Equipment items such as workstations, servers, modems etc. implement platform functions and are potentially vulnerable to damage or misuse, e.g. illicit access to a server could disclose network data. The security relevant information relates to the security aspects of the equipment, e.g. tamperproof, cost and delay of replacement, likelihood of failure (MTBF) etc. The linkages to the buildings and sites and platform nodes allow for threat events to be traced through the system. 2.2.5.4 Services. Services comprise power supplies, communication cabling, air conditioning, water supplies, fire alarms, smoke detectors etc. that are either essential for the operation of equipment items implementing platform nodes, or a potential source of threat to such equipment e.g. water damage from fractured pipes. Much of this information is captured in native form, e.g. wiring diagrams. Linkages are made to buildings and sites housing the services, equipment whose operation depends on the equipment etc. 2.2.5.5 Roles and procedures. Roles and procedures relate to personnel responsible for operational activities, or maintenance, their levels of access privileges, business continuity responsibilities and the manual of procedures which guide their actions. The hierarchy of roles from a security responsibility and privilege viewpoint are represented as tree structures. Security operating procedures, security codes of practice, security policy and organisational details will be stored within the procedures section as appropriate text files. Linkages in this case will include, inter alia, platform nodes subject to access by specific roles, security procedures for platform nodes, e.g. four eyes principles for sensitive transactions. Documentation with sections relevant to organisational information processing security is often incomplete and/or outdated. More importantly, however, it is likely to be stored in various departments with virtually no means of cross-reference. The description of the RDR domains above clearly indicates the range of information that is significant from a security viewpoint, and the associated linkages. Storage in a single computer model provides for such cross-reference between

2.2.6 Mapping

[ 34 ]

Lam-for Kwok and Dennis Longley Information security management and modelling Information Management & Computer Security 7/1 [1999] 3039

entities by simply clicking an icon. The bilateral mapping included in the model is given below. 1 Environment domain: . Buildings and sites to: equipment; services; roles and procedures. . Equipment to: platform nodes; buildings and sites. . Services to: platform nodes buildings and sites; . Roles and procedures to: platform nodes; buildings and sites. 2 Platform domain: platform nodes to: . threat countermeasure diagrams; . services; . equipment; . roles and procedures; . processes; . data assets. 3 Information assets: data assets to: processes.

(AS4444) (1996) are based on a BS 7799: Code of Practice for Information Security Management (1995). It comprises ten sections: 1 security policy; 2 security organisation; 3 assets classification and control; 4 personnel security; 5 physical and environmental security; 6 computer and network management; 7 system access control; 8 system development and maintenance; 9 business continuity planning; 10 compliance. The RDR was reconsidered in the light of the recommendations of the standards, to determine the degree of cross-correlation. Given that the RDR is intended as a security model for the organisation, this model would be the obvious starting point for security audits, particularly those aimed at testing the degree of organisational conformance to the standards. The following sections discuss the degree of cross-correlation which currently exists and the potential enhancements of the RDR to provide for conformance audits.

3. RDR and standards

The potential use of the RDR in risk analysis has been described in previous papers (Anderson et al., 1994; Kwok, 1997; Kwok and Longley, 1996). Currently the methodology and associated software is under further development in a collaborative research project in conjunction with the National Australia Bank, funded by the Australian Research Council. Based on experience with consultancy studies it is clear that a major factor of data security management is modelling and documentation. Existing documentation can be fragmented and hence fail to convey the complete security scenario. If conformance to standards is to become a feature of information security management, then it is essential that the necessary information is readily available to security officers, management and auditors, without excessively time consuming data collection exercises. Moreover such information needs to be in a format that allows for ease of cross-referencing and updating by the security officer. The RDR provides such a security model and it was decided to investigate the extent to which this model was compatible with the emerging information security management standards. The Australian and New Zealand Information Security Management standards

3.1 Overview

3.2 RDR domains vis-a-vis security standards 3.2.1 Security policy

The main recommendations in the security policy section of the standards are: . definition of information security; . statement of management intention supporting the goals and principles of information security; . explanation of the specific security policies, principles, standards and compliance requirements; . definition of general and specific responsibilities for all aspects of information security; . explanation of the process for reporting suspected security incidents.

At a trivial level the documented security policy could simply be included as an entry in the roles and procedures section of the environment domain. However, a closer analysis of the RDR indicates that it already contains implicit information on the security policy and hence serves to highlight the relationship between formal and implicit policy. For example the business impact statements included in the information assets domain effectively describe senior management intentions supporting the goals and principles of information security in protecting the confidentiality, integrity and availability of organisational assets. A low business impact statement, or absence of a statement, for a particular asset would

[ 35 ]

Lam-for Kwok and Dennis Longley Information security management and modelling Information Management & Computer Security 7/1 [1999] 3039

conflict with a declared intention to protect such an asset, e.g. personnel records. The general and specific security responsibilities for all aspects of information security would be included in the statements associated with individual roles.

and would need to be updated in the light of the proposed arrangements. As indicated above it is postulated that the RDR can provide the essential electronic documentation for an independent review of information security. The assets classification and control section of the standards is concerned with the effective administration, from a security viewpoint, of the organisational hardware and software assets. In particular with: . inventory of assets; . classification guidelines; . classification labelling. The equipment section of the environment domain and the data assets section of the information assets domain provide for the suggested inventory. If an organisational classification system for information assets is employed then it will appear within the business impacts statements for the data assets. If no such classification system is employed then the intrinsic classification in terms of organisational views on the sensitivity of data assets may be derived from the business impact statements. Personnel security is a vital part of organisational information security and it is important that there be formal commitments to this topic, and such formal commitments are communicated to staff. Thus the standards recommendations comprise: . security in job descriptions; . recruitment screening; . confidentiality agreement; . information security education and training; . reporting of security incidents; . reporting of security weaknesses; . reporting of software malfunctions; . disciplinary process. This section contains procedural information that is not normally included in risk analysis studies or models but there are significant links to the roles and procedures entities in the environment domain, when much of the relevant procedures and regulations could be stored. The standards drew heavily on past experience of computer centre management and as could be expected the physical and environmental security sections emphasised the security of large computing installations including: . physical security perimeter; . physical entry controls;

3.2.2 Security organisation

The recommendations of the security organisation section are concerned with the organisational structures for information security roles and responsibilities: . information security co-ordination; . allocation of information security responsibilities; . authorisation process for IT facilities; . specialist information security advice; . co-operation between organisations; . independent review of information security; . security of third-party access. From a risk analysis viewpoint much of this section would not have been stored in the RDR explicitly, except for the allocation of information security responsibilities included in the roles section of the environment domain. The documentation for much of this section could nevertheless be conveniently maintained within the procedures section of the environment domain. The RDR does, however, have an important role in the compliance of many of these recommendations i.e.: authorisation process for IT facilities, co-operation between organisations and independent review of information security. It is important that the security officer be involved in the authorisation process for new IT facilities both to ensure that the security implications of the proposed acquisition are discussed and that the security model is subsequently updated. The proposed acquisition could have significant security implications if it: . involved data or processes with high business impacts; . provided new accesses to sensitive data or processes; . impacted on current countermeasures. Information on all these matters is available in the assets, platforms and threat countermeasure diagrams of the RDR. Co-operation between organisations might well involve some new form of electronic access to information assets, e.g. new network links, or providing external staff with access privileges. In such cases the potential impact upon organisational risk may be estimated from the assets and platform domain. If new access privileges are to be granted then the roles and procedures would contain guidance

3.2.3 Assets classification and control

3.2.4 Personnel security

3.2.5 Physical and environmental security

[ 36 ]

Lam-for Kwok and Dennis Longley Information security management and modelling Information Management & Computer Security 7/1 [1999] 3039

. . . . . . . . .

security of data centres and computer rooms; isolated delivery and loading areas; clear desk policy; removal of property; equipment siting and protection; power supplies; cabling security; equipment maintenance; security of equipment off premises; secure disposal of equipment.

The environment domain of the RDR is designed to integrate the physical and logical aspects of information security and therefore plays an important part in this section of the standards. The sections dealing with physical security perimeter, physical entry controls, security of data centres and computer rooms and equipment siting and protection relate to the buildings and sites diagrams which can indicate security perimeters, and associated information can detail physical access control arrangements. The mappings from platforms nodes to equipment to buildings and sites can thus provide information on the physical access control for equipment hosting sensitive applications. Power supplies and cabling security is included in the services section of the RDR where the mapping between these entities, equipment and platform nodes highlights the potential security risks associated with such services. The section on computer and network management emphasises procedures associated with computer and network centre operations, although the final section on data and software exchange deals with the specific problems of the electronic office. The recommendations include: . operational procedures and responsibilities; . system planning and acceptance; . protection from malicious software; . housekeeping; . network management; . media handling and security; . data and software exchange.

3.2.6 Computer and network management

within operational procedures and responsibilities, are required for sensitive systems highlighted in the RDR and should be recorded in the procedures entities of the environment domain. This section also deals with security functions of roles, e.g. segregation of duties which would feature within the security attributes of roles in the environment domain. System planning and acceptance, particularly capacity planning, must take due cognisance of availability business impacts in the information assets domain. Likewise the business impacts associated with confidentiality and integrity of data assets should be taken into account in the security requirements of new systems. Virus controls appears to have been given a particular prominence in the standards, whereas one might have expected to see a wider discussion on more generic countermeasures. However, virus controls would be included within threat countermeasure diagrams in the platforms domain of the RDR. Similarly backup routines would appear as countermeasures in threat countermeasure diagrams dealing with loss of process availability threats. The section on data and software exchange actually includes a useful section on electronic office security and in addition to advice on the safe handling of magnetic media. Codes of conduct for electronic office security should be stored within the procedures section of the environment domain. The standards recognise the vital role of access control and this section not only gives the security officer an authoritative document for a topic that is likely to meet with some user resistance, but it also provides extensive checklists on password management etc. The specific recommendations include: . business requirements for system access; . user access management; . user responsibilities; . network access control; . computer access control; . application access control; . monitoring system access and use. The RDR can play a major role in relating access control to business requirements because the access control at platform nodes, as demonstrated by the threat countermeasure diagram nodes, can be directly linked to the information assets associated with those nodes and hence to the business impact associated with illicit access to those assets. The sections on user access management and user responsibilities should be included

3.2.7 System access control

The management section of the standards relates mainly to operational control and responsibilities and is therefore not included explicitly in the RDR, which serves primarily as a security model. Nevertheless, these procedures and associated documentation require cross-reference to the RDR to ensure that essential security aspects are incorporated in the management responsibilities and associated documentation. For example, appropriate incident management procedures,

[ 37 ]

Lam-for Kwok and Dennis Longley Information security management and modelling Information Management & Computer Security 7/1 [1999] 3039

in the procedures section of the environment domain of the RDR. The network access control is now a major feature of organisational information security management and a very common problem often arises because management are unaware of the extent of network configurations carrying sensitive traffic. The platform domain of the RDR can be an invaluable tool in maintaining diagrams of organisational networks, and demonstrating which networks or subnetworks carry sensitive data. These diagrams can then be checked against recommendations of the standards, e.g. segregation of networks to minimise security problems. The threat countermeasure diagrams should include details of network defences, e.g. user and node authentication, measures to protect against network roaming etc. Similarly the threat countermeasure diagrams will not only provide details of computer access control, use of passwords etc.; these diagrams will also indicate the manner in which countermeasures are structured to provide maximum effective defences.

RDR. When this occurs the information may be collected by interviews, filing cabinet retrievals etc. In this case the retrieved information can be stored in the RDR as part of its continual evolution. In some cases there may be no record available and insufficient time to acquire it. In this case assumptions are often made, e.g. on the business impacts associated with information assets. The RDR provides a convenient place holder for such assumptions, and an opportunity to test out the assumptions at a later time. If these assumptions prove to be incorrect then they may then trigger a reconsideration of the security decisions. The RDR has a major role in business continuity planning because it provides a model of the total system and cross referencing between the system's environment, the logical systems and the business impacts associated with loss of availability of processes. The recommendations of this section of the standard include: . business continuity planning process; . business continuity planning framework; . testing business continuity plans; . updating business continuity plans. The plans may be stored in the procedures section of the environment domain; on the other hand the RDR may itself may be included in the plans, or at least the resources to be made available to the planners. The business continuity plan in effect forms a countermeasure against loss of availability of essential processes and to this extent some aspects of it would be recorded in the threat countermeasures diagrams of the platform domain. The compliance section of the standards provides guidelines on the potential internal and external regulatory information security obligations of the organisation. The headings within this section are listed below: . compliance with legal requirements; . control of proprietary software copying; . safeguarding of organisational records; . data protection; . prevention of misuse of IT facilities; . compliance with security policy; . technical compliance checking; . system audit controls; . protection of system audit tools. It is suggested in this paper that the existence of the RDR will assist in checking organisational compliance. It would be useful to store details of such regulations in the procedures section of the environment domain. The degree to which the organisation specifies a commitment to these obligations can be

3.2.9 Business continuity planning

There will be wide variations in the applicability of this section of the standards; many organisations are now large users of computer systems but undertake very little in-house development. Nevertheless, even where no in-house development occurs, new systems are implemented by purchase of computer and communication equipment, off-the-shelf software etc. and what might appear to be quite minor changes can have significant security implications. The recommendations in this section include: . security requirements of systems; . security in application systems; . security of application system files; . security in development and support environments. The RDR will be a major source of information in all these activities, since if conducted with a view to maintaining and hopefully enhancing security then decisions on new system will depend on: . business security requirements as specified in business impacts in information assets domain; . current systems and countermeasures as specified in the platforms and threat countermeasure diagrams in the platforms domain; . host environment for the new system as specified in the environmental domain. In many cases it is likely that the required information has not been entered into the

3.2.8 Systems development and maintenance

3.2.10 Compliance

[ 38 ]

Lam-for Kwok and Dennis Longley Information security management and modelling Information Management & Computer Security 7/1 [1999] 3039

demonstrated by viewing the business impacts in the information assets domain. For example, a commitment to data protection legislation would be indicated if there were a high business impact associated with loss of confidentiality of personal data. Such a statement may be considered to be a necessary but not sufficient demonstration of commitment. The links from the data asset to the platform nodes, and the threat countermeasure diagrams for those nodes, would provide evidence of the current state of defences. The requirements to check compliance with security policy can also be met using the RDR to access the security policy, check its manifestation in the business impact statements and then trace the risk scenario and defences by tracing through the links provided by the mapping facilities.

4. Conclusions
The RDR was originally conceived as a tool for risk analysis but experience to date with the model and security audits suggests that it provides the basis for a security model which describes and cross-correlates the essential security information within an organisation. Given that information security standards are likely to play an increasingly important role in security officers modus operandi this paper investigated the correlation between the information stored on the RDR and the requirements of the standards. Many of the standards have been compiled in terms of organisational structures and operating requirements and to this extent the RDR procedures section of environment domain would provide a convenient placeholder. However, as shown above the RDR can provide a convincing overview of system security for security audits, and an essential tool for system security development and business continuity planning. Without the RDR such processes either present a major data collection task or are completed with a lack of necessary information. Moreover the RDR is a dynamic model in the sense that it may be easily updated and hence it serves a useful purpose at the outset, holding the best currently available information and is continually updated as it is employed in the system development, security audit and business continuity planning processes.

References

Anderson, A., Kwok, L.F. and Longley, D. (1994), ``Security modelling for organisations'', Proceedings of the Second ACM Conference on

Computer and Communications Security, CCS'94, Fairfax, VA, 2-4 November, ACM Press, pp. 241-50. British Standards Institute (1995), BS 7799: Code of Practice for Information Security Management. Caelli, W., Longley, D. and Tickle, A.B. (1992), ``A methodology for describing information and physical security architectures'', in Gable, G.G. and Caelli, W.J. (Eds), IT Security: The Need for International Cooperation, Proceedings of the IFIP TC11 Eighth International Conference on Information Security in IFIP Sec.'92, Singapore, 27-29 May 1992, Elsevier Science Publishers, New York, NY, pp. 277-96. Commission of the European Communities (1991), Information Technology Security Evaluation Criteria (ITSEC), Provisional Harmonized Criteria, Version 1.2, May. Department of Defense (1985), Trusted Computer Systems Evaluation Criteria, (TCSEC also known as Orange Book), DoD 5200.28-STD, December. Federal Information Processing Standards (1974), Federal Information Processing Standards Publication 31 Guidelines for Automatic Data Processing Physical Security and Risk Management, National Technical Information Service, Springfield, IL. Federal Information Processing Standards (1979), Publication 65: Guidelines for Automatic Data Processing Risk Analysis, National Technical Information Service, Springfield, IL. International Organisation of Standardisation (1994), ISO/DTR 13569 Banking and related services- Information Security Guidelines for Banking (Future Technical Report, type 3) 1st ed., ISO/TC 68/SC 2, International Organisation of Standardisation, Geneva. International Organization of Standardization (1995), ISO/IEC DIS 14980 Information Technology Code of Practice for Information Security Management, International Organisation of Standardisation, Geneva. Kwok, L.F. (1997), ``A hypertext information security model for organisations'', Information Management and Computer Security, Vol. 5 No. 4, pp. 138-48. Kwok, L.F. and Longley, D. (1996) ``A security officer's workbench'', Computers and Security, Vol. 15 No. 8, pp. 695-705. Kwok, L.F. and Longley, D. (1997), ``Code of practice: a standard for information security management'', in Yngstrom, L. and Carlsen, J. (Eds), Information Security in Research and Business, Proceedings of the IFIP TC11 13th International Conference on Information Security, IFIP Sec.'97, Copenhagen, Denmark, 14-16 May, Chapman & Hall, London, pp. 78-90. Standards Australia/Standards New Zealand (1996) Australian/New Zealand Standard: Information Security Management, AS4444.

[ 39 ]