ESA Glossary

Glossary

The table below is made up of information from various sources credited in the far right column of the table. The terms defined in the table are used in many of the ESA Program documents available through this portal. Please use the authoritative source when referencing terms in this glossary.

Note: The terms in this glossary apply primarily to the ESA program, the framework, initiative and its artifacts. While some of the terms can be applied to Security outside fo the ESA and Information Technology scope, the definitions here are intended to provide a better understanding of the terms used in ESA related artifacts and documents.

Glossary of Terms

Term	Definition	Source
Accidental Threat	An unplanned threat caused by a human being.	HTRA, Reference 1
Architecture	A set of design artifacts, that are relevant for describing an object such that it can be produced to requirements (quality) as well as maintained over the period of its useful life (change). The design artifacts describe the structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.	OSA, Reference 20
Architecture Description	An architecture description is a formal description of an information system, organized in a way that supports reasoning about the structural properties of the system. It defines the components or building blocks that make up the overall information system, and provides a plan from which products can be procured, and systems developed, that will work together to implement the overall system. A document that provides a detailed description of the architectural approach that will realize a particular solution in support of the Business (IT) Services. It is the architecture blueprint of the solution and will include descriptions of various views of the solution such as systems engineering, enterprise security, communications, data flow, enterprise manageability. It enables further gap analysis to be performed with the identification of the detailed Baseline (or Current) Architecture and detailed Target Architecture. It also includes high-level implementation recommendations to transition from current state to target state.	TOGAF
Access Management	The management and control of the ways in which entities are granted or denied access to the protected resources of an organization and are authorized to perform a specific action(s) within a given resource.	GC ICAM
Account (User Account)	In the context of GC ICAM, a user account is a mechanism used to establish and control user access to IT systems such as networks, servers and workstations. Users may be individual or NPEs.	GC ICAM
Architecture Framework	A conceptual structure used to develop, implement, and sustain an architecture.	TOGAF
Architecture Requirement Specifications	Provides a set of quantitative statements that outline what an implementation project must do in order to comply with the architecture.	ESA Framework
Architecture Roadmap	An Architecture Roadmap lists individual work packages that will realize the Target Architecture and lays them out on a timeline to show progression from the Baseline Architecture to the Target Architecture.	ESA Framework
Architecture View	A perspective from which an architecture may be viewed in order to ensure that a specific topic is considered in a coherent manner.	ESA Framework
Artifacts	An architectural work product that describes an aspect of the architecture. Architectural artifacts are created in order to describe a system, solution, or state of the enterprise.	TOGAF
Assurance	A measure of certainty that a statement or fact is true.	Standard on Identity and Credential Assurance
Assurance Level	A level of confidence that may be relied on by others. (Also see Security Assurance Level)	Standard on Identity and Credential Assurance
Attribute Based Access Control (ABAC)	An access control method where subject requests to perform operations on objects are granted or denied based on assigned attributes of the subject, assigned attributes of the object, environment conditions, and a set of policies that are specified in terms of those attributes and conditions.	GC ICAM
Audit (Information System)	The activity of monitoring the operation of a product from within the product. It includes monitoring of a product for a set of pre-determined events. Each audit event may indicate rogue behavior, or a condition that is detrimental to security, or provide necessary forensics to identify the source of rogue behaviour.	ESA Framework
Audit Log	A chronological record of the audit events that have been deemed critical to security. The audit log can be used to identify potentially malicious activity that may further identity the source of an attack, as well as potential vulnerabilities where additional countermeasures or corrective action are required.	ESA Framework
Authentication	The process of establishing truth or genuineness to generate a measure of certainty that a statement or fact is true.	Guideline on Defining Authentication Requirements; Pan Canadian Assurance Model
Authentication Assurance Level	The degree of confidence in the authentication process expressed in terms of one of four Levels of Assurance (LOA) as defined below. A number of factors contribute to the determination of the LOA including (but not limited to) identity proofing and credential/token issuance and use.	GC ICAM
Authoritative Source	A collection or registry of records maintained by an authority that meets established criteria (e.g., federation criteria).	Guideline on Defining Authentication Requirements
Authorization (ICAM)	The processes of granting or denying specific requests for obtaining and using information processing services or data and to enter specific physical facilities. It ensures individuals can only use those resources they are entitled to use and then only for approved purposes, enforcing security policies that govern access throughout the enterprise.	FICAM Glossary (Authentication and Access)
Authorization (Information Security)	The ongoing process of obtaining and maintaining official management decision by a senior organizational official to authorize operation of an information system and to explicitly accept the risk of relying on the information system to support a set of business activities based on the implementation of an agreed-upon set of security controls, and the results of continuous security assessment.	NIST SP800-39, Reference 7, adapted
Availability	The state of being accessible and usable in a timely and reliable manner. Note: (a) Availability is generally applied to information assets, application software, and hardware (infrastructure and its components). Availability can also be applied to business processes, and personnel; (b) It is implicit in the definition that the integrity of objects being accessed has not been compromised (e.g., corrupted data)	PGS, Reference 2, adapted
Availability Security Objective	To ensure the availability of a business activity or IT asset against a specified set of threats in order to prevent injury to national interests or non-national interests.	ITSG-33 Annex 5
Baseline Architecture	Describes the current state for an enterprise architecture.	ESA Framework
Baseline Security Controls	Mandatory security controls of Treasury Board of Canada Secretariat (TBS) policy instruments for implementation by departments in departmental IT security functions and information systems.	MITS,Reference 3
Blueprint	Includes artifacts that compose various architectural views.	ESA Framework
Business Activity	Any activity performed by a department in the course of its operations to deliver or support the delivery of its programs or services. A business activity is composed of one or several business processes and related information assets. Note: A business activity can be a GC program (e.g., Employment Insurance), a specific business process and related information assets (e.g., accounting), or a set of business processes and related information assets with common organizational objectives (e.g., human resources management). Business activities can also include broader concerns such as mission, image, and reputation.	ITSG-33 Annex 5
Business Context	A component of a departmental or domain security control profile. A business context defines the business activities that are within the scope of a profile in terms of their business processes, related information assets, business needs for security, and their security categories.	ITSG-33 Annex 5
Business Domain	An operational environment where a department performs business activities supporting common organizational objectives.	ITSG-33 Annex 5
Business Domain Security Control Profile (Domain Security Control Profile)	A departmental security control profile for a specific business domain as opposed to a department as a whole.	ITSG-33 Annex 5
Business Need for Security	Any protection or compliance requirement associated with a business activity that can be satisfied by security controls. Business needs for security are derived from laws (e.g., Employment Insurance Act, Financial Administration Act), policies (e.g., Policy on Financial Management, Information and Reporting), and any other regulatory instruments such as directives and standards governing GC business activities. Business needs for security can also be derived from departmental missions, objectives, priorities, the need to preserve the organization’s image and reputation, and various obligations that may have been contracted.	ITSG-33 Annex 5
Business Process	A business process refers to the work required to transform inputs into outputs.	BTEP, Reference 4, adapted from service process
Context Specific Architecture View	Artifacts developed at this layer provide supplementary details; their scope is on common, shared or departmental services and they have a business impact. Example Artifacts: Strategy & Plans Generic Threat Assessment Baseline Security Controls Requirements Matrix Security Patterns Target Architectures Transition Strategies & Roadmaps	ESA Framework
Certificate / Certification Authority (CA)	An authority trusted by one or more users to create and assign certificates.	ESA Framework
Certificate Policy (CP)	A named set of rules that indicate the applicability of a certificate to a particular community and/or class of application with common security requirements. For example, a particular CP might indicate applicability of a type of certificate to the authentication of parties engaging in business-to-business transactions for the trading of goods or services within a given price range.	ESA Framework
Classified IT Asset	An IT asset that contains, stores, processes, or transmits data representing information that may qualify for an exemption or exclusion under the Access to Information Act or the Privacy Act, because its disclosure would reasonably be expected to cause injury to national interests.	ITSG-33 Annex 5
Components	Components are allocated to one or more patterns. Components represent the lowest level of implementable elements in the ESADD and act as the central meeting point for understanding the system-level relationships among requirements, threats, controls, patterns, and use cases.	ESA Framework
Compromise	The unauthorized access to, disclosure, destruction, removal, modification, use, or interruption of IT assets, causing a loss of confidentiality, integrity and/or availability. [PGS, Reference 2, adapted] verb. The act of causing a compromise by exploiting vulnerabilities. Note: This loss may lead to the failure of a business activity and its related requirements. This failure may lead to injuries to national interests or nonnational interests.	ITSG-33 Annex 5
Confidentiality	The state of being disclosed only to authorized principals. Note: Confidentiality is typically applied to information assets. Confidentiality can also be applied, usually at a classified level, to some business activities, such as military missions and intelligence collection activities, where the fact the mission or activity exists is classified, and the particulars of its execution is also classified. Operations Security (OPSEC), typically supported by IT security, is one technique used to protect the confidentiality of business activities. In addition, confidentiality can also be applied to other types of IT assets such as Type-1 COMSEC and SIGINT equipment or weapons systems. Confidentiality in these cases means that the equipment must be provided to, handled by, and disposed of by cleared and authorized personnel. An adversary getting hold of classified equipment may be able to reverse engineer it to deduce classified information about the design, configuration, and weaknesses.	PGS, Reference 2, adapted
Confidentiality Security Objective	To ensure the confidentiality of business activities and IT assets against a specified set of threats in order to prevent injury to national interests or non-national interests.	ITSG-33 Annex 5
Concept of Operations	A document that provides a high-level view of the operating model of an information system. It generally evolves from a concept and is a description of how a set of capabilities may be employed to achieve desired objectives or target state. Verbal and graphic statement, in broad outline, of an organization's assumptions or intent in regard to an operation or series of operations	ISO/IEEE 29148
Confirm	Declare that something has been reviewed in detail with an independent determination of sufficiency.	CC, Reference 5
Contextual Architecture	A description of the business context in which your secure system must be designed, built and operated.	SABSA
Control Objectives	A statements of desired results or purposes to be achieved by implementing y controls	ESA Framework, adapted from COBIT
Credential	In the context of GC ICAM, an object or data structure that authoritatively binds an individual or NPE to a token possessed and controlled by that individual or NPE. While common usage often assumes that the credential is maintained by the individual or NPE, this term also refers to electronic records maintained elsewhere (e.g., a protected userid/password database maintained by an application or a public key certificate stored in a repository).	GC ICAM
Credential Assurance Level	In the context of GC ICAM, the degree of confidence that an individual or NPE has maintained possession and control over the token issued to them and the token and associated credentials have not been tampered with or compromised. The degree of confidence is expressed in terms of one of four Levels of Assurance (LOA) as defined below.	GC ICAM
Credential Authentication (Credential Validation)	The process of establishing confidence that the client has control over their rightful credential (i.e. not stolen), and that the credential (or information contained within) has not been compromised (i.e. not tampered with or modified).	Pan-Canadian Assurance Model
Credential Management	In the context of GC ICAM, the policies, principles, practices, processes, procedures and technology that collectively enable the reliable and secure life cycle management of credentials and the associated tokens.	GC ICAM (aligns with the definition for Identity Management)
Critical IT Asset	An IT asset that supports a business activity having some degree of criticality.	ITSG-33 Annex 5
Criticality	The relative importance of a business activity in promoting or maintaining the health, safety, security, or economic well-being of Canadians, or to the effective functioning of the GC.	PGS, Reference 2, adapted from critical service
Cyber Security	Cyber security is the body of technologies, processes, practices and response and mitigation measures designed to protect electronic information and information infrastructure from mischief, unauthorized use, or disruption. Cyber security involves securing systems and information that may be vulnerable online (e.g. perimeter security, need to know access, vulnerability management, patch management, and related processes).	Policy on Service and Digital
Data	Electronic representation of information. The quantities, characters, or symbols on which operations are performed by a computer, being stored and transmitted in the form of electrical signals and recorded on magnetic, optical, or mechanical recording media.	Oxford, Reference 9, adapted
Deliberate Threat	A planned or premeditated threat caused by a human being.	HTRA, Reference 1
Demonstrate	Provide a conclusion gained by an analysis that is more rigorous than a trace but less rigorous than a proof. To demonstrate a mapping, a rigorous analysis and an informal proof of the more detailed correspondence between elements of successive specifications is required.	CC, Reference 5
Departmental Security Control Profile	A set of security controls that a department establishes as the minimum mandatory requirements for their departmental IT security function and their information systems. A profile must satisfy TBS baseline security controls and departmental business needs for security with due consideration for the departmental threat context and technical context.	ITSG-33 Annex 5
Departmental Security Program	The group of security-related resource inputs and activities that departmental security officers (DSOs) manage to address the security needs of their department while achieving the results set forth in security related TBS policy instruments.	ITSG-33
Departmental Security Requirement	Any security requirement prescribed by senior officials of a department that applies generally to information systems of that department. Departmental security requirements may relate to business processes, information assets, IT-related threats, robustness levels, security control profiles, security assurance requirements, business needs for security, security architecture, security design, common security controls, and specific security solutions.	ITSG-33 Annex 5
Departments (GC Departments)	GC departments, agencies, and other organizations subject to the Policy on Government Security.	ITSG-33 Annex 5
Describe	Provide specific details.	CC, Reference 5
Determine	Affirm a particular conclusion based on independent analysis with the objective of reaching a particular conclusion.	CC, Reference 5
Development Environment	Environment in which the information system is developed.	CC, Reference 5, adapted
End User Device (EUD)	Any device that is used to access GC Enterprise resources and services for the purpose of conducting the business of the GC. This includes static solutions such as workstations and desktops as well as mobile solutions such as tablets, smart phones, and laptops.	ESADD Annex A
Enterprise Architecture	A description of the structure of an enterprise, which comprises enterprise components (business entities), the externally visible properties of those components, and the relationships (e.g. the behaviour) between them. Enterprise architecture describes the terminology, the composition of enterprise components, and their relationships with the external environment, and the guiding principles for the requirement, design, and evolution of an enterprise. This description is comprehensive, including enterprise goals, business processes, roles, organizational structures, organizational behaviours, business information, software applications, and information systems.	ITSG-33 Annex 5
Enterprise IT Security Architecture	The translation of government-wide IT security vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise’s future IT security state and enable its evolution.	ESA Framework
GC Unique Identifier	In the context of GC ICAM, a unique reference (e.g., a number) associated with a specific individual or NPE used to unambiguously distinguish one individual or NPE from another. In the context of GC ICAM, the GC unique identifier is permanently associated with the individual or NPE.	GC ICAM
GC Worker (GC ICAM)	In the context of GC ICAM, GC employees, contractors, Canadian Forces military personnel, regular members of the RCMP (i.e., police officers), trusted guests, or any other authorized users operating internal to the GC.	GC ICAM
High-Level Architecture View	Artifacts developed at this layer are high level documents that are GC/Enterprise in scope and have a strategic impact.	ESA Framework
Identification	The “I” in IA&A, identification is the act of asserting an identity. Usually, the entity asserting an identity is required to prove the assertion by authenticating.	ESA Framework
Identity	In the context of GC ICAM, a reference, designation or set of attributes used to distinguish a unique and particular individual or NPE within a given context.	GC ICAM
Identity Authentication	Identity Authentication is the act of proving an asserted identity. For example, a password can be used to authenticate a presented identity or a digital signature can be used to authenticate an identity asserted in a public key certificate; The process of verifying that a claimed individual or NPE is genuine and based on valid credentials.	ESA Framework; GC ICAM
Identity Assurance Level	In the context of GC ICAM, the degree of confidence that an individual or NPE is who or what it claims to be expressed in terms of one of four Levels of Assurance (LOA) as defined below.	GC ICAM
Identity Attribute	In the context of GC ICAM, a data element that represents a property, quality or characteristic associated with the identity of an individual or NPE.	GC ICAM
Identity Management	In the context of GC ICAM, the policies, principles, practices, processes, procedures and technology that collectively enable the reliable and secure life cycle management of identities and identity attributes.	GC ICAM
Identity Proofing	The process used to collect, validate and verify identity information associated with an individual or NPE. (Note: Guidance associated with this process is provided in the Guideline on Identity Assurance.)	GC ICAM
Implementation (Implement, Implementing)	A term used to designate the phases of the system lifecycle that are responsible for the delivery of an information system. It includes the initiation, development/acquisition, and integration and installation phases of the system lifecycle, but excludes the operations and maintenance phase and the disposal phase.	ITSG-33 Annex 5
Implementation Representation	The least abstract representation of an information system. It consists of source code, hardware and software products, physical network diagrams, configuration documentation such as build books, and so on. Collectively, these elements allow for the construction of the information system without having to make any further design or implementation decisions.	ITSG-33 Annex 5
Information (Information Asset)	Any pattern of symbols or sounds to which meaning may be assigned.	HTRA, Reference 1
Information System	An information system is generally composed of data, computing platforms, communications networks, business applications, people, and processes, organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information.	NIST SP800-39, Reference 7, adapted
Information System Security Implementation Process (ISSIP)	The process of identifying security needs and then building information systems capable of satisfying these needs in a real-world operational environment. ISSIP incorporates process areas of information system security engineering, security assessment, and authorization to form a comprehensive process for the implementation of dependable information systems.	ITSG-33 Annex 5
Injury	The damage to the national interests and non-national interests that business activities serve resulting from the compromise of IT assets.	[HTRA, Reference 1, adapted]
Injury Level	The severity of an injury. Five levels are defined: very low, low, medium, high, very high.	ITSG-33 Annex 5
Integrity	The state of being accurate, complete, authentic, and intact. Note: Integrity is generally applied to information assets. Integrity can also be applied to business processes, software application logic, hardware and personnel.	DDSM, Reference 6
Integrity Security Objective	To ensure the integrity of a business activity or IT asset against a specified set of threats in order to prevent injury to national interests or nonnational interests.	ITSG-33 Annex 5
Intermediate Architecture	Provides detailed and context-specific information required to implement one of the transition states described in a transition strategy and roadmap.	ESA Framework
IT Asset	A generic term used to represent business applications, electronic representations of information (data), and the hardware, software, and system data that information systems are composed of.	ITSG-33 Annex 5
IT Security	The discipline of applying security controls, security solutions, tools, and techniques to protect IT assets against threats from compromises throughout their lifecycle, based on the security category of supported business activities, and in accordance with departmental and GC policies, directives, standards, and guidelines. These securirty controls are intended to preserve the confidentiality, integrity, availability, intended use and value of electronically stored, processed or transmitted information. Note: Protecting IT assets helps protect departmental business activities and therefore departmental mission and objectives.	ITSG-33 Annex 5
IT Security Function	The elements of a departmental security program that are dedicated to the protection of departmental IT assets.	ITSG-33 Annex 5
IT Security Incident	Any unexpected or unwanted event that might cause a compromise of IT assets.	MITS, Reference 3, adapted
IT Security Risk	The potential that a given threat will compromise IT assets and cause injury.	HTRA, Reference 1, adapted
IT Security Risk Management	The process by which organizations manage IT security risks. IT security risk management is achieved through IT security and other risk management processes.	ITSG-33 Annex 5
IT Threat	Any potential event or act, deliberate, accidental or natural hazard, that could compromise IT assets.	HTRA, Reference 1, adapted
Justify (Justification)	Provide a conclusion gained by an analysis that is more rigorous than a demonstration but less rigorous than a proof. It requires significant rigour in terms of very carefully and thoroughly explaining every step of a logical argument.	CC, Reference 5, adapted from justification
Logical Access Control Systems (LACS)	An electronic system that controls an individual’s ability to access one or more computer system resources such as a workstation, network, application, or database.	GC ICAM
Management Security Control	A security control that focuses on the management of IT security and IT security risks.	NIST FIPS 200, Reference 11, adapted
Monitor (Monitoring)	The continuous process of observing the operations of information systems with the objective of detecting deviations from planned or expected behaviour.	ITSG-33 Annex 5
Must	This word means that the statement is a mandatory requirement.	RFC 2119, Reference 8, adapted
Natural Hazard	A threat attributable to forces of nature.	HTRA, Reference 1
National Interests	The security and the social, political, and economic stability of Canada.	PGS, Reference 2
Non-National Interests	The safety, health, and well being of individuals, and the financial position and reputation of individuals and Canadian companies.	PGS, Reference 2, SOAS, Reference 10, adapted
Non-Person Entity (NPE)	Any type of non-human device (e.g., routers, servers, firewalls, mobile devices such as smart phones), application or software object.	GC ICAM
Operational Concept (OpsCon)	verbal and graphic statement of an organization's assumptions or intent in regard to an operation or series of operations of a system or a related set of systems	ISO/IEEE 29148
Operational Security Control	A security control that is primarily implemented and executed by people and is typically supported by the use of technology, such as supporting software.	NIST FIPS 200, Reference 11, adapted
Orphaned Account	An account belonging to a user that has left the organization or no longer requires access to the resource. Orphaned accounts are most often the result of ineffective de-provisioning processes wherein user access privileges are not removed immediately upon a user leaving the organization. These accounts create security vulnerabilities, which may be exploited by individuals seeking to do harm.	FICAM Glossary
Physical Access Control Systems (PACS)	Systems controlling access to physical areas or assets (e.g., buildings, restricted zones).	GC ICAM
Principal	Participating entity in an information system (physical person, legal person, role, equipment, channel, automated process).	ITSG-33 Annex 5
Privilege Management	A set of processes for establishing and maintaining the entitlement or privilege attributes that comprise an individual’s access profile. These attributes are features of an individual that can be used as the basis for determining access decisions to both physical and logical resources.	FICAM Glossary
Protected IT Asset	An IT asset that contains, stores, processes, or transmits data representing information that may qualify for an exemption or exclusion under the Access to Information Act or the Privacy Act because its disclosure would reasonably be expected to cause injury to non-national interests.	ITSG-33 Annex 5
Protection Profile	A document used as part of the certification process according to the Common Criteria. As the generic form of a security target, it is typically created by a user or user community and provides an implementation independent specification of information assurance security requirements.	ESA Framework
Public Key Infrastructure (PKI)	A cryptographic key and certificate delivery system that makes possible secure electronic transactions and exchanges of sensitive information using a system of trusted third parties called “certificate authorities.”.	PWGSC - Information Management Fascicle 2: Information Security Glossary
Recommended	Refer to the definition of should.	ITSG-33 Annex 5
Reference Design	A predefined pattern, or set of patterns, possibly partially or completely instantiated, designed, and proven for use in particular business and technical contexts, together with supporting artifacts to enable their use.	Rational Unified Process
Residual Risk	A risk that remains after security controls have been selected, approved and implemented. Note: Business owners should generally require the support of an information system with a security posture that aligns with their tolerance to risk. For example, they should require the support of an information system with a strong security posture where their tolerance to risk is low. However, this may not always be the case. For example, it may be acceptable for troops to deploy in theatre to save lives with the support of IT assets having a weaker security posture than would normally be required if the consequences of not performing the mission (i.e., loss of many civilian lives) are worse (relatively) than the consequences of relying on these IT assets of weaker security posture to perform the mission (i.e., loss of some military assets).	HTRA, Reference 1, adapted
Residual Risk Level (IT Security Residual Risk Level)	The degree of residual risk.	ITSG-33 Annex 5
Residual Risk Assessment	The assessment performed at the conclusion of the system development lifecycle to adjust the conclusions of the detailed threat and risk assessment to account for unresolved security deficiencies identified during the design, development, testing, and installation phases.	ITSG-33 Annex 5
Risk	refers to the effect of uncertainty on objectives. It is the expression of the likelihood and impact of an event with the potential to affect the achievement of an organization's objectives.	TBS Framework for the Management of Risk
Risk Level	The degree of risk	ITSG-33 Annex 5
Risk management	A systematic approach to setting the best course of action under uncertainty by identifying, assessing, understanding, acting on and communicating risk issues	TBS Integrated Risk Management Framework
Robustness	A characterization of the security strength and security assurance of an implemented security control.	ITSG-33 Annex 5
Robustness Level	A robustness level is composed of a security strength component and a security implementation assurance component. Together, these two components define the requirements that must be met in the implementation and operation of a security control to satisfy defined security control objectives. Note: A security control of a higher robustness level aims to counter threat agents with more sophisticated capabilities, or accidental threats and natural hazards of higher magnitude.	ITSG-33 Annex 5
Roots of Trust	Security primitives composed of hardware, firmware and/or software that provide a set of trusted, security-critical functions. They must always behave in an expected manner because their misbehaviour cannot be detected. As such, Roots of Trust need to be secured by their design. Hardware Roots of Trust are preferred over software Roots of Trust due to their immutability, smaller attack surface, and more reliable behaviour.	NIST SP 800-164
Scenario	A scenario is a refinement of a use case (see Use Case) that shows a sequence of interactions between the system and the user (actor) and/or external systems. It may also show interactions between components internal to the system. A single use case is often associated with multiple scenarios that show alternative interactions, including those that deal with error conditions.	ESA Framework
Security Architecture	The design artifacts that describe how the security controls are positioned, and how they relate to the overall IT Architecture. These controls serve the purpose to maintain the system’s quality attributes, among them confidentiality, integrity, availability, accountability and assurance.	OSA
Security Assessment (Information System)	The ongoing process of evaluating the performance of IT security controls throughout the lifecycle of information systems to establish the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the departmental business needs for security. Security assessment supports authorization by providing the grounds for confidence in information system security.	NIST SP800-39, Reference 7, adapted from security control assessment
Security Assurance Level	Predefined measure of Robustness	ITSG-33 Annex 5, Adapted
Security Implementation Assurance	Confidence-building tasks that aim to ensure that a security control is designed and implemented correctly, and is operating as intended, with the resiliency required to meet an assurance level expected by the business owner. This is also called “Security Assurance” in ITSG-33. Note: Security Implementation Assurance and the Security Strength (of mechanism) both characterize the Robustness level.	Adapted from “Security Assurance” ITSG-33 Annex 5
Security Implementation Assurance Level	The level of assurance achieved by completing a predefined set of security implemntation assurance tasks.	ITSG-33 Annex 5
Security Implementation Assurance Task	An action performed by a security practitioner or an assessor to establish assurance (confidence) in a specific security aspect of an information system. There are two types of security implementation assurance tasks: engineering task and assessment task. Engineering tasks include the production of documentation and may need to satisfy documentation content requirements.	ITSG-33 Annex 5
Security Categorization	The process of determining the security category of business activities, information systems, and IT assets. Notes: a) Security categorization is established by assessing injury to national and non-national interests as a result of failures of business activities to meet their security objectives of confidentiality, integrity, and availability. Information systems and IT assets generally inherit the security category of the business activities that relate to them. b) At the departmental level, security categorization is a continuous activity for categorizing the security of business activities to support the development of security control profiles. At the information system level, security categorization is an activity of the ISSIP for categorizing the security of the information system and its IT assets. For the information system, it is done early in the system development lifecycle. For IT assets, it is done later during the design phases when IT assets have been defined.	ESA Framework
Security Category	A security category characterizes a business activity by the severity of expected injuries (injury level) from compromise with respect to the security objectives of confidentiality, integrity, and availability.	ITSG-33 Annex 5
Security Control	An administrative, operational, technical, physical or legal measure for managing security risk (avoid, counteract or minimize security risks).	CSEC ITSG-33
Security Control (IT Security Control)	A management, operational, or technical high-level security requirement prescribed for an information system to protect the confidentiality, integrity, and availability of its IT assets. Security controls are implemented using various types of security solutions that include security products, security policies, security practices, and security procedures.	NIST SP800-39, Reference 7, adapted
Security Control Enhancement	A statement of security capability to: (i) build in additional, but related, functionality to a basic control; and/or (ii) increase the security strength of a basic security control.	NIST SP800-39, Reference 7
Security Controls Mapping Matrix	A tool used to for compliance and support for SA&A analysts. It provides a complete mapping of security controls to components and threats, and indirectly to patterns and use cases.	ESA Framework
Security Control Objective	A statement, stated in a standardize language, that formalizes what is to be achieved by a security control to satisfy business needs for security. Note: A security control objective should be written in a way that is specific, measurable, attainable, results-oriented, and time-based. A security control objective must be measurable using performance metrics, continuous monitoring, and security assessment. The implementation of security controls aims to fulfill the security control objectives, in order to satisfy the business needs for security. For example, the issuance of an accurate benefits amount to an authorized recipient (citizen) is a business need for security. The security control objectives for this business need for security may be defined as a function of the positive authentication of the recipient with a defined error rate; the positive authorization of the recipient in receiving the benefits payment with a defined error rate; and the preservation of the integrity of the payment transaction event (log of the business process events) and payment record (log of the approved payment and all related information) with high confidence. The exact metrics (e.g., error rate and confidence) associated with the security control objectives need to be defined based on the injuries that could be incurred by the recipient where the business need for security is not satisfied. The metrics may be loose when the injuries are minor (an inaccurate payment amount leads to some inconvenience), or strict when the injuries are serious (an inaccurate amount leads to serious stress and financial loss).	ITSG-33 Annex 5
Security Domain	Within the context of this document, a security domain represents a collection of data, components, systems, devices, networks, etc. that operate under the same security policy. Before moving data between security domains, an assessment should be made to determine whether the security policy of the target domain is sufficient to protect the data. If not, the transfer should be blocked or the data sanitized prior to transfer.	ESA Framework
Security Measure	Refer to the definition of security solution.	ITSG-33 Annex 5
Security Mechanism	A class of security solutions rated in terms of security strength of protection and security implementation assurance to address specific threats. Note: examples of classes of security solutions are: biometrics, digital signature, hot standby, anti-tampering, discretionary access control, packet filtering. Each of these classes can be implemented by various security solutions (e.g., products). For example, biometrics can be implemented using fingerprint, iris or retina scanners.	ITSG-33 Annex 5
Security Objective	Refer to the definitions of confidentiality security objective, integrity' security objective, and availability security objective.	ESA Framework
Security Pattern	A general reusable solution to a commonly occurring problem in creating and maintaining secure information systems. A technique for putting building blocks into context; for example, to describe a re-usable solution to a problem. Building blocks are what you use: patterns can tell you how you use them, when, why, and what trade-offs you have to make in doing so.	OSA, TOGAF
Security Posture	A characteristic of an information system that represents its resilience to a specific set of deliberate attacks and accidental and natural hazards (i.e., selected threats) Note: Resilience relates not only to the capability of the information system to prevent threats but also to detect, respond, and recover from their compromises. A security posture is assessed without regard for unselected threats.	ITSG-33 Annex 5
Security Posture (Very Weak)	This rating means that the potential for selected threats compromising an information system’s IT assets is assessed as severe. This rating indicates that the information system has not been adequately built to prevent, detect, respond, or recover from compromises. The department does not have in place the mechanisms to manage IT security incidents and compromises, or to implement required improvements.	ITSG-33 Annex 5
Security Posture (Weak)	This rating means that the potential for selected threats compromising an information system’s IT assets is assessed as considerable. Issues characterizing an information system having a weak security posture typically include many of the following: The business needs for security are not fully understood and are not well documented; The security controls and requirements are not fully defined and are not well documented; The threats are not fully understood and are not well documented; The implemented security solutions fulfill only partially the security controls and requirements, without adequate assurance; The information system is not operated in a manner to maintain the security posture; The departmental IT security function does not perform adequate monitoring and security assessment; The department does not have mechanisms in place to learn fromthe IT security incidents and compromises and to implement required improvements. These elements increase the potential of threats compromising IT assets due an increase in the number or significance of exploitable vulnerabilities. In the event of a compromise, the information system, IT operations group, and the departmental IT security function cannot effectively detect, respond to, and recover from the compromise.	ITSG-33 Annex 5
Security Posture (Average)	This rating means that the potential for selected threats compromising an information system’s IT assets is assessed as significant. Issues characterizing an information system having an average security posture may include some of the following: The business needs for security are not fully understood or are not well documented; The security controls and requirements are not fully defined or are not well documented; The threats are not fully understood or are not well documented; The implemented security solutions fulfill only partially the security controls and requirements, without adequate assurance; The information systems is not operated efficiently in a manner to maintain the security posture; The departmental IT security function does not perform efficient monitoring and security assessment; The department does not have in place mature mechanisms to learn from IT security incidents and compromises and to implement required improvements. These elements increase the potential of threats compromising IT assets due an increase in the number or significance of exploitable vulnerabilities. In the event of a compromise, the information system, IT operations group, and the departmental IT security function cannot gracefully detect, respond to, and recover from the compromise.	ITSG-33 Annex 5
Security Posture (Strong)	This rating means that the potential for selected threats compromising an information system’s IT assets is assessed as minor. The key characteristics of an information system having a strong security posture include most or all of the following: The business needs for security are well understood and documented; The security controls and requirements are well defined and documented; The threats are well understood and documented; The implemented security solutions fulfill the security controls and requirements, with adequate assurance; The information system is operated in a manner to maintain the security posture over time; The departmental IT security function performs adequate monitoring and security assessments of implemented security controls; In the event of a compromise, the information system, IT operations group, and the departmental IT security function can detect, respond to, and recover gracefully from the compromise,thus minimizing the possibility of incurring injuries, or the severity of injuries; The department learns from incidents and implements any required improvements. This rating indicates that the information system has been adequately built to prevent, detect, respond, and recover gracefully from compromise.	ITSG-33 Annex 5
Security Posture (Very Strong)	This rating means that the potential for selected threats compromising an information system’s IT assets is assessed as very small. The information system fully satisfies business needs for security, has been adequately built to prevent, detect, respond, and recover gracefully from compromise, and is fully documented. The department has in place mature mechanisms to manage incidents and compromise, learns from the experience, and implements required improvements promptly.	ITSG-33 Annex 5
Security Requirement	Any need, stated in a standardized language, that an information system must satisfy through IT security that contributes to achieving a business need for security.	CC, Reference 5, adapted
Security Requirements Traceability Matrix	A tool used to trace the correspondence between high-level business and security requirements through successively more detailed designs. The SRTM provides a cross-reference of system security requirements to components, and indirectly to patterns and use cases.	ESA Framework
Security Risk	An expression of the likelihood and impact of events with the potential to cause injury to information, assets, individuals or services	ESA Framework
Security Safeguard	Refer to the definition of security solution.	ITSG-33 Annex 5
Security Solution	Any security function, product, practice, or procedure that is implemented in an information system to realize a security control.	ITSG-33 Annex 5
Security Strength	The characterization of an implemented security control’s potential to protect IT assets against compromises from threats. Note: As the security strength increases, the effort (cost) or magnitude required by the threat agent to defeat the implemented security control also increases. The protective potential of an implemented security control can be fulfilled only when it is implemented with adequate security implementation assurance.	ITSG-33 Annex 5
Security Testing	Testing conducted during the development phase and the integration and testing phase of the system development lifecycle (SDLC) and that contributes to the establishment of security implementation assurance. Note: During the development phase, security testing includes functional testing of custom security solutions (e.g., functional unit testing) and may also include other forms of testing such a negative functional testing of non-security functions (e.g., fuzz testing of URL against a web application) and the testing of operational procedures to determine usability and maintainability. During the integration and testing phase, security testing includes functional security testing and may also include vulnerability assessments and penetration testing, depending on the security implementation assurance requirements.	ITSG-33 Annex 5
Selected Threat (Selected IT Threat)	Any IT-related threat that has been deemed, through a threat assessment, as relevant to a business activity or an information system and against which a department intends to protect its IT assets. Note: Factors influencing the selection of threats include, for example, the resources and skill set available or not available to the organization to effectively counter a threat; the limited budget allocated to IT security; the assessment that some threat compromises may not lead to injuries; etc. Refer to the definition of threat assessment for more information.	ITSG-33 Annex 5
Shall	Refer to the definition of must.	ITSG-33 Annex 5
Should	This word indicates a goal or preferred alternative. There may exist valid reasons in particular circumstances to ignore a particular item or statement, but the full implications must be understood and carefully weighed before choosing a different course.	RFC 2119, Reference 8, adapted
Solution Architecture	A description of a discrete and focused business operation or activity and how IS/IT supports that operation. A Solution Architecture typically applies to a single project or project release, assisting in the translation of requirements into a solution vision, high-level business and/or IT system specifications, and a portfolio of implementation tasks.	TOGAF
Solution Architecture View	Artifacts developed at this layer include significant detail, are system in scope and have an operational impact.	ESA Framework
Statement of Assessment	Any recognition or acknowledgement that the assessment process has been completed with acceptable results. It can be as simple as a record of decision appearing in the minutes of an engineering or project meeting or as formal as an assessment certificate signed by a security assessor.	ITSG-33 Annex 5
Statement of Sensitivity (SOS)	Identification and categorization of relevant assets according to their confidentiality, integrity and availability values based upon the injuries that may reasonably be expected in the event of a compromise	HTRA
Strategy	The pattern or plan that integrates an organization’s major goals, policies, and action sequences into a cohesive whole.	EABOK Starter Glossary
System Development Lifecycle	The successive stages through which information systems are implemented (i.e., brought into service or delivered). Note: The reference SDLC used in ITSG-33 publications consists of the following phases: 1) stakeholder engagement, 2) concept, 3) planning, 4)requirements analysis, 5) high-level design, 6) detailed design, 7)development, 8) integration and testing, and 9) installation.	ITSG-33 Annex 5
System Lifecycle	The successive stages that information systems pass through from their inception to their end of life. Note: The reference SLC used in ITSG-33 publications consists of the following phases: 1) Initiation, 2) development/acquisition, 3) integration and installation, 4) operations and maintenance, and 5) disposal.	ITSG-33 Annex 5
Target Architecture	The description of a future state of the architecture being developed for an organization. There may be several future states developed as a roadmap to show the evolution of the architecture to a target state.	TOGAF
Token	In the context of GC ICAM, something that an individual or NPE possesses and controls that is used to authenticate that individual or NPE. A token can be thought of as a secure container for a secret (i.e., Token Secret) that is used to generate a Token Authenticator. Additional information regarding these concepts can be found in NIST SP 800-63-2, Section 6.	GC ICAM
Transition Architecture	A formal description of one state of the architecture at an architecturally significant point in time. One or more Transition Architectures may be used to describe the progression in time from the Baseline to the Target Architecture.	TOGAF
Transition Strategy and Roadmap	Outlines an incremental approach to evolve from current state to the target architecture. Each transition state described in a roadmap provides a clear milestone with measurable business value.	ESA Framework
Technical Context	A component of a departmental or domain security control profile. A technical context defines in general terms the technical environment that might influence the selection of the profile’s security controls.	ITSG-33 Annex 5
Technical Security Control	A security control implemented and executed by information systems primarily through security mechanisms contained in hardware, software, and firmware components. Note: A technical security control is dependent on the proper functioning of the information system for effectiveness. Also, some operational aspects may be included in the implementation of the control (e.g., manual assessment of log monitoring results).	NIST FIPS 200, Reference 11, adapted
Threat	An event or act, deliberate or accidental, that could cause injury to information, assets or individuals.	ITSG-33
Threat Actor	A threat actor is an individual or organization that conducts or may conduct an attack against an information system.	ITSG-33
Threat Agent	A threat agent is an autonomous entity that acts on behalf of a threat actor. A threat agent can be a human, electronic, or mechanical device that can communicate with a threat actor and act on instructions. The degree of autonomous behaviour varies with the complexity of the threat agent.	ITSG-33
Threat Assessment	The process of identifying and qualifying threats faced by an organization’s business activities and information systems supporting them. Note: A threat assessment will identify all threats faced by an organization. The selected threats are the ones that the organization chooses to address and are documented explicitly. Threats that an organization may face, but that are not addressed for various reasons, such as cost constraints, technical constraints, or operational constraints, are also documented explicitly (i.e., unselected threats).	ITSG-33 Annex 5
Threat and Risk Assessment (IT-Related TRA)	The process of identifying and qualifying threats and risks to IT assets and of implementing or recommending additional security controls to mitigate risks that are deemed unacceptable.	ITSG-33 Annex 5
Threat Context	A characteristic of a departmental or domain security control profile. A threat context defines the selected threats of relevance to the domain’s business activities.	ITSG-33 Annex 5
Threat Event	The occurrence of an actual incident in which a threat agent exploits a vulnerability on an information system (which may or may not be successful at achieving the threat actor’s objectives) with potentially adverse effects on an IT asset of value.	ITSG-33
Trace/Tracing(IT)	Perform an informal correspondence analysis between two entities with only a minimal level of rigour. Tracing involves documenting a basic correspondence between the elements of successive specifications.	ITSG-33 Annex 5
Use Case	A function offered by the system that results from, or results in, interaction between the system and a user (actor) and/or external systems. A use case identifies the purpose and nature of the function, but contains no details of how it is implemented (see Scenario).	ESA Framework
View	The representation of a related set of concerns. A view is what is seen from a viewpoint. An architecture view may be represented by a model to demonstrate to stakeholders their areas of interest in the architecture. A view does not have to be visual or graphical in nature.	TOGAF
Viewpoint	A definition of the perspective from which a view is taken. It is a specification of the conventions for constructing and using a view (often by means of an appropriate schema or template). A view is what you see; a viewpoint is where you are looking from - the vantage point or perspective that determines what you see.	TOGAF
Vulnerability	An inadequacy related to security that could increase susceptibility to compromise or injury.	ESA Framework
Vulnerability Assessment	A determination of the existence of information system vulnerabilities.	MITS, Reference 3
Work Package	A set of actions identified to achieve one or more objectives for the business. A work package can be a part of a project, a complete project, or a program.	TOGAF

