Security Playbook for Information System Solutions

1.1 Purpose

This document is a “playbook” for federal departments and agencies and outlines a set of security tasks for consideration when designing and implementing solutions for Government of Canada (GC) information systems in cloud environments.

The goal of this playbook is to:

• help projects develop a reasonable level of security assurance when implementing an information system solution
• help facilitate security assessment and authorization (SA&A) activities
• ensure that projects implement security considerations that conform with:
  • the Directive on Security Management
  • the Direction on the Secure Use of Commercial Cloud Services: Security Policy Implementation Notice (SPIN) 2017‑01

This playbook:

• focuses on a set of preliminary baseline security controls as a starting point
• is built around agile and lean principles
• is aligned with the guidance in IT Security Risk Management: A Lifecycle Approach (ITSG-33)
• does not prescribe a system development methodology

1.2 Scope

This playbook:

• focuses on software information system solutions being deployed in cloud environments
• addresses the specific scope of responsibility for the application components of information system solutions that projects are implementing in addition to cloud services
• assumes that security controls at the infrastructure layers have been implemented, in addition to the cloud service provider (CSP) environment, and are therefore inherited by the information system solution

Project teams should validate any assumption of security control inheritance with their departmental IT security authorities.

1.3 Stakeholders

This playbook is to be used by individuals who act in the following roles and participate in the project activities outlined in this playbook:

• the product owner^{Footnote 1}
• the authorizer (if different than the product owner)
• the project team lead
• the architecture owner
• the security architecture owner (if different than the architecture owner)
• project team members
• the security assessor
• the operations manager

Definitions of these roles can be found on the Disciplined Agile website and in Annex 1 of ITSG-33.

2.1 Baseline security controls

This playbook focuses on a preliminary set of baseline security controls that are suitable for application components of information system solutions that have a security category up to and including Protected B, medium integrity and medium availability (PBMM). This selection of security controls, listed in the appendix, provides a starting point for project teams and was selected to achieve the following objectives:

• comply with the applicable mandatory procedures in the Directive on Security Management
• meet the requirements of the Direction on the Secure Use of Commercial Cloud Services: Security Policy Implementation Notice (SPIN)
• address the Communications Security Establishment’s (CSE’s) Top 10 Security Actions
• align with Government of Canada Security Control Profile for Cloud-Based GC Services
• focus on the selection of security controls to those implemented in software components of information system solutions
• achieve threat protection objectives specified in the ITSG-33 generic PBMM profile and the Government of Canada Security Control Profile for Cloud-Based GC Services

Project teams will need to tailor the applicable profile for their information system solution. This tailoring may result in the selection and implementation of additional security controls or enhancements to satisfy departmental security requirements or increase mitigation of specific threats.

In the security control catalogue, increasing levels of strength in security mechanisms can be achieved by implementing enhancements to base security controls. As a general rule, for a given security control, the more enhancements are implemented, the stronger the security mechanism. For example, implementing enhancement 1 of base security control IA-2 increases the strength of the identification and authentication mechanism, such as enforcing a second factor of authentication for privileged accounts.

2.2 Inherited security controls

The US National Institute of Standards and Technology defines common security controls as “security controls whose implementation results in a security capability that is inheritable by one or more organizational information systems.” Security controls are deemed inheritable by information systems or information system components when systems or components receive protection from implemented controls that were developed, implemented, assessed, authorized, and monitored by entities other than those responsible for the systems or components. Examples of security controls that information systems and components could inherit include:

• IT security policies
• security awareness and training
• incident response plans
• physical access to facilities
• personnel security
• rules of behaviour

There are also a variety of technology-based security controls, which are typically implemented as common security controls and which can be used in information systems. Examples of technology-based, common security controls include:

• public key infrastructure (PKI) systems
• access control systems
• boundary protection systems

2.3 System development lifecycle process

Project teams using agile or more traditional waterfall methodologies should be able to use this playbook. Regardless of the methodology used, this playbook supports the integration of security activities within a project and throughout the system development lifecycle (SDLC) process by providing a set of tasks that project teams can add to their work items backlog or schedule.

If personal information is involved, project teams must ensure that privacy requirements are identified and appropriately addressed in their solutions in consultation with their departmental access to information and privacy (ATIP) office.

Project teams can learn more about security in IT projects in Applying ITSG‑33 guidance to IT projects (ITSG‑33 Primer for IT Projects), which is available on the ESA Tools and Templates GCpedia page (accessible only on the Government of Canada network).

2.4 Enterprise alignment

Project teams should consult with their departmental IT security and enterprise architecture or enterprise security architecture teams to:

• identify applicable security standards and opportunities for security solution reuse
• ensure enterprise alignment

2.5 Threat modelling

