|
|
| Line 26: |
Line 26: |
| | |} </div></div> | | |} </div></div> |
| | | | |
| − | {{TOCright}} | + | {{Delete|reason=Expired Content}} |
| − | | |
| − | == Overview of Requirements Traceability ==
| |
| − | Project teams should always use a requirements traceability matrix (RTM) or security requirements traceability matrix (SRTM) to document and trace system security requirements. In large projects, project teams should strongly consider using a commercial requirements management product.
| |
| − | | |
| − | In addition, project managers should always designate a member of the project team to act as the requirements analyst for the duration of the project. In The Requirements Engineering Handbook, Ralph R. Young describes the requirements analyst as a person who works collaboratively with business owners, users, systems architects, and system designers to identify the requirements for a planned information system implementation. By designating a requirements analyst, project teams establish a single point of contact for collecting and coordinating the treatment of both system and system security requirements throughout the life of the project, thus greatly increasing the odds of a successful implementation.
| |
| − | | |
| − | As part of the GC Enterprise Security Architecture definition, a set of requirements has been established. ESA system requirements capture the [http://www.gcpedia.gc.ca/gcwiki/images/1/17/GC_ESA_Vision_and_Strategy.pdf GC ESA Vision and Strategy] and are derived from GC instruments, and industry standards. Requirements are identified as function or non-functional, and allocated to the appropriate Enterprise Security Focus Area (ESFA).
| |
| − | | |
| − | The ESA system requirements make broad statements about the capabilities, operation, and management of an ESA-compliant system. They are categorized as follows:
| |
| − | * '''Technical:''' Requirements that primarily identify technical capabilities of the system that must be developed or updated and implemented
| |
| − | * '''Policy:''' Requirements that primarily identify policy instruments that must be developed or updated and implemented
| |
| − | * '''People and Process:''' Requirements that primarily identify day-to-day operational procedures that must be developed or updated and implemented
| |
| − | Some system requirements include a sub-category that narrows the focus of those requirements. The system requirements consist of a subset of top-level requirements that are common to all ESFAs, whereas other are focused on a single ESFA. The requirement ID for a top-level requirement is prefixed with "ESA" whereas an ESFA-specific requirement ID is pre-fixed with the ESFA trigraph.
| |
| − | === ''Requirements Matrix Format Description'' ===
| |
| − | * '''Requirement (Req.) ID''' – All security requirements (SR) would be given an appropriate prefix to differentiate them from requirement gathered by and focused on the interests of the business. For ESA system requirements, the following nomenclature is used: xxx-yyyy, xxx represents the ESFA, yyyy represent a unique numeric identifier.
| |
| − | * '''Requirement Description''' – All SRs would be described in this field according to pre-established rules and guidance on how to write "good requirements"
| |
| − | * '''Date''' – This is the date when the SR was collected or elicited
| |
| − | * '''Source''' – The source of the requirement by document or stakeholder name
| |
| − | * '''Requirement Type''' – Functional, non-functional, constraints, and "others" to be completed by an analyst or architect as an adjunct to the SR description provided
| |
| − | * '''Stakeholder Priority''' – Rated from 1-5, where 1 is "most important", all SRs derived from stakeholders should be assigned a value
| |
| − | * '''Notes''' – Comments on SR history, questions to resolve, feasibility, and other notes to be recorded over time
| |
| − | * '''Changes''' – If the SR is amended, the changes, including original text and date of change, should be noted in this field or as a link to an SR Change Log.
| |
| − | {| class="wikitable" border="1"
| |
| − | |+ Example of an ESA Requirement Baseline Attributes
| |
| − | |-
| |
| − | !Req. ID
| |
| − | !Requirement Description
| |
| − | !Date
| |
| − | !Source
| |
| − | !Type
| |
| − | !Stakeholder Priority
| |
| − | !Notes
| |
| − | !Changes
| |
| − | |-
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | |}For more information about Requirements Traceability, please read the [http://www.gcpedia.gc.ca/gcwiki/images/5/59/DRAFT_GC_ESA_Framework.pdf GC ESA Framework].
| |
| − | | |
| − | <br>
| |
| − | | |
| − | ==Security Requirements Traceability Matrix (SRTM)==
| |
| − | As identified in [https://www.cse-cst.gc.ca/en/node/265/html/22839 Annex 2 of ITSG-33 - IT Security Risk Management: A Lifecycle Approach], a [[Media:GC ESADD Security Requirements Traceability Matrix (SRTM).xlsx|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. [https://www.cse-cst.gc.ca/en/node/265/html/22839 Annex 2 of ITSG-33] identifies how an SRTM can be used, including:
| |
| − | *To document business needs for security and trace their correspondence with the departmental objectives that they satisfy;
| |
| − | *To document system security controls and trace their correspondence to the business needs for security and other applicable high-level requirements that they satisfy;
| |
| − | *To trace design specifications to their corresponding system security controls and to trace system security controls to the threats that they counter; and
| |
| − | *To trace security mechanisms to their corresponding system security controls and to trace system security mechanisms to the threats that they counter.
| |
| − | 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.
| |
| − | ===''SRTM Format Description''===
| |
| − | *'''Req. ID''' – The ESA System Requirement ID, xxx-yyyy, xxx represents the ESFA, yyyy represents a unique numeric identifier.
| |
| − | *'''Requirement Description''' – Defines the ESA System Requirement for the given ESFA.
| |
| − | *'''Associated Controls''' – Identifies the security controls, including enhancements and other compensatory controls specific to the project or program
| |
| − | *'''Components''' – Identifies the enterprise Components where the system Requirement is to be met.
| |
| − | *'''Pattern ID''' – Identifies the Pattern ID(s) where the Component(s) reside in context of the given system Requirement.
| |
| − | *'''Rationale''' – Explain the selection of controls in summary or detail as applicable. It could also be used for qualifying remarks.
| |
| − | *'''Dependencies''' – List of specific controls or the identified Req. ID if they depend on other system requirements and associated controls for fulfillment in architecture or operations
| |
| − | *'''Notes''' – Comments on any related issues, implementation priority, and other matters
| |
| − | *'''Optional Attributes:'''
| |
| − | **''Rationalized Security Requirement Number –'' A sub-set of rationalized security requirements (RSRs) created if scoping and consolidation of initial SRs results in redundancy of SRs, unclear overlaps, or simply too many SRs to be addressed in a reasonable manner in architecture
| |
| − | **''Architecture Domains'' – If an SR is applicable to multiple domains or domains other than security, those domains should be noted in this field
| |
| − | **''Document'' – Used as the project or program progresses to demonstrate where SRs are included and addressed in architecture or detailed design documents, by name and relevant section
| |
| − | **''Test'' – Used to trace SRs to relevant test cases or SA&A steps and tasks
| |
| − | {| class="wikitable" border="1"
| |
| − | |+ Example of a Security Requirements Traceability Matrix
| |
| − | |-
| |
| − | !Req. ID
| |
| − | !Requirement Description
| |
| − | !Associated Controls
| |
| − | !Pattern ID
| |
| − | !Components
| |
| − | !Rationale
| |
| − | !Dependencies
| |
| − | !Notes
| |
| − | |-
| |
| − | |EUD-0140
| |
| − | |Where warranted based on TRA, an ESA compliant EUD shall provide appropriate roots-of-trust (e.g., hardware and/or software).
| |
| − | |SI-7(3),SI-7(10),SI-7(11),SI-7(13)
| |
| − | |PA-EUD-001, PA-EUD-007
| |
| − | |EUD::Root of Trust,EUD::Security Mgmt.
| |
| − | |BIOS integrity measurement and validation functionality
| |
| − | |
| |
| − | |
| |
| − | |}As part of the ESA Program, an SRTM linked to the Use Cases, Patterns and security controls can be found in the [http://www.gcpedia.gc.ca/gcwiki/images/1/19/GC_ESADD_Security_Requirements_Traceability_Matrix_%28SRTM%29_%28Jan_2016%29.xlsx GC ESADD Security Requirements Traceability Matrix (SRTM)] document. For more information about the Security Requirements Traceability Matrix, please read the [[Media:GC ESA Framework.pdf|GC ESA Framework]].
| |
| − | | |
| − | <br>
| |
| − | | |
| − | ==Security Controls Mapping Matrix (SCMM)==
| |
| − | [[Media:GC ESADD Security Controls Mapping Matrix (SCMM).xlsx|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 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. The primary user of the SCMM is a Security Assessment and Authorization (SA&A) support specialist to ensure that all tailored security controls are allocated to components or mitigated by some other means. The SANS “Top 20” controls lists may also be used to prioritize development tasks if necessary. The SCMM is an important artifact in the development of an independent security assessment plans and, together with a Plan of Action and Milestones (POA&M), an important artifact in the authorization package.
| |
| − | | |
| − | The following table provides an example of an SCMM. Using a tool and repository/database would help facilitate the management of both the SRTM and SCMM.
| |
| − | ===''SCMM Format Description''===
| |
| − | *'''Security Control''':
| |
| − | **''Control ID'' – All security controls, but consolidating control numbers and security control attributes from the current SCMM into one attribute that is still sortable
| |
| − | **''Enhancements'' – As required by [https://www.cse-cst.gc.ca/en/publication/itsg-33 ITSG-33] and necessary based on possible project- or program-specific supplements
| |
| − | **''Control Name'' – As required by [https://www.cse-cst.gc.ca/en/publication/itsg-33 ITSG-33]
| |
| − | *'''Pattern ID''' – Identifies the Pattern ID associated with the Security Control.
| |
| − | *'''Component within the Pattern''' – Identifies the enterprise Component associated with the given Security Control.
| |
| − | *'''Potential Mechanisms''' – Identifies potential security capabilities for the Component that could be used to meet the desired intent of the Security Control in context of the identified Pattern.
| |
| − | *'''Rationale''' – Describes the rationale as to why the particular Security Control was selected against the Component in context of the identified Pattern ID.
| |
| − | *'''Req. IDs''' – List of ESA System Requirements tied to the given Security Control.
| |
| − | *'''Optional Attributes:'''
| |
| − | **''Security Control Profile(s)'' – Reference to the appropriate ITSG-33 suggest organizational security control profile(s) or departmental or program security control profile if available
| |
| − | **''Family –'' As required by [https://www.cse-cst.gc.ca/en/publication/itsg-33 ITSG-33], families of controls help to logically associate various controls for review and consideration during architecture
| |
| − | **''Stability'' – Stability of the identified controls and mechanisms can vary and should be noted, marked as High, Medium, and Low, with appropriate notes in the Notes field.
| |
| − | {| class="wikitable" border="1"
| |
| − | |+ Example of a Security Control Mapping Matrix
| |
| − | |-
| |
| − | ! Security Control
| |
| − | ! Control Name
| |
| − | ! Pattern ID
| |
| − | ! Component within the Pattern
| |
| − | ! Potential Mechanisms
| |
| − | ! Rationale
| |
| − | ! Req. IDs.
| |
| − | |-
| |
| − | | SI-7(3)
| |
| − | | SOFTWARE AND INFORMATION INTEGRITY
| |
| − | | PA-EUD-001
| |
| − | | EUD:: Root of Trust
| |
| − | | Digital Signature, HW Token/HW Signature
| |
| − | | Ensure integrity of the device
| |
| − | | EUD-0175, EUD-0429
| |
| − | |}For more information about the Security Control Mapping Matrix, please read the [[Media:GC ESA Framework.pdf|GC ESA Framework]].
| |
| − | | |
| − | <br>
| |
| − | | |
| − | == References ==
| |
| − | * [[Media:GC ESA Framework.pdf|GC ESA Framework]]
| |
| − | * [http://www.gcpedia.gc.ca/gcwiki/images/1/17/GC_ESA_Vision_and_Strategy.pdf GC ESA Vision and Strategy]
| |
| − | * [[Media:GC ESADD Security Requirements Traceability Matrix (SRTM).xlsx|Security Requirements Traceability Matrix (SRTM)]]
| |
| − | * [[Media:GC ESADD Security Controls Mapping Matrix (SCMM).xlsx|Security Controls Mapping Matrix (SCMM)]]
| |
| − | * [https://www.cse-cst.gc.ca/en/publication/itsg-33 ITSG-33 - IT Security Risk Management: A Lifecycle]
| |
| − | | |
| − | [[Category:Enterprise Security Architecture]]
| |
