802
edits
Changes
Jump to navigation
Jump to search
Created page with "<div class="center"><div style="float: right; z-index: 10; position: absolute; right: 0; top: 1;">File:JoinusonGCconnex.png|link=http://gcconnex.gc.ca/groups/profile/2785549..."
<div class="center"><div style="float: right; z-index: 10; position: absolute; right: 0; top: 1;">[[File:JoinusonGCconnex.png|link=http://gcconnex.gc.ca/groups/profile/2785549/gc-enterprise-security-architecture-gc-esa]]<br />[[File:ESAcontactus.png|link=mailto:ZZTBSCYBERS@tbs-sct.gc.ca]]</div>
[[File:GOC ESA.jpg|center|link=http://www.gcpedia.gc.ca/wiki/Government_of_Canada_Enterprise_Security_Architecture_(ESA)_Program]]
<div class="center">
{| style="border: 2px solid #000000; border-image: none;" width="1000px"
|-
! style="background: #e1caf7; color: black" width="20%" scope="col" " width="175px" | [[Government of Canada Enterprise Security Architecture (ESA) Program|ESA Program Overview]]
! style="background: #C495F0; color: black" width="20%" scope="col" " width="125px" | [[ESA Backgrounder (Strategy)|ESA Foundation]]
! style="background: #e1caf7; color: black" width="20%" scope="col" " width="125px" | [[ESA Requirements|ESA Artifacts]]
! style="background: #e1caf7; color: black" width="20%" scope="col" " width="125px" | [[ESA Initiatives|ESA Initiatives]]
! style="background: #e1caf7; color: black" width="20%" scope="col" " width="125px" | [[ ESA Tools and Templates]]
! style="background: #e1caf7; color: black" width="20%" scope="col" " width="125px" | [[GC ESA Artifact Repository|ESA Reference Materials]]
! style="background: #e1caf7; color: black" width="20%" scope="col" " width="100px" | [[ESA Glossary| Glossary]]
|}
{| style="border-bottom: #000000 2px solid; border-left: #000000 2px solid; border-right: #000000 2px solid" width="1000px"
|-
! style="background: #c2c2fa; color: black" width="25%" scope="col" " width="225px" | [[ESA Backgrounder (Strategy)| ESA Backgrounder]]
! style="background: #c2c2fa; color: black" width="25%" scope="col" " width="225px" | [[ESA Program Charter| ESA Program Charter]]
! style="background: #9a9af8; color: black" width="25%" scope="col" " width="325px" | [[ESA Program Implementation Framework| ESA Program Implementation Framework]]
! style="background: #c2c2fa; color: black" width="25%" scope="col" " width="225px" | [[ESA Framework| ESA Framework]]
|}
{| style="border-bottom: #000000 2px solid; border-left: #000000 2px solid; border-right: #000000 2px solid" width="1000px"
|-
! style="background: #d7d7d7; color: black" width="14%" scope="col" " width="225px" | [[ESA Program Processes]]
! style="background: #d7d7d7; color: black" width="14%" scope="col" " width="325px" | [[ESA Program Life Cycle Integration]]
! style="background: #d7d7d7; color: black" width="14%" scope="col" " width="225px" | [[Operational Scenarios]]
! style="background: #969696; color: black" width="14%" scope="col" " width="225px" | [[Foundational Disciplines]]
|}
</div></div>
{{TOCright}}
== Foundational Disciplines ==
The following sections will describe some of the strategies that help to implement the program to meet GC strategic objectives. To be successful at implementing dependable information systems, security needs to be integrated in the very fabric of IT project disciplines. These include project management, requirements engineering, the broader disciplines of systems and software engineering, system and software design, system development and software coding, and the various forms of testing and assurance.
For more information about this, please read the [http://www.gcpedia.gc.ca/gcwiki/images/2/20/GC_ESA_Program_Implementation_Framework.pdf GC ESA Program Implementation Framework].
== IT Project Management ==
Despite decades of practice, IT projects continue to fail to successfully implement information systems. Success is achieved when an IT project delivers an information system that fully satisfies stakeholder needs and requirements on time and on budget. While these are attainable objectives, many IT projects fail to achieve them. In the Why Projects Fail section of their web site, the International Project Leadership Academy has identified common classes of project failure. These include organizational and planning failures; leadership and governance failures; underestimation and analysis failures; and skills, knowledge, and competency failures.
A strong, mature project management practice is therefore a prerequisite to success. Furthermore, the practice must account for the activities, time, and cost of addressing security throughout the SDLC process, and project managers must ensure that the project team has the necessary competencies to complete the security work.
For their projects to be successful at implementing security, project managers must:
* Identify and engage security stakeholders. Key security stakeholders typically include the authorizer, the enterprise architect or enterprise security architect, and the security assessor. The authorizer is the individual or individuals who will be relying on the GC IT service being implemented to support their program or service delivery.
* Ensure that the appropriate security control profile and threat report are selected. The profile will include the baseline security controls to use as input to requirements engineering, the business needs for security that need to be satisfied by the security controls, and any security approaches that the IT project team must account for in the treatment of security controls and security design. The threat report will contain the threat data that the IT project team will require to resolve risk-based design and engineering problems.
* Integrate IT security activities to the project plan and schedule.
* Allocate sufficient funds, time, and resources to complete the IT security activities.
* Ensure through resourcing and training that the IT project team members have the necessary competencies to successfully complete the security activities.
* Liaise with the project governance entity such as a project steering committee and the authorizer to ensure timely approvals at scheduled project gates.
== System and Software Engineering ==
Because their objective is to implement information systems for stakeholders, IT projects cannot be successful without following some process to collect and understand stakeholder needs and requirements, translate these needs and requirements into specifications, and build an information system to these specifications.
The ISO standard on system life cycle processes (Systems and software engineering – System life cycle processes, ISO/IEC 15288) [5] describes system engineering life cycle processes for information systems. It does this by specifying a set of interdisciplinary processes by which stakeholder needs, requirements, and constraints are transformed into information system solutions and the resulting solutions are maintained over their life cycle. A system can consist of various components of hardware, software, data, people, processes, procedures, and facilities.
IT projects can therefore be successful at implementing information systems by following a systems engineering process. For the SDLC, ISO 15288 defines technical management processes and technical processes. The technical management processes consist of project planning, project assessment and control, decision management, risk management (project risks, not IT security risks), configuration management, information management, measurement, and quality assurance. The technical processes consist of business or mission analysis, stakeholder needs and requirements definition, system requirements definition, architecture definition (referred to as high-level design in the ITSG-33 ISSIP and this guide), design definition, system analysis, implementation (referred to as development in the ITSG-33 ISSIP and this guide), integration, verification, transition, and validation.
NOTE: IT projects may also consider the international standard on software lifecycle processes (System and software engineering – Software life cycle processes, ISO/IEC 12207) [6] for information systems that consist of custom software or that include a custom software component. ISO 12207 is aligned with ISO 15288 and can be used in conjunction to deliver all system and software components of a GC IT service.
== Requirements Engineering ==
Requirements engineering is the cornerstone of systems and software engineering. The internal standard on requirements engineering (System and software engineering – Life cycle processes – Requirements engineering, ISO/IEC 29148) defines requirements engineering as an “interdisciplinary function that mediates between the domains of the acquirer and supplier to establish and maintain the requirements to be met by the system, software, or service of interest.” According to ISO 29148, the requirements engineering process includes tasks for “discovering, eliciting, developing, analyzing, determining verification methods, validating, communicating, documenting, and managing requirements.”
Requirements engineering is therefore fundamental to the success of IT projects in satisfying stakeholder needs and requirements. To that end, ISO 29148 specifies several requirements engineering instruments consisting of the stakeholder requirements specification (StRS), the operational system concept (OpsCon); the system requirements specification (SyRS); and the software requirements specification (SRS).
NOTE: In the most recent version of ISO 29148 (29148:2015), the terms concept of operations (ConOps) and operational system concept (OpsCon) are defined. The OpsCon describes what the information system is expected to do, not how it is expected to do it. Its intent is to describe an information system’s characteristics from the point of view of the users, not from the point of view of the system and its operations as IT projects often do. The ConOps is defined as an instrument to capture how an organization’s leaders intend to operate their organization using existing and future information systems. As such, the ConOps is an instrument of enterprise architecture rather than an instrument for the implementation of specific information system solutions.
== Systems Security Engineering ==
Maturity in the systems engineering process is crucial not only for the overall success of IT projects but also as a foundation for the execution of system security engineering (SSE). For instance, an IT project that exhibits a low maturity in requirements engineering will most likely not have success in transforming security controls into system security requirements, and then validating the system security requirements through the various phases of the SDLC. IT projects can use the process assessment model of ISO 15504 (Information technology – Process assessment, ISO/IEC 15504) [7] to determine the maturity level of their systems engineering process. For the SSE process, the system security engineering capability maturity model in ISO 21827 (Information technology – Security techniques – Systems Security Engineering – Capability maturity model, ISO/IEC 21827) [8] defines a capability maturity model that IT projects can use to determine their maturity level for that discipline.
ISO 21827 shares with ISO 15288 the same objectives of being successful at meeting stakeholder needs and requirements but focuses on security needs and requirements and security assurance. According to ISO 21827, a mature SSE process includes activities to:
* Specify security needs and requirements;
* Assess threats, vulnerabilities, and risks;
* Support system design and development;
* Verify and validate security; and
* Build a security assurance argument.
Note: The ITSG-33 ISSIP incorporates the SSE process areas of ISO 21827, including the activities of the threat and risk assessment. This means that by following the ITSG-33 ISSIP, IT projects should be able to implement dependable information systems that satisfy applicable security needs and requirements and that are operating under accepted residual risk levels.
== References ==
* [http://www.gcpedia.gc.ca/gcwiki/images/2/20/GC_ESA_Program_Implementation_Framework.pdf GC ESA Program Implementation Framework]
[[Category:Government of Canada Enterprise Security Architecture (ESA) Program]]
[[Category:Enterprise Security Architecture]]
[[File:GOC ESA.jpg|center|link=http://www.gcpedia.gc.ca/wiki/Government_of_Canada_Enterprise_Security_Architecture_(ESA)_Program]]
<div class="center">
{| style="border: 2px solid #000000; border-image: none;" width="1000px"
|-
! style="background: #e1caf7; color: black" width="20%" scope="col" " width="175px" | [[Government of Canada Enterprise Security Architecture (ESA) Program|ESA Program Overview]]
! style="background: #C495F0; color: black" width="20%" scope="col" " width="125px" | [[ESA Backgrounder (Strategy)|ESA Foundation]]
! style="background: #e1caf7; color: black" width="20%" scope="col" " width="125px" | [[ESA Requirements|ESA Artifacts]]
! style="background: #e1caf7; color: black" width="20%" scope="col" " width="125px" | [[ESA Initiatives|ESA Initiatives]]
! style="background: #e1caf7; color: black" width="20%" scope="col" " width="125px" | [[ ESA Tools and Templates]]
! style="background: #e1caf7; color: black" width="20%" scope="col" " width="125px" | [[GC ESA Artifact Repository|ESA Reference Materials]]
! style="background: #e1caf7; color: black" width="20%" scope="col" " width="100px" | [[ESA Glossary| Glossary]]
|}
{| style="border-bottom: #000000 2px solid; border-left: #000000 2px solid; border-right: #000000 2px solid" width="1000px"
|-
! style="background: #c2c2fa; color: black" width="25%" scope="col" " width="225px" | [[ESA Backgrounder (Strategy)| ESA Backgrounder]]
! style="background: #c2c2fa; color: black" width="25%" scope="col" " width="225px" | [[ESA Program Charter| ESA Program Charter]]
! style="background: #9a9af8; color: black" width="25%" scope="col" " width="325px" | [[ESA Program Implementation Framework| ESA Program Implementation Framework]]
! style="background: #c2c2fa; color: black" width="25%" scope="col" " width="225px" | [[ESA Framework| ESA Framework]]
|}
{| style="border-bottom: #000000 2px solid; border-left: #000000 2px solid; border-right: #000000 2px solid" width="1000px"
|-
! style="background: #d7d7d7; color: black" width="14%" scope="col" " width="225px" | [[ESA Program Processes]]
! style="background: #d7d7d7; color: black" width="14%" scope="col" " width="325px" | [[ESA Program Life Cycle Integration]]
! style="background: #d7d7d7; color: black" width="14%" scope="col" " width="225px" | [[Operational Scenarios]]
! style="background: #969696; color: black" width="14%" scope="col" " width="225px" | [[Foundational Disciplines]]
|}
</div></div>
{{TOCright}}
== Foundational Disciplines ==
The following sections will describe some of the strategies that help to implement the program to meet GC strategic objectives. To be successful at implementing dependable information systems, security needs to be integrated in the very fabric of IT project disciplines. These include project management, requirements engineering, the broader disciplines of systems and software engineering, system and software design, system development and software coding, and the various forms of testing and assurance.
For more information about this, please read the [http://www.gcpedia.gc.ca/gcwiki/images/2/20/GC_ESA_Program_Implementation_Framework.pdf GC ESA Program Implementation Framework].
== IT Project Management ==
Despite decades of practice, IT projects continue to fail to successfully implement information systems. Success is achieved when an IT project delivers an information system that fully satisfies stakeholder needs and requirements on time and on budget. While these are attainable objectives, many IT projects fail to achieve them. In the Why Projects Fail section of their web site, the International Project Leadership Academy has identified common classes of project failure. These include organizational and planning failures; leadership and governance failures; underestimation and analysis failures; and skills, knowledge, and competency failures.
A strong, mature project management practice is therefore a prerequisite to success. Furthermore, the practice must account for the activities, time, and cost of addressing security throughout the SDLC process, and project managers must ensure that the project team has the necessary competencies to complete the security work.
For their projects to be successful at implementing security, project managers must:
* Identify and engage security stakeholders. Key security stakeholders typically include the authorizer, the enterprise architect or enterprise security architect, and the security assessor. The authorizer is the individual or individuals who will be relying on the GC IT service being implemented to support their program or service delivery.
* Ensure that the appropriate security control profile and threat report are selected. The profile will include the baseline security controls to use as input to requirements engineering, the business needs for security that need to be satisfied by the security controls, and any security approaches that the IT project team must account for in the treatment of security controls and security design. The threat report will contain the threat data that the IT project team will require to resolve risk-based design and engineering problems.
* Integrate IT security activities to the project plan and schedule.
* Allocate sufficient funds, time, and resources to complete the IT security activities.
* Ensure through resourcing and training that the IT project team members have the necessary competencies to successfully complete the security activities.
* Liaise with the project governance entity such as a project steering committee and the authorizer to ensure timely approvals at scheduled project gates.
== System and Software Engineering ==
Because their objective is to implement information systems for stakeholders, IT projects cannot be successful without following some process to collect and understand stakeholder needs and requirements, translate these needs and requirements into specifications, and build an information system to these specifications.
The ISO standard on system life cycle processes (Systems and software engineering – System life cycle processes, ISO/IEC 15288) [5] describes system engineering life cycle processes for information systems. It does this by specifying a set of interdisciplinary processes by which stakeholder needs, requirements, and constraints are transformed into information system solutions and the resulting solutions are maintained over their life cycle. A system can consist of various components of hardware, software, data, people, processes, procedures, and facilities.
IT projects can therefore be successful at implementing information systems by following a systems engineering process. For the SDLC, ISO 15288 defines technical management processes and technical processes. The technical management processes consist of project planning, project assessment and control, decision management, risk management (project risks, not IT security risks), configuration management, information management, measurement, and quality assurance. The technical processes consist of business or mission analysis, stakeholder needs and requirements definition, system requirements definition, architecture definition (referred to as high-level design in the ITSG-33 ISSIP and this guide), design definition, system analysis, implementation (referred to as development in the ITSG-33 ISSIP and this guide), integration, verification, transition, and validation.
NOTE: IT projects may also consider the international standard on software lifecycle processes (System and software engineering – Software life cycle processes, ISO/IEC 12207) [6] for information systems that consist of custom software or that include a custom software component. ISO 12207 is aligned with ISO 15288 and can be used in conjunction to deliver all system and software components of a GC IT service.
== Requirements Engineering ==
Requirements engineering is the cornerstone of systems and software engineering. The internal standard on requirements engineering (System and software engineering – Life cycle processes – Requirements engineering, ISO/IEC 29148) defines requirements engineering as an “interdisciplinary function that mediates between the domains of the acquirer and supplier to establish and maintain the requirements to be met by the system, software, or service of interest.” According to ISO 29148, the requirements engineering process includes tasks for “discovering, eliciting, developing, analyzing, determining verification methods, validating, communicating, documenting, and managing requirements.”
Requirements engineering is therefore fundamental to the success of IT projects in satisfying stakeholder needs and requirements. To that end, ISO 29148 specifies several requirements engineering instruments consisting of the stakeholder requirements specification (StRS), the operational system concept (OpsCon); the system requirements specification (SyRS); and the software requirements specification (SRS).
NOTE: In the most recent version of ISO 29148 (29148:2015), the terms concept of operations (ConOps) and operational system concept (OpsCon) are defined. The OpsCon describes what the information system is expected to do, not how it is expected to do it. Its intent is to describe an information system’s characteristics from the point of view of the users, not from the point of view of the system and its operations as IT projects often do. The ConOps is defined as an instrument to capture how an organization’s leaders intend to operate their organization using existing and future information systems. As such, the ConOps is an instrument of enterprise architecture rather than an instrument for the implementation of specific information system solutions.
== Systems Security Engineering ==
Maturity in the systems engineering process is crucial not only for the overall success of IT projects but also as a foundation for the execution of system security engineering (SSE). For instance, an IT project that exhibits a low maturity in requirements engineering will most likely not have success in transforming security controls into system security requirements, and then validating the system security requirements through the various phases of the SDLC. IT projects can use the process assessment model of ISO 15504 (Information technology – Process assessment, ISO/IEC 15504) [7] to determine the maturity level of their systems engineering process. For the SSE process, the system security engineering capability maturity model in ISO 21827 (Information technology – Security techniques – Systems Security Engineering – Capability maturity model, ISO/IEC 21827) [8] defines a capability maturity model that IT projects can use to determine their maturity level for that discipline.
ISO 21827 shares with ISO 15288 the same objectives of being successful at meeting stakeholder needs and requirements but focuses on security needs and requirements and security assurance. According to ISO 21827, a mature SSE process includes activities to:
* Specify security needs and requirements;
* Assess threats, vulnerabilities, and risks;
* Support system design and development;
* Verify and validate security; and
* Build a security assurance argument.
Note: The ITSG-33 ISSIP incorporates the SSE process areas of ISO 21827, including the activities of the threat and risk assessment. This means that by following the ITSG-33 ISSIP, IT projects should be able to implement dependable information systems that satisfy applicable security needs and requirements and that are operating under accepted residual risk levels.
== References ==
* [http://www.gcpedia.gc.ca/gcwiki/images/2/20/GC_ESA_Program_Implementation_Framework.pdf GC ESA Program Implementation Framework]
[[Category:Government of Canada Enterprise Security Architecture (ESA) Program]]
[[Category:Enterprise Security Architecture]]
