You are on page 1of 6

Enterprise Security Planning with TOGAF-9

L. Ertaul1, A. Movasseghi2, and S. Kumar2
Math & Computer Science, CSU East Bay, Hayward, CA, USA
Math & Computer Science, CSU East Bay, Hayward, CA, USA

Abstract. Enterprise security architecture is a unifying 2. TOGAF Structure
framework and reusable services that implement policy,
standard and risk management decision. The purpose of the As shown in Fig 1, TOGAF structure consists of;
security architecture is to bring focus to the key areas of
concern for the enterprise, highlighting decision criteria and
context for each domain. TOGAF-9 architecture framework
provides guidance on how to use TOGAF-9 to develop
Security Architectures and SOA’s. This paper addresses 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.

Keywords: Enterprise Security Planning, Enterprise
Architectures, TOGAF

1. Introduction
The Open Group Architecture Framework (TOGAF) is a
framework - a detailed method and a set of supporting
tools for developing enterprise architecture [1]. TOGAF
9 is much different from other architecture frameworks
such as Zachman, as it is lot more process driven and
gives you a way to essentially codify architectural Figure 1. TOGAF Structure
patterns [2]. Key enhancement in TOGAF 9 is the
introduction of a seven-part structure and reorganization PART I (Introduction) -This part provides a high-level
of the framework into modules with well-defined introduction to the key concepts of enterprise
objectives. This will allow future modules to evolve at architecture and in particular the TOGAF approach. It
different speeds and with limited impact across the contains the definitions of terms used throughout
entire blueprint -- something that's needed if you're TOGAF and release notes detailing the changes between
looking to create architecture within compartments and this version and the previous version of TOGAF.
have those compartments operating independently
[1],[3],[5]. TOGAF 9, first of all, is more business PART II (Architecture Development Method) - This
focused. Before that it was definitely in the IT realm, part is the core of TOGAF. It describes the TOGAF
and IT was essentially defined as hardware and Architecture Development Method (ADM) - a step-by-
software. The definition of IT in TOGAF 9 is the step approach to developing enterprise architecture.
lifecycle management of information and related
technology within an organization. It puts much more PART III (ADM Guidelines and Techniques) This
emphasis on the actual information, its access, part contains a collection of guidelines and techniques
presentation, and quality, so that it can provide not only available for use in applying TOGAF and the TOGAF
transaction processing support, but analytical processing ADM.
support for critical business decisions [4].
PART IV (Architecture Content Framework) This
part describes the TOGAF content framework, including
a structured metamodel for architectural artifacts, the
use of re-usable architecture building blocks, and an
overview of typical architecture deliverables.

PART VI (TOGAF Reference Models) This part provides a selection of architectural reference models. . possible. throughout the phases of the 4.) as security-related concerns unless there is special Business rules regarding handling of data/information awareness on the part of the IT architect.1 Security for Architecture Domains 3. processes. should be traceable to business and policy decisions. add or change how policies are implemented in Security Architecture is a cohesive security design the system.) Data classification ADM. 3. 5. and artifacts which should be created. permitted capabilities for a person or entity whose and the Integrated Information Infrastructure Reference identity has been established. Authorization: The definition and enforcement of which includes the TOGAF Foundation Architecture. This definition is tolerance for risk. 1. skills. For example. 3.3 Security Architecture Artifacts All groups of stakeholders in the enterprise will have security concerns. and responsibilities required to establish and operate an architecture function within an enterprise.) 3. Although all parts work together without service interruption or depletion despite as a whole. steps which should be taken.[7]. In TOGAF 9. guidance will be offered on security-specific policy documentation. from the special definition found in financial markets which has a structure and addresses the relationship and insurance institutions that have formal risk between the components [6][7]. These concerns might not be obvious Typical security architecture artifacts should include. TOGAF-9 Security Architecture Administration: The ability to add and change security policies. architecture is a design. It is desirable assets. Model (III-RM). risks of a particular environment/scenario and specifics what security controls are to be applied where.PART V (Enterprise Continuum & Tools) This 3. information which should be gathered. policies.) Risk analysis documentation. these independent parts is to allow for different areas of specialization to be considered in detail and potentially Availability: The ability of the system to function addressed in isolation. adoption whilst excluding others. person or entity related to the system in some way [8]. The Risk Management: The organization's attitude and design process should be reproducible.) to bring a security architect into the project as early as Codified data/information asset ownership and custody. roles. unauthorized and unintended use. (This risk management is different intended to specify only that. it is also feasible to select particular parts for abnormal or malicious events. an organization may wish to adopt the ADM process.2 Areas of Concerns for Security Architecture part discusses appropriate taxonomies and tools to categorize and store the outputs of architecture activity Authentication: The authenticity of the identity of a within an enterprise.) Written and published security policy. Audit: The ability to provide forensic data attesting that PART VII (Architecture Capability Framework) the system was used in accordance with stated security This part discusses the organization. but Asset Protection: The protection of information assets elect not to use any of the materials relating to from loss or unintended disclosure. and resources from architecture capability [1]. 2. which should derive from a risk analysis. and add or change the persons or entities which addresses the requirements and in particular the related to the system. management departments. like all others. Assurance: The ability to test and prove that the system has the security attributes required to uphold the stated The intention of dividing the TOGAF specification into security policies. Architecture decisions related to security.