References

[Reference 1] Communications Security Establishment Canada and the Royal Canadian Mounted Policy. Harmonized Threat and Risk Assessment (TRA) Methodology. 23 October 2007.

[Reference 2] Treasury Board of Canada Secretariat. Policy on Government Security.1 July 2009.

[Reference 3] Treasury Board of Canada Secretariat. Operational Security Standard: Management of Information Technology Security. 31 May 2004.

[Reference 4] Treasury Board of Canada Secretariat. Business Transformation Enablement Program (BTEP). Glossary. April 2006.

[Reference 5] Common Criteria for Information Technology Security Evaluation Part 3: Security Assurance Requirements. CCMB-2009-07-001, Version 3.1, Revision 3. July 2009.

[Reference 6] Treasury Board of Canada Secretariat. Directive on Departmental Security Management. 1 July 2009.

[Reference 7] National Institute of Standards and Technology. Information Security. Managing Information Security Risk: Organization, Mission, and Information System View. NIST Special Publication 800-39, March 2011.

[Reference 8] Internet Engineering Task Force. RFC2119 Key words for use in RFCs to Indicate Requirement Levels. March 1997.

[Reference 9] Oxford Dictionaries Online (ODO). http://oxforddictionaries.com

[Reference 10] Treasury Board of Canada Secretariat. Security Organization and Administration Standard. 1 June 1995.

