GO-ITS 42 Security Requirements for Enterprise Vulnerability Management

Approvals and version history

1. Foreword

Government of Ontario Information Technology Standards (GO-ITS) are the official publication on the IT standards adopted by the Ministry of Government and Consumer Services (MGCS) for use across the government’s IT infrastructure.

These publications support the responsibilities of the Ministry of Government and Consumer Services (MGCS) for coordinating standardization of Information & Information Technology (I&IT) in the Government of Ontario.

In particular, GO-ITS describe where the application of a standard is mandatory and specify any qualifications governing the implementation of the IT standards.

2. Introduction

Background and rationale

GO ITS 42 - Security Requirements for Enterprise Vulnerability Management outlines an Enterprise Vulnerability Management Practice (EVMP) and describes parameters, features, or configurations associated with managing vulnerabilities across the Ontario Public Service (OPS). Program areas and their IT service provider partners are responsible for the implementation of appropriate safeguards based on an assessment of the risks involved.

GO ITS 42 – Security Requirements for Enterprise Vulnerability Management will be reviewed on an ongoing basis to take into account trends in the cyber security industry and best practice guidance with respect to Vulnerability Management. Changes or additions to the GO ITS 42 – Security Requirements for Enterprise Vulnerability Management Standard will be established in writing and communicated to all appropriate personnel upon approval.

Vulnerability management (VM) is defined as a process cycle for finding, assessing, remediating, and mitigating security weaknesses in IT systems. As part of this process, policy and scope definition, assessment, remediation, mitigation, and monitoring are required^{footnote 1[1]}.

Effective vulnerability management assists in reducing organizational and systemic vulnerabilities across the enterprise, including our own networks, as well as other critical systems and assets. Through technical capabilities, cyber security information, and other assistance, stakeholders are empowered to better manage and mitigate their cybersecurity risks.

This document is one in a series that supports organization risk management, requirements, processes and best practices for the protection of Government of Ontario information assets, networks, and computer systems. The objective of this document is to outline the requirements of Vulnerability Management within an EVMP so that the organization is capable of identifying, assessing, remediating, mitigating, and monitoring vulnerabilities on an ongoing basis.

Target audience

The target audience for this document includes, but is not limited to, operational staff, system administrators, technical managers, functional managers, cyber security specialists, program owners, users and other I&IT staff members who are responsible for managing Government of Ontario information systems.

Scope

This document is intended to inform the implementation of an EVMP across the Government of Ontario.

In scope

GO ITS 42 – Security Requirements for Enterprise Vulnerability Management applies to:

• Any device (whether connected to the GO NET or externally hosted) that is responsible for storing, processing, transmitting, or handling Ontario Government information or that is used to deliver Ontario Government services, including:
  • Information & Information Technology (I&IT) Servers
  • User Endpoints
  • Cluster Managed Devices
  • Network devices or other devices with network interfaces (i.e. Multi-function devices)
• Common infrastructure, vendor managed devices, and appliances (network, server, email, firewall, internet, etc.) that are involved in OPS service delivery

Requirements apply to all ministries, IT Clusters and corporate areas, former Schedule I and IV agencies, and vendors/third parties (including any information technology system or network that processes ministry and agency information) under contract to the Ontario Government unless exempted in a Memorandum of Understanding.

The Cyber Security Division (CSD) or any successor organization should be contacted if the requirements in this document need clarification, or if is not clear whether this standard applies to a given situation.

Out of scope

This document has no specific out of scope requirements associated with it. It is intended as a baseline for all Government of Ontario I+IT projects and services.

Applicability statements

Organization

All adjudicative and advisory agencies are subject to Government of Ontario IT Standards.

All other agencies that are using Ontario Public Service (OPS) information and information technology products or services are required to comply with Government of Ontario IT standards if they are subject to the either the Management and Use of I+IT Directive or Government of Ontario IT Standards by Memorandum of Understanding.

As new GO IT standards are approved, they are deemed mandatory on a go-forward basis meaning at the next available project development or procurement opportunity as applicable.

When implementing or adopting any Government of Ontario IT standards or IT standards updates, ministries, I+IT clusters and applicable agencies must follow their organization’s pre-approved policies and practices to ensure that adequate change control, change management, risk mitigation, and control selection mechanisms are in place and employed.

Other applicability

Interconnected computer systems and networks are necessary for government operations, and the actions of one environment can influence the security of another. Changes to a computer-based environment in one ministry or cluster may affect the environment in another. Therefore, the measurement of risk must be based on an “enterprise-wide” evaluation and must include input and representation from a number of sources.

These considerations make it mandatory that every Ontario Public Service (OPS) employee complies with security requirements. Details on responsibilities for members of the Ontario Public Service are outlined in the Corporate Policy on Information and Information Technology (I&IT) Security and the Information and the Acceptable Use of I+IT Resources Policy.

Additionally, security requirements and procedures must also form part of any contract or agreement related to IT systems used by the Ontario government and should apply with equal force to third-party contractors (and sub-contractors).

Terms

Within this document, certain wording conventions are followed. There are precise requirements and obligations associated with the following terms:

3. Technical specification

The Management and Use of Information & Information Technology (I&IT) Directive and the Government of Ontario’s Information Sensitivity Classification Policy and associated guidelines require that confidentiality, integrity, and availability of information and information systems is safeguarded.

Vulnerability Management must continuously be undertaken to effectively secure an organization’s IT infrastructure and environment. Vulnerabilities are weaknesses in an information system, system security procedure, internal control, or implementation that could be exploited by a threat actor. Vulnerabilities are discovered daily in software (i.e., memory violations, input validation errors, etc.) and systems (i.e., open ports, susceptibility to malware infections, etc.) which increases the risk to the organization if not properly addressed.

In order to mitigate these vulnerabilities, an effective EVMP is required to ensure that all I&IT systems are safeguarded in a timely manner.

Background

The Ontario Public Service’s enterprise IT environment is extremely diverse as various platforms, application versions, software development models (i.e., open source vs. closed source), and commercial off-the-shelf (COTS) products co-exist. An Enterprise Vulnerability Management Practice (EVMP) is necessary to safeguard corporate I&IT information and IT assets and reduce the likelihood of potential exploitation of software and system vulnerabilities. An Enterprise Vulnerability Management Practice (EVMP) is intended to outline a manageable and implementable risk-based framework to address vulnerabilities in software and systems as they are identified.

Risk management

A risk-informed approach must be taken with respect to Enterprise Vulnerability Management and the mitigation or remediation of identified vulnerabilities.

