ESA Framework
Introduction
The purpose of the GC Enterprise Security Architecture (ESA) Framework document is to provide an overview of the architecture framework, which describes the "how we are doing this" aspect from an architecture perspective. Any framework is intended to present a hypothetical description of a complex system or processes in a common, rationalized and approachable manner. The GC ESA Framework brings together a number of elements to provide a foundation for developing GC enterprise IT security architectures and blue prints. These elements include a common taxonomy, best practices, recommended standards, and templates/tools to help guide and support security practitioners. The goal of the GC ESA Framework is to enable security practitioners to design, evaluate, and build the right systems and processes for their organization.
For more information about the purpose and benefits of the GC ESA Framework, please read the GC ESA Framework document. For more information about the ESA Program, please read the GC ESA Program Overview page.
Alignment with GC Enterprise Architecture Framework (GCEAF)
The GC Enterprise Architecture (GCEA) Framework is an overarching structure that is comprised of five (5) components that are key to the overall management of enterprise architecture within the GC. They are shown in the image on the right.
Part of the GCEAF includes an enterprise architecture model that provides common language and a common understanding of the top-level architectural constructs. This model forms the basis for the architectural artifacts that will be developed to describe IT-enabled solutions and capabilities. It is through these architectural products that alignment is demonstrated with departmental program-driven and GC enterprise priorities and direction.
Various architectural viewpoints are required to effectively describe IT-enabled business solutions. A viewpoint provides insight into these IT-enabled solutions from a specific perspective. These viewpoints include: Business, Information, Application, and Technology (BIAT) with Security and Privacy as cross-cutting concerns. As shown in the image on the left, the GC ESA supports the Security viewpoint that spans all other enterprise architecture domains. The GC ESA integrates with the GCEAF and follows a whole-of-government and business driven approach. It ensures that IT security risk management is applied from an enterprise perspective. The IT Security Tripartite (ITST) supports the GC Architecture Review Board (GCARB) in evaluating the business to the GC, while ensuring that solutions are designed with the appropriate selection of security controls and are aligned with GC IT security strategies. For more information on how the GC ESA Framework aligns with the GCEAF, please read the GC ESA Framework.
ESA Viewpoint
To ensure the needs of the enterprise are completely met and security services are designed, delivered, and supported as an integral part of the business and IT management infrastructure, a model and methodology are required for developing enterprise security architectures and for delivering security infrastructure solutions that support critical business initiatives. It must be derived from an analysis of the business requirements for security, especially those in which security has an enabling function through which new business opportunities can be developed and exploited. The image below provides an overview of the GC ESA Viewpoint. For more information about the ESA Viewpoint, please read the GC ESA Framework.
Alignment with SABSA
One approach to developing enterprise security architectures is outlined by the Sherwood Applied Business Security Architecture (SABSA) framework. It can be used to make security relevant to all stakeholders within an organization. SABSA introduces a layered approach to architecture where each layer corresponds to a different stakeholder's view within the organization as it relates to specifying, designing, constructing, and operating a security architecture. The ESA program is primarily focused on the contextual (business view) and conceptual (security architect view) architectures that are mainly driven by GC strategic objectives. For common or GC priority initiatives, the ESA program will provide guidance on the logical, physical and component architectures. For more information on how the ESA program aligns with the SABSA Model, please read the GC ESA Framework.
Requirements Management
Requirements management plays a central role in successful architecture development. As per the Policy on Government Security (PGS), TBS is responsible for setting government-wide direction, establishing priorities, and defining and formalizing security and identity management requirements for the GC and departments. Requirements must be analysed at the outset of any ESA project to understand and meet business needs.
The proposed approach provides an overview of how security requirements will be managed for the GC Enterprise IT security architecture “enterprise continuum.” Objectives include:
- To develop a process for identifying and managing IT security requirements and ensuring alignment with business and IT
- To develop GC security control profiles that are aligned with GC security policy and enterprise objectives, and establish a minimum baseline security control profile for the GC
- To provide a requirements traceability methodology to ensure that requirements have been satisfied, that the selected controls are robust, and to identify any gaps and dependencies that need to be addressed, and
- To adopt a pattern-based approach that will provide reusable designs and capture the allocation of security controls and required enterprise component.
In the GC ESA project, it will be critical that security requirements are fully documented and addressed during design, development, and implementation of the information system. This can result in security requirements that are mapped to specific controls in a one-to-one or one-to-many relationship. The ESA program will also help to identify a set of security controls that can be incorporated into policy and will help to establish a minimum baseline for all systems. The adoption of a pattern-based approach will also enable the incorporation of security requirements into reusable designs that visually depict the allocation of relevant security controls. Security patterns provide guidelines for the construction of secure system designs and help to bridge the gap between the requirement phase and the design phase. Overall, the image on the right summarizes the framework. For more information about the framework for security requirements, please read the GC ESA Framework.
Sources of Security Requirements
Open Security Architecture defines IT Security Requirements as those “functional and non-functional requirements that need to be satisfied in order to achieve the security attributes of an IT system.” Requirements are derived from various sources “to ensure the confidentiality, integrity, and availability of the information being processed, stored, or transmitted.”
Sources of security requirements include:
- Legislation/policy instruments,
- Business drivers/needs,
- Threat information, and
- Best practices and industry standards.
Additional sources include risk assessments where specific risk mitigation requirements are identified, and other projects or program requirements which are interdependent with security requirements or have an impact on ESA development. For more information about the sources of security requirements, please read the GC ESA Framework.
Security Controls
Security controls address requirement and provide a measure for managing security level of assurance. Security controls are defined in Communications Security Establishment's (CSE) ITSG-33 - IT Security Risk Management: A Lifecycle Approach as "a management, operational, or technical security functional requirement prescribed for an information system to protect the confidentiality, integrity, and availability of its IT assets." Annex 3 of the ITSG-33 contains definitions of security controls that security practitioners can use as a foundation for selecting controls for the protection of GC information system and managing IT security risks.
CSE further groups security controls into two categories, operating environment security controls and information system security controls, as shown in the image on the right. Operating environment security controls are predominantly management or operational in nature and are implemented through programs, policies, or procedures at the departmental level. Information system security controls are further subdivided into technology-related control elements and procedural-related control elements.
To help ensure that selected and implemented controls are sufficient to mitigate risks to organizational operations and assets, the National Institute of Standards and Technology's NIST Special Publication 800-53, Revision 4: Security and Privacy Controls for Federal Information Systems and Organizations introduces the concept of overlays. An overlay provides a set of security controls, control enhancements, and supplemental guidance for community-wide use or to address specialized requirements, technologies, or unique missions and environments of operation. Overlays complement initial security control baselines and:
- Provide the opportunity to add or eliminate controls;
- Provide security control applicability and interpretations;
- Establish community-wide parameter values for assignment and/or selection statements in security controls and control enhancements; and
- Extend the supplemental guidance for security controls, where necessary.
Multiple overlays can be applied to a single security control baseline. The tailored baselines that result from the overlay development process may be more or less stringent than the original security control baselines. Risk assessments provide information necessary to determine if the risk from implementing the tailored baselines falls within the risk tolerance of the organizations or communities of interest developing the overlays.
Requirements Refinement
In a GC ESA project, there will be a need to gather and use clear and unambiguous Security Requirements (SR) in all stages of architecture, design, testing, and deployment. Key stages in SR gathering and refinement are shown in the image on the right. Subsequent assessments of project or program success may also draw on SRs.
Security practitioners, including enterprise security architects, will need to participate in the overall requirements collection process and specifically:
- Identify the security problem space;
- Identify types of information needed and available as inputs to Security Requirements both generically within the GC and specific to the project or program;
- Identify the appropriate stakeholder subset for interview or consultation in SR collection or validation;
- Identify qualifying and qualitative criteria for security requirements (SR);
- Analyze other collected requirements to identify security requirements (SRs);
- Rationalize and prioritize SRs using business needs, stakeholder input, GC security guidance, and best practices; and
- Map rationalized SRs to security controls, patterns, and use cases to be written into one or more architecture description documents.
Architecture Development Approach
The following sections provide additional information to support the development of the ESA work activities:
Actors
As defined by The Open Group Architecture Framework (TOGAF), an actors is "a person, organization, or system that has a role that initiates or interacts with activities." Actors may be internal or external to an organization. The GC ESA Concept of Operations (ConOps) document defines a set of notional enterprise actors.
Components
Architectural components represent collections of security and enterprise IT functionality or capabilities. Each component defines a logical set of tightly-related functions that may be implemented by one or more hardware and software components. The proposed GC enterprise components are mapped to the enterprise security focus areas (ESFAs). Each ESFA decomposes into architectural components that represent collections of security and enterprise functionality.
Use Cases and Patterns
As outlined by MITRE, a use case is a description of a system's behaviour as it responds to a request that originates from outside of that system. It describes "who" interacts with "what" for the system in question and allows a system's behavioural requirements to be captured as scenarios that trace back to requirements. Use cases are ideally generated from the System Concept of Operations (ConOps) and are decomposed into one or more detailed scenarios that assist in the identification or creation of an applicable pattern.
An ESA pattern is simply a description of a reusable solution to a problem. Patterns must include a description of the content and problem addressed by the pattern.
Requirements Traceability Matrices
As identified in Annex 2 of ITSG-33 - IT Security Risk Management: A Lifecycle Approach, the Security Requirements Traceability Matrix (SRTM) can be a suitable tool when security assurance requirements call for tracing the correspondence between an information system's successive requirements and design specifications. The development of an SRTM focusing on the GC enterprise will help to identify a set of security controls that all systems must meet to ensure a consistent security profile across the GC.
The Security Controls Mapping Matrix (SCMM) is a tool that maps security controls to existing or planned enterprise components. The SCMM and associated ESA Definition Document (ESADD) artifacts are the "blueprint" for defining and assessing security compliance, and determining resulting security risk. The SCMM is also used to drive risk assessment in a rigorous manner, with the primary user of it being a security assessment and authorization support specialist who ensures that all tailored security controls are allocated to components or mitigated by some other means.
Target and Transition Architectures
The Open Group Architecture Framework (TOGAF) defines target architecture as “the description of a future state of the architecture being developed for an organization.” There may be several future states developed as a roadmap to show the evolution of the architecture to a target state. It defines the components or building blocks that make up the overall information system, and provides a plan from which products can be procured and systems developed that will work together to implement the overall system. The ESA Program will provide target reference architectures and models to enable an enterprise-wide IT security architecture that is aligned with GC enterprise strategies.
A Transition Architecture is a formal description of one state of the architecture at an architecturally significant point in time. Each transition state provides a clear milestone with measurable business value. Transition strategies outline an incremental approach to evolve from the current state to the target architecture based on GC priorities, major enterprise initiatives, and the availability of mature technical solutions.
For more information about target and transition architectures, please read the GC ESA Framework.
Context-Specific Architectures
Context-specific architectures are developed to meet business or operational outcomes. The building blocks that will be developed under the GC enterprise security architecture definition activities will support the development of more contextualized architectures. Using GC ESA target architectures as references will help to ensure alignment with overall GC strategic objectives. More detailed reference security architectures for various GC enterprise systems or contexts will be developed for GC common services or priority initiatives. For more information about context-specific architectures, please read the GC ESA Framework.