[Reference 11] National Institute of Standards and Technology. Minimum Security Requirements for Federal Information and Information Systems FIPS PUB 200. March 2006.

[Reference 12] FICAM Glossary - US Federal Identity, Credential, and Access Management (FICAM) Roadmap and Implementation Guidance, Version 2.0, Appendix B, December 2, 2011

[Reference 13] NIST SP 800-63-2 - National Institute of Standards and Technology Electronic Authorization Guideline, August 2013

[Reference 14] OMB M-04-04: Executive Office of the President Office of Management and Budget Memorandum on E-Authentication Guidance for (US) Federal Agencies, December 16, 2003

[Reference 15] ICAM Lexicon: Identity, Credential and Access Management Lexicon, National Security Systems Identity, Credentialing and Access Management Focus Group, Version 1.0, 30 May 2013

[Reference 16] Directive on Identity Management – Directive on Identity Management, Government of Canada, July 1, 2009

[Reference 17] Standard on Identity and Credential Assurance – Standard on Identity and Credential Assurance, Government of Canada, February 1, 2013

[Reference 18] Guideline on Defining Authentication Requirements – Guideline on Defining Authentication Requirements, Government of Canada

[Reference 19] Draft Guideline on Identity Assurance – draft Guideline on Identity Assurance, Government of Canada, January 21, 2014

[Reference 20] Open Security Architecture Glossary (http://www.opensecurityarchitecture.org/cms/definitions/glossary), Accessed July 24th 2014