I&IT risk management is a joint responsibility between I&IT and ministries. Both I&IT and ministries must work together to ensure that proper due diligence is undertaken to identify and mitigate any risks to information and information systems. Risk management is a continuous process that occurs throughout the entire life cycle of information and information systems; new vulnerabilities are detected daily. I&IT risk management requires that particular attention must be paid to mitigate and manage shared risks that could impact consolidated infrastructure or shared systems (i.e., systems that impact more than one program, ministry or cluster). All identified exposures that represent a privacy risk must be assessed by the Privacy Office, or equivalent, in accordance with the Privacy Impact Assessment process.

Table 3.1 – Cyber Risk Approval Authorities

* If the new client is altering the risk profile of the enterprise solution or service, other program areas that are already using the solution/service must be notified of the revised risk profile

Approach to rating the severity level of a vulnerability

A threat/risk matrix is used to classify severity levels of vulnerabilities based on a scale that considers:

• Exposure Level: Number and type of systems potentially affected by a malicious technique or payload that exploited the identified vulnerability, with consideration for factors such as:
  • Number of sites/devices potentially impacted;
  • Number of mission or time critical systems potentially impacted;
  • Number of systems potentially impacted; and
  • Geographic distribution of those systems/devices.
• Impact Level: Damage to systems that a malicious program taking advantage of the identified vulnerability could cause. Included in this metric are factors such as:
  • Ability of existing installed technology to mitigate the threat/risk;
  • Risk of critical server or network traffic performance degradation;
  • Potential for data destruction/modification or release of confidential information;
  • Loss of productivity;
  • Compromise of security settings; and
  • Cost or effort required to recover or repair damage.
  • The rate of distribution or speed at which a malicious program spreads may be used by Cyber Security and its IT partners to elevate Severity Levels.

Cyber Security must rate the severity level of a vulnerability; no self-assessments are permitted

The following table summarizes the classification of Severity Levels:

Table 3.2 – Severity Threat/Risk Matrix

* Levels are determined by Cyber Security with CVSS Scorecard and Severity vs Impact Matrix in Appendix 9.3

Table 3.3 – Definition of Severity

*For associated Matrix that determines timelines, please see appendix 9.3 and Vulnerability Management section below

Enterprise Vulnerability Management Practice requirements

Various components exist within an EVMP. Controls should be in place to address the various types of vulnerabilities. Vulnerabilities and any associated risk(s) that cannot be resolved must be appropriately recorded and managed.

IT Asset Management

IT Asset Management (ITAM) is the set of business practices that join financial, contractual and inventory functions to support life cycle management and strategic decision making for the IT environment. Assets include all elements of software and hardware that are found in the business environment. ITAM should include an inventory control mechanism that is kept up to date; i.e. CMDB. The effective use of ITAM will have a significant impact on the security of a network. Some key areas where ITAM can improve security are; timely assessment of vulnerability, accurately estimating down-time, securing and fixing affected assets, and enabling faster recovery from an incident.

Asset Identification

Best practices indicate that a detailed inventory within an EVMP must be established and maintained to ensure that all IT assets are accounted for. Completion of detailed inventory metrics will help facilitate the EVMP, allow the organization to respond more proactively and provide compliance reports.

The following requirements must be addressed for asset identification within an EVMP:

• OPS I&IT assets must be identified, proactively monitored, and capable of providing reporting and compliance metrics in a consistent and repeatable manner. OPS I&IT assets include, but are not limited to; desktops, notebooks, servers (physical or virtual), storage area networks, switches, smartphones, etc.
• The following details must be recorded if available:
  • Last logon date
  • Last logged on user
  • Asset Name
  • Asset Owner
  • Asset Tag Number
  • BIOS/Firmware version number
  • Operating System including version number
    • All installed software including, but not limited to, APIs, run time, package, or image, including version
  • Date Last Queried.
• An up-to-date and enterprise repository of all OPS enterprise applications must be managed and maintained with priority given to applications that are considered mission or business critical or High Sensitivity.
• The following details must be recorded if available:
  • Accountable CIO
  • Application Owner
  • Application Custodian
  • Application Criticality Ranking
  • Sensitivity of Information
  • Hostname, IP address and URL
  • Public Facing or Internal Use
  • Go-Live date
  • Operating System including version number
  • Firmware version number
  • Installed software including, but not limited to, APIs, run time, package, or image, including version
• An up-to-date and enterprise repository of all I&IT Servers, including virtualized servers must be managed and maintained with priority given to servers that are considered mission or business critical or that host High Sensitivity information.
• The following details must be recorded if available:
  • Accountable CIO
  • Server Owner
  • Server Custodian
  • Server Criticality
  • Sensitivity of Information
  • Hostname, IP Address and URL
  • Operating System including version number
  • Firmware version number
  • Installed software including, but not limited to, APIs, run time, package, or image, including version
• I&IT Servers and I&IT Endpoints must be scanned on a monthly basis to update inventory metrics and evaluate current Vulnerability status
• I&IT Servers and I&IT Endpoints must be able to be scanned on an on-demand basis in the event of an incident
• Other network appliances must be scanned on a quarterly basis to update inventory metrics and evaluate current Vulnerability status^{footnote 2[2]}
• I&IT assets that have not established an active connection to the GO-NET for longer than sixty (60) business days should be quarantined or isolated until devices are scanned and mitigation solutions are applied

Operations and maintenance framework

All OPS I&IT assets (software and hardware) must be included in documented planned maintenance windows at regular intervals, where any updates (BIOS, OS, Firmware, Security Patches, etc.) can be performed. The intent of the maintenance window is to reserve time when systems/services can be taken off-line for non-emergency preventive maintenance only.

• Where a maintenance window is not currently feasible, rationale must be documented and approved by data owners then filed with Cyber Security
• Attempts must continue to be made until the scheduled updates have been successfully applied
• All program areas must have a documented plan to address an emergency or unexpected need for a maintenance window

End-of-life assets

Products that are no longer supported by vendors are said to be end-of-life and represent a risk to the I&IT environment. End-of-Life Assets are comprised of all software and hardware elements of the environment. The following guidance is recommended for end-of-life products across the OPS I&IT environment:

