GAEA Security Architecture
For Project: Enterprise Architecture Foundation
Program: Government of Alberta Enterprise Architecture (GAEA)
Document Name: 09.GAEASecurityArchitectureV2.0.doc
© 2002 Government of Alberta
Government of Alberta Enterprise ArchitectureE.A. Foundation Project
Security Architecture
DOCUMENT HISTORY
Document Location
Ensure that this document is current. Printed documents and locally copied files may become obsolete due to changes to the master document.
Revision History
Revision Number / Revision Date / Summary of Changes / ChangesMarked
0.8 / April 30, 2002 / First Draft Published for Core Team Review and initial QA / N
1.4 / May 23, 2002 / Second Draft Published for Core Team Review and QA / N
1.7 / June 19, 2002 / Incorporate feedback from Final QA, Core Team, and Extended team. / N
1.9 / June 25, 2002 / Final formatting and edits applied / N
1.10 / July 10, 2002 / Changes submitted by R. Simon applied. This version submitted for sign-off and approval. / N
2.0 / August 15, 2002 / Apply formatting standards / N
November 14, 2002 / Applied SFIs related to Energy feedback: 78,79,80,81 / N
Dec 06, 2002 / Harold: Changed “Public” to “GoA” in section 5.1.3.3 GoA Credential and Validation Manager Node / N
2.1 / December 6, 2002 / Publish final versions of all project deliverables (per Steering Committee’s project sign off). All V2.0 revisions accepted / N
The SFIs (Suggestions For Improvement) to GAEA are documented in more detail on the following report:
If there are any further SFIs, please forward them to the GAEA Project Core Team.
Approvals
This document requires the approval of the GAEA ProjectSteering Committee.
Distribution
This document has been prepared based on input and direction from the GAEA Project Departmental Subject Matter Experts Team and additional representatives from participating departments. Their feedback and comments have been incorporated.
This document has been distributed to the GAEA Project Core Team and the GAEA Review Committeeand has incorporated their review feedback and comments.
The current membership of the GAEA teams and committees is available at the following Internet URL:
Upon approval, the final version of this document will be made available for further distribution via the Government of Alberta SHARP web site. The Internet URL of this web site is:
TABLE OF CONTENTS
1.Executive Summary
1.1Key Security Architecture Recommendations
1.1.1Key Recommendations - Overall Security Architecture
1.1.2Key Recommendations - Trusted Credential Subsystem
1.1.3Key Recommendations - Access Control Subsystem
1.1.4Key Recommendations - Information Flow Control Subsystem
1.1.5Key Recommendations - Integrity Subsystem Recommendations
1.1.6Key Recommendations - Audit Subsystem
2.Introduction and Key Concepts
2.1The Purpose of the Document
2.2Approach to Security Architecture
2.3Security Architecture Roadmap
2.4GoA Security Policies
2.5Security Architecture Requirements
3.Security Architecture (SA)
3.1General Security Strategies
3.2Security Zones of Control
3.3Security Architecture Design Objectives and Design Guidelines
3.4Enterprise Threat and Risk Assessment
3.4.1Concern - Loss of Confidentiality
3.4.2Concern - Loss of Integrity
3.4.3Concern - Loss of Availability
3.5Security Architecture Reference Standards/Models
3.5.1ISO/IEC 15408-2 Common Criteria
3.5.2ISO/IEC 13335-4 GMITS
3.5.3IBM Method for Architecting Secure Solutions (MASS)
3.6Security Subsystems - Overview
4.Security Architecture Findings, Decisions and Recommendations
4.1Overall SA Findings and Recommendations
4.1.1Overall Security Architecture Findings
4.1.2Overall Security Architecture Recommendations
4.2Trusted Credential Subsystem
4.2.1Trusted Credential Findings
4.2.2Trusted Credential Recommendations
4.2.3User Category Decisions
4.2.4Credential Decisions - for One-factor (simple) Authentication
4.2.5Credential Decisions - for Two-Factor (Strong) Authentication
4.2.6Operational Decisions re: Trusted Credentials
4.3Access Control Subsystem
4.3.1Access Control Findings
4.3.2Access Control Recommendations
4.3.3Operational Decisions re: Access Control
4.4Information Flow Control
4.4.1Information Flow Control Findings
4.4.2Information Flow Control Recommendations
4.4.3Operational Boundary Flow Controls Decisions
4.4.4Demilitarized Zone (DMZ) Decisions
4.5Integrity Subsystem
4.5.1Integrity Subsystem Findings
4.5.2Integrity Subsystem Recommendations
4.5.3Overall Integrity Decisions
4.5.4Operational Integrity Subsystem Decisions
4.6Audit Subsystem
4.6.1Audit Subsystem Findings
4.6.2Audit Subsystem Recommendations
4.6.3Audit Subsystem Decisions
5.Security Subsystems - Detailed
5.1Trusted Credential Subsystem
5.1.1Trusted Credential Subsystem (Functional View)
5.1.2Trusted Credential Subsystem Components (Functional view)
5.1.3Trusted Credential Subsystem Nodes (Operational View)
5.1.3.1Public Credential and Validation Manager Node
5.1.3.2Public Credential Repository Node
5.1.3.3GoA Credential and Validation Manager Node
5.1.3.4GoA Credential Repository Node
5.2Access Control Subsystem
5.2.1Access Control Subsystem (Functional View)
5.2.2Access Control Subsystem Components (Functional View)
5.2.3Access Control Subsystem Nodes (Operational view)
5.2.3.1GoA Identification and Authentication Node
5.2.3.2GoA Coarse-grained Authorization Node
5.2.3.3Public Identification and Authentication Node
5.2.3.4Public Coarse-grained Authorization Node
5.3Information Flow Control Subsystem
5.3.1Information Flow Control Subsystem (Functional view)
5.3.2Information Flow Control Subsystem Components (Functional view)
5.3.3Information Flow Control Subsystem Nodes (Operational view)
5.3.3.1External Business Boundary Flow Control Node
5.3.3.2Internet Boundary Flow Control Node
5.3.3.3RAS Boundary Flow Control Node
5.3.3.4Internal Boundary Flow Control Node
5.3.3.5Subdomain Boundary Flow Control Node
5.3.3.6Highly Secure Boundary Flow Control Node
5.4Integrity Subsystem
5.4.1Integrity Subsystem – Functional View
5.4.2Integrity Subsystem Components (Functional View)
5.4.3Integrity Subsystem Nodes (Operational View)
5.4.3.1Common Virus Protection and Monitoring Node
5.4.3.2GoA Key Repository (Escrow) Node
5.4.3.3GoA Confidential Email Node
5.4.3.4GoA Time Manager Node
5.4.3.5Common Intrusion Detection/Monitoring Node
5.5Audit Subsystem
5.5.1Audit Subsystem – Functional View
5.5.2Audit Subsystem Components (Functional view)
5.5.3Audit Subsystem Nodes (Operational View)
5.5.3.1Audit Data Collection and Storage Node
5.5.3.2Audit Information Repository Node
5.5.3.3Audit Management and Reporting Node
Appendix A. Scenarios
A.1Health Provider Registry System Scenario
A.1.1Use Case #1: A Source submits provider data using the WEB Browser
A.1.1.1SA Operational Example – Login and data request
A.2.1Use Case #2: A Source submits provider data using Electronic Messaging
A.1.2.1SA Operational Example - Trusted Update
A.3.1Use Case #3: New/updated data is distributed to an authorized Consumer via messaging
A.1.3.1SA Operational example - Information Push to Client System
Appendix B. Glossary
Appendix C. GMITS – Part 4 - Threat Definitions
Appendix D. GoA Security Policy Support
Appendix E. Summary of Workshop Participation
Table of Figures
Figure 1: Credential Types
Figure 2: When is Strong Authentication Required? - Flow Chart
Figure 3: Security Architecture Domain – Project Flow
Figure 4: Security Architecture Roadmap
Figure 5: GAEA Security Zones
Figure 6: Threat/Risk Assessment Process
Figure 7: Loss of Confidentiality – Risk Grid
Figure 8: Loss of Integrity – Risk Grid
Figure 9: Loss of Availability – Risk Grid
Figure 10: Common Criteria
Figure 11: Security Subsystems
Figure 12: Credential Types
Figure 13: When is Strong Authentication required? - Flow Chart
Figure 14: Security Subsystem Components
Figure 15: Subsystem Template
Figure 16: Trusted Credential Subsystem Process and Flow
Figure 17: Trusted Credential Subsystem Components and Interfaces
Figure 18: Trusted Credential Subsystem Nodes
Figure 19: Access Control Subsystem Process
Figure 20: Access Control Subsystem Components and Interfaces
Figure 21: Access Control Subsystem
Figure 22: Information Flow Control Process
Figure 23: Information Flow Control Subsystem Components
Figure 24: Information Flow Control Node Diagram
Figure 25: Integrity Subsystem Process Flow
Figure 26: Integrity Subsystem Components
Figure 27: Integrity Subsystem Nodes
Figure 28: Audit Subsystem Process Flow
Figure 29: Audit Subsystem Components
Figure 30: Audit Subsystem Nodes
Figure 31: Provider Registry Use Case #1
Figure 32: SA Operational Example – Login and Data request
Figure 33: Provider Use Case #2
Figure 34: SA Operational Example of – Trusted Update
Figure 35: Provider Use Case #3
Figure 36: SA Operational Example - "Push" of Information
index of tables
Table 1 - Security Architecture Requirements
Table 2: Zones to Logical Location Cross Reference
Table 3: Zones to Logical User Groups Cross Reference
Table 4: Security Design Objectives (SDO) and their related Security Design Guidelines (SDG)
Table 5: Mapping Design Objectives to Security Subsystems
Table 6: Confidentiality Risk Analysis
Table 7: Integrity Analysis
Table 8: Availability Analysis
Table 9: Security Zones to Logical User Groups
Table 10: Security Architecture Workshop Attendance
1.Executive Summary
This document presents the GAEA Security Architecture that was developed by the core team and the extended team as part of the overall GAEA Foundation project[1]. It is intended to convey the key findings and recommendations that resulted from the Security Architecture.
The GAEA Security Architecture (SA) defines how detective and protective security controls, audit trails, and tool kits should be planned and implemented to provide integrated security across the four primitive architecture domains (business, applications, data, and technology).
Objectives of the Security Architecture
The primary purpose of the GAEA Security Architecture is to support the ITM Strategy and GoA Security Policy. The specific objectives and deliverables of the GAEA SA are as follows.
Provides guidance to Government of Alberta ITM decision-makers, allowing them to make better Security-related investment/design decisions regarding Government of Alberta ITM Solutions. The resulting decisions will be strategically aligned, faster, and more consistent across departments. Further, it is expected that more sharing of ITM assets between departments will result.
Supports the GAEA Business and Data Architectures, and complies with the GAEA Principles, while providing specific security-related input into the GAEA Application, Technology, and potentially the Privacy Architecture domains.
Supports, enables, and extends the GoA Security Policy by providing specific security-related guidance to ITM decision-makers.
Describes general security strategies that are used to guide decisions within the GAEA Security Architecture domain and within individual GoA ITM Solutions.
Describes the concept of “zones”, which compartmentalize the GoA Security Environment. The security zones of control are crucial, high-level design constructs in the security architecture.
Describes the high-level design objectives and guidelines that influence the Security Architecture decisions.
Describes an Enterprise Threat and Risk Assessment which details the common set of threats faced within the GoA ITM environment, quantifies the relative risk of each threat, and lists associated safeguards which can be used to mitigate the threats. The listed safeguards become important design elements, which the architectures focus on implementing.
Leverages published Industry standards and models to ensure Security best practices are being applied, and that the GoA Security approach is consistent with other public and private organizations.
Describes Security Subsystems that provide structure to the overall GAEA Security Architecture. Each Subsystem is described from both a functional and operational viewpoint. Within the operational view, security solutions that can be shared across the GoA are described.
Documents the findings, recommendations and decisions that were made during in the Security Architecture Workshop sessions by the GAEA Project Departmental Subject Matter Experts Team. These decisions have been organized by security subsystems.
Expected Benefits
The primary reason that the GAEA project is pursuing Security Architecture is that it is a key underpinning for Electronic Service Delivery, and therefore fundamental to the success of the ITM strategy. Our approach to the GAEA SA is expected to have the following underlying benefits:
Consistently manage ITM Solution risk across the GoA, while leveraging industry best practices – Security, like a chain, is only as strong as its weakest link. A consistent approach within the GoA, based on industry best practices, will result in better overall security of the ITM environment.
Reduce costs and improve flexibility by implementing common Security Solutions across the GoA – Security solutions that are sharable across the GoA will reduce total costs. In addition, shared solutions will also reduce barriers to solution integration and interoperability – thus improving flexibility.
Improve customer service by offering common user ids for accessing GoA ITM Solutions, and a common approach to user enrolment (registration). The GAEA SA recommends a set of common user ids, and common “Trusted Credential” processes and solutions that will simplify the end user experience.
Allow ITM decision-makers to make better and faster Security-related investment/design decisions. The resulting decisions will be strategically-aligned, faster, and more consistent across departments
Promote ITM Solution Interoperability, Integration, and ease-of-access. ITM Solution access, interoperability, and integration are all enabled by strong and consistent security mechanisms.
The Security Architecture was developed by the GAEA Foundation Project Core Team and an extended team consisting of cross-departmental Subject Matter Experts. There were a total of five facilitated workshops in the period from March 27th to April 18th, 2002. The purpose of these workshops was to provide input to the development of the GAEA Security Architecture and validate, refine and contribute to the deliverables.
Key Overall Security Architecture Findings
The following key findings of the Security Architecture workshops provide a basis for the SA recommendations:
An inconsistent approach to Risk Management and Security Architecture across GoA departments introduces security and privacy “weak-links”.
There is strong support among the representatives of the participating departments on the concept of a common, cross-government, approach to Risk and Security Management.
There is strong support among the representatives of the participating departments on the concept of sharing key security mechanisms/solutions as a means of improving both security and cost-effectiveness.
There is strong support among workshop participants that an accepted definition of an overall architecture and framework along with the implementation guidance using the Security Architecture for reference will provide a consistent approach to risk acceptance across the government. The five security subsystems presented in the GAEA workshops provide a consistent and effective cross-government approach to defining Security Architecture.
1.1Key Security Architecture Recommendations
This section presents the key Security Architecture recommendations for executive summary purposes. For further details on each of these recommendations, and to see other associated recommendations (and findings), please refer to Section 4. Security Architecture Findings, Decisions and Recommendations.
These recommendations were developed and agreed to by the project team and the majority of the subject matter experts as a product of the security architecture workshops.
The recommendations have been grouped according to the five Security Subsystems (introduced in Section 3.6) as follows:
Key Recommendations - Overall Security Architecture
Key Recommendations - Trusted Credential Subsystem
Key Recommendations - Access Control Subsystem
Key Recommendations - Information Flow Control Subsystem
Key Recommendations - Integrity Subsystem
Key Recommendations - Audit Subsystem
1.1.1Key Recommendations - Overall Security Architecture
The departments should adopt and utilize the GAEA Security Architecture subsystems as a common point of reference for developing Secure ITM Solutions.
1.1.2Key Recommendations - Trusted Credential Subsystem
User Category Recommendations
The Logical User Groups defined in the GAEA Business Architecture provide the Security Architecture with essential knowledge of the GoA user communities. The Security Architecture has grouped the Logical User Groups into four categories with similar Security Requirements. Many of the Security Architecture (and other architecture domain) decisions are based upon these four user categories:
External Public User - External Public Users are typically Alberta Citizens who access GoA ITM Solutions from the Public (Uncontrolled) Zone. The GoA will perform the enrolment/registration of these users.
External Contracted User- This category of users is typically businesses that are not directly governed by the GoA Security Policy because it cannot be enforced. Alternatively, their security responsibilities and requirements are detailed in the formal agreements or contracts with the GoA. External Contracted Users typically access GoA ITM Solutions from external zones. The GoA will perform the enrolment/registration of these users
External Organization - This category of users is influenced by the GoA Security Policy, and are considered “Semi-Trusted”. Extended government bodies (e.g. RHAs) are typically in this category. Enrolment and management of the user is the responsibility of the organization. External Organization Users typically access Government of Alberta ITM Solutions from external zones.
Internal User - This category of Users is governedby the Government of Alberta Security Policy, so they are considered “Trusted”. Internal Users may have role-dependent access to Government of Alberta ITM Solutions from any/all Zones. This user category includes Contractors acting in the capacity of an “internal” user. Enrolment of Internal Users is performed by the Government of Alberta
Credential Recommendations - for One-factor (simple) Authentication
Figure 1: Credential Types, shown below, illustrates the various credential types that individuals may have – including variations based upon role, which services are being accessed, and required authentication type (single-factor, two-factor).
A Government of Alberta employee may have at least 2 identities (IDs), one to conduct his/her job responsibilities (as an “internal user”), the other to interact with government programs as a citizen (as an “external public user”).
External Public users will have at least one authenticated user identity that will provide access to citizen-facing e-government services that require authenticated access.
User IDs have been the de facto credential type for one-factor authentication within the GoA. (A User ID is a unique representation of a users identity recognizable to a computer system) This practice is expected to continue for the foreseeable future.
There may also be a pseudo anonymous identity where the user will select their own user ID and password known only to them.
Internal users will have one user identity to access multiple systems within government departments and across the government, as required by job function and responsibilities.
External Contracted and External Organization users will have one user identity to access the appropriate systems provided by government departments, as deemed by job function and responsibilities attributed to the External Contracted or External Organization.
Figure 1: Credential Types