preferences used to support security policies. In the case where 1. In the case of 3. 4. A new IT architecture initiative discovers new stakeholders and/or new requirements. Security considerations can conflict Tension between delivery of new business functions and with functional considerations and a security advocate is security policies do exist. and not applicable jurisdictions and outputs comes out in form technology specific. So.1 Preliminary Phase 4. A new threat realized or experienced 3.4 ADM Security Architecture Requirement does encompass group of other organizations. then a Management common ground should need to be established between architects of different organization so they can develop Security Policies and security standards are one of the interfaces and protocols for exchange of security most important part of enterprise requirement information related to federated identity. list of security standards are highly dynamic and state technological conditions and boundary conditions. Security Architecture and ADM Security architecture and ADM have eight different Figure 2. above. Other architects and management need to of difficult issues. In order to implement these policies there is executives should need to identified and frequently need to identify a security architect or security updated about the security related aspects of project. and 2. Security security policy. the inputs to this phase would be executive level and have the characteristics like written security policy. these new requirements would be drivers for input to the change management system discussed in Phase H.2 Phase A (Architecture Vision) As shown in Fig 2. [7][9]. list of applicable requirement for all architecture projects. Security policies are established at and authorization.3. this phase is responsible for the In Phase A. A new architecture initiative might be launched to examine the existing infrastructure and applications to determine the extent of changes required to meet the new demands. So the processes solving such required to ensure that all issues are addressed and disputes must be established at the early stage of the conflicts of interest do not prevent explicit consideration project. authentication management process. If the business model of organization . relevant statutes. Security patterns for deploying these security-related building blocks are referred to in the Security Guidance to Phase E. In TOGAF 9. above occur. Security standards will manifest themselves as security-related building blocks in the Enterprise Continuum. Once established act as a of list of applicable regulations. ISO/IEC the security related architecture decision should be 17799:2005 is used for the formation of security documented and the concern management peoples and policies. architecture team. list of durability. the main intention of security architect is to defining and documenting applicable rules and security obtain management support for security measures. New security requirements arise from many sources: 1. security team roaster. a new security requirement will enter the requirements management system. TOGAF Security Architecture and phases as explained below ADM 4. All policies requirements. A new statutory or regulatory mandate 2. resistant to impulsive change.