• Any IT Asset that includes an operating system, firmware, or any type of software must be supported by a vendor that provides on-going security updates. If the vendor no longer supports the asset with security updates the asset will be considered non-compliant
• Program areas that are using end-of-life software in production environments must have a documented plan to migrate to a supported version of software
• Program areas that are using end-of-life hardware in production environments must have a documented plan to migrate to supported hardware
• Any maintenance contracts purchased for continued extended support from vendors must be documented along with the expiry date of the extended support plan
• Where migration to supported software or hardware is not currently feasible, additional safeguards must be implemented and documented to reduce the potential exploitation of any identified vulnerabilities

Baseline Configurations

Baseline configurations must be established for all I&IT assets. The following guidance is recommended for baseline configurations across the OPS I&IT environment:

• I&IT assets must be configured according to consistent, applicable, relevant, and secure baseline configurations
• I&IT assets must be hardened, as per applicable industry best practices, and relevant build books
• Baseline configurations for all I&IT assets should be documented
• Baseline configurations should be kept up-to-date and reviewed annually, or whenever major changes have been made in a system configuration or composition
• Baseline configurations should be used to evaluate benchmark metrics across all I&IT assets
• All I&IT endpoint applications should be installed from an ITS supported approved software list
• Periodic review of endpoint applications should be conducted to identify all unapproved software that may be installed

Vulnerability Identification & Assessment

The following guidance must be used to identify and assess vulnerabilities across the OPS I&IT environment:

• Threat intelligence services or vendor announcements, and publications must undergo daily monitoring by Cyber Security operations
• Vulnerabilities must be identified in a consistent and repeatable way based on information from threat intelligence services or vendor announcements, and publications
• Vulnerabilities should be assessed using the most recent Common Vulnerability  Scoring System SIG (CVSS) calculator^{footnote 3[3]}
• Identified vulnerabilities must be analyzed to determine the potential impact to the organization
• Remediation should be considered based on cost, effectiveness, and if any compensating controls are in place
• Bundled vulnerability alerts must be assessed in order to identify any critical or high vulnerabilities that may exist within the release
• Identified vulnerabilities must be communicated to accountable stakeholders
• Remediation for identified vulnerabilities should be assessed and prioritized in a consistent and repeatable way using Qualitative or Quantitative Risk Analysis where:
  • Consideration is given about any compensating controls in place
  • Relevance of the vulnerability to the OPS environment is evaluated
  • Assess the likelihood and impact, should the identified vulnerability be exploited
• Remediation of identified vulnerabilities must be prioritized based on the level of risk posed to the enterprise^{footnote 4[4]}
• Remediation of identified vulnerabilities must be documented and communicated to data/application owners with an estimated time for mitigation
• Remediation of identified vulnerabilities must have an appropriate response communicated to data/application owners with a plan to mitigate
• Where no security update is available or deployment would result in an unacceptable level of risk, compensating controls must be implemented to prevent the exploitation of any identified vulnerabilities

Vulnerability monitoring

The following guidance is recommended to monitor vulnerabilities across the OPS I&IT environment:

• Vulnerability scans must be performed and vulnerability management reports must be produced on a monthly basis
• Quarterly scans should be conducted on the I&IT environment to monitor the status of identified vulnerabilities and if they have been mitigated
• An up-to-date and enterprise repository of all vulnerability remediation and mitigation plans should be available
• Risk Management reports should include enterprise Vulnerability Management efforts

Vulnerability remediation and mitigation

I&IT assets which are known to have identified vulnerabilities represent a risk, whether to one program or to the enterprise. The following guidance is recommended to remediate and mitigate vulnerabilities across the OPS I&IT environment:

• Individuals who are accountable for vulnerability management, remediation and mitigation must be identified for each cluster and corporate area, and must attend monthly meetings to discuss remediation and mitigation status updates
• Identified vulnerabilities that exist in the OPS environment must be mapped to specific mission or business critical services/systems, where applicable
• Identified vulnerabilities with a rating of critical or high must have an approved mitigation action plan assigned and communicated to accountable individuals
• Approvals for any non-compliance with routine vulnerability management processes must be sought from both the accountable ministry or agency program area and applicable I&IT area (see table 3.1)
• All outstanding identified vulnerabilities that cannot be mitigated within the outlined timeframe based on priority or severity must be documented through a Cyber Security Vulnerability Deferral or Deferral of Risk Treatment process
  • Provide business justification, alternate timeframe, strategies, and compensating controls. Some common attributes to be documented are:
    • Date
    • Duration of deferral
    • Which systems or services are impacted (including related systems/services)
    • Assessment of Vulnerability against the environment
    • Compensating controls in place (i.e. safeguards)
    • Target mitigation date
    • IT and Ministry approvals (as per table 3.1)

Implementing mitigations

The following guidance is recommended for implementing mitigations in an EVMP across the OPS I&IT environment:

• All standard changes (configuration and testing) must be implemented promptly and tested prior to installation if change control requirements apply to the environment.
• Testing must be validated to ensure that changes have been successfully applied
• For less severe vulnerabilities, the Change Request (CRQ) process must be followed as outlined in GO ITS 35 – Enterprise Change Management Standard – for more severe/higher criticality vulnerabilities, the incident management process (documented in GO ITS 37 – Enterprise Incident Management Process) will be followed^{footnote 5[5]}
• Failed changes that result in a disruption of services must be handled in accordance with the OPS Change Management process as documented in GO-ITS 35
• Rollback plans must be included and tested to ensure that I&IT assets can be recovered to a functional state
• Emergency mitigations must be authorized by accountable stakeholders

Vulnerability management suggested controls

In most cases, a single control cannot be used to mitigate all potential vulnerabilities. Effective vulnerability management relies on a defence-in-depth approach where multiple layers of security controls are put into place throughout a system or IT environment. Enhancing vulnerability management practices with the following suggested controls could aid in the remediation of potential threats.

Administrative Security

Administrative Security, also referred to as Access Control, pertains to controls that are put in place to prevent select users from inadvertently or deliberately compromising the confidentiality, integrity, and availability of data or IT systems. Users that possess elevated or privileged accounts or systems that are operating in a privileged state could be susceptible to running unintended executables. For full details regarding Administrative Security please see GO ITS 25.0– General Security Requirements (Section 3.1.1 and 3.1.2).

Vulnerability Management

Vulnerability Patches are defined as pieces of software that are designed to correct errors, such as security vulnerabilities, bugs or other performance/stability issues that may reside in firmware, operating systems, or applications. Vulnerability Management is the process by which security fixes and application security patches or updates are collected, analyzed, tested, and implemented throughout the I&IT environment.

