Difference between revisions of "Annex C: Secure Enterprise Application Delivery"
(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...") |
(No difference)
|
Revision as of 08:39, 7 April 2021
| ESA Program Overview | ESA Foundation | ESA Artifacts | ESA Initiatives | ESA Tools and Templates | ESA Reference Materials | Glossary |
|---|
| ESA Requirements | ESA Concept of Operations | ESA Description Document | ESA Pattern Diagram Repository |
|---|
| Annex A: Data Loss Prevention | Annex B: Cloud Security | Annex C: Secure Enterprise Application Delivery | Annex D: Secure Enterprise Systems Administration | Annex E: Vulnerability Management System | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
Overview
The Government of Canada (GC) has embarked on a number of application delivery initiatives to reduce costs and to increase efficiency. The goal is to eliminate application functionality duplicated in multiple departments (departmental "stovepipes") and make consolidated functionality widely and securely available both within the GC and to Canadian citizens. The first image below and on the right has been adapted from a GC presentation on Financial Management Transformation and summarizes the goals of application delivery transformation. Applicable initiatives include:
- Email Transformation Initiative (ETI)
- GC Back Office Transformation
- Identity, Credential, and Access Management (ICAM)
- Cloud First
- Open Government
The concepts described in the GC ESA ConOps Annex C: Secure Enterprise Application Delivery document are generally applicable to all application consolidation initiatives, but the document focuses specifically on the GC Back Office Transformation initiative for the following reasons:
- Deployment of Service-Oriented Architecture (SOA) technology in support of GC Back Office Transformation is currently underway within the GC,
- It deals with core GC administrative functions, such as Financial Management and Human Resources,
- Consolidation of the approximately 12,000 back office systems in use across the GC will lead to significant increases in efficiency and reductions in cost,
- It is a complex technical and organizational undertaking that requires significant collaboration among multiple GC departments, and
- It has significant security and privacy concerns as it encompasses consolidation of HR, finance, pay, pension, and other applications that process sensitive data requiring protection at the "Protected B" level.
GC Back Office Transformation
The image below and on the right illustrates the GC Back Office Transformation goal of providing a single point of access by end users to consolidated back office applications. In addition to providing a single point of access to individual applications, GC Back Office Transformation also supports the creation of automated business processes that enable users to execute complex business functions that result in automated interaction and exchange of data among multiple back office applications.
GC Back Office Transformation is an Enterprise Application Integration (EAI) initiative that leverages open standards. It implements a Service Oriented Architecture (SOA) centred on Enterprise Service Bus (ESB) technology. In contrast to older EAI architectures that relied on a centralized broker, use of an ESB distributes application interoperability capabilities throughout the network the network infrastructure to improve application reliability. The use of web services protocols based on open standards to implement a set of well-defined application services enhances the ability to interoperate and reduces the risk of vendor lock-in. Although Back Office Transformation provides the initial motivation for deploying a GC-wide SOA, the SOA is intended to eventually support other types of enterprise application.
The GC Back Office Transformation initiative is made up of three distinct components. These components are highly dependent on each other and must be effectively integrated for the initiative to be successful:
- GC Back Office Transformation Interoperability that consists of middleware technologies (messaging fabric, GC service bus, departmental buses), and the networking and computing infrastructure that hosts all services,
- Business application transformation (Pension, Pay, Human Resources, Case Management, Information Management, Financial Management) that result in the delivery of GC-wide consolidated application services that interoperate using the middleware technologies, and
- Support services that include Identity, Credential, and Access Management (ICAM), system management, and security capabilities.
Security is of paramount importance in the deployment of a GC Back Office Transformation solution. The integration of multiple technologies provided by multiple departments (including TBS, SSC, and PSPC) requires a comprehensive whole-of-government approach to risk management. The consolidated, multi-tenant nature of the solution creates a community risk in that poor risk management by one department puts other departments' data and services at risk. The solution will consist of a combination of Commercial-Off-The-Shelf (COTS) products and custom development (e.g. applications, application adapters, executable business processes, business rules, digital policies) making acquisition and development security very important aspects of risk management. Enterprise applications will be required to communicate with external entities (businesses, other governments, citizens) and public cloud services, further emphasizing the need for a comprehensive risk management approach.
Identity, Credential, and Access Management (ICAM)
From a technology perspective, a GC-wide solution for Identity, Credential, and Access Management (ICAM) is a key element of reducing risk. A GC-wide approach to ICAM provides a consistent level of authentication assurance commensurate with the sensitivity of data being accessed, allows timely revocation of obsolete accounts, and makes it easier to periodically review access permission for excess privileges. A Single Sign-On (SSO) solution relieves users of having to memorize a multitude of passwords. This has the dual benefits of reducing the burden on the user and improving security as users no longer need to write down or otherwise record passwords where they are vulnerable to unauthorized disclosure. Finally, a centralized ICAM capability also decreases the likelihood of vulnerabilities cause by design or implementation defects in comparison to each application implementing its own ICAM solution.
The ability to centrally manage and monitor the solution for signs of attack or misuse is also critical. The deployment of centralized audit, security information management, and security event management systems that allow security-related events and information to be correlated and analyzed is necessary for detection of attack patterns and the ability to effectively respond. Similarly, centralized configuration and vulnerability management capabilities help ensure that all components of the solution are up-to-date and able to resist the widest range of attacks.
For more information, please read the GC ESA ConOps Annex C: Secure Enterprise Application Delivery document.
Current Situation
Back office application services within the Government of Canada are currently delivered in a fragmented and inconsistent fashion where individual departments operate their own applications. Data gathered in the preparation of the Report of the State of Aging IT Across the Government of Canada identified 16,000 IT systems operate by 66 departments The report states the following with respect to back office systems:
"Approximately 12,000 of the reported 16,000 systems address administrative functions, suggesting that, in the aggregate, total IT spending on systems could be rebalanced between program delivery and administration. For line-of-business systems, it was noted that, in some cases, a few departments accounted for all of the identified systems in a few business objectives. For example, five departments alone account for the nearly 2000 systems that have been identified as related to the business objective of movement of people. Likewise, eight departments identified over 250 systems related to the business objective of health care provision."
In the area of financial management alone, there are 500+ applications that support 113 departments and agencies, 1,400 towns and cities throughout Canada, 100s of international locations, and 377,000 self-service users.
Management of electronic identities within the GC is also fragmented. This requires multiple system owners to provide identity services and results in GC users having too many credentials (and passwords to remember) leading to increased costs and reduce security.
As shown in the image on the right, the current GC enterprise application environment consists of multiple stovepiped applications operated by different departments that result in duplicated infrastructure and overlapping functionality. There is limited business process automation requiring users to interact with multiple applications with a frequent need to re-enter the same data. The absence of an integrated workflow capability results in users having to coordinate execution of business processes through the use of file transfers, email, phone calls, paper documents, etc.
Because of the specialized knowledge required to access multiple applications with different interfaces, and the need for extensive manual coordination, these tasks are often delegated to administrative staff to perform.
Most, if not all, of the existing enterprise applications implement their own access control services that provide identification, authentication, and authorization. This leads to a proliferation of user IDs and passwords that must be memorized by users. It also increases the risk that user accounts and associated authorizations are not regularly reviewed.
For more information, please read the GC ESA ConOps Annex C: Secure Enterprise Application Delivery document.
Operational States
It is not practical to assess the operational states supported by the approximately 12,000 back office systems deployed throughout the GC, but the available states are expected to be similar.
The goal of the GC Back Office Transformation program is to decommission the majority of these legacy applications. The operational states of the surviving applications must be analyzed to determine their influence on the operational states of the integrated enterprise application delivery environment. In particular, if some of the integrated applications are in failed or maintenance states, the overall system may be able to continue operating in a degraded state.
The operational states of application services are dependent on the operational states of the network and computing infrastructure. These states may change over time as data centre consolidation progresses and control of infrastructure is transferred from departments to SSC. The image on the left identifies the operational states of the secure application delivery production system with emphasis on the enterprise application development and deployment. This image include the states defined in the GC ESA ConOps Main Body document with the addition of a degraded state that reflects the distributed nature of the secure enterprise application delivery environment.
In addition to the production system, one or more development systems will be required together with a test system. The test system must closely mirror the configuration of the production system to ensure that representative interoperability, performance, and security testing can be performed prior to deploying new capabilities to the production system.
The risk management process should defined the process for transitioning to the production system. If the test system does not comply with all required security controls, an interim authority may be granted to transition to the production environment if there is an approved action plan to address the identified deficiencies. The governance structure must allow an interim authority to be withdrawn if the action plan is not followed.
For more information about each operation state from the perspective of secure application delivery, please read the GC ESA ConOps Annex C: Secure Enterprise Application Delivery document.
Justification For and Nature of Changes
Justification for Changes
Moving from multiple application "silos" to a consolidated and centralized enterprise application delivery approach is expected to result in significant improvements in efficiency and reductions in cost. Consolidation and integration of enterprise applications enables the definition and implementation of automated business processes that span applications. These automated processes will provide more timely and relevant data and services to Canadian citizens, elected representatives, and public servants.
The benefits of business transformation and changes to the enterprise application delivery model are best summarized by the following quotes from senior GC officials:
Tony Clement, President of the Treasury Board (2011-2015):
"We are determined to shift departments away from owning and operating different systems that meet similar back office needs... This will free up resources that can be reinvested in modernized applications... My intention is to have government act more like the enterprise it truly is... Identify common issues, develop a roadmap, and work with the private sector to implement new solutions."
Corinne Charette, GC Chief Information Officer (2009-2015):
"In 2009, I spoke of our need to move away from costly and unsustainable department-centric IT service delivery towards consolidated, standard systems and reengineered IT service delivery that would see us work across the GC, with other jurisdictions and with our private sector partners, in greater concert... We have taken some critical and irreversible steps towards behaving as one IT enterprise where we need to - this whole of government IT service delivery approach has become our new normal."
Wayne Wouters, Clerk of the Privy Council (2009-2014):
"To ensure that we continue to offer Canadians excellent service, we must make silos, as an organization structure, a thing of the past... We must do out utmost to present out elected representatives with accurate and timely information to ensure that they have the best background possible upon which to base their decisions... A whole-of-government approach that enhances service delivery and value for money."
James Ralston, Comptroller General (2009-2014):
"As I describe it, the enterprise approach discards the notion of departments as independent corporate entities in favour of the notion of departments as divisions of 'Canada Inc.'... We expect financial information to be more complete and consistent, more timely and useful with an increased ability to perform financial analyses."
Description of Desired Changes
The goal of GC SOA is to provide user access to consolidated enterprise applications through an enterprise services portal that:
- Provides a single point of access for enterprise application services,
- Provides a consistent interface and common language for communicating with applications services,
- Allows the creation of automated business processes to improve user efficiency through the creation of single transactions that span multiple applications,
- Provides a unified access control system that eliminates the need for users to log in to multiple applications, and
- Facilitates the migration from department or application-specific infrastructure to a shared infrastructure model (e.g. cloud).
Beyond these improvement in efficiency and usability, consolidation and centralization of services can improve security in a number of ways:
- Many older applications are difficult to support and may contain vulnerabilities that cannot easily be fixed. Replacement or enforced upgrades of these applications can be expected to reduce the overall number of vulnerabilities.
- Deployment of modern protocols for application interoperability that support the latest encryption and key management techniques improve confidentiality and integrity protection of data in transit (DIT)
- A centralized and consolidated application access environment eases the collection and correlation of security information and events that allow earlier detection and analysis of anomalous behaviour. This will assist the GC in transitioning from a reactive to a proactive approach to cyber security in which information about anomalous behaviour can be combined with threat intelligence data to automatically detect and prevent attacks earlier in the cyber "kill chain".
- A centralized and consolidated application environment simplifies configuration management and eases distribution of security updates. Exploitation of outdated or unpatched software is a common attack vector.
- A centralized access control system reduced the number of accounts that must be managed and the number of credentials issued to users. This reduces the risk of obsolete accounts remaining active and passwords being written down (or otherwise recorded) by users, both of which are targets for exploitation by threat agents. centralized authorization policies help ensure consistency and can be more conveniently reviewed to prevent privilege creep and enforce the security principle of lease privilege. A centralized access control scheme also eases authentication, authorization, and creation of secure channels between enterprise applications.
Assumptions and Constraints
The following assumptions were used when writing the GC ESA ConOps Annex C: Secure Enterprise Application Delivery document:
Assumptions:
- The proposed solution for enabling GC Back Office Transformation Interoperability is a Service-Oriented Architecture (SOA) based on W3C and OASIS web services standards. The RESTful approach to implementing a SOA is not appropriate for the message-oriented middleware currently being deployed within the GC.
- GC Back Office Transformation will rely on a GC-wide identity management solution. The GC ICAM initiative, which is not part of the GC Back Office Transformation initiative, will be appropriately funded and a roadmap agreed that supports GC Back Office Transformation initiative. It is also assumed that the GC ICAM initiative led by TBS and the Privilege Management Infrastructure (PMI) initiative led by SSC will be aligned to eliminate duplicate enterprise ICAM functionality.
- Current Business Application Transformation initiative (HR, FM, and IM) are aligned with GC Back Office Transformation initiative concept and goals. The application transformation projects collaborate to ensure interoperability among applications are a consistent interface to end users.
- Back office data can be secured at the "Protected B" level when operating over a "Protected A" network and computing infrastructure. This requires the middleware and enterprise applications to compensate for the 31 confidentiality-related security controls present in the ITSG-33 IT Security Risk Management: A Lifecycle Approach PBMM profile, but not in the PAMM profile.
- Departmental buses connected to the GC Service Bus over the GC Messaging Fabric may be authorized for different levels of sensitive data. This will require enforcement of access controls based on sensitivity of data at boundaries between buses. If departmental buses are authorized for a higher level sensitivity than the GC Messaging Fabric, data may need to be end-to-end encrypted. The on-boarding strategy for enterprise applications must consider the sensitivity levels of departmental buses to ensure interoperability.
- There will be no restrictions on connectivity between old data centres and new consolidated data centres that prevent or limit interoperability among applications.
- Roles and responsibilities are clearly defined, documented, and agreed upon by all participating departments and agencies.
Constraints:
- It may not be possible or cost-effective to adapt some legacy applications to operate as part of a service-oriented architecture. These applications will continue to operate standalone until they can be replaced or significantly upgraded.
- Some enterprise applications participating in the GC Back Office Transformation initiative are likely to retain application-local authentication and authorization capabilities due to the cost of migrating to a centralized architecture.
- It may not be possible or cost effective to adapt some legacy applications handling "Protected B" information to operate securely over a network infrastructure designed to protect information up to and including "Protected A".
For more information, please read the GC ESA ConOps Annex C: Secure Enterprise Application Delivery document.
Summary of Impacts
This section describes the operational impacts of the proposed system on the users, the suppliers, and the operations and maintenance organizations. It allows affected organization to prepare for the changes that will be brought about by the new system.
User Impacts
GC Back Office Transformation is expected to significantly reduce redundant data entry. Well-designed automated business processes will automatically handle transfer of necessary data among applications. This will also result in a reduction in the use of inefficient manual and semi-automated exchange of information using email, phone calls, files transfers, etc. The Enterprise Services Portal will provide a common look and feel for all application services which will make it easier for users to transition to new roles or different departments.
An enterprise Single Sign-On (SSO) solution will relieve users of the need to remember numerous authentication secrets (passwords, passphrases, PINs, etc.) that often have different renewal cycles and complexity requirements.
All users, administrative and non-administrative, will be required to undergo training on the new interfaces and automated business processes.
Organizational Impacts
Consolidated applications and a unified infrastructure create a shared risk environment that affects all departments. Departments must agree on a common security plan and participate in a GC-wide Security Assessment & Authorizations (SA&A) process.
Application consolidation will require departments to yield control of legacy applications and the data they process. To achieve availability and performance requirements, it may be necessary for the departments to obtain commitments from the service provider (PSPC and/or SSC) in the form of a Service Level Agreement (SLA).
Identification of required application services and automated business processes, and development of a canonical data model are significant tasks that will require adequate funding and close collaboration among departments and agencies. Much of this work must be performed before deployment of any technology, and may therefore represent a sizeable upfront hidden cost.
Impacts during Development
It is necessary to establish teams made up from members of all stakeholder organizations to coordinate GC-wide development activities in order to understand the impacts during development and to develop a strategy that minimizes the impacts to operational requirements. The image below provides an illustration showing the transitioning process flow and the stakeholder teams involved in the transition planning efforts.
GC-Wide Program Management
Program management is responsible for strategizing and planning the transition from the legacy application delivery environment to the consolidated secure enterprise application environment. The strategy will prioritize the order in which applications are transitioned. Consideration must be given to the impact each application service has on business processes, identify the user community involved in the transition, as wella s the dependence on other applications to meet ongoing work flow obligations. The transition plan will document the order and transitional impact considerations that must be addressed from a transitional ConOps perspective.
GC-Wide Risk Management Assessment
The GC-wide risk management planning team is responsible for evaluating the transition plan and evaluating the program and security risk potential during development and transition activities for compliant application services. This risk assessment is high level assessment that addresses development and transition risks. It does not address risks at the component or application level as these will be individually risk assessed during the transition process by the responsible risk assessors. The risk assessment is focused on addressing issues with the transition plan and is a companion document to the transition plan.
GC-Wide System and Security Engineering
The system and security engineering transition teams are responsible for evaluating the transition plan and the associated risk assessments, and determining the readiness requirements for transitioning the application services to the framework. These teams are responsible for determining if system and security interface and messaging requirements of the application services have been met, and for ensuring these services are available at the time of transition.
GC-Wide ICAM Implementation
As application services are transitioned to the framework, user communities will need to be identified and a plan for rolling out new or revised credentials will be required to ensure the user community is not impacted during transition due to access or authorization issues.
GC-Wide System and Security Test Planning
Transitioning the application services to the framework will require an incremental approach to system and security testing. A transitional system-wide test plan will identify the test requirements required for transitioning application services and any regression testing that must be performed as more application services are transitioned. This plan will also address the business work flow obligations of the application services. Work flows may be incrementally implemented depending on the availability of the collaborating application services.
The transition test plan does not replace individual test plans, but rather addresses the underlying issues with development and transitioning and ensures that test requirements are developed and verified as part of the transition plan.
Transition to Consolidated Application Services
The transitioning of application services to the framework is highly dependent on the planning efforts described in the previous sub-section. However, the transition to consolidated business work flows across the various application services will be incrementally implemented as it will be dependent on the availability of the collaborating application services. Therefore, it is necessary to consider an incremental approach to developing and deploying business workflows. The following implementation guidance may be used during the transition planning to plan for incremental work flow development.
- Pre-Condition - Business work flows have been analyzed and work flow use cases are available
- Prioritize transition of those application services that do not participate in a work flow collaboration. These include standalone applications, such as email and file transfer services. These services may collaborate later in a work flow but are not normally dependent on any work flow collaboration to meet user needs
- Review the GC Back Office Transformation transition plan and determine which applications are going to be available to collaborate in a work flow during the transition period. Small work flows dependent on two or three application services should be developed first and then integrated into more elaborate work flows
- Test the work flows in the development environment before transitioning the work flows to the production environment.
Security Analysis of the Proposed System
This section identifies a number of high-level security concerns to consider when designing and deploying GC Back office Transformation capabilities, and discusses mitigation measures for each concern.
At a more detailed level, NIST SP 800-95 describes web services and web service protocols, identifies some common vulnerabilities, and discusses how to mitigate them. The Open Web Application Security Project (OWASP) maintains a top 10 list of web services security risks and provides a detailed description of each risk. The list is periodically updated to reflect changing threats and technology. The most recent update was made in 2013. These lower level mitigation tactics will be used during the development of the GC Back Office Transformation initiative solutions.
For more information about this, please read the following sections which can be expanded by clicking on 'Expand' on the far right.