Project teams need to perform threat modelling to ensure that all threat exposures within their information system solutions are covered by appropriate designs and security mechanisms. The following links are resources that provide an introduction to threat modelling:

• Security Threat Models: An Agile Introduction from Agile Modeling
• Introduction to Microsoft’s Security development Lifecycle (SDL) Threat Modelling presentation

In addition, departmental security authorities may want to document residual risks associated with the information system solution that a project is implementing against departmental threats. In the GC, the methodology of choice for that purpose is the Harmonized TRA Methodology (TRA-1). Threat modelling methodologies are typically not suited for assessing residual risks because they:

• tend to focus on threats and their mitigation
• do not include the qualification or quantification of risks

However, risk assessments and threat modelling can work together to satisfy both project-level and department-level requirements. Figure 1 presents an example of these methods working together in alignment with the guidance in ITSG‑33.

Figure 1 - Text version

Figure 1 shows the relationship between department-level and project-level activities for threat assessments.

At the department level, the departmental threat assessment and the domain security control profiles are inputs into a generic threat and risk assessment.

The generic threat and risk assessment:

• generates threat data, which are used to perform threat modelling at the project level
• supports the assessment and documentation of residual risk
• is applied to the threat mitigation results

The domain security control profiles are used to conduct the steps at the project level. These steps are:

• select the applicable security control profile
• tailor the security controls, from which are derived the system-specific security controls
• perform solution engineering and design
• perform threat modelling, which informs the threat mitigation results

In Figure 1, departmental security authorities use a generic threat and risk assessment (TRA) to assess residual risks associated with the information system. The project team:

• selects an applicable security control profile and tailors the security controls for the information system
• models threats as part of the solution engineering and design processes to ensure that secure design patterns are adopted and appropriate security mechanisms are selected and implemented
• adjusts its threat model based on the threat data in the generic TRA

As the solution engineering and design processes progress:

• the project team informs departmental security authorities of threat mitigation results
• departmental security authorities use these results to assess and document residual risks

The right threat modelling method to use and exactly when threat modelling occurs in a project is the subject of debate. Project teams should use a method that they understand and that works well with their SDLC process.

2.6 Security assurance

Project teams need to be concerned with security assurance^{Footnote 2} for the:

• information system solutions that they implement
• underlying cloud services

For information system solutions, project teams can establish assurance by:

• incorporating security in project documentation
• completing security verification and validation tasks

Projects teams also need to produce verifiable outputs, such as testing plans and results, to support security assessment and authorization (SA&A). For more information on these topics, see Applying ITSG‑33 guidance to IT projects (ITSG‑33 Primer for IT Projects), which is available on the ESA Tools and Templates GCpedia page (accessible only on the Government of Canada network).

For the underlying cloud services, project teams can obtain security assurance by asking for SA&A evidence, either directly from internal service providers (for example, in the department or at Shared Services Canada), or through request for proposal (RFP) requirements or contractual clauses for commercial cloud service providers. See the Government of Canada Cloud Security Risk Management Approach and Procedures for more information on the SA&A process for commercial cloud services.

It is assumed that any underlying and external service used by a solution has been established through an approved security assurance process.

2.7 Security design considerations

While these security controls provide a strong foundation for the protection of most GC information system solutions that have a maximum security category of PBMM, project teams need to consider other factors when designing and building their solutions. These factors are:

• business needs for security and other business-related requirements for which specific security controls are prescribed
• design constraints, such as network security zoning, multi-tiered application structures, security design patterns and other architectural requirements
• the requirement for additional security controls to conform to departmental security standards or address specific threats
• the need to select stronger security mechanisms to address increasing levels of threat capabilities or impacts

4.1 Related policy instruments

• Directive on Security Management
• Direction on the Secure Use of Commercial Cloud Services: Security Implementation Notice (SPIN) 2017-01

4.2 Additional references

• Government of Canada Security Control Profile for Cloud-based GC Services
• Government of Canada Cloud Security Risk Management Approach and Procedures
• Security categorization guide and tool (accessible only on the Government of Canada network)
• Government of Canada Cyber Security Event Management Plan (GC CSEMP) 2018
• Concept case for digital projects
• Enterprise security architecture (ESA) template guides (accessible only on the Government of Canada network)
• Guideline on Defining Authentication Requirements
• Guideline on Identity Assurance
• Considerations for Cryptography in Commercial Cloud Services(accessible only on the Government of Canada network)
• IT Security Risk Management: A Lifecycle Approach (ITSG‑33)
• Guidance on Securely Configuring Network Protocols (ITSP.40.062)
• Baseline Security Requirements for Network Security Zones in the Government of Canada (ITSG-22)
• Network Security Zoning: Design Considerations for Placement of Services within Zones (ITSG-38)

Abbreviations

DSM: Directive on Security Management
SPIN: Security Policy Implementation Notice
OWASP: Open Web Application Security Project