Upon the identification of a vulnerability that has been rated as a Severity 0 or Severity 1 level, a number of actions must be taken to address this threat. Cyber Security creates a parent change request (CRQ) with all relevant information, including all known assets (physical and application assets), and the Common Vulnerability Scoring System (CVSS) result. Once created, CSD sends the CRQ to all change stakeholders. At the same time, the Priority 1 Incident Response process - as detailed in GO-ITS 37 - Enterprise Incident Management Process - will be initiated and will dictate the actions to mitigation.

Should the asset owner(s) identified be incorrect or unresponsive, CSD and ITS must take steps (that include consultations of impacted executives), to quarantine the asset(s) until the vulnerability patch can be applied or the vulnerability is otherwise managed. In the most severe instances, where taking these steps does not mitigate the vulnerability, additional efforts to mitigate the risk must be taken.

A typical formal Vulnerability process involves the following steps:

• Receive notice

This will come in the form of an announcement from the vendor(s), partners, third parties, or via general news sources.

• Determine applicability

Not every Vulnerability Patch may be applicable to every client who owns the targeted system. A Vulnerability analysis process, with an owner/role specifically assigned to perform this function for each Vulnerability, must be undertaken.

• Determine potential impact

If a Vulnerability has been determined necessary/applicable, the next step is to figure out what other systems might be affected if the Vulnerability Patch is implemented and what additional risks patching might introduce.

• Test

All Vulnerability Patches should be packaged and applied in a test environment, to determine whether they will cause any interoperability problems in the production environment. The testing environment should be logically, or if possible physically, separated from the production environment.

• Perform backup of target system

Even after testing, the Vulnerability Patch may cause unforeseen issues upon actual implementation. Rollback capability, to a previous working version, must be available to ensure that no data/transactions/capabilities are lost, and that system integrity is maintained.

• Apply Vulnerability Patch

This should be performed in accordance with the vendor/issuer instructions, industry best practices, and OPS standards.

• Confirm installation

Confirmation can be performed using automated tools to confirm the presence of the successfully deployed Vulnerability Patch on the target system. A separate system should be used for deployment and confirmation.

• Solicit/receive user feedback

The Vulnerability Patching team should be ready to take input from the user community about possible operational changes/problems/issues that arise from the Vulnerability Patch.

• Prepare for rollback

Significant negative impact to the operational environment might entail rollback to a previous (pre-Vulnerability Patch) machine state. Because rollback would, of course, involve accepting the additional risk the Vulnerability Patch was meant to obviate, this decision requires appropriate business owner involvement.

• Document

Everything must be annotated for later reference; Vulnerability Patching records must be included in the asset inventory, as Vulnerability management is a form of Change Management.

The following guidance is recommended for Vulnerability management across the OPS I&IT environment:

• Vulnerability Patch schedules must be developed and documented that guides the normal application of Vulnerability Patches and updates to systems
• Where possible, all new Vulnerability Patches must be validated to ensure they are signed by the vendor or hashed signatures/certificates of origin are provided
• Vulnerability Patches must be deployed in a consistent and repeatable manner across all I&IT assets
• Vulnerability Patches released to address critical or high vulnerabilities must be applied
• Periodic audits must be completed to ensure that Vulnerability Patches were successfully applied
• Vulnerability Patch deployment attempts must continue to be made until the Vulnerability Patch has been successfully applied
• Vulnerability Patches must be reviewed to ensure that unintended/desired ports are closed and unnecessary services are disabled that may have been applied by default vendor Vulnerability Patch releases
• Compliance metrics should be obtained from a solution that is different than that which is used for Vulnerability Patch deployments
• Vulnerability Patches and all proposed system changes should be tested against similar build configurations that are not in live or production environments
• Vulnerability Severity ^{footnote 6[6]} must be determined by Cyber Security^{footnote 7[7]}
• Vulnerability Patches must be completed according to the priority timelines (Table 3.6) when a Vulnerability Patch has been made available
• When a vulnerability is published, and no patch is available, the Systems Severity Evaluation Process must be followed to determine vulnerability impacts to affected asset(s) and develop specific mitigation strategies to manage risk(s)
• Cyber Security is aware of unique situations where a vendor may release an official patch for a vulnerability and subsequently not endorse installation of that patch on specific implementations of its supported platform. If this applies, CSD must be contacted for special guidance.
• If a Systems Severity Evaluation CRQ will not be completed in accordance with Table 3.6, the Systems Severity Evaluation Process must be followed
• If a Vulnerability Patch deployment still cannot be successfully completed, it must be reported and tracked through the Vulnerability Deferral Process, and must include the following:
  • Business justification/case
  • Impacted assets
  • Specific Vulnerability Patches to be deferred
  • Risk Summary (to be completed by Cyber Security)
  • Proposed compensating controls (to be completed by Cyber Security)
  • Authorization from both ministry and IT partners

In the event a Severity 0 or Severity 1 level Vulnerability is released, if conformity to the Priority 1 incident management process cannot be met, operations teams from both ITS and CSD must quarantine the asset(s) until the vulnerability patch can be applied or other mitigation implemented.

Table 3.6, Severity Target Timeline

*Response/engagement required as per GO-ITS 37 Incident Management

** 100% Complete denotes all issued CRQ’s must be patched or have a signed deferral completed within the prescribed timelines

Systems Severity Evaluation Process

Cyber Security has developed a process and tools to better engage with stakeholders when dealing with Patching. The Systems Severity Evaluation Process must be used to validate the identification of vulnerabilities and provide guidance to all parties involved to effectively manage a security Vulnerability update.

Cyber Security

Cyber Security gathers information about a vulnerability, rates the vulnerability, collects and reviews all known assets for applicability, associates those assets to the Master CRQ and opens a CRQ with assessment tasks for all known stakeholders associated with those assets. Cyber Security then attaches an Alert template and an Excel template for re-assessing risk score, impacted assets and environment specifics for the CRQ. Cyber Security will check for Child CRQ’s associated with Master CRQ’s to ensure compliance.

Application Stakeholders

Application Stakeholders will open a child CRQ(s) from the assessment tasks created by Cyber Security, to remediate the vulnerable assets that they are responsible for. Using either the timelines indicated in the original Severity Level or the modified timelines indicated in the Excel Sheet if the application stakeholders chose to complete the optional questionnaire. If the system is public-facing, the stakeholder must complete the questionnaire for those systems.

Vulnerability Deferral Process

