| You are here: | ||
| <<< Previous | Home | Next >>> |
The goal of this chapter is to explain the security considerations that need to be addressed during application of the TOGAF Architecture Development Method (ADM).
Architecture development methods are tools in the hands of the security practitioner to be used to create best practice and organization-specific security capability.
The guidance included here is intended to help both enterprise architects and security practitioners to avoid missing critical security concerns.
This chapter informs the enterprise architect of what the security architect will need to carry out during the security architecture work.
Often the security architecture is treated as a separate architecture domain within the enterprise architecture while needing to be fully integrated in it. The focus of the security architect is enforcement of security policies of the enterprise without inhibiting value.
Security architectures generally have the following characteristics:
Security concerns are pervasive throughout the architecture domains and in all phases of the architecture development. Security is called out separately because it is infrastructure that is rarely visible to the business function. Its fundamental purpose is to protect the value of the systems and information assets of the enterprise. Often the nature of security in the enterprise is that it is deemed successful if either nothing happens that is visible to the user or other observer, and/or no damage or losses occur to the enterprise. For example, the data in a customer records database is not leaked or damaged - or an intangible issue such as the company name appears in an article in the news saying that its data systems had been compromised.
The security architecture does have its own single-purpose components and is experienced as a quality of systems in the architecture. The Enterprise Security view of the architecture has 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, yet not interfere with system operations and functions. It is least costly and most effective to plan for and implement security-specific functions 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 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 and fail.
All groups of stakeholders in the enterprise will have security concerns and 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. Architecture decisions related to security should be traceable to business and policy decisions and their risk management.
The generally accepted areas of concern for the security architect are:
Typical security architecture artifacts would include:
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 architecture 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:
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 architecture 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.
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 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.
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.
If the business model of the organization does encompass federation with other organizations, the extent of the security federation should be established at this point in the process. Contractual federation agreements should be examined for their security implications and agreements. It may be necessary to establish joint architecture meetings with other members of a federation to establish interfaces and protocols for exchange of security information related to federated identity, authentication, and authorization.
The framework and principles rarely change, and so the security implications called out in the objectives of this phase should be fairly straightforward. A written security policy for the organization must be in place, and there should be regular notification and education established for employees. ISO/IEC 17799:2005 is a good place to start the formation of a security policy, and can be used to assess the security readiness of an organization. Without a written and published security policy, enforcement is difficult. Security policies refer to many aspects of security for the organization - such as physical premises security - that are remotely related to security of systems and applications. The security policy should be examined to find relevant sections, and updated if necessary. Architecture constraints established in the security policy must be communicated to the other members of the architecture team.
In a similar fashion, there may be regulatory requirements that specify obligations the system must fulfil or actions that must be taken. Whether the system will be subject to regulation will depend upon the functionality of the system and the data collected or maintained. In addition, the jurisdiction where the system or service is deployed, where the users reside, or under which the deploying entity is chartered or incorporated will inform this decision. It may be wise to obtain legal counsel regarding these obligations at the outset of activities.
Agreement on the role of the security architect in the enterprise architecture process and in the architecture and IT governance should also be established. Security considerations can conflict with functional considerations and a security advocate is required to ensure that all issues are addressed and conflicts of interest do not prevent explicit consideration of difficult issues. Executive policy decisions should be established at this point about what security policies can be negotiable and which policies must be enforced for regulatory or statutory reasons.
The level of formality used to define and manage security architecture content will be highly dependent on the scale, sophistication, and culture of the security architecture function.
The approach to security tools may be based on relatively informal usage of standard office productivity applications, or may be based on a customized deployment of specialist security architecture tools and techniques.
Security considerations have an impact on Phases A to H of the TOGAF ADM. The following security specifics appropriate to the security architecture must be addressed within each phase in addition to the generic phase activities.
The steps of the Architecture Vision phase are applicable to ensuring that security requirements are addressed in subsequent phases of the ADM. Security considerations will have an effect on the enterprise such that all enterprise architecture development needs to be informed and utilize the security policy, constraints, governance, artifacts, and building blocks.
After establishing any enterprise architecture project, the following specific security-related activities need to be undertaken.
Definition of relevant stakeholders and discovery of their concerns and objectives will require development of a high-level scenario. Key business requirements will also be established through this early scenario work. The TOGAF ADM business scenario process may be useful here and at later stages.
In similar fashion to obtaining management recognition and endorsement for the overall architecture project, so too endorsement of the security-related aspects of the architecture development effort should be obtained. Recognition that the project might have development and infrastructure impact that are not readily visible by looking solely at the systems in question should be made clear. Thorough consideration and mitigation of issues related to risk and security may be perceived as a waste of resources and time; the level of management support must be understood and communicated throughout the team.
The traceability of security-related architecture decisions should be documented and the appropriate executives and line management who need to be informed of security-related aspects of the project need to be identified and the frequency of reporting should be established. It should be recognized that the tension between delivery of new business function and enforcement of security policies does exist, and that a process for resolving such disputes that arise should be established early in the project. Such tensions often have the result of putting the security architect seemingly "in the way of completing the project". It needs to be understood by management and the other architects involved that the role of the security architect is to safeguard the assets of the enterprise.
Any existing disaster recovery and business continuity plans must be understood and their relationship with the planned system defined and documented.
All architecture decisions must be made within the context of the environments within which the system will be placed and operate. Physical environments that should be documented may include battlefield environments, commercial environments, outdoor environments, mobile environments, and the like. In a similar fashion, the business environment must be defined. Potential business environments may include different assumptions regarding users and interfaces, and those users or interfaces may carry the onus of regulatory environments in which the system must operate (users under the age of thirteen in the US, for example).
Safety-critical systems place lives in danger in case of failure or malfunction.
Mission-critical systems place money, market share, or capital at risk in case of failure.
Non-critical systems have little or no consequence in case of failure.
Development of the business scenarios and subsequent high-level use-cases of the project concerned will bring to attention the people actors and system actors involved. Many subsequent decisions regarding authorization will rely upon a strong understanding of the intended users, administrators, and operators of the system, in addition to their expected capabilities and characteristics. It must be borne in mind that users may not be humans; software applications may be legitimate users. Those tending to administrative needs, such as backup operators, must also be identified, as must users outside boundaries of trust, such as Internet-based customers.
The business process regarding how actors are vetted as proper users of the system should be documented. Consideration should also be made for actors from outside the organization who are proper users of the system. The outside entities will be determined from the high-level scenarios developed as part of Phase A.
Security measures, while important, can impose burden on users and administrative personnel. Some will respond to that burden by finding ways to circumvent the measures. Examples include administrators finding ways to create "back doors" or customers choosing a competitor to avoid the perceived burden of the infrastructure. The trade-offs can require balancing security advantages against business advantages and demand informed judicious choice.
Every cybernetic or business system must rely upon existing systems beyond the control of the project. These systems possess advantages and disadvantages, risks and benefits. Examples include the Domain Name System (DNS) that resolves computer and service names to Internet addresses, or paper currency issued by the local treasury. The address returned by the host or service DNS may not always be trustworthy; paper currency may not always be genuine, and recourse will vary in efficacy between jurisdictions. These interfaces must be understood and documented.
Assets are not always tangible and are not always easy to quantify. Examples include: loss of life, loss of customer good will, loss of a AAA bond rating, loss of market share.
It must be remembered that those assets most challenging to quantify can be the most valuable and must not be neglected. Even qualitative estimates will prove valuable in assessing comparative risks.
Assets may be owned by outside entities, or by inside entities. Inside entities may be owned by individuals or by organizations. Determine:
Always trace it to the real world; i.e.:
All security decisions rely upon trust that has been established in some fashion. No trust assumptions have any value if they cannot be rooted in real-world assessment and liability. In most business environments, trust is established through contracts that define liability where the trust is breached. The onus for assessing trust is the responsibility of those choosing to enter into the contracts and their legal counsel. It is important to note that technology (e.g., digital certificates, SAML, etc.) cannot create trust, but can only convey in the electronic world the trust that already exists in the real world through business relationships, legal agreements, and security policy consistencies.
To be able to enforce security policies, breaches of security need to be properly captured so that problem determination and possible policy or legal action can be taken against the entity causing the breach. Forensic practices suitable to provide evidence where necessary need to be established and documented. Security personnel should be trained to follow the forensic procedures and training material regarding the need to collect evidence should be considered for the standard security education given to employees.
The risks associated with loss of availability may have already been adequately considered in the foregoing mission-critical/safety-critical assessment.
A risk analysis (an understanding of the value of assets at risk and the likelihood of potential threats) provides an important guideline for investments in mitigation strategies for the identified threats.
Business analysis involves a number of rigorous thought exercises and may call into question the initial assumptions identified in the Architecture Vision.
The security policies identified in the Preliminary Phase may have provisions that are difficult or impossible to reconcile with the business goals in light of the identified risks. Possible responses include alteration of aspects of the business environment, modification of the intended user population, or technical mitigation of risks (addressed in Phase C).
Perform a threat analysis that identifies the high-level threats bearing upon the system and their likelihood.
A full inventory of architecture elements that implement security services must be compiled in preparation for a gap analysis.
Every state change in any system is precipitated by some trigger. Commonly, an enumerated set of expected values of that trigger initiates a change in state. However, there are likely other potential trigger inputs that must be accommodated in non-normative cases. Additionally, system failure may take place at any point in time. Safe default actions and failure modes must be defined for the system informed by the current state, business environment, applicable policies, and regulatory obligations. Safe default modes for an automobile at zero velocity may no longer be applicable at speed. Safe failure states for medical devices will differ markedly from safe failure states for consumer electronics.
Standards are justly credited for reducing cost, enhancing interoperability, and leveraging innovation. From a security standpoint, standard protocols, standard object libraries, and standard implementations that have been scrutinized by experts in their fields help to ensure that errors do not find their way into implementations. From a security standpoint, errors are security vulnerabilities.
In light of the risk assessments performed, assumptions regarding interconnecting systems may require modification.
Information stored, created, or manipulated by the system may or may not be subject to an official classification that defines its sensitivity and the obligations to which the system and its owners are subject. The absence of any official classification does not necessarily absolve the onus on maintaining the confidentiality of data. Consideration must be made for different legislative burden that may hold jurisdiction over the system and the data stored.
All assets of value are kept and maintained on behalf of the owner. The specific persons or organizations charged with this responsibility must be identified.
Presumably, in the event of system failure or loss of functionality, some value is lost to stakeholders. The cost of this opportunity loss should be quantified, if possible, and documented.
Existing business disaster/continuity plans may accommodate the system under consideration. If not, some analysis is called for to determine the gap and the cost if that gap goes unfilled.
No environment is static and systems must evolve to accommodate change. Systems architected for ready reconfiguration will better reflect that change and result in lower cost over the life of the system. Security is enhanced when security-related changes can be implemented inexpensively and are, hence, not sidelined. Security is also enhanced when changes require no changes to code; changes to code introduce bugs and bugs introduce security vulnerabilities.
Information maintained beyond its useful lifespan represents wasted resources and, potentially, business decisions based upon suboptimal data. Regulation, however, sometimes mandates the timetable for maintenance of information as archival data.
There are several standard ways to address identified and quantified risk. The list above is not intended to be exhaustive for all approaches.
Anomalous actions and states will outnumber planned actions and states. These transitions will warrant logging to reconstruct chains of events, facilitate root cause analysis, and, potentially, establish evidence for civil or criminal action. It must be borne in mind that logs must be regularly reviewed to be introduced as evidence into a court of law in some jurisdictions.
Since malicious tampering of systems is commonly accompanied by tampering of logged data to thwart investigation and apprehension, the ability to protect and establish the veracity of logs through cryptographic methods will remove uncertainty from investigations and bolster cases in legal proceedings.
Thinking like an adversary will prepare the architect for creation of a robust system that resists malicious tampering and, providentially, malfunction arising from random error.
Every system will rely upon resources that may be depleted in cases that may or may not be anticipated at the point of system design. Examples include network bandwidth, battery power, disk space, available memory, and so on. As resources are utilized approaching depletion, functionality may be impaired or may fail altogether. Design steps that identify non-renewable resources, methods that can recognize resource depletion, and measures that can respond through limiting the causative factors, or through limiting the effects of resource depletion to non-critical functionality, can enhance the overall reliability and availability of the system.
As systems are deployed and operated in dynamic environments, security measures will perform to varying degrees of efficacy as unexpected threats arise and as expected threats change in the environment. A method that facilitates ongoing evaluation of the value of security measures will inform ongoing changes to the system in response to changing user needs, threat patterns, and problems found.
Regulatory requirements, information classification levels, and business needs of the asset owners will all influence the required level of trust that all interactive entities will be required to fulfil to qualify for access to data or services.
Granting sweeping capabilities to any user, application, or other entity can simplify successful transaction completion at the cost of complicating or precluding effective control and audit. Many regulatory obligations are more challenging to demonstrate compliance where privileges are sweeping and controls are loose.
This objective is where the classic security services of identification, authentication, authorization, data confidentiality, data integrity, non-repudiation, assurance, and audit are brought into play, after their applicability is determined and the cost/value of protection has been identified.
From the Baseline Security Architecture and the Enterprise Continuum, there will be existing security infrastructure and security building blocks that can be applied to the requirements derived from this architecture development engagement. For example, if the requirement exists for application access control external to an application being developed, and such a system already exists, it can be used again. Statutory or regulatory requirements may call for physical separation of domains which may eliminate the ability to re-use existing infrastructure. Known products, tools, building blocks, and patterns can be used, though newly implemented.
Having determined the risks amenable to mitigation and evaluated the appropriate investment in that mitigation as it relates to the assets at risk, those mitigation measures must be designed, implemented, deployed, and/or operated.
Since design, code, and configuration errors are the roots of many security vulnerabilities, taking advantage of any problem solutions already engineered, reviewed, tested, and field-proven will reduce security exposure and enhance reliability.
Populate the Architecture Repository with new security building blocks.
In a phased implementation the new security components are usually part of the infrastructure in which the new system is implemented. The security infrastructure needs to be in a first or early phase to properly support the project.
During the operational phases, mechanisms are utilized to monitor the performance of many aspects of the system. Its security and availability are no exception.
Security of any system depends not on design and implementation alone, but also upon installation and operational state. These conditions must be defined and monitored not just at deployment, but also throughout operation.
Many security vulnerabilities originate as design or code errors and the simplest and least expensive method to locate and find such errors is generally an early review by experienced peers in the craft. Locating such errors, of course, is the first step and implementing corrections at an appropriate point in the development lifecycle is necessary to benefit from the investment. Follow-on inspections or formalized acceptance reviews may be warranted in high-assurance or safety-critical environments.
While planning and specification is necessary for all aspects of a successful enterprise, they are insufficient in the absence of testing and audit to ensure adherence to that planning and specification in both deployment and operation. Among the methods to be exercised are:
Training is not necessary simply to preclude vulnerabilities introduced through operations and configuration error, though this is critical to correct ongoing secure performance. In many jurisdictions, proper training must be performed and documented to demonstrate due diligence and substantiate corrective actions or sanctions in cases where exploits or error compromise business objectives or to absolve contributory responsibility for events that bring about harm or injury.
The very purpose of governance is the establishment of a feedback loop that determines the efficacy of plan execution and implements corrections, where required. It must be borne in mind that the imperfections in plans executed are rooted both in human processes and cybernetic processes.
As stated in Part II, 17. ADM Architecture Requirements Management (Requirements Management), change is driven by new requirements. Changes in security requirements are often more disruptive than a simplification or incremental change. Changes in security policy can be driven by statute, regulation, or something that has gone wrong.
Changes in security standards are usually less disruptive since the trade-off for their adoption is based on the value of the change. However, standards changes can also be mandated. Similar approaches to these changes as mentioned above are good rules of thumb for security as well. However, security changes are often infrastructure changes, and can have a greater impact. A seemingly small security requirement change can easily trigger a new architecture development cycle.
Good security forensics practices in conjunction with a written published security policy make determination of what has gone wrong possible. Further, they make enforcement possible. As the guidance above suggests, minor changes can be made in the context of change management and major changes will require a new architecture effort.
Changes that arise as a result of a security problem or new security technology will feed into the Requirements Management process.
The TOGAF document set is designed for use with frames. To navigate around the document:
Downloads of TOGAF®, an Open Group Standard, are available under license from the TOGAF information web site. The license is free to any organization wishing to use the TOGAF standard entirely for internal purposes (for example, to develop an information system architecture for use within that organization). A book is also available (in hardcopy and pdf) from The Open Group Bookstore as document G116.