|
|
| Line 26: |
Line 26: |
| | </div></div> | | </div></div> |
| | | | |
| − | {{TOCright}} | + | {{Delete|reason=Expired Content}} |
| − | | |
| − | == Overview of the ESA Program Life Cycle Integration ==
| |
| − | Security must be considered an integral part of normal project and systems development planning cycles. It is important that IT security architectures are derived from an analysis of business requirements for security, especially those in which security has an enabling function through which new business opportunities can be developed and exploited. This page will provide a brief overview on how the ESA Program will integrate security into various life cycles. 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].
| |
| − | | |
| − | <br>
| |
| − | | |
| − | == ESA Program Life Cycle ==
| |
| − | [[File:ESA Life Cycle.PNG|left|thumb|193x193px|ESA Program Life Cycle]]
| |
| − | The ESA program will follow a life cycle approach to ensure that IT security architecture designs are relevant and meets the needs of the business. GC business requirements for security must be analysed at the outset and derive IT security architectures. The ESA program is business driven, thus the ESA Program Life Cycle creates a chain of traceability for the business requirements for security through each phase and will help to ensure that the business mandate is preserved.
| |
| − | | |
| − | The image on the left shows the ESA program life cycle with its four phases:
| |
| − | | |
| − | '''Strategy & Plan:''' Includes activities to define requirements and target security architectures based on ESA focus areas for the GC high-level view;
| |
| − | | |
| − | '''Design:''' Embraces the technology-neutral design of the logical, physical, component and operational architectures;
| |
| − | | |
| − | '''Implement:''' ESA oversight and includes activities, such as product selection and deployment of the solution, and;
| |
| − | | |
| − | '''Manage and Measure:''' Enables target performance metrics to be set
| |
| − | | |
| − | For more information about the ESA Program Life Cycle, please read the [http://www.gcpedia.gc.ca/gcwiki/images/2/20/GC_ESA_Program_Implementation_Framework.pdf GC ESA Program Implementation Framework].
| |
| − | | |
| − | <br>
| |
| − | | |
| − | == GC IT Management System ==
| |
| − | [[File:GC IT Management System.PNG|thumb|683x683px|GC IT Management System|link=http://www.gcpedia.gc.ca/wiki/File:GC_IT_Management_System.PNG]]To ensure that GC business requirements are addressed, a business intake process for the ESA program is required. By being proactive and identifying business and technical requirements early in the life cycle of a project or system, it can give the GC the ability to be flexible and adaptable to provide holistic services, meeting both immediate need and providing structure for future growth.
| |
| − | | |
| − | In order to provide architectural advice and guidance, CIOB has proposed the establishment of IT architecture review at the department level, including a GC Architecture Review Board (GCARB). The GCARB will include involvement at various gates within the project life cycle and include an architecture compliance review process. A GCARB architecture review condition would be triggered if any of the following criteria were met:
| |
| − | # GC CIO or Departmental CIO requests review,
| |
| − | # IT-enabled project spans more than one department or is a shared or common government assets, and/or
| |
| − | # Project >= $1M or is a result of a TB submission.
| |
| − | Requests for architecture reviews will be coordinated by the GCARB. Architecture reviews will be requested by Departments or by the GC CIO at various points in an IT-enabled project life cycle. Subsequently, the GCARB will convene architecture review meetings with domain experts including Security. An architecture artifact may be approved or a decision be made by the GCARB that allows the project to move forward. Subject matter experts (SMEs) from the ESA program will participate in the security domain architecture reviews to ensure that proposed solutions are aligned with GC IT security strategies and objectives. For more information about the GC IT Management System, please read the [http://www.gcpedia.gc.ca/gcwiki/images/2/20/GC_ESA_Program_Implementation_Framework.pdf GC ESA Program Implementation Framework].
| |
| − | | |
| − | <br>
| |
| − | | |
| − | ==Project Life Cycle ==
| |
| − | ESA artifacts support the planning phase of the project life cycle as it will help guide the development of systems to ensure that security is built in from the beginning. Security is addressed as part of any new project initiation, acquisition, or relationship, and as part of ongoing project management. Security requirements are addressed throughout all system/software development life cycle phases including acquisition, integration, requirements engineering, system architecture and design, development, testing, operations, maintenance, and disposal. For more information about the Project Life Cycle, please read the [http://www.gcpedia.gc.ca/gcwiki/images/2/20/GC_ESA_Program_Implementation_Framework.pdf GC ESA Program Implementation Framework].
| |
| − | | |
| − | <br>
| |
| − | | |
| − | == System Development Lifecycle ==
| |
| − | A secure systems development life cycle is required in the development and implementation of resilient and secure information systems. By ensuring that information security requirements are integrated into the organization’s system development life cycle processes, more resilient information systems will be developed and implemented. ESA artifacts will provide guidance to the initiation, development and acquisition phases, which includes requirements analysis and high-level design. For more information about the System Development Cycle, please read the [http://www.gcpedia.gc.ca/gcwiki/images/2/20/GC_ESA_Program_Implementation_Framework.pdf GC ESA Program Implementation Framework]
| |
| − | | |
| − | <br>
| |
| − | | |
| − | == Security in Acquisitions ==
| |
| − | As the GC IT environment is transformed, and services and solutions are being acquired, security is a key element of the process. Security activities must be integrated into the procurement process to ensure the services being developed will meet GC business requirements for security. The IT Security Tripartite (ITST) will provide security review, support, and guidance on secure design of information systems as they are renewed. The image below shows a proposed set of activities that should be performed during the acquisition process following the collaborative procurement model for the ESA program. For more information about the Security in Acquisitions, please read the [http://www.gcpedia.gc.ca/gcwiki/images/2/20/GC_ESA_Program_Implementation_Framework.pdf ESA Program Implementation Framework].[[File:Key security activities in acquisitions.png|675x675px|centre|thumb|Key Security Activities in Acquisition|link=http://www.gcpedia.gc.ca/wiki/File:Key_security_activities_in_acquisitions.png]]
| |
| − | | |
| − | <br>
| |
| − | | |
| − | == 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]]
| |
