Engineering secure systems with ISO 26702 and 27001

P12‐4 1 Engineering Secure Systems with ISO 26702 and 27001 Rhys Evans1, Aggeliki Tsohou2, Theo Tryfonas1 and Thea Morgan1 1 Systems Centre, University of Bristol, UK Laboratory of Information & Communication Systems Security, University of Aegean, Greece 2 System engineers are confronted with fast-paced technology developments, complicated contractual relationships, emerging threats and global security requirements, concerns for sustainability and viability of their ventures and a raft of other issues. In this environment, information technology-intensive systems in particular are exposed to risk and recent high-profile incidents have contributed to significant emphasis to be given to security. It is however impossible for systems engineers to become specialists in all areas of concern in order to be able to tackle effectively those issues and thus architecting systems needs to take into account good practice and existing relevant knowledge. When such knowledge is embodied into established and widely accepted standards, not only is there the opportunity to capitalise on their mature content but also to ripe the benefits of compliance, seamless integration and competitive advantage that standardisation provides. In this spirit we investigate in this paper the use of two popular and established standards, the ISO 27000 series and ISO/IEC 26702, as aids in the process of engineering secure systems. Index Terms—security engineering, standards. I. T INTRODUCTION ODAY’S complex systems of any kind, be they intelligent buildings, information systems, or other, rely increasingly on interdisciplinary collaborative development approaches and for this reason Systems Engineering (SE) has become of great importance in recent years. The definition of SE is described by IEEE as [1]: An interdisciplinary collaborative approach to derive, evolve, and verify a lifecycle balanced system solution which satisfies customer expectations and meets public acceptability. Where a system is defined as [1]: An assemblage of objects united by some form of regular integration or interdependence. Complexity increases dependency on systems, from banking, to crime fighting, and retention of medical records. And as such, their trouble-free and uncompromised operation is critical for the success of their mission. Security in this context refers to the protection from exposure to unauthorised access, use or other exploitation of the system or any of its elements. Although International Standards exists for both the application of Systems Engineering (ISO 26702) and for the development of dependable, secure information systems (ISO 27001) there is no formal integrated approach based on the two. This paper will look at developing a framework for Secure Systems Engineering via process integration of aspects of both ISO 26702 and 27001. It will look at designing an Information Security Management System before beginning a System Engineering project, and how the stages of the System Engineering Process can be enhanced by following simple security processes laid out in ISO 27001. The paper then is structured as follows: Section 2 provides a brief overview of secure systems and their development, section 3 outlines ISO 26702 and 27001, Section 4 suggests a method for process integration of the two standards, and finally Section 5 concludes the paper. II. OVERVIEW OF SECURE SYSTEMS IMPLEMENTATION APPROACHES: DEVELOPMENT & MANAGEMENT Insofar three main streams of security practices have appeared over the years and they reflect largely on developments in the related security research [2]. To begin with, the first explicit concerns in regard to systems security appear around 1960. The practices in question capitalised on previously accumulated knowledge and thus were empirical and heuristic, such as extensive security checklists or countermeasure catalogues. In order to develop the system’s security the security professional was called to choose practices that were most suitable for the system of concern. There are specific advantages in similar approaches in the sense that they may be employed by less experienced organisations as they embody existing knowledge and offer solutions to pre-specified problems. They can also form the basis for the development of good practices (e.g. BSI baseline handbook [3]) or standards, as in the case of the British Standard 7799 (2000) that emerged through codes of good practice. On the other hand, they tend to be abstract and generic and require further elaboration effort in order to become tailored to specific organisational needs. The second stream of security practices originated from research that flourished in the field around 1980. Then, the concepts of security risk, threat and vulnerability were formally introduced in the literature and were embodied in methods and techniques. This enabled the development of system modelling-based approaches and tools such as the CCTA Risk Analysis and Management Method [4]. The security practitioner could now model the system in question and tailor the security analysis to the organisation’s particular needs. Whatever the differences between the various methods, risk analysis and management is separated in two stages, where each stage is divided into steps. In the analytical stage the analyst develops an understanding of the system and its functionality, evaluates its components and assesses its P12‐4 exposure to various risks. The management stage is introduced by selecting appropriate countermeasures to deal with the risk exposure. This approach is usually performed on an existing IS, and is not easily integrated into the systems development. That is because at the development stages a system’s model is altering from stage to stage and consequently, this approach is more applicable to an already developed information system. Risk analysis and management are techniques that require expert skills in evaluating the information related risk and implementing countermeasures on a cost/benefit basis. As further criticism, IS risk analysis and management are not regarded as scientific methods, because of their lack of feedback concerning the specification, design and countermeasure implementation [5]. Yet they are of the most popular approaches that practice has embraced. Both previous streams of practices are characterised by the fact that they are usually applied after the system’s development. Such a post-applied practices could expose the system to risk until the security is implemented and also they are usually applicable to a system’s ‘frozen’ instance in time, meaning that significant rework needs to be performed every time that changes are implemented into the system. Irvine et al. [6], separate the risks of IS in development and functionality risks. The development risks are separated in sublime errors that can be handled with quality assurance and malicious development that can be handled with configuration management. However, this is not a simple task because of the limited time to perform it and also due to the associated cost. For this reason audits are conducted over representative areas and are targeted and selective. It is now well over a decade ago since Wood noted a trend for integrating baseline security features into commercial products [7]. In such a way the responsibility for the provision of security is transferred to the manufacturer/service supplier. Consequently the organisation is responsible of ensuring that the product is deployed properly and the users are trained for its use. However, the majority of existing development methodologies does not appear to embed particular security provisions for the system under development. Popular methodologies such as MERISE, DSDM and the Information Engineering refer partially, if at all to how the developer will integrate security features along with the desired functionality. That is why approaches of the third and most recent research stream, try to incorporate security requirements within the development process of information systems. In such a way, security is introduced early into the system, making it easier to tackle potential future changes. In this stream of research, studies are concerned about how the use of techniques and tools could help in the merging of the security requirements with the specifications of the IS. Siponen [8] identifies a duality in these techniques in terms of their focus to either the modelling techniques (the majority of proposals) or the development process. From a modelling point of view, Baskerville [9] proposed the use of popular diagramming techniques such as Data Flow Diagrams and Entity-Relationships Models for the specification of security 2 requirements. Other researchers provide modelling extensions of widely used modelling languages such as the Unified Modelling Language (UML), in order to accommodate the security requirements [10]. From a process point of view, Downs et al. [11] present in their book an interface between CRAMM and SSADM. More recently, Warren and Batten [12] introduced a complementary method to be used alongside ETHICS (SIM-ETHICS) and Evertsson et al. [13] proposed a framework for integration of security to the systems development process. There also exist alternative approaches such as the Virtual Methodology (VM) developed by Hitchings [14], that largely utilises managerial and problem solving techniques such as the Soft Systems Methodology [15] for the construction of system models and the assessment of the risk exposure. In this stream we can also categorise the Security By Analysis [16] methodology, developed in Sweden where the socio-technical system design is popular. It is based on a process of engagement of the key system stakeholders to analyse and to consent on the issues of asset valuation, risk exposure and security controls selection over a series of frequent meetings. Information security management refers to the structured process for the implementation and ongoing management of information security in an organization [17], where risk assessment is a core element. Risk assessment is the process that includes risk analysis, thus identifying risks and describing them in quantitative or qualitative terms, and risk evaluation, thus prioritizing risk against risk evaluation criteria and objectives. In more detail, the objective of risk assessment is to determine the value of information assets, identify the applicable threats and vulnerabilities and determine potential consequences. Finally, risk assessment aims at prioritizing the derived risks and ranking them against the risk evaluation criteria. Following risk assessment, risk treatment takes place in order to determine and implement controls to reduce, retain, avoid or transfer the risks. Finally, risk acceptance tasks are conducted to ensure that residual risks are explicitly accepted by the managers of the organization, and risk communication activities are implemented so as information about risk to be exchanged between the decision-makers and the other stakeholders. III. SYSTEMS STANDARDS FOR ARCHITECTURE AND SECURITY Standardization is the process of developing and agreeing upon technical standards. A standard is a document that establishes uniform engineering or technical specifications, criteria, methods, processes, or practices. The benefits of standardisation are reflected to a) enterprises by providing competitive advantage and facilitating trade, b) consumers by enjoying products and services with specific quality characteristics, and c) governments by technology diffusion. In the area of information systems, the advantages of standardization are two-folded: first, standards establish a consensus on terminology and thus make technology transfer easier and safer, and second, they support the common P12‐4 understanding and agreement of functional and non-functional requirements, thus facilitating the design of systems that ensure the compatibility of equipment of diverse origins and strengthen interoperability. In the information systems security area, more specifically, standards support the common understanding of security requirements and ensure that the security mechanisms implemented do comply with globally accepted rules and practices. In this way the systems that are being implemented reach a commonly accepted security level and interoperate with other systems in an efficient and secure way (International Organization for Standardization - ISO). Therefore, the basic purpose of the information security standardization is to create a common security model in order to enable companies to carry out their business and cooperate globally [18]. A. ISO/IEC 26702 (IEEE 1220) The international standard ISO/IEC 26702 Application and Management of the Systems Engineering Process defines the interdisciplinary tasks that are required throughout a system’s life cycle to transform stakeholder needs, requirements, and constraints into a system solution [19]. ISO/IEC 26702 is aimed at development of commercial product-oriented systems, such as aeroplanes and information systems, and is currently utilised globally by industry, government, and academia [20]. The standard consists of 6 clauses. 1. Scope, purpose, and organization 2. References 3. Terms and acronyms 4. General requirements 5. Life-cycle stages 6. Systems engineering process (SEP) The SEP (shown in figure 1), consists of eight subprocesses; requirements analysis, requirements validation, functional analysis, functional verification, synthesis, design verification, systems analysis, and control. Requirements Analysis - Stakeholder input is used to establish the required system capability through performance criteria, operational environments, system interfaces and constraints. Trade-off and risk analyses are conducted to identify and resolve any conflicts. The output is a requirements baseline that contains an operational view, a functional view, and a design view of the system. Requirements Validation – The requirements baseline is evaluated against the stakeholder expectations and system constraints. If the baseline fails to address the criteria then both Analysis and Validation must be repeated iteratively. Functional Analysis - The requirements defined during Analysis are translated into a collection of design elements. The output is a functional architecture for the system. Functional Verification – The functional architecture is evaluated against the original requirements baseline to ensure that it is complete. Synthesis – The verified functional architecture is translated into several possible design solutions. The optimal solution is 3 selected using criteria relating to budget, schedule, performance, and risk. Design Verification - The design solution architecture is evaluated against the requirements baseline and functional architecture to ensure alignment. Systems Analysis – A set of techniques to assist with the three analysis stages, Requirement, Functional, and Synthesis. These techniques can include conflict resolution, system effectiveness assessments, and risk management. Control – Tasks are carried out to manage and document SEP activities and results, this information is used to monitor progress of the project. ISO/IEC 26702, initially released as the trial issue standard IEEE 1220 in 1995 and as a full standard in 1998, has remained largely unchanged since. A 2007 revision aligned application of IEEE 1220 practices and processes with the Fig. 1. The Systems Engineering Process [19]. overarching system life-cycle processes described in the standard ISO/IEC 15288 Systems Engineering, System Life Cycle Processes. Combined, these two standards provide complete technical, management and support process practices for product system solutions. Both standards are compatible for use with software standards such as ISO/IEC 12207 or the IEEE/EIA 12207 series, as well as the ISO 9000 family [21]. A similar standard is ANSI/EIA 632 Processes for engineering a system, which is far broader in scope than ISO/IEC 26702 (though both EIA 632 and IEEE 1220 evolved out of the US military standard MIL-STD-499B). The processes it outlines are considered a subset of ISO/IEC 15288. ISO/IEC 26702 includes an enterprise focus that is lacking in other systems engineering standards. Historically ISO/IEC 26702 (or its predecessors) has been used mainly on large space and military acquisition projects in the US. Altomare [22] concludes that in general “the [systems engineering] process is now being adopted by some nondefence industries but it has not been generally recognized as a useful management tool for all types of projects, large or small, defence or non-defence. This may be due to its association with large complex Department of Defence or aerospace engineering projects, or difficulties encountered in P12‐4 attempting to apply the concepts.”. However, according to Sheard [20], the key systems engineering standards, including ISO/IEC 26702, have begun to move away from “a federal government contract-centric approach to a commercial, voluntary compliance approach. The focus has changed from management to process orientation”. The hope is that the most recent revision (2007) will encourage use of the standard in more commercial settings and in a wider range of organisation types, both in the US and globally. A number of capability assessment tools (e.g. SECM, EIA/IS 731, CMMI) can be used in conjunction with ISO/IEC 26702. In this way an organisation can monitor and improve its systems engineering efforts against pre-defined levels. These levels, once obtained, can be used to demonstrate competence to clients or stakeholders and to differentiate an organisation from its competitors. Through these tools ISO/IEC 26702 can add value to any organisation in the business of developing complex systems. B. ISO/IEC 27000 series (BS7799) ISO/IEC 27000 series is a family of standards published by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). The series includes standards that provide best practice recommendations on information security management, risks and controls. The provided guidelines are based on an Information Security Management System (ISMS) and a process-oriented approach structured in a circular model (Plan-Do-Check-Act, fig. 2) for security management. The purpose of such an ISMS is to ensure the selection of adequate and proportionate security controls that protect information assets and give confidence to interested parties. The proposed practices apply to all kinds of organizations irrespectively of size or type (commercial, governmental etc.). ISO/IEC 27000 series, at the moment, comprise from seven standards (Table 1); while two more standards are under development. Furthermore, guidelines regarding ISMSs in specific sectors are published; i.e. ISO/IEC 27011 for telecommunication organization. The advantages of security standardization are nowadays recognized by organizations, as it is depicted by the growing acceptance and adoption of security standards. Organizations in the United Kingdom (UK) are increasingly utilising the ISO Fig. 2. PDCA Model applied to ISMS Processes/ 27000 family standards for developing their security activities [23]. The most popular standards of the 27001 [24] family, 4 however, are ISO/IEC 27001 and ISO/IEC 27002; for both standards an increasing adoption is revealed from surveys [23] [25], and furthermore, an increase of ISO/IEC 27001:2005 certifications has also be noticed [26]. Briefly, the Plan-Do-Check-Act model’s main elements (ISO/IEC 27001, 2005) include: the Planning phase that TABLE I THE ISO/IEC 27000 SERIES STANDARD ISO/IEC 27000 ISO/IEC 27001 ISO/IEC 27002 ISO/IEC 27003 ISO/IEC 27004 ISO/IEC 27005 ISO/IEC 27006 ISO/IEC 27007 ISO/IEC 27008 FOCUS REGARDING THE ISMS STATUS Overview and vocabulary: Assists organizations of all types to understand the fundamentals, principles and concepts to improve protection of their information assets. Requirements: Specifies the requirements for establishing, implementing, operating, monitoring, reviewing, maintaining and improving a documented ISMS. Code of practice: Provides general guidance on the commonly accepted goals of information security management. Published in 2009 ISMS implementation guidance: Focuses on the critical aspects needed for successful design and implementation of an ISMS. Measurement: Provides guidance on assessment of the effectiveness of an implemented ISMS. Information security risk management: Provides guidelines for information security risk management. Requirements for audit and certification bodies: specifies requirements and provides guidance for bodies providing audit and certification of an ISMS. Auditing: It will provide guidelines for ISMS auditing. Guidance for auditors on ISMS controls. Formerly known as BS7799-part2. Published in 2005 (a revision is planned). Formerly known as ISO 17799 and BS7799-part1. Published in 2005 (a revision is planned). Published in 2010. Published in 2009 Based on BS7799part3. Published in 2008. Published in 2007 Under development. Under development. begins with the definition of the ISMS’ scope, boundaries and of an ISMS policy. Moreover, a systematic approach to information security risk management is determined and actions for obtaining management approval are taken. Finally, a Statement of Applicability is developed. Continuing with the Do phase, the risk treatment plan is implemented and the way that the implemented controls’ effectiveness will be measured is defined. In addition, security awareness and training programs are implemented, and also operating the ISMS activities and prompt detection of security events activities take place. The Check phase aims at continual monitoring and reviewing of risks. To do so, procedures that promptly identify attempted and successful security breaches, incidents, and errors are documented, and also, regular reviews of the ISMS effectiveness are undertaken. Finally, the “Act” phase includes activities to maintain and improve the risk management process, and also, to take the appropriate corrective and P12‐4 5 preventive actions, to communicate the actions and improvements to all interested parties and to ensure that the improvements achieve their intended objectives. IV. INTEGRATING ISO 26702 WITH 27001 IN ARCHITECTING SECURE SYSTEMS Section 3 provided a brief overview of both the Systems Engineering and Information Security Management standards. As mentioned in Section 1 we are looking to develop a more secure approach to Systems Engineering, this section will discuss a possible way of integrating these two standards to create a Secure Systems Engineering standard. The SEP should include the four stages of the ISMS process at different points in its eight sub-processes. An updated SEP diagram is shown in Figure 3, with the new stages shown in bold. The new process begins with the establishment of an Information Security Management System (ISMS), this is steps a-c of 4.2.1 of ISO 27001. This will define the scope of the ISMS and the risk management procedure for the whole SE process. The planning stage of the ISMS continues during the three analysis steps of the SEP, Requirement and Functional Analysis and Synthesis. At each of these stages the risks would need to be identified and evaluated, with options included for mitigating those risks. This would be following steps c-g of 4.2.1 of ISO 27001. Doing this would ensure that the risks associated with every requirement and design element are taken into account before they go through to the implementation stages. During the requirements stage each non-functional requirement should contain, by default, references to security, so looking at how the requirements effects confidentiality, integrity, etc. The systems analysis section is now extended to include the DO stage of the ISMS, that is section 4.2.2 of ISO 27001. This would mean that when assessing the requirements, functional elements and design objects, the risks associated with them are taken into account. A mitigation plan would then be developed to reduce, or avoid, the risks associated with each item. This mitigation plan would then be returned along with the tradeoffs and impacts for the validation stages. During the three Validation and Verification stages the risks outlined in the analysis sections and the mitigation plans developed in the Systems Analysis section must be reviewed (Section 4.2.3 of ISO 27001). Doing this ensures that your risks have been dealt with before you move onto the next section. A method will need to be developed for deciding on the residual risk of each section and when it should be accepted. As the Control stage of the project is already used to collect project data and monitor risks, it seems natural to use this section to perform, in addition to the Monitoring the ISMS, to also Maintain and Improve the ISMS (Sections 4.2.3 and 4.2.4 of ISO 27001). This would then ensure that risks are being handled appropriately and that the ISMS is continually updated and, if need, improved. V. CONCLUSIONS AND FURTHER WORK This paper has outlined the need for a secure approach to Systems Engineering, i.e. why today we expect our systems to be of increasing complexity while still maintaining security. Fig. 3. Extended SEP to include ISMS processes. We have looked at the current standards for both Systems Engineering and developing secure systems. It has shown that neither of these standards is acceptable for Secure Systems Engineering and that we should look to integrate the two standards if we are to make System Engineers more security aware. The integration approach we defined involved adding secure development techniques, taken from ISO 27001, to the Systems Engineering methods, outlined in ISO 26702. This involves extended the SEP to include the stages of the ISMS at various point in its eight sub-process. This ensures that an ISMS is set up before works begins and that risks are evaluated at each analysis stage of the process. These risks are then mitigated and checked before work can progress onto the next stage of the project. The extended SEP is designed so that it ensures regular checking and updating of the initial ISMS. ACKNOWLEDGMENT Rhys Evans and Thea Morgan are Research Engineers supported by EPSRC funding through the Bristol-Bath Industrial Doctorate Centre in Systems. P12‐4 6 REFERENCES [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] J.M. Tien and D. Berg. A case for service systems engineering. In Journal of systems science and systems engineering, volume 12 No. 1, pages 13-38, 2003. Baskerville, R. Information Systems Security Design Methods: Implications for Information Systems Development. ACM Computing Surveys, 25(4), pp. 375-414, 1993. BSI (2003) IT Baseline Protection Manual. Bundesamt fur Sicherheit in der Informationstechnik (Institute for Security in Information Technologies), material on the web site http://www.bsi.bund.de/english/gshb/index.htm, accessed May 2005. CRAMM. CCTA Risk Analysis & Management Method v5.0, material on the web site www.cramm.com, accessed May 2005. Katsikas, S. (1995) Risk Management in Information Systems. In Information Security: Technical, Legal and Social Issues by Alexandris, Kiountouzis & Trapezanoglou, published by the Greek Computer Society. Irvine, C.E. et al. (2002) An Approach to Security Requirements Engineering for a High Assurance System. Requirements Engineering, 7, 192-206. Wood, C.C. (1995) Shifting IS Security Responsibility from User Organisations to Vendor/Publisher Organisations. Computers & Security, 14, pp. 283-284. Siponen, M. (2003) New directions on IS security methods: The process view. In: Security and Privacy in the Age of Uncertainty, Gritzalis, D. et al. (eds.), Kluwer Academic Publishers, 325-336. Baskerville, R. (1988) Designing Information Systems Security, Wiley publications. McDermott, J. & Fox, C. Using abuse case models for security requirements. In: Proceedings of the 15th Annual Computer Security Applications Conference (ACSAC), 1999. Downs, E., Clare, P. and Coe, I. SSADM: Application and Context, Prentice Hall, 1992. Warren, M.J. & Batten, L.M. Security Management: An Information System Setting. In: Proceedings of the ACISP 2002 Conference, Batten, L., Seberry, J. (eds.), Springer-Verlag LNCS 2384, 257-270, 2002. Evertsson, U., Orthberg, U. & Yngström, L. Integrating Security into Systems Development. In: Security and Privacy in the Age of Uncertainty, Gritzalis, D. et al. (eds.), Kluwer Academic Publishers, 313-324, 2003. [14] Hitchings, J. Achieving an Integrated Design: The Way Forward for Information Security. In: Information Security – the next decade, Ellof, J. and von Solms, S. (eds), pp. 369-383, Chapman & Hall, 1995. [15] Checkland, P. (1981) Systems thinking, systems practice, Wiley Publications. [16] SBA (2005) IT Security By Analysis, material on the web site http://www.dfs.se/products/sbaeng/, accessed May 2005. [17] Vermeulen. C., and Von Solms. R. (2002) The information security management toolbox – taking the pain out of security management. Information Management & Computer Security, 10 (3), 119-125. [18] Kajava, J. et al (2006) Information security standards and global business: Proceedings of International Conference on Industrial Technology (ICIT 2006), December 15-17, Mumbai, India. p. 20912095. [19] ISO/IEC 26702. Systems engineering - application and management of the systems engineering process. Technical report, International Standards Organisation, 2007. [20] Sheard, S. A. and Lake, J. G., 1998, Systems Engineering Standards and Models Compared, Proceedings of 8th Symposium of INCOSE, Vancouver, Columbia. [21] Doran, T (2005) IEEE 1220: For Practical Systems Engineering. Computer May 2006 (vol. 39 no. 5). [22] Altomare, P M, (1996) Implementing systems engineering into an ongoing programme American Society of Mechanical Engineers, Dynamic Systems and Control Division, v 60, p 77-79, Engineering Systems [23] BERR. (2008) Information Security Breaches Survey, technical report. PriceWaterHouseCoopers, in association with Symantec, HP and The Security Company. Available from: http://www.security-survey.gov.uk [Accessed 8th February 2010]. [24] ISO/IEC 27001. Information technology - security techniques information security management systems - requirements. Technical report, International Standards Organisation [25] Ernst & Young. (2008) Global Information Security Survey: Moving beyond compliance. Ernst & Young. Available from: http://www.ey.com [Accessed 8th February 2010] [26] The ISO Survey of Certifications. (2008) ISO Central Secretariat. Available from: http://www.onac.org.co/portal/images/stories/ISO_Survey2008.pdf [Accessed 8th February 2010].