Those innovation. Identify and objective). errors are security vulnerabilities. must also be identified. business environment. on users and administrative personnel. some outside the organization who are proper users of the value is lost to stakeholders. cost. proper users of the system should be documented. revisit assumptions regarding interconnecting document interconnecting systems beyond project systems beyond project control. there are likely other potential trigger defined [7][9]. If not. However. or through limiting the effects of resource depletion to non-critical functionality.identify that the role of security architect is safeguard 4. loss of a AAA bond rating. From a security standpoint. in addition differ markedly from safe failure states for consumer to their expected capabilities and characteristics. Assets are not always tangible and are not applicable recognized guidelines and standards. inputs that must be accommodated in non-normative cases. business and regulatory environment must be state. It must electronics. applicable policies. identify and evaluate control. Many regulatory obligations. Safe default modes for an subsequent decisions regarding authorization will rely automobile at zero velocity may no longer be applicable upon a strong understanding of the intended users. and documented. the measures. such as Internet-based customers. Presumably. Determine and document system design. and measures that can respond through limiting the causative factors. The cost of this opportunity system. appropriate security forensic processes in order to proper battery power. how much security (cost) is justified by the threats and Design steps that identify non-renewable resources. Additionally. Examples include network bandwidth. Standards are justly credited for reducing be borne in mind that users may not be humans. Every always easy to quantify. as must users outside implementations that have been scrutinized by experts in boundaries of trust. All the architecture decisions gap analysis. Safe default actions and failure modes must be defined for the system informed by the current Phase B help to locate the legitimate actors who will state. disk space. standard object libraries. From a security standpoint. Every state change in any system is must be made between the context of environment precipitated by some trigger. implementation of security policies which in turn helps As resources are utilized approaching depletion. methods that can recognize resource depletion. Determine and document functionality may be impaired or may fail altogether. Examples include: loss of life. Existing business disaster/continuity plans may Security measures. system failure may take place at any 4. and leveraging software applications may be legitimate users. and interact with the product/service/process. The outside entities will be determined from the loss should be quantified. if possible. high-level scenarios developed as part of Phase A. . and operators of the system. can enhance the overall reliability and availability of the system [7] [9]. Any existing disaster recovery and business continuity plan must be understood and A full inventory of architecture elements that implement their relationship with the planned system must be security services must be compiled in preparation for a defined and documented. So the set of expected values of that trigger initiates a change in physical. while important. The trade-offs can require balancing Security architect should assess and baseline current security advantages against business advantages and security-specific technologies (enhancement of existing demand informed judicious choice. the value of the assets at risk [7][9]. such as backup protocols. to catch the security breaches. can impose burden accommodate the system under consideration. Commonly. available memory. system will rely upon resources that may be depleted in loss of customer good will. their fields help to ensure that errors do not find their The business process regarding how actors are vetted as way into implementations. Safe failure states for medical devices will administrators. at speed. in the Consideration should also be made for actors from event of system failure or loss of functionality. enhancing interoperability.5 Phase D (Technology Architecture) competitor to avoid the perceived burden of the infrastructure. and so on. standard tending to administrative needs. Some will some analysis is called for to determine the gap and the respond to that burden by finding ways to circumvent cost if that gap goes unfilled [7][9]. an enumerated within which system will be placed and operate. cases that may or may not be anticipated at the point of loss of market share. Examples include administrators finding ways to create "back doors" or customers choosing a 4. and standard operators.3 Phase B Business Architecture point in time.4 Phase C Information Systems Architectures the assets of enterprise.

but also upon installation and operational state.opengroup. system already exists. http://www. rather than just addressing identified risks. Statutory or regulatory requirements may call for physical separation 5. Since design.http://www. and code reviews improvement/2808  and define acceptance criteria for the successful 5. that reflects operational stability and adherence to security policies. not technical ones. and such a [9]. and patterns can be used. document them and then security vulnerabilities.9 Phase H (Architecture Management) infrastructure and security building blocks that can be applied to the requirements derived from this Incorporate security-relevant changes to the architecture development engagement. building Unless the security architecture can address a wide blocks. Implement methods and gaf9‐doc/arch/chap04. then it will amenable to mitigation and evaluated the appropriate likely fail to deliver what the business expects. and/or operated. though newly range of operational requirements and provide real implemented. and operations of security. security architecture. Secondly. terms at all times. gaf9‐doc/arch/  . but also throughout operation [7][9]. Also.4. togaf‐9‐means‐better‐architecture‐555  4.isss. Yet it is not sufficient to compile a code.html  procedures to review evidence produced by the system 6. it can be used again. those mitigation measures must be designed. http://www. information systems industry. To achieve all those things it is curity_Architecture. and configuration errors are the roots of many set of business requirements.zdnet. design. mechanisms are utilized to monitor cture/togaf9-doc the performance of many aspects of the system. http://www. In a phased implementation the new security components are usually part of the infrastructure in implementation of the findings. not just in the realm of implemented. Known products.infoworld. there will be existing security at 4. deployed. Having determined the risks focusing upon short-term point solutions. and setting up quantifiable success metrics that are developed in business terms around 4. reviewed.pdf  necessary to trained people to ensure correct 7. From the Baseline Security Architecture and the Enterprise Continuum. TOGAF version 9 Enterprise properly support the project. Security of en‐group‐upgrades‐enterprise‐architecture‐ any system depends not on design and implementation 402.6 Phase E (Opportunities and Solution) relevant subsystems and components. For example. References which the new system is implemented. These conditions must be defined and monitored not just 3. and proceed to design a security solutions already engineered.infoworld. Engineer mitigation measures business support and enablement. and field- architecture driven by technical thinking alone. ensure awareness training of all users and non-privileged operators of the Identify existing security services available for re-use. if environment into the requirements for future the requirement exists for application access control enhancement (enhancement of existing objective) [7] external to an application being security and availability are no exception.8 Phase G (Implementation Governance) ‐9‐advances‐it‐maturity‐while‐offering‐ more‐paths‐to‐architecture‐level‐it‐ Establish architecture artifact. during the operational phases. http://www. http://www. taking advantage of any problem put them on the shelf. tools.  alone. tested. Conclusions of domains which may eliminate the ability to re-use existing infrastructure. system and/or its components[7][9].opengroup. Its 2. The security infrastructure needs to be in a first or early phase to 1. http://www. This type investment in that mitigation as it relates to the assets at of failure is a common phenomenon throughout the risk.7 Phase F (Migration Planning) business performance parameters. Being a proven will reduce security exposure and enhance successful security architect means thinking in business reliability [7] [9].

  fourth  edition. Prentice Hall.  Stallings.8. 2010  9.  “Cryptography  and  Network  Security  Principles  and  Practices”.net/MVeeraragaloo /togaf‐9‐security‐architecture‐ver1‐0‐ 5053593   . http://www.slideshare. W.