The Vulnerability Deferral Process provides the direction required to stakeholders who request, process or authorize vulnerability patch deferrals in the OPS. The Vulnerability Deferral Process must be followed whenever system owners are unable to implement recommended patches according to established timelines. It is essential that the risk of not applying a security patch is determined by security reviewers and accepted by accountable Ministry and IT approvers. The maximum deferral period is one (1) year. No deferrals are permitted for Vulnerability that are required to remediate critical vulnerabilities (Severity Zero or Priority 1 – Under Attack).

For more information, including detailed process documents and examples, please review the Patch Deferral Process guideline document on Cyber Security’s intranet site.

Anti-Malware Controls

Malware is short for Malicious Software and is software intended to damage or disable computers and computer systems. Malware can be in the form of worms, viruses, Trojans, spyware, adware and rootkits, etc., which steal protected data, delete documents or add software not approved by a user.

Malware may be present as executables or interpretable scripts, shell code, or program commands in files, e-mail or web content. All of these should be scanned and verified against using software or systems that can detect signatures, indicators or behavioural characteristics of malware. Anti-malware controls are intended to detect, prevent, and remediate incidents of malware that may impact IT systems.

In addition to the controls against malware requirements outlined in GO ITS 25.0, the following guidance is recommended for anti-malware controls across the OPS I&IT environment:

• Anti-malware solutions must be installed, operated and updated regularly for both clients and servers
• Anti-malware solutions must provide logs to a central location, so they can be ingested into Cyber Security’s Enterprise SIEM solution (Security Information and Event Management)
• Anti-malware controls must be in place to detect, prevent or quarantine against known attacks, where technically possible
• Anti-malware solution must be actively running and cannot be disabled or altered by users, unless specifically authorized by management on a case-by-case basis for a limited time period
• If anti-malware controls cannot be deployed, the risk must be reviewed and an anti-malware risk assessment completed
• Logging controls should be in place to capture and analyze suspicious or unauthorized access

Secure Application Development

Secure Application Development must adhere to the requirements outlined in GO ITS 25.13 – Security Requirements for Web Applications, where applicable. The following guidance is recommended for Secure Application Development across the OPS I&IT environment:

• Applications or solutions/products developed for the OPS must be developed such that they are not dependent on an unsupported version of another application product in order to function as intended
• Any applications or solutions/products developed for the OPS should avoid specific version dependencies, and deprecated user interfaces

Any applications or solutions/products developed for the OPS should be developed using secure coding practices recommended by The Open Web Application Security Project (OWASP). Secure coding practices may consist of, but are not limited to:

• • Preventing Injection, Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF)
  • Session Management
  • Preventing Access Control flaws
  • Securing Misconfigurations
  • Preventing Data Exposure
  • Sufficient Attack Prevention
  • Protecting API’s
• Internally developed OPS Enterprise Applications must undergo a code review prior to being deployed in a production environment
  • Testing should occur after integration but before promotion
• Custom developed libraries should be maintained and tested to use industry best practices on software maintenance routines

Endpoint Protection

Endpoint Protection controls address potential endpoint vulnerabilities that may exist as a result of loss or theft, software vulnerabilities or missing/failed installation of security controls. Endpoint Protection solutions could potentially run processes in isolated environments, restrict users from transferring sensitive data and provide greater controls around network access.

Endpoint Protection controls should be applied to I&IT endpoints to prevent the propagation of vulnerabilities across the infrastructure. The following guidance is required for Endpoint Protection across the OPS I&IT environment:

• Endpoint Protection controls should be centrally managed and installed, operated, and maintained on all applicable I&IT endpoints
• Endpoint Protections should be in place to detect, prevent, or quarantine against known attacks
• Endpoint Protections should be in place to capture and analyze suspicious or unauthorized processes
• Endpoints should be hardened, as per applicable industry best practices, and relevant build books (Hardening (hardened) refers to providing various means of protection in a computer system. Protection is provided in various layers. Protecting in layers means to protect at the host level, the application level, the operating system level, the user level, the physical level and all the sublevels in between. Each level requires a unique method of security)

Intrusion Detection / Prevention Systems

Intrusion Detection or Prevention Systems (IDS/IPS) are used to monitor network or system activities for malicious activity, logging information, and reporting and blocking malicious attempts.

Intrusion Detection or Prevention Systems must be configured with the requirements outlined in GO ITS 25.0 – General Security Requirements and GO ITS 25.11 – Security Design Requirements. Additional configuration requirements with respect to Vulnerability Management for IDS/IPS include, but are not limited to the following:

• Operational areas responsible for IDS/IPS functionality should frequently scan threat intelligence services or vendor announcements, and publications for vulnerability alerts and configure sensors accordingly
• IDS/IPS should be configured to monitor against port attacks that are exploitable by identified vulnerabilities

Service Management

Incorporating Service Management into an effective EVMP ensures that all changes are planned while minimizing the risk of service disruptions. Enterprise Change Management must be carried out as per the requirements outlined in GO ITS 35 – Enterprise Change Management Standard. Incident Management must be carried out as per the requirements outlined in GO-ITS 37 – Incident Management Standard. The following guidance is recommended for Service Management across the OPS I&IT environment:

• Vulnerability Management practices should be incorporated into Service Management procedures to ensure that proposed changes do not put the environment at risk
• Proper service management planning should be carried out to ensure that solutions or applications are decommissioned prior to reaching end-of-life

Penetration Testing

Penetration Testing is an authorized proactive evaluation that is used to test a system, application or network’s controls to determine if any vulnerabilities exist that could potentially be exploited. Penetration Testing should be completed as per GO ITS 25.0 – General Security Requirements as part of its requirements for Security Testing and Evaluation (STE). The following guidance is recommended for Penetration Testing across the OPS I&IT environment:

• All Penetration Test(s) must inform or obtain approval from potentially impacted system owners prior to conducting scans, unless approved by the OPS’s Corporate Chief Security Officer
• Any major system change (i.e., application functionality, etc.) to an external facing or externally accessible application must undergo a penetration test prior to that system being implemented in a production environment.
• Penetration testing on the OPS I&IT environment should be conducted to determine if any discovered vulnerabilities can negatively impact the confidentiality, integrity, or availability of Government information or services:
  • Penetration Test(s) should be prioritized on services processing High Sensitivity information
  • Systems that are not deemed time-sensitive but are critical to the OPS should be tested at least once every two years
  • Results of Penetration Test(s) should be communicated and provided to accountable stakeholders with an action plan for remediation/mitigation
  • Remediation/mitigation strategies should be tracked and monitored by Cyber Security Division
• All new OPS I&IT servers must undergo a Vulnerability Assessment scan prior to deployment into production
• Vulnerability Assessment scans must be conducted on network components on an annual basis

