ESA Requirements
ESA Architectural Needs and Requirements Overview
ESA activities are driven by two sets of needs: Architectural Needs and Operational Needs. Both types of needs are written in an informal style to capture intent and are not intended to act as, or replace, formal testable requirements. Needs are typically high-level descriptions covering areas such as goals, desires, constraints, and directives from both an architectural and operational perspective. Formal testable system requirements will be derived from the operational needs.
Architectural Needs
Architectural Needs are applicable GC-wide and are not specific to any initiative. They identify essential characteristics of the target GC Enterprise IT/IS Infrastructure as it undergoes transformation from its current state:
- Overarching concepts that are defined at a high enough level to be applicable GC-wide. Technical concepts include support for GG-wide consolidation, interoperability (internal and external), and hierarchical situational awareness. Non-technical concepts include risk management, supply chain integrity, and security awareness training.
- Guiding principles, in the form of laws, regulations, policy instruments, and government publications (such as Blueprint 2020), that define the desired approach to securing the GC Enterprise IT/IS Infrastructure. These artifacts may also identify constraints, particularly in the area of protecting the privacy of GC workers and other Canadian citizens.
The GC ESA Architectural Needs are not intended to act as a complete set of drivers, but rather to provide direction when developing the GC Enterprise Security Architecture Description Document (ESADD) and its supporting annexes.
Operational Needs
Operational Needs are developed in response to initiatives created by the IT Security Tripartite. They capture the key desires that motivated the creation of the initiative. Any Operational Needs that state initiative-specific architectural needs should be consistent with any overarching Architectural Needs. Like Architectural Needs, Operational Needs are not intended to be a comprehensive set of drivers. They guide development of the Operational Concept (OpsCon) document for the initiative and, where required, an initiative-specific reference design captured in the associated High-Level Design (HLD) document. An Implementation Strategy (IS) may also be developed that defines a set of implementation phases over which the Operational Needs will be met.
The needs analysis documented in the OpsCon results in the creation of a set of initiative-specific system functions and system requirements that provide a comprehensive decomposition of the Operational Needs. The system requirements are formal statements (“shall” statements) that identify the required functional, performance, and security capabilities of the system to be developed, together with any constraints. The system requirements are not only technical in nature; they also address policy changes, operational procedures, and other non-technical aspects necessary to develop a complete operational solution. The system requirements should be complete, unambiguous, and testable.
As more initiatives are developed, the set of system requirements is expanded. The set of Architectural Needs are associated architectures are refined and/or expanded to provide improved guidance for future initiatives. This results in an iterative process of continuous improvement. The output from the HLD is a set of HLD Requirements that can be used in acquisition documents, design specifications and product evaluations. Like the system requirements, the HLD Requirements should be complete, unambiguous, and testable. The reference design documented in the HLD may also be included in acquisition documents. The initiative components and design patterns that comprise the reference design are vendor-neutral but are derived from an analysis of vendor offerings. This ensures that an implementation is feasible and enables vendors to relate their product offerings to the reference design.
Any deployed system or subsystem must be assessed against a set of tailored security controls as part of the risk assessment process. As part of the HLD development process, security controls are allocated to initiative components and design patterns. This activity is guided by the allocation of security control to ESA components and architectural patterns defined in the ESADD. As the HLD represents a reference design, the selection and allocation of security controls to initiative components and design patterns must be tailored based on the target operational environment, detailed design, and selected product capabilities when a solution is procured.
The GC ESA System Requirements Traceability Matrix (SRTM) captures the system requirements that have been developed for the various initiatives and includes associated object traceability information. The GC ESA Security Controls Mapping Matrix (SCMM) lists parent security controls that have associated traceability information.
For more information and details about the ESA Architectural Needs and Requirements, please read the GC ESA Requirements Database Overview document.