European Government Enterprise Architecture: Interoperability Architecture
European public-sector EA must deliver actionable recommendations and effective solution designs to support government demands for interoperability and digitalization.
Government Enterprise Architecture (GEA) in the European context has two major levels:
Each country’s own National GEA practice
European GEA practice
Strictly speaking, the European practice has not been called Enterprise Architecture per se, but was and is in all but name a Government Enterprise Architecture practice (“EA by stealth”).
It became the theme interoperability that caught the attention of the European Commission, who defines interoperability as the facilitation of cross-border and cross-sector information exchange, taking into account legal, organisational, semantic and technical aspects (source).
From IDA to ISA2
The Inter-Change of Data Between Administrations programme (IDA) was launched in 1995 and later became the Interoperable Delivery of European eGovernment Services to public Administrations, Businesses and Citizens programme (IDABC), which offered funding of some €25 million per year from 2004-2009 for various pan-European interoperability projects. One of these projects formulated the European Interoperability Framework v1, published in 2004, which provides recommendations and defines generic standards with regard to organizational, semantic and technical aspects of interoperability, offering a comprehensive set of principles for European cooperation in eGovernment. The framework was accompanied by the IDA Architecture Guidelines. Updated in 2010, the framework (now European Interoperability Framework v2) became part of the European Interoperability Strategy.
For continued work on European interoperability, a new programme was established in 2010: The ISA Programme, Interoperability Solutions for European Public Administrations:
Public administrations are expected to provide efficient public services to businesses and citizens across Europe. ISA, the programme on Interoperability Solutions for European Public Administrations, addresses this need. ISA supports and facilitates efficient and effective cross-border electronic collaboration between European public administrations. The programme enables the delivery of electronic public services and ensures the availability, interoperability, re-use and sharing of common solutions (source).
With a budget of €164 million for the period from 2010-2015, the ISA programme has established a number of action areas.
The ISA action on Interoperability architecture studies the possibility of structuring European public information systems and services around a joint architectural blueprint. This action develops together with the Member States and the relevant European Commission departments a joint vision for an Interoperability Architecture for European public services. This involves outlining its scope, deciding how the architectural building blocks will fit together, and determining the need for interface standards between such building blocks, tools and services that can be reused across borders and sectors, such as the following:
a multilingual service, CIRCABC provides private workspaces for collaborative groups to share information and documentation;
a Machine translation service can be used by European public administrations to facilitate efficient and effective electronic cross-border interaction;
the sTesta project provides a secure private European network for data exchange between all the EU Institutions and national networks.
ISA has further supported the development of interoperability-related recommendations for the assessment of standards and specifications used by Member States when acquiring electronic tools and services. The aim to create not only more interoperable information systems but also more efficient use of public funds via sharing and reuse of completed assessments among eGovernment projects. The National Interoperability Framework Observatory tries to help in the sharing, and collects/creates informative Member State Factsheets.
Conceptual Reference Architecture. This involves defining conceptual reference building blocks that are needed in order to build systems supporting public services. A conceptual reference architecture captures the fundamental patterns and concepts that should be applicable for all domains and more specific architectures.
Cartography. This involves mapping existing reusable solutions towards the conceptual reference building blocks. The cartography is meant to include solutions that are readily reusable.
European Interoperability Reference Architecture
The European Interoperability Reference Architecture (EIRA) is
an architecture content metamodel defining the most salient architectural building blocks (ABBs) needed to build interoperable e-Government systems.
On 8 June 2015, release 0.9.0 beta of the EIRA entered an eight-week public review period. Stakeholders working for public administrations in the field of architecture and interoperability were invited to provide feedback.
The EIRA is a four-view reference architecture for delivering interoperable digital public services across borders and sectors. It defines the required capabilities for promoting interoperability as a set of architecture building blocks (ABBs). The EIRA has four main characteristics:
Common terminology to achieve a minimum level of coordination: It provides a set of well-defined ABBs that provide a minimal common understanding of the most important building blocks needed to build interoperable public services.
Reference architecture for delivering digital public services: It offers a framework to categorise (re)usable solution building blocks (SBBs) of an e-Government solution. It allows portfolio managers to rationalise, manage and document their portfolio of solutions.
Technology- and product-neutral and a service-oriented architecture (SOA) style: The EIRA adopts a service-oriented architecture style and promotes ArchiMate as a modelling notation. In fact, the EIRA ABBs can be seen as an extension of the model concepts in ArchiMate.
Alignment with EIF and TOGAF: The EIRA is aligned with the European Interoperability Framework (EIF) and complies with the context given in the European Interoperability Strategy (EIS) . The views of the EIRA correspond to the interoperability levels in the EIF: legal, organisational, semantic and technical interoperability. Within TOGAF and the Enterprise Architecture Continuum, EIRA focuses on the architecture continuum. It re-uses terminology and paradigms from TOGAF such as architecture patterns, building blocks and views.
EIRA in one picture
The figure below provides a high-level overview of the four views in EIRA. Each of the four views consists of a set of Architecture Building Blocks (ABBs) and relations pertaining to the legal, organisational, semantic and technical domain of an Interoperable European Architecture. Each view has entry and exit points from one view to another.
The legal, organisational, semantic and technical domains are the classic European interoperability concerns. The EIRA defines building blocks for each view.
In addition, a new Interoperability specification underpinning view has been added as an additional view, depicting architecture building blocks of the different views as a taxonomy of interoperability specifications:
The “metaview” detailing and specifying interoperability.
EIRAs raison d’etre?
The key concepts of the EIRA and their relationships are described here:
The following list explains the different relationships:
A. The EIRA is derived from the European Interoperability Framework (EIF);
B. The EIRA has one view for each EIF interoperability level;
C. Each EIRA view contains several EIRA ABBs;
D. EIRA ABBs can be used to create reference architectures;
E. A SAT addresses a certain interoperability need. It consists of a sub-set of the most important EIRA ABBs and is derived from a reference architecture;
F. An EIRA SBB realizes one or more EIRA ABB;
G. A (interoperable) solution consists of one or more SBBs;
H. A (interoperable) solution realizes a solution architecture;
I. A solution architecture can be derived from a SAT or directly from a reference architecture;
J. As the EIRA focuses only on the most important ABBs needed for interoperability, other ABBs (= non-EIRA ABBs) can exist;
K. Similar to ABBs, non-EIRA SBBs can exist next to EIRA SBBs.
Release 0.9 of the EIRA does not provide as much detail about the SBBs as it does on the ABBs. This will be done in another project. Also see the SBB template document.
Further information about the EIRA can be obtained in the document ‘An introduction to the European Interoperability Reference Architecture v0.9.0’ (EIRA_v0.9.0_beta_overview.pdf). The release consists of the following release components:
EIRA_v0.9.0_beta_overview.pdf:PDF document containing an introduction to the EIRA, including its key concepts, used ArchiMate notation, tool support, and views.
EIRA_v0.9.0_beta_ABBs: An HTML file containing the definitions of the architecture building blocks.
EIRA lists 161 architecture building blocks. Of these, more than half are technical:
82 Technical View (27 Application and 55 Infrastructure)
26 Organisational View
19 Semantic View
18 Legal View
6 Interoperability View
10 Deprecated (11 if ABB59 Logging Service included – not marked in View:Deprecated but in Status).
The building blocks are described via selected archimate model concepts, of which four are used a lot:
40 archimate:ApplicationService
34 archimate:BusinessObject
26 archimate:ApplicationComponent
18 archimate:DataObject
Other model concepts are also used:
6 archimate:BusinessProcess
5 archimate:Contract
4 archimate:BusinessActor
3 archimate:BusinessRole
3 archimate:InfrastructureService
3 archimate:Network
3 archimate:Node
2 archimate:ApplicationInterface
1 archimate:BusinessFunction
1 archimate:BusinessInteraction
1 archimate:BusinessInterface
1 archimate:BusinessService
So, looking at the big picture, EIRA is perhaps a bit “heavy” on the technology side of interoperability, but does cover the four layers. In particular, EIRA establishes a set of views across the four layers. In doing so, it has to “embrace and extend” ArchiMate.
EIRA and ArchiMate
EIRAs commitment to ArchiMate is somewhat courageous. And somewhat creative, for example:
EIRAs Business Capability is covered by archimate:BusinessFunction
EIRAs Business Information Exchange is covered by archimate:BusinessInteraction
A Business Capability is the expression or the articulation of the capacity, materials and expertise an organization needs in order to perform core functions. Enterprise architects use business capabilities to illustrate the over-arching needs of the business in order to better strategize IT solutions that meet those business needs.
A Business Information Exchange is a piece of business data or a group of pieces of business data with a unique business semantics definition in a specific business context [ISO15000-5, UN/CEFACT CCTS].
These are work-arounds to two well-known ArchiMate limitations.
The archimate:BusinessObject is also quite busy, and for example covers these ABBs:
Business Rule
Business Information
Organisational Procedure
Organisational Structure
Again, work-arounds to current ArchiMate limitations.
EIRAs ABBs have changed with each release. Deprecated ABBs in the 0.9 beta include:
Business Process
Business Process Model
Business Transaction
Licensing and Charging Policy
Privacy Policy
Metadata Management Policy
Data Routing Service
Data Routing Component
Information Security Policy
Data Quality Policy
Logging Service?
So, Business Process and Business Process Model are deprecated, but the archimate:BusinessProcess model concept is used several times, namely for these ABBs:
Public Policy Cycle
Definition of Public Policy Objectives
Formulation of Public Policy Scenarios
Impact Assessment
Public Policy Implementation
Public Policy Evaluation
ArchiMate of course allows for a certain amount of flexibility (ArchiMate 2.1, Chapter 9 Language Extension Mechanisms), but the creativity can be dangerous, expecially in an interoperability context.
EIRA is an many ways ahead of ArchiMate. The challenge is that ArchiMate is under continuous development, and is likely to change on exactly these areas in future versions (see chapter 12.1 in the ArchiMate 2.1 spec). So EIRAs current notation standard should be seen as a temporary “fix”.
A note of caution
EIRA has obviously selected a winner of the longstanding Process vs Capability Debate. Eradicating processes is rather bold, and contrary to advice from experts like Roger Burlton, Paul Harmon, Alan Ramias and Andrew Spanyi, and Keith Swenson. While it is laudable to focus on capabilities, the use of capabilities should not be seen as an alternative to using processes and business process models. Both are needed.
From a maturity standpoint, this is only just acceptable. Even an Excel sheet version would be better, but better would be “raw data” available in a range of formats, possible as an api.
EIRA does not have any mapping to any other framework.
The Legal and the Organisational views are less conventional as architecture views go. The Semantic, Application (Technical) amd Infrastructure (Technical) views are classic architecture views in many EA frameworks. A comparison with established frameworks seems to be a good idea.
A key part of the US Federal Enterprise Architecture Framework Version 2 (FEAF-II) is the Consolidated Reference Model, which equips the US Federal Government and its Federal agencies with a common language and framework to describe and analyze investments. It consists of a set of interrelated reference models that describe the six sub-architecture domains in the framework:
Strategy
Business
Data
Applications
Infrastructure
Security
EIRAs Legal view is roughly equivalent to FEAF-IIs Strategy (Performance Reference Model), and EIRAs Organisational view roughly equivalent to FEAF-IIs Business Reference Model.
Contentwise, EIRA and FEAF-II use these two layers in different ways:
US FEAF-II Performance Reference ModelEU EIRA Legal Interoperability viewEIRAs organisational viewUS FEAF-II Business Reference Model
EIRAs model scope is wider than FEAF-IIs, but FEAF-II is more comprehensive as a classification scheme.
EIRA should consider taking inspiration from FEAF-II, and at least add a security view. If anything, such view should become mandatory for all European governments.
Towards EIRA 1.0
The 0.9 release of EIRA is a big step forward for reference architecture work in European governments.
QualiWare proposes a rapid consolidation and documentation process, and then releasing Version 1.0. EIRA should not await the next version of ArchiMate, but rather run with well-documented revision control.
QualiWare is committed to supporting international governments in their interoperability work. QualiWare fully supports using ArchiMate 2.1. If customer demand requires it, the “EIRA ArchiMate” approach can easily be supported.
SABSA is a proven methodology for developing business-driven, risk and opportunity focused Security Architectures at both enterprise and solutions level that traceably support business objectives.
SABSA is a matrix based taxonomy very similar to the Zachman Framework, but with a security twist. Each layer of the SABSA matrix is meant to force the security architect to ask questions to ensure they understand all the various attributes of security mitigations. Each layer takes a different view of the system and provides an explanation to a different set of developers and designers.
SABSA is a series of integrated frameworks, models, methods and processes, used independently or as an holistic integrated enterprise solution, including:
Business Requirements Engineering Framework (known as Attributes Profiling)
Risk and Opportunity Management Framework
Policy Architecture Framework
Security Services-Oriented Architecture Framework
Governance Framework
Security Domain Framework
Through-life Security Service Management & Performance Management Framework
Over the years, many security standards and requirements frameworks have been developed in attempts to address risks to enterprise systems and the critical data in them. However, most of these efforts have essentially become exercises in reporting on compliance and have actually diverted security program resources from the constantly evolving attacks that must be addressed. In 2008, this was recognized as a serious problem by the U.S. National Security Agency (NSA), and they began an effort that took an “offense must inform defense” approach to prioritizing a list of the controls that would have the greatest impact in improving risk posture against real-world threats. A consortium of U.S. and international agencies quickly grew, and was joined by experts from private industry and around the globe. Ultimately, recommendations for what became the Critical Security Controls (the Controls) were coordinated through the SANS Institute. In 2013, the stewardship and sustainment of the Controls was transferred to the Council on CyberSecurity (the Council), an independent, global non-profit entity committed to a secure and open Internet.
Standardization and automation is another top priority, to gain operational efficiencies while also improving effectiveness. The actions defined by the Controls are demonstrably a subset of the comprehensive catalog defined by the National Institute of Standards and Technology (NIST) SP 800-53. The Controls do not attempt to replace the work of NIST, including the Cybersecurity Framework developed in response to Executive Order 13636. The Controls instead prioritize and focus on a smaller number of actionable controls with high-payoff, aiming for a “must do first” philosophy. Since the Controls were derived from the most common attack patterns and were vetted across a very broad community of government and industry, with very strong consensus on the resulting set of controls, they serve as the basis for immediate high-value action.
Executive Summary
The national and economic security of the United States depends on the reliable functioning of critical infrastructure. Cybersecurity threats exploit the increased complexity and connectivity of critical infrastructure systems, placing the Nation’s security, economy, and public safety and health at risk. Similar to financial and reputational risk, cybersecurity risk affects a company’s bottom line. It can drive up costs and impact revenue. It can harm an organization’s ability to innovate and to gain and maintain customers.
To better address these risks, the President issued Executive Order 13636, “Improving Critical Infrastructure Cybersecurity,” on February 12, 2013, which established that “[i]t is the Policy of the United States to enhance the security and resilience of the Nation’s critical infrastructure and to maintain a cyber environment that encourages efficiency, innovation, and economic prosperity while promoting safety, security, business confidentiality, privacy, and civil liberties.” In enacting this policy, the Executive Order calls for the development of a voluntary risk-based Cybersecurity Framework – a set of industry standards and best practices to help organizations manage cybersecurity risks. The resulting Framework, created through collaboration between government and the private sector, uses a common language to address and manage cybersecurity risk in a cost-effective way based on business needs without placing additional regulatory requirements on businesses.
The Framework focuses on using business drivers to guide cybersecurity activities and considering cybersecurity risks as part of the organization’s risk management processes. The Framework consists of three parts: the Framework Core, the Framework Profile, and the Framework Implementation Tiers. The Framework Core is a set of cybersecurity activities, outcomes, and informative references that are common across critical infrastructure sectors, providing the detailed guidance for developing individual organizational Profiles. Through use of the Profiles, the Framework will help the organization align its cybersecurity activities with its business requirements, risk tolerances, and resources. The Tiers provide a mechanism for organizations to view and understand the characteristics of their approach to managing cybersecurity risk.
The Executive Order also requires that the Framework include a methodology to protect individual privacy and civil liberties when critical infrastructure organizations conduct cybersecurity activities. While processes and existing needs will differ, the Framework can assist organizations in incorporating privacy and civil liberties as part of a comprehensive cybersecurity program.
The Framework enables organizations – regardless of size, degree of cybersecurity risk, or cybersecurity sophistication – to apply the principles and best practices of risk management to improving the security and resilience of critical infrastructure. The Framework provides organization and structure to today’s multiple approaches to cybersecurity by assembling standards, guidelines, and practices that are working effectively in industry today. Moreover, because it references globally recognized standards for cybersecurity, the Framework can also be used by organizations located outside the United States and can serve as a model for international cooperation on strengthening critical infrastructure cybersecurity.
The Framework is not a one-size-fits-all approach to managing cybersecurity risk for critical infrastructure. Organizations will continue to have unique risks – different threats, different vulnerabilities, different risk tolerances – and how they implement the practices in the Framework will vary. Organizations can determine activities that are important to critical service delivery and can prioritize investments to maximize the impact of each dollar spent. Ultimately, the Framework is aimed at reducing and better managing cybersecurity risks.
The Framework is a living document and will continue to be updated and improved as industry provides feedback on implementation. As the Framework is put into practice, lessons learned will be integrated into future versions. This will ensure it is meeting the needs of critical infrastructure owners and operators in a dynamic and challenging environment of new threats, risks, and solutions.
Use of this voluntary Framework is the next step to improve the cybersecurity of our Nation’s critical infrastructure – providing guidance for individual organizations, while increasing the cybersecurity posture of the Nation’s critical infrastructure as a whole.
Section 2
Framework Basics
The Framework provides a common language for understanding, managing, and expressing cybersecurity risk both internally and externally. It can be used to help identify and prioritize actions for reducing cybersecurity risk, and it is a tool for aligning policy, business, and technological approaches to managing that risk. It can be used to manage cybersecurity risk across entire organizations or it can be focused on the delivery of critical services within an organization. Different types of entities – including sector coordinating structures, associations, and organizations – can use the Framework for different purposes, including the creation of common Profiles.
The Framework Core (download Excel) provides a set of activities to achieve specific cybersecurity outcomes, and references examples of guidance to achieve those outcomes. The Core is not a checklist of actions to perform. It presents key cybersecurity outcomes identified by industry as helpful in managing cybersecurity risk. The Core comprises four elements: Functions, Categories, Subcategories, and Informative References, depicted in Figure 1:
The Framework Core elements work together as follows:
Functions organize basic cybersecurity activities at their highest level. These Functions are Identify, Protect, Detect, Respond, and Recover. They aid an organization in expressing its management of cybersecurity risk by organizing information, enabling risk management decisions, addressing threats, and improving by learning from previous activities. The Functions also align with existing methodologies for incident management and help show the impact of investments in cybersecurity. For example, investments in planning and exercises support timely response and recovery actions, resulting in reduced impact to the delivery of services.
Categories are the subdivisions of a Function into groups of cybersecurity outcomes closely tied to programmatic needs and particular activities. Examples of Categories include Asset Management, Access Control, and Detection Processes.
Subcategories further divide a Category into specific outcomes of technical and/or management activities. They provide a set of results that, while not exhaustive, help support achievement of the outcomes in each Category. Examples of Subcategories include External information systems are catalogued, Data-at-rest is protected, and Notifications from detection systems are investigated.
Informative References are specific sections of standards, guidelines, and practices common among critical infrastructure sectors that illustrate a method to achieve the outcomes associated with each Subcategory. The Informative References presented in the Framework Core are illustrative and not exhaustive. They are based upon cross-sector guidance most frequently referenced during the Framework development process. NIST developed a Compendium of informative references gathered from the Request for Information (RFI) input, Cybersecurity Framework workshops, and stakeholder engagement during the Framework development process. The Compendium includes standards, guidelines, and practices to assist with implementation. The Compendium is not intended to be an exhaustive list, but rather a starting point based on initial stakeholder input.
The five Framework Core Functions are defined below. These Functions are not intended to form a serial path, or lead to a static desired end state. Rather, the Functions can be performed concurrently and continuously to form an operational culture that addresses the dynamic cybersecurity risk. See Appendix A for the complete Framework Core listing.
Identify – Develop the organizational understanding to manage cybersecurity risk to systems, assets, data, and capabilities. The activities in the Identify Function are foundational for effective use of the Framework. Understanding the business context, the resources that support critical functions, and the related cybersecurity risks enables an organization to focus and prioritize its efforts, consistent with its risk management strategy and business needs. Examples of outcome Categories within this Function include: Asset Management; Business Environment; Governance; Risk Assessment; and Risk Management Strategy.
Protect – Develop and implement the appropriate safeguards to ensure delivery of critical infrastructure services. The Protect Function supports the ability to limit or contain the impact of a potential cybersecurity event. Examples of outcome Categories within this Function include: Access Control; Awareness and Training; Data Security; Information Protection Processes and Procedures; Maintenance; and Protective Technology.
Detect – Develop and implement the appropriate activities to identify the occurrence of a cybersecurity event. The Detect Function enables timely discovery of cybersecurity events. Examples of outcome Categories within this Function include: Anomalies and Events; Security Continuous Monitoring; and Detection Processes.
Respond – Develop and implement the appropriate activities to take action regarding a detected cybersecurity event. The Respond Function supports the ability to contain the impact of a potential cybersecurity event. Examples of outcome Categories within this Function include: Response Planning; Communications; Analysis; Mitigation; and Improvements.
Recover – Develop and implement the appropriate activities to maintain plans for resilience and to restore any capabilities or services that were impaired due to a cybersecurity event. The Recover Function supports timely recovery to normal operations to reduce the impact from a cybersecurity event. Examples of outcome Categories within this Function include: Recovery Planning; Improvements; and Communications.
Framework Implementation Tiers
The Framework Implementation Tiers (“Tiers”) provide context on how an organization views cybersecurity risk and the processes in place to manage that risk. The Tiers range from Partial (Tier 1) to Adaptive (Tier 4) and describe an increasing degree of rigor and sophistication in cybersecurity risk management practices and the extent to which cybersecurity risk management is informed by business needs and is integrated into an organization’s overall risk management practices. Risk management considerations include many aspects of cybersecurity, including the degree to which privacy and civil liberties considerations are integrated into an organization’s management of cybersecurity risk and potential risk responses.
The Tier selection process considers an organization’s current risk management practices, threat environment, legal and regulatory requirements, business/mission objectives, and organizational constraints. Organizations should determine the desired Tier, ensuring that the selected level meets the organizational goals, is feasible to implement, and reduces cybersecurity risk to critical assets and resources to levels acceptable to the organization. Organizations should consider leveraging external guidance obtained from Federal government departments and agencies, Information Sharing and Analysis Centers (ISACs), existing maturity models, or other sources to assist in determining their desired tier.
While organizations identified as Tier 1 (Partial) are encouraged to consider moving toward Tier 2 or greater, Tiers do not represent maturity levels. Progression to higher Tiers is encouraged when such a change would reduce cybersecurity risk and be cost effective. Successful implementation of the Framework is based upon achievement of the outcomes described in the organization’s Target Profile(s) and not upon Tier determination.
The Tier definitions are as follows:
Tier 1: Partial
• Risk Management Process – Organizational cybersecurity risk management practices are not formalized, and risk is managed in an ad hoc and sometimes reactive manner. Prioritization of cybersecurity activities may not be directly informed by organizational risk objectives, the threat environment, or business/mission requirements.
• Integrated Risk Management Program – There is limited awareness of cybersecurity risk at the organizational level and an organization-wide approach to managing cybersecurity risk has not been established. The organization implements cybersecurity risk management on an irregular, case-by-case basis due to varied experience or information gained from outside sources. The organization may not have processes that enable cybersecurity information to be shared within the organization.
• External Participation – An organization may not have the processes in place to participate in coordination or collaboration with other entities.
Tier 2: Risk Informed
• Risk Management Process – Risk management practices are approved by management but may not be established as organizational-wide policy. Prioritization of cybersecurity activities is directly informed by organizational risk objectives, the threat environment, or business/mission requirements.
• Integrated Risk Management Program – There is an awareness of cybersecurity risk at the organizational level but an organization-wide approach to managing cybersecurity risk has not been established. Risk-informed, management-approved processes and procedures are defined and implemented, and staff has adequate resources to perform their cybersecurity duties. Cybersecurity information is shared within the organization on an informal basis.
• External Participation – The organization knows its role in the larger ecosystem, but has not formalized its capabilities to interact and share information externally.
Tier 3: Repeatable
• Risk Management Process – The organization’s risk management practices are formally approved and expressed as policy. Organizational cybersecurity practices are regularly updated based on the application of risk management processes to changes in business/mission requirements and a changing threat and technology landscape.
• Integrated Risk Management Program – There is an organization-wide approach to manage cybersecurity risk. Risk-informed policies, processes, and procedures are defined, implemented as intended, and reviewed. Consistent methods are in place to respond effectively to changes in risk. Personnel possess the knowledge and skills to perform their appointed roles and responsibilities.
• External Participation – The organization understands its dependencies and partners and receives information from these partners that enables collaboration and risk-based management decisions within the organization in response to events.
Tier 4: Adaptive
• Risk Management Process – The organization adapts its cybersecurity practices based on lessons learned and predictive indicators derived from previous and current cybersecurity activities. Through a process of continuous improvement incorporating advanced cybersecurity technologies and practices, the organization actively adapts to a changing cybersecurity landscape and responds to evolving and sophisticated threats in a timely manner.
• Integrated Risk Management Program – There is an organization-wide approach to managing cybersecurity risk that uses risk-informed policies, processes, and procedures to address potential cybersecurity events. Cybersecurity risk management is part of the organizational culture and evolves from an awareness of previous activities, information shared by other sources, and continuous awareness of activities on their systems and networks.
• External Participation – The organization manages risk and actively shares information with partners to ensure that accurate, current information is being distributed and consumed to improve cybersecurity before a cybersecurity event occurs.
Framework Profile
The Framework Profile (“Profile”) is the alignment of the Functions, Categories, and Subcategories with the business requirements, risk tolerance, and resources of the organization. A Profile enables organizations to establish a roadmap for reducing cybersecurity risk that is well aligned with organizational and sector goals, considers legal/regulatory requirements and industry best practices, and reflects risk management priorities. Given the complexity of many organizations, they may choose to have multiple profiles, aligned with particular components and recognizing their individual needs.
Framework Profiles can be used to describe the current state or the desired target state of specific cybersecurity activities. The Current Profile indicates the cybersecurity outcomes that are currently being achieved. The Target Profile indicates the outcomes needed to achieve the desired cybersecurity risk management goals. Profiles support business/mission requirements and aid in the communication of risk within and between organizations. This Framework document does not prescribe Profile templates, allowing for flexibility in implementation.
Comparison of Profiles (e.g., the Current Profile and Target Profile) may reveal gaps to be addressed to meet cybersecurity risk management objectives. An action plan to address these gaps can contribute to the roadmap described above. Prioritization of gap mitigation is driven by the organization’s business needs and risk management processes. This risk-based approach enables an organization to gauge resource estimates (e.g., staffing, funding) to achieve cybersecurity goals in a cost-effective, prioritized manner.
Coordination of Framework Implementation
Figure 2 describes a common flow of information and decisions at the following levels within an organization: • Executive • Business/Process • Implementation/Operations The executive level communicates the mission priorities, available resources, and overall risk tolerance to the business/process level. The business/process level uses the information as inputs into the risk management process, and then collaborates with the implementation/operations level to communicate business needs and create a Profile. The implementation/operations level communicates the Profile implementation progress to the business/process level. The business/process level uses this information to perform an impact assessment. Business/process level management reports the outcomes of that impact assessment to the executive level to inform the organization’s overall risk management process and to the implementation/operations level for awareness of business impact.
The FISMA Act is a set of guidelines for selecting and specifying security controls for information systems that process, store, or transmit Federal information. The Act references that NIST publishes Special Publications as important updates that should be referred to.
NIST 800-53 is specifically pointed towards as a reference for how to select controls and what it is that you need to implement for your systems. NIST 800-53 expects the important element of risk assessment to determine which controls apply, to what degree they should be applied, and what areas specifically should be considered.
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).
21.2 Introduction
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 architecture has its own discrete security methodology.
Security architecture composes its own discrete views 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 skills and competencies of the enterprise and IT architects.
21.3 Guidance on Security for the Architecture Domains
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:
Authentication: The substantiation of the identity of a person or entity related to the enterprise or 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 systems have been used in accordance with stated security policies.
Assurance: The ability to test and prove that the enterprise architecture has the security attributes required to uphold the stated security policies.
Availability: The ability of the enterprise 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 enterprise, and add or change the persons or entities related to the systems.
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.)
Typical security architecture artifacts would include:
Business rules regarding handling of data/information assets
Written and published security policy
Codified data/information asset ownership and custody
Risk analysis documentation
Data classification policy documentation
21.4 ADM Architecture Requirements Management
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:
A new statutory or regulatory mandate
A new threat realized or experienced
A new IT architecture 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 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.
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 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.
21.5 Preliminary Phase
Scope the enterprise organizations impacted by the security architecture
Identify core enterprise (units) – those who are most affected and achieve most value from the security work
Identify soft enterprise (units) – those who will see change to their capability and work with core units but are otherwise not directly affected
Identify extended enterprise (units) – those units outside the scoped enterprise who will need to enhance their security architecture for interoperability purposes
Identify communities involved (enterprises) – those stakeholders who will be affected by security capabilities and who are in groups of communities
Identify the security governance involved, including legal frameworks and geographies (enterprises)
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.
Define and document applicable regulatory and security policy requirements
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.
Define the required security capability as part of Architecture Capability
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.
Implement security architecture tools
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.
21.5.1 Security Inputs
Written security policy
Relevant statutes
List of applicable jurisdictions
21.5.2 Security Outputs
List of applicable regulations
List of applicable security policies
Security team roster
List of security assumptions and boundary conditions
21.6 Phase A: Architecture Vision
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.
Obtain management support for security measures
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.
Define necessary security-related management sign-off milestones of this architecture development cycle
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.
Determine and document applicable disaster recovery or business continuity plans/requirements
Any existing disaster recovery and business continuity plans must be understood and their relationship with the planned system defined and documented.
Identify and document the anticipated physical/business/regulatory environment(s) in which the system(s) will be deployed
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).
Determine and document the criticality of the system: safety-critical/mission-critical/non-critical
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.
21.6.1 Security Inputs
List of applicable security policies
List of applicable jurisdictions
Complete disaster recovery and business continuity plans
21.6.2 Security Outputs
Physical security environment statement
Business security environment statement
Regulatory environment statement
Security policy cover letter signed by CEO or delegate
List of architecture development checkpoints for security sign-off
List of applicable disaster recovery and business continuity plans
Systems criticality statement
21.7 Phase B: Business Architecture
Determine who are the legitimate actors who will interact with the product/service/process
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.
Assess and baseline current security-specific business processes (enhancement of existing objective)
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.
Determine whom/how much it is acceptable to inconvenience in utilizing security measures
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.
Identify and document interconnecting systems beyond project control
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.
Determine the assets at risk if something goes wrong – “What are we trying to protect?”
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.
Determine the cost (both qualitative and quantitative) of asset loss/impact in failure cases
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.
Identify and document the ownership of assets
Assets may be owned by outside entities, or by inside entities. Inside entities may be owned by individuals or by organizations. Determine:
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.
Determine and document appropriate security forensic processes
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.
Identify the criticality of the availability and correct operation of the overall service
The risks associated with loss of availability may have already been adequately considered in the foregoing mission-critical/safety-critical assessment.
Determine and document how much security (cost) is justified by the threats and the value of the assets at risk
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.
Reassess and confirm Architecture Vision decisions
Business analysis involves a number of rigorous thought exercises and may call into question the initial assumptions identified in the Architecture Vision.
Assess alignment or conflict of identified security policies with business goals
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).
Determine “what can go wrong?”
Perform a threat analysis that identifies the high-level threats bearing upon the system and their likelihood.
21.7.1 Security Inputs
Initial business and regulatory security environment statements
List of applicable disaster recovery and business continuity plans
List of applicable security policies and regulations
21.7.2 Security Outputs
List of forensic processes
List of new disaster recovery and business continuity requirements
Validated business and regulatory environment statements
List of validated security policies and regulations
List of target security processes
List of baseline security processes
List of security actors
List of interconnecting systems
Statement of security tolerance for each class of security actor
Asset list with values and owners
List of trust paths
Availability impact statement(s)
Threat analysis matrix
21.8 Phase C: Information Systems Architectures
Assess and baseline current security-specific architecture elements (enhancement of existing objective)
A full inventory of architecture elements that implement security services must be compiled in preparation for a gap analysis.
Identify safe default actions and failure states
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.
Identify and evaluate applicable recognized guidelines and standards
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.
Revisit assumptions regarding interconnecting systems beyond project control
In light of the risk assessments performed, assumptions regarding interconnecting systems may require modification.
Determine and document the sensitivity or classification level of information stored/created/used
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.
Identify and document custody of assets
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.
Identify the criticality of the availability and correct operation of each function
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.
Determine the relationship of the system under design with existing business disaster/continuity plans
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.
Identify what aspects of the system must be configurable to reflect changes in policy/business environment/access control
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.
Identify lifespan of information used as defined by business needs and regulatory requirements
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.
Determine approaches to address identified risks:
Mitigate
Accept
Transfer
Avoid
There are several standard ways to address identified and quantified risk. The list above is not intended to be exhaustive for all approaches.
Identify actions/events that warrant logging for later review or triggering forensic processes
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.
Identify and document requirements for rigor in proving accuracy of logged events (non-repudiation)
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.
Identify potential/likely avenues of attack
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.
Determine “what can go wrong?”
21.8.1 Security Inputs
Threat analysis matrix
Risk analysis
Documented forensic processes
Validated business policies and regulations
List of interconnecting systems
New disaster recovery and business continuity requirements
21.8.2 Security Outputs
Event log-level matrix and requirements
Risk management strategy
Data lifecycle definitions
List of configurable system elements
Baseline list of security-related elements of the system
New or augmented security-related elements of the system
Security use-case models:
Normative models
Non-normative models
List of applicable security standards:
Protocols
Object libraries
Others …
Validated interconnected system list
Information classification report
List of asset custodians
Function criticality statement
Revised disaster recovery and business continuity plans
Refined threat analysis matrix
21.9 Phase D: Technology Architecture
Assess and baseline current security-specific technologies (enhancement of existing objective)
Revisit assumptions regarding interconnecting systems beyond project control
Identify and evaluate applicable recognized guidelines and standards
Identify methods to regulate consumption of resources
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.
Engineer a method by which the efficacy of security measures will be measured and communicated on an ongoing basis
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.
Identify the trust (clearance) level of:
All users of the system
All administrators of the system
All interconnecting systems beyond project control
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.
Identify minimal privileges required for any entity to achieve a technical or business objective
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.
Identify mitigating security measures, where justified by risk assessment
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.
Determine “what can go wrong?”
21.9.1 Security Inputs
List of security-related elements of the system
List of interconnected systems
List of applicable security standards
List of security actors
Risk management strategy
Validated security policies
Validated regulatory requirements
Validated business policies related to trust requirements
21.9.2 Security Outputs
Baseline list of security technologies
Validated interconnected systems list
Selected security standards list
Resource conservation plan
Security metrics and monitoring plan
User authorization policies
Risk management plan
User trust (clearance) requirements
21.10 Phase E: Opportunities & Solutions
Identify existing security services available for re-use
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.
Evaluate tested and re-usable security software and security system resources
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.
Identify new code/resources/assets that are appropriate for re-use
Populate the Architecture Repository with new security building blocks.
Determine “what can go wrong?”
21.11 Phase F: Migration Planning
Assess the impact of new security measures upon other new components or existing leveraged systems
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.
Implement assurance methods by which the efficacy of security measures will be measured and communicated on an ongoing basis
During the operational phases, mechanisms are utilized to monitor the performance of many aspects of the system. Its security and availability are no exception.
Identify correct secure installation parameters, initial conditions, and configurations
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.
Implement disaster recovery and business continuity plans or modifications
Determine “what can go wrong?”
21.12 Phase G: Implementation Governance
Establish architecture artifact, design, and code reviews and define acceptance criteria for the successful implementation of the findings
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.
Implement methods and procedures to review evidence produced by the system that reflects operational stability and adherence to security policies
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:
Review system configurations with security impact which can be modified to ensure configuration changes have not compromised security design
Audit the design, deployment, and operations against security policies
Audit the design, deployment, and operations against business objectives
Run test cases against systems to ensure the security systems have been implemented as designed
Run disaster recovery tests
Run business continuity tests
Implement necessary training to ensure correct deployment, configuration, and operations of security-relevant subsystems and components; ensure awareness training of all users and non-privileged operators of the system and/or its components
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.
Determine “what has gone wrong?”
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.
21.13 Phase H: Architecture Change Management
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.
Determine “what has gone wrong?”
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.
Incorporate security-relevant changes to the environment into the requirements for future enhancement (enhancement of existing objective)
Changes that arise as a result of a security problem or new security technology will feed into the Requirements Management process.
21.14 References
NIST 80018: Guide for Developing Security Plans for Information Technology Systems
NIST 80027: Engineering Principles for Information Technology Security (A Baseline for Achieving Security)
NIST 80030: Guide for Risk Management for Information Technology Systems