Compliance reporting

Cyber Security should provide regular reporting of vulnerability management compliance to IT Clusters, and Program Owners where applicable, to improve security visibility and raise awareness around system vulnerabilities and efforts to mitigate them.

• Cyber Security should report on vulnerability and patch management

• Cyber Security should support and report on Patch Deferrals

• Cyber Security should report on outstanding Risk Mitigation Reports

4. Related standards

Impacts to existing standards

Identify any GO ITS standards that reference or are referenced by this standard:

Impacts to existing infrastructure

Infrastructure impacted by this standard:

Impacts to related policy

5. Compliance requirements

In order to manage the effectiveness of this standard, ministries, clusters and applicable agencies are expected to adopt and monitor compliance.

This document is intended to guide the design, development, deployment and operation of Enterprise Vulnerability Management. Compliance with this document is mandatory due to the high potential for exposure and impact associated with failure to effectively identify and mitigate vulnerabilities across the enterprise I&IT environment.

Implementation and metrics

The intention of the OCCIO is to advertise and promote this standard as being a mandatory component throughout government. However, in order to effectively manage its implementation; ministries, clusters and applicable agencies are expected to adopt and monitor compliance to this standard.

6. Responsibilities

IT clusters

• Supporting Program Managers and Directors in ensuring that OPS I&IT assets undergo all Vulnerability Management processes requirements outlined in this standard
• Supporting ITS and CSD in ensuring that all cluster managed devices are identified and can be reported on as outlined in the requirements of this standard
  • Contributing to the maintenance of an up-to-date inventory of all OPS I&IT assets
• Supporting ITS and CSD in ensuring that all cluster applications are identified and can be reported on as outlined in the requirements of this standard
• Ensuring that all agreements with service providers include adherence to Corporate Policies, standards, and enterprise security requirements
• Managing OPS I&IT assets (and any associated services) to ensure they are in compliance with this standard
• Responsible for testing and verifying the integrity of any software deployed
• Using supported software wherever possible
• Working with ITS and CSD partners to minimize the risk to the OPS I&IT environment
• Supporting Program Managers and Directors in ensuring that all privacy risks are identified, assessed, mitigated, and monitored
• Working with IPA partner to minimize risk of privacy breaches
• Owners of information must review all policies, procedures and requirements required to manage and mitigate risk, and maintain knowledge of applicable regulatory requirements.
• I&IT Clusters should support the business to ensure that information is updated when changes with respect to products, services, strategic plans, other activities and corporate structure are made.

Cyber Security Division

• Maintaining this standard and other applicable IT security standards and related guidance on behalf of the Government of Ontario
  • Updating this document and ensuring that Enterprise Vulnerability Management advice and requirements are kept current
  • Annual review of this document
• Monitoring the corporate environment and industry/intelligence information sources for potential security vulnerabilities
• Determining and communicating levels of risk associated with identified vulnerabilities
• Monitoring and reporting on Enterprise Vulnerability Management
• Providing recommendations and assisting with the deployment of mitigating security controls
• Providing Education and Awareness materials for Enterprise Vulnerability Management
• Providing Risk Posture Reports and informing the OCCIO about overall enterprise residual risk
• Supporting eSM Major Incident Manager (MIM) in the management security incidents
• Compliance reports must be filed in accordance with specific procedures outlined in each report, and must be maintained for review by Cyber Security.
• Cyber Security should provide information that is updated, as necessary, to reflect new and changing regulatory requirements.

Architecture Review Board and Information Technology Executive Leadership Council

• Endorsing/approving this standard
• Providing support to I&IT stakeholders in the development and maturation of an Enterprise Vulnerability Management Practice
• Receiving reports about vulnerability management and residual risks

Information Technology Services (including enterprise Service Management)

• Maintaining a repository that can contain an up-to-date inventory of all OPS I&IT assets
• Maintaining an up-to-date inventory of all ITS enterprise applications for which it is responsible
• Leading the enterprise Change Management and enterprise Incident Management processes as per GO-ITS 35 and GO-ITS 37
• Ensuring that appropriate resources are assigned to vulnerability management tasks based on the identified severity levels and associated timelines
• Ensuring that infrastructure/hosting systems are hardened and Patched accordingly
• Responsible for testing and verifying the integrity of software it deploys
• Communicate to data/application owners estimated mitigation timelines for I&IT assets with identified vulnerabilities in systems for which it is accountable
• Informing users of potential service outages due to VM activities
• Managing central backups and restore capabilities
• Conducting periodic review of infrastructure components to determine current Vulnerability status
• Ensuring that agreements that are entered into with service providers will also reflect the requirements outlined in this standard
• Supporting the implementation of any compensating controls identified in this standard

Ontario Internal Audit Division

• Conducting periodic audits of pertinent activities to test compliance with this and other security standards
• Communicating with appropriate management about any risks identified and the severity of those risks
• Working with management to define action plans to mitigate any risks noted during the course of an audit and conducting follow-up as required

Program Owners

• Complying with this standard when purchasing, using or modifying OPS-issued I&IT assets
• Ensuring that the risk profile of their services and applications are assessed and addressed
• Participating in the identification of business or mission critical services and data; and
• Working with ITS and Cluster partners to minimize the risk to the OPS I&IT environment.
• Ensuring that personal information risk is assessed and addressed in accordance with Privacy Impact Assessment practices
• Reporting any privacy breaches to the Privacy Office or equivalent.
• Procedures should exist in operational management to assure that all information owners are complying on a day-to-day basis with the regulatory requirements applicable to the activities of the business.
• Such procedures should be tailored to the business activities. They should be incorporated into, and maintained in, relevant business operations.

7. Roles - standard owner

Accountable Role (Standard Owner) Definition

The individual or committee ultimately accountable for the process of developing and maintaining this standard. Where a committee owns the standard, the committee Chair is accountable for developing the standard including future updates. There must be exactly one accountable role identified.

Accountable Role:
Title: Head, Cyber Security Strategy, Risk Management & Architecture
Ministry/I&IT Cluster: Ministry of Government and Consumer Services (MGCS)
Division: Cyber Security Division

Responsible Role Definition
The organization(s) responsible for the development of this standard. There may be more than one responsible organization identified if it is a partnership/joint effort. (Note: the responsible organization(s) provides the resource(s) to develop the standard).

Responsible Organization(s):
Ministry/I&IT Cluster: Ministry of Government and Consumer Services (MGCS)
Division: Cyber Security Division
Section:  Cyber Security Policy and Standards

