Guide to Security Architecture in TOGAF ADM A White Paper developed by: The Open Group Security Forum and Members of The Open Group Architecture Forum November, 2005 Guide to Security Architecture in TOGAF ADM Copyright © 2005 The Open Group All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of the copyright owners. Boundaryless Information Flow™ is a trademark and Making Standards Work®, UNIX®, and The Open Group® are registered trademarks of The Open Group in the United States and other countries. All other trademarks are the property of their respective owners. Guide to Security Architecture in TOGAF ADM Document No.: W055 Published by The Open Group, November, 2005 Any comments relating to the material contained in this document may be submitted to: The Open Group 44 Montgomery St. #960 San Francisco, CA 94104 or by email to: [email protected] www.opengroup.org A White Paper Published by The Open Group 2 Guide to Security Architecture in TOGAF ADM Table of Contents Executive Summary 4 Introduction to Security Architecture Guidance in the ADM 5 ADM Overview..................................................................................................5 Security Guidance for ADM Architecture Requirements Management 8 Objective............................................................................................................8 Approach............................................................................................................8 Security Guidance..............................................................................................9 Security Guidance for Preliminary Phase: Framework and Principles11 Objectives.........................................................................................................11 Approach..........................................................................................................11 Security Guidance............................................................................................12 Security Guidance for Phase A: Architecture Vision 14 Objectives.........................................................................................................14 Approach..........................................................................................................14 Security Guidance............................................................................................15 Security Guidance for Phase B: Business Architecture 17 Objectives.........................................................................................................17 Approach..........................................................................................................17 Security Guidance............................................................................................18 Security Guidance for Phase C: Information System Architectures 22 Objective..........................................................................................................22 Approach..........................................................................................................22 Security Guidance............................................................................................23 Security Guidance for Phase D: Technology Architecture 26 Objective..........................................................................................................26 Approach..........................................................................................................26 Security Guidance............................................................................................26 Security Guidance for Phase E: Opportunities and Solutions 29 Objective..........................................................................................................29 Approach..........................................................................................................29 Security Guidance............................................................................................30 Security Guidance for Phase F: Migration Planning 32 Objective..........................................................................................................32 Approach..........................................................................................................32 Security Guidance............................................................................................34 Security Guidance for Phase G: Implementation Governance 35 Objective..........................................................................................................35 Approach..........................................................................................................35 Security Guidance............................................................................................36 Security Guidance for Phase H: Architecture Change Management 37 Objective..........................................................................................................37 Approach..........................................................................................................37 Security Guidance............................................................................................39 About The Open Group 41 www.opengroup.org A White Paper Published by The Open Group 3 Guide to Security Architecture in TOGAF ADM Boundaryless Information Flow™ achieved through global interoperability in a secure, reliable, and timely manner Executive Summary The Open Group Architecture Framework (TOGAF) is now well-established in the IT Architecture industry. The core of TOGAF is its Architecture Development Method (ADM). Development of TOGAF ADM has matured and extended in its coverage over many years now. The latest published version is TOGAF8. Coverage of information security considerations in TOGAF ADM has, for several years, been acknowledged as a significant omission. In late 2004, The Open Group Security Forum undertook a collaborative project with members of the Architecture Forum to correct this omission. The result is this White Paper. The goal of this White Paper is to explain what security considerations need to be addressed in the TOGAF ADM for the guidance of enterprise architects and system designers. Its primary purpose is as input to the Architecture Forum, for integrating security considerations into their development of the next version of TOGAF (designated TOGAF9). We also anticipate it will be of value to system architects and designers who include information security considerations in their designs. The work in developing this White Paper is based on the existing published TOGAF- 8, so the Security Forum and our collaborators from the Architecture Forum appreciate that there may be new considerations arising in TOGAF9 development that we will want to re-visit when TOGAF9 becomes sufficiently stable. It is significant to note that during this development project, several security-related architecture and design issues arose which the information security experts wanted to include in this White Paper, but which were ruled as out of scope of the coverage of TOGAFADM. Follow-on work will aim at a minimum to capture these issues and make them available from the Security Forum web site (www.opengroup.org/security). www.opengroup.org A White Paper Published by The Open Group 4 Guide to Security Architecture in TOGAF ADM Introduction to Security Architecture Guidance in the ADM ADM Overview The TOGAF Architecture Development Method (ADM) is the result of continuous contributions from a large number of architecture practitioners. It describes a method for developing an enterprise architecture, and forms the core of TOGAF. It integrates elements of TOGAF as well as other available architectural assets, to meet the business and information technology needs of an organization. The TOGAF Architecture Development Method (ADM) forms the core of TOGAF. It is a method for developing an enterprise architecture to meet the business and information technology needs of an organization, utilizing the other elements of TOGAF described in this document, and other architectural assets available to the organization. Architectural development in the process of the ADM is iterative in nature, in that as the development of the architecture progresses, many areas of concern are revisited but at a finer-grained level of examination. Through the several phases the reader might see topics repeated, or in an earlier phase a topic might be treated at a higher level than the reader might expect. Architecture development methods are also tools in the hands of the practitioner to be used as best fits the practitioner's experience. The guidance included here is intended to help practitioners avoid missing a critical security concern. It is expected that elements included by the authors in specific phases will be modified and shifted according to the practitioner's experience. This guide is not intended to be a Security Architecture Development Methodology. It is intended for the enterprise architect deploying TOGAF ADM, to inform the enterprise architect of what the security architect will need to carry out their security architecture work. It is also intended as a guide to help the enterprise architect avoid missing a critical security concern. Discussion of security architecture has the tension of being separate from the remainder of enterprise architecture development and at the same time needing to be fully integrated in it. The focus of the security architect is enforcement of security policies of the enterprise, which at times can be seen as inhibiting advancement of projects undertaken by the enterprise architect and application development team. Security architects spend a good deal of effort proving the negative. Characteristics of Security Architecture • Security architecture has its own methods. These methods might be the basis for a discreet security methodology. • Security architecture composes its own discrete view and viewpoints. • Security architecture addresses non-normative flows through systems and among applications. • Security architecture introduces its own normative flows through systems and among applications. • Security architecture introduces unique, single-purpose components in the design. • Security architecture calls for its own unique set of skill requirements in the IT architect. www.opengroup.org A White Paper Published by The Open Group 5 Guide to Security Architecture in TOGAF ADM Guidance on Security for the Architecture Domains Pervasively throughout the architectural domains and in all phases of the architecture development, security concerns of the enterprise need to be accounted for. Security is called out separately because it is infrastructure that is rarely visible to the business function being added to the target architecture to derive value. Its fundamental purpose is to protect the value of the systems and information assets of the enterprise. The nature of security in the enterprise is that it is deemed successful if nothing happens that is visible to the user or other observer, and no damage or losses occur. That is, if the enterprise retains the use and value of its information assets, the goals of security in the enterprise have been met. These assets might be obvious – like the data in a customer records database – or intangible – like not having the company name appear in an article in the news saying that its data systems had been compromised. While security architecture does have its own single-purpose components, security is experienced as a quality of systems in the architecture. As salt is a separate seasoning, it becomes part of the quality of the dish once it is used. The security view of the architecture calls out its own unique building blocks, collaborations, and interfaces. These security-unique elements must interface with the business systems in a balanced and cost-effective way, so as to maintain the security policies of the enterprise, but not interfere with system operations and functions. It is least costly and most effective to plan for and implement security-specific function in the target architecture as early as possible in the development cycle to avoid costly retrofit or rework because required building blocks for security were not added or used during systems development and deployment. The approach of the IT architect operating in the security domain is also different from IT architects operating in other architecture domains. The security architect considers not only the normal flow of the application, but also the abnormal flows, failure modes, and ways the systems and applications can be interrupted. Put differently, the IT architect tends to focus mostly on how a system will work while the security architect focuses primarily on how the system might fail. All groups of stakeholders in the enterprise will have security concerns. These concerns might not be obvious as security-related concerns unless there is special awareness on the part of the IT architect. It is desirable to bring a security architect into the project as early as possible. Throughout the phases of the ADM, guidance will be offered on security-specific information which should be gathered, steps which should be taken, and artifacts which should be created. Architectural decisions related to security, like all others, should be traceable to business and policy decisions, which should derive from a risk analysis. The generally accepted areas of concern for the security architect are: • Authentication The substantiation of the identity of a person or entity related to the system in some way. • Authorization The definition and enforcement of permitted capabilities for a person or entity whose identity has been established. • Audit The ability to provide forensic data attesting that the system was used in accordance with stated security policies. www.opengroup.org A White Paper Published by The Open Group 6 Guide to Security Architecture in TOGAF ADM • Assurance The ability to test and prove that the system has the security attributes required to uphold the stated security policies • Availability The ability of the system to function without service interruption or depletion despite abnormal or malicious events. • Asset Protection The protection of information assets from loss or unintended disclosure, and resources from unauthorized and unintended use. • Administration The ability to add and change security policies, add or change how policies are implemented in the system, and add or change the persons or entities related to the system. • Risk Management The organization's attitude and tolerance for risk. (This risk management is different from the special definition found in financial markets and insurance institutions that have formal risk management departments.) Sample Artifacts 1. Business rules regarding handling of data/information assets 2. Written and published security policy 3. Codified data/information asset ownership and custody 4. Risk analysis documentation 5. Data classification policy documentation www.opengroup.org A White Paper Published by The Open Group 7 Guide to Security Architecture in TOGAF ADM Security Guidance for ADM Architecture Requirements Management Objective To define a process whereby requirements for enterprise architecture are identified, stored, and fed into and out of the relevant ADM phases. Approach As indicated by the “Requirements Management” circle at the center of the ADM graphic, the ADM is continuously driven by the requirements management process. It is important to note that the “Requirements Management” circle denotes, not a static set of requirements, but a dynamic process whereby requirements for enterprise architecture and subsequent changes to those requirements are identified, stored, and fed into and out of the relevant ADM phases. The ability to deal with changes in requirements is crucial. Architecture is an activity that by its very nature deals with uncertainty and change – the “grey area” between what stakeholders aspire to and what can be specified and engineered as a solution. Architecture requirements are therefore invariably subject to change in practice. Moreover, architecture often deals with drivers and constraints, many of which by their very nature are beyond the control of the enterprise (changing market conditions, new legislation, etc.), and which can produce changes in requirements in an unforeseen manner. Note also that the requirements management process itself does not dispose of, address, or prioritize any requirements: this is done within the relevant phase of the ADM. It is merely the process for managing requirements throughout the overall ADM. Resources The world of requirements engineering is rich with emerging recommendations and processes for requirements management. TOGAF does not mandate or recommend any specific process or tool: it simply states what an effective requirements management process should achieve (i.e., the “requirements for requirements”, if you like). • Business Scenarios One effective technique that is described in TOGAF itself is business scenarios, which are an appropriate and useful technique to discover and document business requirements, and to articulate an architectural vision that responds to those requirements. Business scenarios are described in detail in TOGAF Part IV: Resource Base, Business Scenarios. www.opengroup.org A White Paper Published by The Open Group 8 Guide to Security Architecture in TOGAF ADM • Volere Requirements Specification Template Architecture requirements is very much a niche area within the overall requirements field. One useful resource is the Volere Requirements Specification Template, available from the Volere web site hosted by the Atlantic Systems Guild. While not designed with architecture requirements in mind, this is a very useful requirements template, which is freely available and may be modified or copied (for internal use, provided the copyright is appropriately acknowledged). One interesting item in this template is the “waiting room”, which is a hold-all for requirements in waiting. There are often requirements identified which, as a result of the prioritization activity that forms part of the requirements management process (see below), are designated as beyond the planned scope, or the time available, for the current iteration of the architecture. The waiting room is a repository of future requirements. Having the ability to store such requirements helps avoid the perception that they are simply being discarded, while at the same time helping to manage expectations about what will be delivered. • Requirements Tools There is a large, and increasing, number of Commercial Off-The-Shelf (COTS) tools available for the support of requirements management, albeit not necessarily designed for architecture requirements. The Volere web site has a very useful list of leading requirements tools. Security Guidance The security policy and security standards become part of the enterprise requirements management process. Security policy is established at an executive level of the business, is long-lived, and resistant to whimsical change. Security policy is not tied to any specific technology. Once the security policies are established, they can be referred to as requirements for all architectural projects. Security standards change more frequently and state technology preferences used to support security policies. New technologies that support the implementation of security policies in a better way can be adopted as needed. The improvements can be in reduced costs or increased benefits. Security standards will manifest themselves as security-related building blocks in the Enterprise Continuum. Security patterns for deploying these security-related building blocks are referred to in the Security Guidance to Phase E. New security requirements arise from many sources: 1. A new statutory or regulatory mandate 2. A new threat realized or experienced 3. A new IT architectural initiative discovers new stakeholders and/or new requirements In the case where 1 and 2 above occur, these new requirements would be drivers for input to the change management system discussed in Phase H. A new architectural initiative might be launched to examine the existing infrastructure and applications to determine the extent of changes required to meet the new demands. In the case of 3 above, a new security requirement will enter the requirements management system. Is our security good? This question inevitably comes from management to the security architect. No security measures are ever perfect, and the potential exists for the amount of money and effort expended to become very www.opengroup.org A White Paper Published by The Open Group 9 Guide to Security Architecture in TOGAF ADM large for little additional return. Security assurance testing should be in place so that the security systems can be measured to ensure that they keep the security policies for which they were designed. Security policy audits should be held and might be mandatory by statute or regulation. These security audits and possible security policy changes are the exact reason why separation of policy enforcement from application code is so strongly emphasized. Nothing useful can be said about a security measure outside the context of an application, or a system and its environment The efficacy of a security measure is considered in relation to the risk it mitigates. An enterprise cannot determine how much it will be willing to spend on securing an asset until it understands the asset value. For example, the use of that asset in an application and the concomitant risk the asset is exposed to as a result will determine the true requirements for security. Additionally, the organization's tolerance for risk is a factor. In other words, the question asked should not be: “is it secure?” but rather: “is it secure enough?” The latter is ultimately a question to be answered by risk analysis. www.opengroup.org A White Paper Published by The Open Group 10