A model for deriving information security control attribute profiles Abstract How does an organization ensure that all information security loopholes are covered? This paper describes a possible solution in terms of an Information Security Control Attribute Profile for an organization. This profile will dictate attributes that should accompany each and every information security control in an organization, thus minimizing the likelihood of malfunctioning controls. It is up to the organization to investigate the best way of implementing information security for itself. This is usually done by the implementation of information security controls in the organization. The paper does not suggest which controls to implement, as the literature provides standardized methods for choosing from lists of controls. Rather, the paper suggests which attributes should support every control in an organization. The organization will be able to derive a set of attributes that should accompany every information security control. The process that should be followed, in order to derive the optimal set of control attributes, is described in a model and presented in this paper. The derived set of control attributes will be called the Information Security Control Attribute Profile for the organization.
It is common practice to implement security controls to provide the required level of protection in an organization. In this process, security risks are reduced to acceptable levels. Additional requirements, for example, legal, regulatory, contractual, etc. requirements are also addressed in this process. The selection process of the most appropriate security controls falls outside the scope of this paper, as it is a well documented process. The objective of this paper is to use the character of the organization to play a role in the identification of the most appropriate security controls by identifying security attributes that should accompany every selected control to ensure their effective, continuous functioning.
Helen van der Haara and Rossouw von Solmsb aFaculty of Computer
Studies, Private Bag X6011, Port Elizabeth, 6000; tel: +2741 5043279; email:
[email protected] bFaculty of Computer
Studies, Private Bag X6011, Port Elizabeth, 6000; tel: +2741 5043603; email:
[email protected]
To address the mentioned objectives, the paper will first discuss the necessity for effective information security controls and then introduce the concept of a model. This will be followed by a brief description of three basic elements that are used in the model, in order to provide for the effectiveness of information security controls. These three basic elements are found in the properties of organizations, the information security goals and levels, and the attributes that can support a security. Finally the Information Security Control Attribute Profile (ISCAP) Model will be presented in detail.
1. Introduction
2. Effective information security controls
It is becoming increasingly difficult for organizations to maintain a satisfactory level of information security (von Solms, 1997). This paper suggests an alternative approach to managing information security in an organization, based on two factors, namely, the diversity of organizations and the environment that renders a security control effective.
The effectiveness of information security controls may be accomplished by associating every control with a predetermined set of attributes. This set of attributes shall be called the ISCAP for the organization and may be unique for every organization, or may be similar to the suggested ISCAP for other organizations that have similar properties. Any individual
Computers & Security Vol 22, No 3, pp 233-244, 2003 Copyright ©2003 Elsevier Ltd Printed in Great Britain All rights reserved 0167-4048/03
233
Helen van der Haar and Rossouw von Solms Deriving Information Security Control Attribute Profiles
Table 1: Some attribute examples that may be applied to a password control.
Control Attribute
Example of the use of the Control Attribute to support the Password Control
Strength
Various strengths of passwords are available. A password may be forced to include at least a certain given number of characters, and/or digits, in which case it may be a stronger password and less easy to guess, than a 3-digit password The password should be implemented correctly in the application i.e. not able to be seen anywhere in the application code or in any database and perhaps should be encrypted. It should not be reflected on the screen when typing it. The code that is written to cater for the password should be verified as being without error, and should have been tested to ensure that it was coded correctly according to good software engineering practice The password should be entered only while there are no other persons standing around the computer screen. Once the password has been entered, the computer may not be left unattended while within the sensitive stages of the application. There should be only a limited group of persons who may have knowledge of the password. The password should be changed regularly. The password should never be written down. There are limitations as to which personnel are assigned clearance to use the password and therefore they will be the only persons to have access to the password and permission to use it. Criteria may be used to decide when the password should 'expire' and require changing - very much like a 'sell-by' date on a tub of yoghurt.
Correct Installation
Rules and Procedures
Clearance Acceptance Criteria
Helen van de Haar Helen van de Haar has been involved in electronic data processing and information technology for more than thirty years. She is a senior lecturer at the Port Elizabeth Technikon in South Africa. Her interests are in the fields of operating systems, information security and software development. Professor Rossouw von Solms Professor Rossouw von Solms is the Head of Department of Information Technology at Port Elizabeth Technikon, in South Africa. He has been a member of the IFIP TC 11 committee since 1996. He has published many papers and presentations in the field of Information Security Management.
234
control in the organization is deemed ‘correct’ as long as each of the suggested attributes listed in the ISCAP are implemented and in operation for that control. Furthermore, any individual control is ‘effective’ as long as each of the suggested attributes are maintained and adhered to. The model that is presented in this paper emphasizes the derivation of the suggested attributes for an organization. Once the required ISCAP has been established through utilizing an implementation of the suggested model, the selected attributes can be listed for the organization. An example ISCAP may be that it comprises Strength, Correct Installation, Rules and Procedures, Clearance and Acceptance Criteria. Each control in the organization should therefore have these attributes in place. Table 1 shows an example where explanations have been given for a subset of attributes for a specific control in the organization, namely, a password control. These explanations could have been prepared by an information security officer or manager in order to adhere to the ISCAP in the information security policy of the organization. The explanations represent very simple examples and should not be seen to be more than just examples.
Other possible attributes are listed here, but for the sake of brevity, no examples are given: Access Rights, Supervision, Checkups, Separation or segregation e.g. of duties, Timing limits, Needto-know aspects, Environmental issues, Boundaries and Location requirements, Authorization, Recruitment, Discipline procedures, Classification, Owner, Formal Agreements, Co-operation between organizations, Specialists, Monitoring, Approval, Reviews, Responsibilities, Error or Incident Detection, Incident Reporting, Intrusion Testing, Business Continuity, Policy Rules, Education and Awareness, Compliance, Definition, Documentation, Requirements Identification, Assigning of Rights, Transportation, Policies or Business Requirements, Distribution, Operating Procedures, Logging, Quality control, Change monitoring and approval thereof, Acceptance Criteria, Testing, Fallback plans, Contingency plans, Documented activity, Identification, Audit trails, Internal Auditing, Exception Handling, Correct Handling, Correct Maintenance, Offsite Requirements, Recovery Procedures, Fault Correction, Disposal Rules, Correct Installation, Backups and Storage Requirements.
The rest of the paper will describe each of the basic elements used for the ISCAP model. A presentation and explanation of the model will follow.
Helen van der Haar and Rossouw von Solms Deriving Information Analysis of Vulnerabilities Security Control in Internet AttributeFirewalls Profiles
Figure 1: From organizational properties to control attributes for effective controls.
3. The ISCAP Model — the concept The basic concept of the model is that the properties of an organization should determine what its information security goals and levels should be. Following on from this, a particular set of control attributes should accompany every control in the organization in order to satisfy these information security goals and levels. This relationship is depicted in Figure 1, showing how organizational properties necessitate the requirement for information security goals and varying levels. In turn, these are provided for by means of control attributes. The standards for information security were analysed in detail in order to validate the idea and formulate the model. A point may be raised first though, and that is: What is a control in terms of this new model i.e. what controls are being enhanced by attributes? A short explanation is given, using a simple traditional control as taken from the Physical Entry Controls section of the BS7799 standard: “Secure areas should be protected by appropriate entry controls.” This goes on further in BS7799 to state the following: “The following controls should be considered: 1. Visitors to secure areas should be supervised, and their date and time of entry and departure recorded. Visitors should only be
granted access for specific, authorized purposes. 2. All personnel should be required to wear visible identification within the secure area, and encouraged to challenge strangers. 3. Access rights should be revoked immediately for staff who leave employment” (BSI, 1998). As can be seen from these three traditionally defined controls, they are all procedural in nature. For the purpose of the suggested model, this traditional control can be analysed and repositioned into a number of other controls. The suggested model, for example, will typically view these statements as incorporating the following controls: Entrance Control Point, Visitor Control and Staff Control. Examples of control attributes can also be found in this BS7799 extract as listed in Table 2. The author has analysed the BS7799 standard in detail, in order to place the controls and their attributes into the model (BSI, 1998). An analysis exercise was also done on the IT Baseline Protection Manual (ITBPM, 1995). In this way, the whole concept of the model can be verified by analysing and repositioning content from these and other information security standards. However, for the sake of brevity as well as protection of research in progress, no further details will be provided in this paper.
235
Helen van der Haar and Rossouw von Solms Deriving Information Security Control Attribute Profiles
Table 2: Examples of controls and control attributes.
Control
Supporting Attributes
Entrance Point Control
Supervision, Incident Reporting and Recording, Checkups e.g. for Visible Identification, Access Lists Maintenance, Authorization that is required for the Access Lists Maintenance, Access Control Supervision, Checkups e.g. for Visible Identification, Authorization that is required to control where the visitors may access Checkups for Visible Identification e.g. made both to staff and from staff to Visitors, Access Lists Maintenance, Authorization that is required for the Access Lists Maintenance e.g. when staff leave the service
Visitor Control Staff Control
The three basic elements of the model will now be discussed in the next section. They are: • organizational properties • information security goals and levels • control attributes
4. Basic elements for the model This section describes the three basic elements of the suggested model, and how they were identified through a thorough literature study of various international standards for information security. For the purposes of this model, firstly the properties of an organization will be discussed, then the information security goals of an organization, and finally the information security control attributes for an organization.
4.1 The properties of an organization This subsection describes the use of organizational properties. All organizations vary and may be characterized according to the sizes, types of business, cultures, etc. These and other properties should be taken into account when providing for information security needs. Organizations do not always know what their information security needs are, but every organization can be described through its unique set of properties. For the purposes of clarity, a list of organizational properties is given in Figure 2a and b together with some simple examples of sub-properties for each of them, but for reasons of brevity, no details are given.
236
Once the properties of an organization are known, it follows that the organization has then been ‘described’. Once an organization is described in terms of these properties one can uncover the information security needs. Information security needs are basically to counteract the risks to an organization. Such risks can be determined by means of risk analysis and in fact many such analyses have already been done for various organizations. It seems appropriate then, to refer to these analyses that have already been performed on other similar organizations. The model proposed in this paper, therefore, is based on the premise that similar organizations will be exposed to similar risks and therefore have similar information security needs, as long as the properties have been applied correctly. These properties include, for example, information security objectives, strategies and policies. Organizations differ with respect to these and should therefore be treated differently regarding information security. One organization may have a strategy of supplying its employees with mobile computers, therefore requiring particular attention being paid to the transportation of information, as well as the medium of transportation. Another organization may have a strategy where no information ever leaves the organizational site, neither being carried out, nor by means of any communication medium such as the Internet. The difference between organizations is also
Helen van der Haar and Rossouw von Solms Deriving Information Analysis of Vulnerabilities Security Control in Internet AttributeFirewalls Profiles
Figure 2: (a and b) Organizational Properties and Sub-Properties.
evident in the issue of responsibility for or ownership of the organization (ISO/IEC TR 13335-1, 1996). An organization that is owned
by a country’s defence force may require extreme attention being paid to privacy and confidentiality.
237
Helen van der Haar and Rossouw von Solms Deriving Information Security Control Attribute Profiles
There are also differences in the degree to which organizations depend on their systems. Perhaps the survival of the business may be affected if the dependence is very high. An organization may also have a business value such as the level of investment made into its systems. In the event of loss of business, the dependence on these systems may be seen in terms of the monetary loss. These economic or financial properties of an organization should be taken into account when selecting the appropriate information security strategy (ISO/IEC TR 13335-2, 1997). These were just a few examples of organizational properties that are of importance. For each of them, one can define sub-properties as well. For example, the dependence of the organization on the information technology systems can vary. Each possible level of dependence is a different sub-property. Perhaps the dependence can be viewed as low, medium or high. An alternative may be to view dependence as (i) ‘totally not dependent’ or ‘independent’, (ii) ‘somewhat dependent’ or (iii) ‘totally dependent’. These properties and sub-properties clearly demonstrate that organizations differ and therefore need different approaches towards information security. Following that each organization has a distinctive set of properties comprising many sub-properties, the next section will define information security goals and levels.
4.2 The information security goals and levels The properties and sub-properties of organizations can be used to describe the organization. This results in different security goals in organizations, or at least, different levels of attention being paid to security goals in organizations. These security goals and levels have been identified from the literature as is shown in this subsection.
238
Some of the security goals have been obtained from the traditional approach to information security services. This refers to the intention of information security to deal with issues relating to the definition, achievement and maintenance of services such as confidentiality, integrity, availability, accountability, authenticity and reliability. All objectives, strategies and policies for an organization would therefore have addressed these services (ISO/IEC TR 13335-1, 1996). For the purposes of clarity, some security services are listed here as analysed from the literature, but for reasons of brevity, no detail is given: Management direction and support, Information Security Infrastructure, Maintenance and Protection of Assets, Reduction of Human Error, Prevention of Unauthorized Access or Damage, Security of Networks, Minimizing Risk of System Failure, Safeguard Data Integrity, Maintenance of Integrity and Availability, Prevention of Damage to Assets, Prevention of Interruption of Business Activity, Protection of Documentation from Bad Usage, Prevention of Loss or Modification of Data, Security in IT Systems, Prevention of Loss of Data in Systems, Preparation for Interruption to Business Activities, Avoidance of Security Contract Breaches.
These services are called information security goals for the purpose of the model, and each goal may be on any one of a number of levels. Organizations differ in the way they view these services. Some may view confidentiality as being at a level of low importance, while others may regard confidentiality as an extremely high priority and therefore at a high level of importance. Besides the traditional services already mentioned in this section, other information security goals have been found in literature and in the various international standards for information security. The Common Criteria are information security standards that provide for the fulfillment of information security requirements for information technology products and systems. A subsequent information
Helen van der Haar and Rossouw von Solms Deriving Information Analysis of Vulnerabilities Security Control in Internet AttributeFirewalls Profiles
Figure 3: (a) Before ISCAP: General IS Issues and (b) After ISCAP: Security Control Attributes.
security evaluation can result in applied assurance measures. This assurance can be given on any one of a number of levels. For the purpose of the model, therefore, assurance is an information security goal and there are various levels of assurance as well. The Common Criteria evaluation provides for confidence in a product or system, namely, confidence that the information security functions of the product or system, and the assurance measures applied to them, meet the information security requirements (CCITT, 1998). More information security goals and levels can be found in other International Standards Organization (ISO) standards. Products should be developed in a quality conscious environment, thereby ensuring reliability, predictability and safe operation. These may be information security goals for the organization. To gain quality assurance, it may also be necessary for auditing (Knight, 1995). Again, these were simply a few examples of information security goals. Each goal may be on one of a number of levels. These security goals and levels differ among organizations and therefore require different attention being paid to information security.
4.3 The control attributes This subsection explains the necessity for control attributes to accompany each control. The control attributes are all identified in literature but not yet linked directly to controls.
Rather the researched literature seems to leave them as general requirements made at a higher level. In this paper they will be brought down to a technical level closer to the control. Figure 3(a) and (b) shows how these attributes are moved closer to the control and actually become part of the control. For example, a contingency plan for the organization is usually a general statement in an Information Security Policy document. The planning for contingency in the organization will be more complete and therefore effective, if there was contingency planning for each and every information security control. This ‘Contingency planning’ would then have been listed as one of the control attributes in the ISCAP. All the organization’s controls can operate more effectively if they have been attended to in terms of the appropriate attributes, where these attributes have been listed in the ISCAP of the organization. There are many possible attributes from which the subset of appropriate attributes for an organization may be chosen. Some identified attributes will be motivated in the following paragraphs. Information Security Management should provide for protection of assets by means of rules, directives and practice within an organization. The controls in the organization can therefore be governed by these rules. Other requirements are to monitor the implementation
239
Helen van der Haar and Rossouw von Solms Deriving Information Security Control Attribute Profiles
and operation of the controls. Employees should be security aware, and should detect and react to incidents around the controls. The detection of an event around a control can be done manually or can be triggered, depending on the importance of the control. Logs and records could be kept and analyses done on these logs. Compliance checking and auditing functions can complement these processes. It is also important to have a responsible person designated for each control, to ensure that information security management for that control is ongoing. There should be disaster recovery and contingency plans for a control. Furthermore, there may be a need for change management and configuration management to be taken care of (ISO/IEC TR 13335-1, 1996). All of these important requirements can be identified as control attributes. There is also an international trend in organizations, to shift towards the ideal software development environment. If products are built in a systematic, knowledgeable and controlled fashion, then one could provide for user/customer assurance on quality throughout the process. One can extend this assurance to the controls by addressing testing of processes, the installation of acceptance and rejection criteria for controls, the reporting of failed controls, and the indicated corrective action to be taken. Auditing and assessment by other parties, such as clients and independent external bodies, place additional conforming requirements on the controls. To ensure compliance, reviews can be done. The use of the control can be halted if deficiencies are found. In the meantime, the contingency plan for that control would be made operational. Eventually the control’s return to use can be authorized (Knight, 1995). Quality records should be kept for controls and should demonstrate the achievement of quality. Various metrics can be used to measure quality (Knight, 1995). All of these attributes
240
mentioned here can provide well for the efficiency of controls. The BS7799 (von Solms, 1999) is another standard from where many control attributes may be obtained for the purposes of the model. Most of these control attributes have already been mentioned. According to BS7799, the following are also important: • Employees should undergo appropriate training. • Only approved controls or device types should be used, therefore there should be some sort of technical authorization. • Correct implementation is important. • There may be other legal restrictions concerning the control. • Documented procedures are responsible for error handling. • There should be formal policy to protect against risks when transporting assets or controls (BSI, 1998). • The original BS7799 has been amended, and more emphasis has been placed on the management of information security. • Procedures play a more important role (Humphreys, 1999). Other standards were also examined for control attributes. The Trusted Computer Security Evaluation Criteria (TCSEC), published in 1983 in the USA, assure that a product meets predefined security evaluation criteria. This implies that an evaluation certificate is attached to the product (von Solms, 1999). One can apply this to a control, by checking it for strength, correctness, and implementing rules and/or procedures governing installation or other aspects of the control. In 1990, the Information Technology Security Evaluation Criteria (ITSEC) were published by the European Commission. Here, the
Helen van der Haar and Rossouw von Solms Deriving Information Analysis of Vulnerabilities Security Control in Internet AttributeFirewalls Profiles
Figure 4: The Organizational Information Security Control Attribute Profile (ISCAP) Model.
information security features, or functionality of a control can be evaluated, as well as assurance of correctness (thoroughness of evaluation) and assurance of effectiveness (whether the information security mechanisms are appropriate) (von Solms, 1999).
the product, are listed in the Common Criteria mechanisms. The standard also provides for the listing of evidence to describe the completeness and cohesiveness of any product that is built according to the Common Criteria (Troy, 1999).
The Common Criteria standard can be used for evaluation of the information security properties in Information Technology (IT) products and systems. The Common Criteria provide mechanisms with which one can define information security requirements and functions. Subsequently, information security evaluation can take place, resulting in applied assurance measures to the IT product or system (CCITT, 1998). There are descriptions of the information security attributes of the environment in which the product is intended to be used, and how it should be deployed. Furthermore, organizational information security policies or rules to be complied with by
Following an examination of literature on the various information security standards, it becomes clear that there are many attributes that can contribute towards the effectiveness of controls. This section has listed a number of these control attributes. All the basic elements of the model have now been discussed, namely the organizational properties, the security goals and the control attributes. The next section takes these elements and explains briefly the workings of the Information Security Control Attribute Profile (ISCAP) Model for the organization.
241
Helen van der Haar and Rossouw von Solms Deriving Information Security Control Attribute Profiles
5. The ISCAP Model – the detail The ISCAP model depicted in Figure 4 comprises various parts which are described in the following paragraphs. Parts A, B and C form the boundaries of the model. Part A, the ‘Standards’ represent the static input to the model. Part B, the ‘Reality’ represents the variable input to the model. Part C, the ‘Required ISCAP’, represents the output of the model, having been obtained by applying some processing to the inputs. The ‘Standards’ (Part A) depict the International Standards Organization (ISO) standards that are applicable to Information Security. By using these standards as the primary source of information, it was possible to further motivate some extraction from the standards in order to derive the basic elements of the model. The Standards are placed outside the rectangular boundary of the model because they do not form part of the model, but rather serve as a source of information and subsequent inspiration for the model. The ‘Reality’ (Part B) represents a description of any real organization, that has its own strategies, problems and policies and therefore its own individuality and reasons for requiring information security management. The organization may apply its Reality to the model in order to find out what its ‘Required ISCAP’ should be. The Reality is also placed outside the rectangular boundary of the model because it serves as the variable input to the model process. The ‘Required ISCAP’ (Part C) is the final output of the model. Whereas the standards for information security were the primary source of static information, and the individual organization’s reality was the variable input, the subsequent Required ISCAP is the output derived from the model process. The Required ISCAP is placed outside the rectangular
242
boundary of the model because it serves as the final output from the model and it represents the set of control attributes fine-tuned for the organization. The various steps in the model process will be explained further. The set of ‘organizational properties’ (Part D) is the first basic element. Some of these properties have been listed in Section 4.1. The ‘information security goals and levels’ (Part E) form the second basic element and has been described in more detail in Section 4.2. The ‘control attributes’ (Part F) form the third basic element, having been described in Section 4.3. Part G depicts the joining of all possible organizational properties from Part D, and all possible information security goals with various levels from Part E. Part G depicts the relationship between organizational properties and information security goals and levels. As displayed in Figure 1, organizational properties necessitate the requirements for information security goals and levels. An example of the association follows: an organization should decide how much it depends on the system. This means how much the survival of the organization or business is effected, and in fact, the effect on the confidentiality and other information security goals (ISO/IEC TR 133352, 1997). The dependence may be one of the organizational properties, and the effect that the dependence has on the information security goal of confidentiality necessitates a certain amount of protection, and therefore a certain level of confidentiality. Part H depicts the joining of all possible information security goals and levels from Part E, and the set of all control attributes from Part F. As displayed in Figure 1, information security goals are provided for by means of control attributes. If the information security goal of high confidentiality is considered to be crucial to the organizational operation then those attributes that can provide high confidentiality should be part of the ISCAP for that
Helen van der Haar and Rossouw von Solms Deriving Information Analysis of Vulnerabilities Security Control in Internet AttributeFirewalls Profiles
organization. A refinement of this is also possible: if the confidentiality is rated low as an information security goal due to the organizational properties, then the more stringent attributes providing medium confidentiality or high confidentiality may not be necessary and will not appear in the ISCAP for the organization. Part I is the most important process. It takes a particular organization’s properties from Part B and, using Part G and Part H for reference, arrives at the ISCAP indicated in Part C. Questions and concerns that may arise at this stage and that should be motivated and defined in detail are the following: • The properties and sub-properties (Part D) • The security goals and levels (Part E) • The control attributes (Part F) form the complete list of attributes that could be chosen to surround any control. In fact if all these attributes were implemented for an individual control, then the control would be providing very good protection. However, any organization may only require a subset of these attributes, hence the model. • The linking (Part G) of properties and subproperties to security goals and levels. For example, the property of dependence (as well as its degree or subproperty) necessitates particular security goals each on a particular level. It is necessary to motivate every possible link and subsequently produce a static table. The ISO standards are used to motivate the entries in this table. • The linking of Part E to control attributes should also be motivated in detail. Again the ISO standards will be used to provide motivation for the development of this table. According to analysis of the BS7799 standard, if the security goal in question is
to ‘minimize the risk of system failure’, then it is required to include the following attributes for all controls: Monitoring, Approval, Incident Recording and Reporting, Education and Awareness, Recording and Approval of Changes, Monitoring of Changes, Acceptance Criteria, Testing, Fallback Plans, Contingency Plans, Fault Correction, Recovery Procedures and Correct Installation (BSI, 1998). By analysis of the IT Baseline Reference Manual, the required attributes could be Incident Recording and Reporting, Education and Awareness and Access Restrictions (ITBPM, 1995). If the security goal is on a particular level such as Low rather than High, then only certain of these control attributes may be necessary. • The final process that uses individual organizational issues to derive appropriate control attributes may be a simple tablelookup procedure. • The variable input, Part B, depicts an individual organization, but may be altered to represent a subdivision of an organization or even just one information system. All of these issues fall outside the focus of this paper and are currently being addressed in further research work.
6. Conclusions It is possible for an organization to be confident that, at a lower level, the information security controls are in place and are functioning efficiently. One way to do this will be to accompany each control with a set of control attributes that have been derived due to the particular needs of the organization. It can then be assumed that the organization has achieved its information security goals. This paper has reported on how it is possible to dictate these control attributes for an organization. The ISCAP model was presented
243
Helen van der Haar and Rossouw von Solms Deriving Information Security Control Attribute Profiles
for this purpose. The ISCAP model can be used to aid the management of information security. In order to derive this ISCAP for the organization, some basic elements were derived from the literature. These are the properties and sub-properties of an organization, the security goals and levels thereof, and the full set of control attributes. These formed the static input to the model process. They were joined appropriately, providing more static tables of information. Subsequently, the model process took an individual organization’s reality situation and by means of a simple table-lookup procedure, derived the set of appropriate control attributes for the organization. To provide for Information Security, the organization would have to implement these attributes for all the organization’s controls. There are alternate ways to provide for Information Security. Risk Analysis is one way to address Information Security issues, but it has been described as a bottom-up approach and as being somewhat subjective. It has further been suggested that, in determining the security controls needed, the security requirements of the organization need to be established i.e. the ‘amount’ of security that the organization needs (Gerber, 2001). The Baseline approach has also been used but to a large extent they leave the choosing of controls to the user and no real guidance is provided as to which controls to choose. This paper supports the idea that one should derive controls with built-in intelligence, thereby providing for the most effective set of controls. The top-down model suggested in this paper makes it easier for an organization to identify its own security needs because it takes into account the type of organization (properties), how much protection
244
it requires (security goals) and subsequently leads on to the derived control attributes that should help provide that protection. Information Security Management is an important concern for any organization. Because every organization may have unique properties, it is important that the correct application of controls is in place. Having a dictated set of attributes to surround each control will go a long way towards securing the organization appropriately, especially if these attributes have been derived according to the specific organization’s requirements.
References •
BSI, 1998. Draft for Public Comment Document 98/682025 Revision of BS7799 Part I Information Security Management, Project No 98 958 Committee Ref B DD/2.
•
CCITT, 1998. Common Criteria for Information Technology Security Evaluation. Part 1: Introduction and General Model, Version 2.0 CCIB-98-026.
•
Gerber, M. and Von Solms, R., 2001. From Risk Analysis to Security Requirements. Computers & Security, Vol. 20, No 7, 2001, pp. 577-584.
•
Humphreys, T., 1999. The New BS7799, XiSEC Consultants Ltd.
•
ITBPM, 1995. IT Baseline Protection Manual, BSI 7152 E, BSI.
•
Knight, J., 1995. Software Quality and ISO9000: Concepts, Software Engineering Applications Laboratory, Document Number: SCP103N06.
•
TECHNICAL REPORT. REF NO. ISO/IEC TR 13335-1: 1996, 1996, Part 1: Concepts and Models for Information Technology Security, ISO/IEC.
•
TECHNICAL REPORT. REF NO. ISO/IEC TR 13335-2: 1997, 15 December 1997, Part 2: Managing and Planning IT Security, ISO/IEC.
•
Troy, E.F., 1999. Common Criteria: Launching the International Standard, http://csrc.nist.gov/cc/info/cc_bulletin.htm, 13 May 1999, pp. 1-10.
•
Von Solms, R., 1997. Can security baselines replace risk analysis, IFIP TC11 13th International Conference on Information Security (SEC’97), Copenhagen, Denmark, Information Security in Research and Business, Edited by Louise Yngström and Jan Carlsen, pp. 91-98.
•
Von Solms, R., 1999. Information security management: why standards are important. Information Management and Computer Security, Vol.7, 1999, pp. 50-57.