8. Contact information

If you have any questions or require further information about this document or the GO-ITS 25 series, please contact the following I&IT Strategy and Cyber Security Division staff:

9. Appendices

9.1 Normative references

Note:  a normative reference specifies a supporting document or GO IT Standard (in the case of the Government of Ontario’s I&IT infrastructure, often another OPS I&IT authorized publication) that must be read to fully understand or implement the subject matter of the main GO IT Standard. Such authoritative or de facto references may be external and may, or may not be, owned/controlled by the GO IT Standard owner.
GO ITS 25.0 – General Security Requirements
/page/go-its-250-general-security-requirements
GO ITS 25.8 – Security Requirements for Servers
/document/go-its-258-security-requirements-servers
GO ITS 25.10 – Security Requirements for Mobile Devices
/document/go-its-2510-security-requirements-mobile-devices
GO ITS 25.21 - Security Requirements for Cloud Services
/page/go-its-2521-security-requirements-cloud-services
GO ITS 35 – OPS Enterprise Change Management Standard
/page/go-its-35-ontario-public-service-enterprise-change-management-standard
GO ITS 36 - Enterprise Service Asset Configuration Management (eSACM) /page/go-its-36-enterprise-service-asset-configuration-management-esacm
GO ITS 37 – Enterprise Incident Management Process
/page/go-its-37-enterprise-incident-management-process
GO ITS 38 – Enterprise Problem Management Process
/document/go-its-38-enterprise-problem-management-process
GO-ITS 40 Enterprise Release Management
/page/go-its-40-enterprise-release-management
GO-ITS 41 Enterprise Service Level Management
/page/go-its-41-enterprise-service-level-management
GO-ITS 44 ITSM Terminology Reference Model
/page/go-its-44-itsm-terminology-reference-model
GO-ITS 55 Ontario Public Service IT Service Desk Interaction Model and Incident Management Support Patterns
/page/go-its-55-ontario-public-service-it-service-desk-interaction-model-and-incident-management-support

9.2 Informative references

Note: an informative reference is not normative; rather, it provides only additional background information.
Gartner – A Guidance Framework for Developing and Implementing Vulnerability Management
National Institute of Standards and Technology – Guide to Application Whitelisting
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-167.pdf
National Institute of Standards and Technology – Guide to Intrusion Detection and Prevention Systems (IDPS)
http://ws680.nist.gov/publication/get_pdf.cfm?pub_id=50951
National Institute of Standards and Technology – Creating a Patch and Vulnerability Management Program
http://csrc.nist.gov/publications/nistpubs/800-40-Ver2/SP800-40v2.pdf
National Institute of Standards and Technology – Security Considerations in the System Development Life Cycle https://csrc.nist.gov/publications/detail/sp/800-64/rev-2/final
National Institute of Standards and Technology – Guide for Conducting Risk Assessments
http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-30r1.pdf
SANS – Patch Management
http://www.sans.org/reading_room/whitepapers/iso17799/patch-management_2064
U.S. Department of Homeland Security; Cybersecurity Strategy   https://www.dhs.gov/sites/default/files/publications/DHS-Cybersecurity-Strategy_1.pdf
National Institute of Standards and Technology – Framework for Improving Critical Infrastructure Cybersecurity, Version 1.1 https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf
Ponemon Institute – Today’s State of Vulnerability Response https://www.servicenow.com/content/dam/servicenow/documents/infographics/infographic-servicenow-ponemon-institute-state-of-vulnerability-response.pdf
Government of Canada, Office of the Superintendent of Financial Institutions – Regulatory Compliance Management (RCM)
www.osfi-bsif.gc.ca/Eng/fi-if/rg-ro/gdn-ort/gl-ld/Pages/e13.aspx

9.3 Vulnerability rating and calculation

9.3.1 Process, severity vs. impact matrix

*All incidents will also include a CRQ for Change Management follow up

9.3.2 Common Vulnerability Scoring System (CVSS)

Software, hardware and firmware vulnerabilities pose a critical risk to any organization operating a computer network, and can be difficult to categorize and mitigate. The Common Vulnerability Scoring System (CVSS) provides a way to capture the principal characteristics of a vulnerability, and produce a numerical score reflecting its severity, as well as a textual representation of that score. The numerical score can then be translated into a qualitative representation (such as low, medium, high, and critical) to help organizations properly assess and prioritize their vulnerability management processes^{footnote 8[8]}.

CVSS is composed of three metric groups; Base, Temporal, and Environmental, each consisting of a set of metrics.

• The base metric group represents the basic elements of a vulnerability. This is derived from the exploitability (how accessible the sensitive information is in actuality) and Impact (the type or number of systems at risk)
• The temporal metric group measures the likelihood of the vulnerability being attacked. This calculates how easy an attack can be deployed and how much or little effort is required to access the network or device
• The environmental metric group looks at the existing security controls in place. This calculates how a current environment/network is secured and if any mitigation or remediation plans are already in place to reduce risk when considering Confidentiality, Integrity and Availability requirements for the affected systems

10. Glossary

Access is gaining entry to an electronic network provided by the Government to its employees and other authorized individuals on our outside government premises, including telework.
Access Control are procedures/devices designed to restrict entry to a physical area (physical access controls) or to limit use of a computer/communications system or computer stored data (logical access controls).
Administrative Security, also referred to as Access Control, pertains to controls that are put in place to prevent select users from inadvertently or deliberately compromising the confidentiality, integrity and availability of data or IT systems.
Application Whitelist is a list of applications, processes and components (i.e. libraries, configuration files, etc.) that are authorized to be present or active on a host.
Authentication is to establish the validity of a claimed identity of a user prior to gaining access (e.g. passwords, access cards, etc.).
Blacklist is a list of discrete entities that have been previously determined to be associated with malicious activity and should be restricted from executing on a system.
Compensating Control(s) is an alternative control that is put in place to satisfy a security requirement for a solution where deployment is not feasible or the implementation would result in an unacceptable level of risk.
Confidentiality is the preservation of a degree of secrecy consistent with the sensitivity of information, competitive position and legislative requirements (e.g. FIPPA).
Data is any formalized representation of facts, concepts or instructions suitable for communication, interpretation or processing by a person or by automated means.
End-of-Life pertains to software products that are no longer publicly supported by vendors.
Endpoint – a device that is an Internet-capable computer hardware device on a TCP/IP network. The term can refer to desktop computers, laptops, smart phones, tablets, thin clients, printers or other specialized hardware such POS terminals and smart meters.
Endpoint Protection is a managed solution that could potentially run processes in isolated environments, restrict users from transferring sensitive data and provide greater controls around network access.
Enterprise Vulnerability Management Practice (EVMP) is a manageable and implementable risk-based framework to address the emerging security weaknesses created by software and system vulnerabilities.
Exploits are documented procedures, programs or scripts that take advantage of a bug, glitch, or vulnerability in order to cause an unintended or unanticipated response from system hardware or software.
Firmware is defined as permanent software that is programmed into read-only memory.
Information is the meaning derived from or assigned to facts or data, within a specified context.
Information Technology Resources are those resources (hardware, software, data, etc.) associated with the creation, storage, processing and communication of information in the form of data, text, image and voice.
Integrity is the authenticity, accuracy and completeness of data that can be affected by unauthorized or accidental additions, changes or deletions.
Intrusion Detection System (IDS) is a device or software application that is responsible for monitoring the network for signs of possible incidents, violations of policies and standard security practices .
Intrusion Prevention System (IPS) is a device or software application that is responsible for monitoring the network for malicious activity and block vulnerabilities from being exploited.
IT Asset is a piece of software or hardware within an information technology environment (device, system or application)
Malware is software or program code/instructions inserted into a system, usually covertly, with the intention of compromising one or more of confidentiality, integrity or availability associated with the system or the data it processes. This includes traditional “virus”, “trojan" and “worm” software as well as “sniffer”, “logger”, “backdoor”, “trapdoor” and “rootkit” threats.
Networks are IT systems that can be made of one or both of the following components:

• Local Area Network (LAN) – Network or Information Technology systems wholly situated at one geographical address;
• Wide Area Network (WAN) – Network or Information Technology systems located over more than one geographical site;

Patches are defined as pieces of software that are designed to correct errors, such as security vulnerabilities, bugs or other performance/stability issues that may reside in firmware, operating systems or applications.
Vulnerability Patch Management is the process by which security fixes and application Vulnerability Patches or updates are collected, analysed, tested, and implemented throughout the I&IT environment.
Penetration Testing is a compensating control that is used to test a system, application or network in order to determine if any vulnerabilities exist that could potentially be exploited.
Personal Health Information (PHI) is information about the health of an individual and related information as defined in section 4 of the Personal Health Information Protection Act.
Personal Information (PI) is information about an identifiable information, as defined in section 2(1) of the Freedom of Information and Protection of Privacy Act.
Privacy Breach is the unlawful collection, use, disclosure, or retention of personal information, including personal health information.
Privacy Impact Assessment (PIA) is a proactive due diligence and risk management process to identify, analyse, avoid, eliminate, minimize privacy-related risks and comply with related laws and policies.
Program is a specific program or service within a Ministry.
Program Manager is the person responsible for the continued development, operational control, implementation, monitoring, etc. of a specific program or service within a Ministry.
Quarantine the asset(s); is the method in which operations teams can isolate an asset(s) from any communication within a network. The asset will still exist on the network, but will not be allowed any form of communication in or out with the network.
Responsibility is the obligation to perform a given task or tasks associated with a specific role.
Risk is a potential opportunity or threat that may impact an organization’s ability to meet its business objectives.
Safeguard is a protective and precautionary measure to prevent a security event from happening.
Sensitive Information is information that if released without authorization would cause harm, embarrassment, or unfair economic advantage (e.g., a breach of confidentiality of personal information, unauthorized modification of financial data, or a release of pre-budget information and strategic planning documents).
Threat and Risk Assessment (TRA) is a tool to assist Program Managers in fulfilling their responsibilities for security risk management and the development of security plans. A Threat and Risk Assessment (TRA) is used to:

• Assess the sensitivity of program assets and information;
• Identify and analyse potential threats and vulnerabilities;
• Assess the level of risk taking into consideration the effectiveness of current security measures; and
• Recommend appropriate measures to protect assets and information from loss, theft, destruction, modification or misuse.

User is a person authorized to access and use Information and Information Technology resources.
Vulnerabilities are considered to be a weakness in an information system, system security procedures, internal controls, or implementation that could be exploited by a threat source
Vulnerability Management (VM) is defined as a process cycle for finding, assessing, remediating and mitigating security weaknesses.
Whitelist is a list of discrete entities, such as hosts, email addresses, network port numbers, runtime processes or applications that are authorized to be present or active on a system.
Whitelist enforcement is an operational mode in Application Whitelisting that permits only whitelist items to be executed and blocks the execution of all others.
A zero-day exploit is an exploit that is not known to the Software vendor or public. A hacker may be the first to discover the vulnerability. Since the vulnerability isn't known in advance, there is no way to guard against the exploit before it happens. It is believed that cybercrime groups or attackers, reserve these exploits for high-value targets.

Requirements levels

Within this document, certain wording conventions are followed. There are precise requirements and obligations associated with the following terms:
Must-This word, or the terms "required", or "shall”, means that the statement is an absolute mandatory requirement.
Should-This word “should”, or the adjective "recommended”, means that there may exist valid reasons in particular circumstances to ignore the recommendation, but the full implications (e.g., business functionality, security, and cost) must be understood and carefully considered before deciding to ignore the recommendation.

Recommended versioning or change management

Changes (i.e. all revisions, updates, versioning) to the standard require authorization from the “responsible” organization. Once a determination has been made by the responsible organization to proceed with changes, the Cyber Security Division, OCCIO, will coordinate and provide assistance with respect to the approvals process. The approval process for changes to standards will be determined based on the degree and impact of the change. The degree and impact of changes will fall into one of two categories:

Minor changes – requiring communication to stakeholders, ARB endorsement required. Changes are noted in the “Document History” section of the standard.

Major changes – requiring a presentation to ARB and ITELC for endorsement.

Below are guidelines for differentiating between minor and major changes:

Minor:

• Represents incremental version changes to one or more specifications;
• Does not impact procurement (other than informational);
• Does not require configuration changes to current solutions;
• Does not impact other standards; and
• Is not related to legislative, policy or procurement changes.

Major:

• Represents a major version change to one or more specifications;
• Impacts procurement;
• Require configuration changes to current solutions;
• Impacts other standards; and
• Responds to legislative, policy or procurement changes.

Publication details

All approved Government of Ontario IT Standards (GO ITS) are published on the Ontario Public Service (OPS) Intranet. Please indicate if this standard is also to be published on the public, GO ITS Internet Site.

Detailed document history