1. Introduction

Government of Ontario Information Technology Standards (GO-ITS) are the official publications on the standards adopted through the Office of the Corporate Chief Information Officer (OCCIO) and Executive Leadership Council (ITELC) for use across the government’s information and information technology (I&IT) infrastructure.

These publications support the responsibilities of the Treasury Board Secretariat for coordinating standardization of I&IT in the Government of Ontario. In particular, GO IT standards describe where the application of a standard is mandatory and specify any qualifications governing the implementation of the standards.

2. Summary

2.1 Standard Name and Description

This document, GO-ITS 25.1 Security Requirements for Routers and Switches, sets out security requirements for routers and switches within the Government of Ontario, which are key components within the Government’s information networks.

2.2 Background and rationale

This GO-ITS is established to ensure that deployment of and reliance on routers and/or switches will not result in unacceptable risks to Government of Ontario I&IT resources.

Without secure and appropriate configuration and management of network routers and switches, attackers targeting these network devices may disrupt or compromise not only networks, but also the systems and applications that rely upon them. The security of these devices and the correctness of their configurations are therefore critical to safeguarding the Government’s I&IT resources.

2.3 Target audience

The target audience for this document includes, but is not limited to:

  • Technical implementers
  • Procurement staff
  • TRA/Security analysts
  • Program owners/managers
  • Internal auditors

2.4 Scope

2.4.1 In scope

The scope of this document is to provide basic requirements for configuration, management and access control of routers and switches, including those for virtualized or software-defined networking, that offer guidance and direction with regards to effective operation and security of these key network components.

For security involving sensitive information footnote 1 , if it becomes known that sensitive information is deemed at serious risk then immediate remedial action must be taken to mitigate the risk by applying the tools, methods, procedures etc. as per the relevant GO-ITS security document.

2.4.2 Out of scope

Not applicable

2.5 Applicability statements

2.5.1 Organization

All Ministries and I&IT Clusters are subject to Government of Ontario IT Standards.

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 either the Governance and Management of Information Technology Directive or Government of Ontario Standards by memorandum of understanding.

GO-ITS 25.1 applies to all vendors and third parties that connect to the Government of Ontario integrated network and use computerized devices for Government purposes unless exempted by a Memorandum of Understanding.

As new GO IT Standards are approved, they are deemed mandatory on a go-forward basis (go-forward basis means at the next available project development or procurement opportunity).

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 for ensuring that adequate change control, change management, and risk mitigation mechanisms are in place and employed. For the purposes of this document, any reference to Ministries or the Government includes applicable agencies.

2.5.2 Requirement levels

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

Must - The requirement is mandatory. Without it, the system is not considered secure.

Should - The requirement ought to be adhered to, unless exigent business needs dictate otherwise and the full implications of non-compliance are understood. All exceptions are to be documented and approved in writing by management, identifying the rationale for the exception to standard practice.

3. Technical specification

The following requirements apply to all I&IT assets and operations within the scope of the Governance and Management of Information Technology Directive.

3.1 Base standards for IP routers

At a minimum, each network router deployed within or operated on behalf of the Government of Ontario must meet the following requirements:

  • The device must be capable of securely storing hashed passwords in configuration files;
  • The device must perform IP network traffic routing;
  • The device must use access control lists only for network management (e.g., route filtering, traffic management) and not for assurance of network security design or function;
  • The device must employ authentication measures for dynamic route updates;
  • The device must possess the ability to discard unwanted traffic (e.g., packets with RFC 1918 source addresses on external interfaces);
  • The device must support interactive session/login timeouts;
  • The device must possess the ability to maintain route state tables;
  • The device must be dedicated to performing network routing functions;
  • The device must not support IP source routing, or the support must be disabled;
  • The device must not support ICMP directed broadcasts;
  • The device must not proxy ARP requests;
  • The device must possess the ability to perform anti-spoofing functions;
  • All device IP addresses must be configured explicitly, and must not be assigned dynamically (except for software-defined networking devices);
  • The device should not support the Telnet protocol;
  • The device must have TCP and UDP small services disabled, if present;
  • Unnecessary services, including (but not limited to) the following must be disabled unless required, and additional mitigation has been employed to reduce the associated risk:
    • TFTP, FTP, “r” services (e.g., rlogin), UUCP, finger, RIP, DHCP, IPSec, PPTP; and
    • Network boot protocols.
  • Router interfaces with different security levels (e.g., associated with varying Security Zones) should not connect to the same physical switch for high-risk situations or environments (e.g., identified by a TRA); physical (not logical or virtual) separation should be used; and
  • IP traffic that is obviously forged, or should not be passed as a function of sound network management practice, should be dropped. Some examples include:
    • Packets appearing to originate from localhost (e.g., 127.0.0.0/8);
    • Inbound traffic destined for external interfaces from a reserved internal address (e.g., 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16);
    • Inbound traffic destined for external interfaces from a multicast address (e.g., 224.0.0.0/10);
    • Outbound traffic on an internal interface that contains an external interface address as a source address;
    • Packets with identical source and destination addresses; and
    • Any other special cases as required, particularly when such traffic originates from external sources (e.g., a network that is not managed by or on behalf of the Government of Ontario).

3.2 Base standards for IP switches

At a minimum, each network switch deployed within or operated on behalf of the Government of Ontario must meet the following requirements:

  • The device must be capable of securely storing hashed passwords in configuration files;
  • The device must use any available access control functions for network management and segmentation purposes only, and not to provide for assurance of security design or controls;
  • The device must deny all unapproved or unauthorized updates (e.g., ports, trunk, spanning tree);
  • The device must possess the ability to drop malicious or unwanted traffic;
  • The device must support interactive session/login timeouts;
  • The device must be dedicated to performing Ethernet switching functions;
  • The device must not support ICMP directed broadcasts;
  • The device must not proxy ARP requests;
  • The device must possess the ability to perform layer two anti-spoofing functions;
  • The device must be configured to deter typical layer two denial of service attacks (e.g., attacks against spanning tree protocol, DHCP, ARP, or MAC address caching) via a port security feature or similar function;
  • All device IP addresses must be configured explicitly, and must not be assigned dynamically (except for software-defined networking devices);
  • The device must not have VLAN 1 assigned to any port;
  • The device must assign a unique native VLAN number to Ethernet trunks (e.g., one that is not assigned to normal switch ports);
  • To protect against documented vulnerabilities, the device must be used in conjunction with layer three access control when private virtual LANs (PVLANs) are used to provide network segregation and a layer three router is present on the segment where PVLANs have been implemented;
  • The device should not support the Telnet protocol.
  • The device must have TCP and UDP small servers disabled, if present; and
  • Unnecessary services, including (but not limited to) the following must be disabled unless required, and additional mitigation has been employed to reduce the associated risk:
    • TFTP, FTP, “r” services (e.g., rlogin), UUCP, finger, RIP, DHCP, IPSec, PPTP; and
    • Any type of automatic / dynamic Ethernet trunk support / negotiation; and
    • Network boot protocols.

3.3 Physical security

  • Router or switch devices must be placed in a locked room accessible only to authorized personnel;
  • Physical devices (e.g., PC cards, modems, KVM-over-IP switches) used to connect to the router or switch must be protected from unauthorized use while in storage;
  • Any operations or storage room should be free from electrostatic or magnetic interference and be environmentally maintained via HVAC, fire, and other systems;
  • If continuous operation of the router or switch is critical, an uninterruptible power supply (UPS) should be installed and spare components kept on hand; and
  • Physical access procedures for routers and switches deployed within high-risk environments or which support the operation of systems processing sensitive information must be subject to authorization, change control, and relevant physical access control techniques as stated within GO-ITS 25.0 General Security Requirements.

3.4 Access control

  • There must be no circumvention of the intended traffic path supported by the router and/or switch by any means (e.g., the use of modems, network tunnels, proxies, cables);
  • All access to Government of Ontario routers and/or switches must comply with GO-ITS 25.0 password management and use requirements;
  • Authentication and authorization for router and/or switch access must be performed via a centralized method, as per GO-ITS 25.0 General Security Requirements;
  • Administrative access to routers and/or switches should employ centralized multi-factor authentication, as per Corporate Policy on the Government of Ontario’s Identity and Credential Assurance (GO-ICA), and privileged access management (PAM); and
  • Section 3.12 has additional access control requirements for software-defined networking.

3.5 Router and switch management

  • Operational access must be restricted to appropriate network service staff;
  • Routers and/or switches should be managed via a management console; direct sessions to individual routers and/or switches should be avoided;
  • Router and/or switch management sessions originating from external network interfaces must not be permitted, unless they are authorized, documented, and approved via agreements;
  • Each authorized administrator must be assigned a unique account for use, in accordance with GO-ITS 25.0 General Security Requirements;
  • A secure session (e.g., an IPSec tunnel, SSH session, HTTPS transport security) employing approved cryptography (i.e., GO-ITS 25.12) should be used for management of routers and/or switches; and
  • The contents of configurations and access control lists must be classified and protected in accordance with the Corporate Policy on Information Sensitivity Classification.

3.6 Simple Network Management Protocol (SNMP)

SNMP community strings must follow GO-ITS 25.0 password selection conventions, as well as the following additional conventions specific to this document:

  • The SNMP community string must contain at least one special character (e.g., % or &);
  • SNMP community strings must be unique for the routers and/or switches in each security zone of a multi-tier environment unless required for business reasons, with additional mitigation employed to reduce the associated risk;
  • Production SNMP community strings must not be the same as those used in development or test environments;
  • SNMP read and write community strings must be different, and not based upon a similar string;
  • SNMP community strings for routers and/or switches must differ from those used on other technology platforms (e.g., firewalls, servers), and not based upon a similar string;
  • SNMP ingress must be prohibited from any network not managed by or on behalf of the Government of Ontario, unless authorized, documented, and approved via agreements;
  • Routers and/or switches should use SNMP v3 (designed with security requirements in mind) as a minimum standard;
  • SNMP management access must be limited to specific systems;
  • SNMP traps and/or queries must only be permitted to and from dedicated central management hosts located on an isolated, secure management network available only to authorized administrative staff; and
  • SNMP write access should be disabled where possible.

3.7 Logging

Logging must be consistent with the controls described in GO-ITS 25.0 General Security Requirements. In addition to those requirements, the following router and/or switch specific requirements must be implemented:

  • Routers and/or switches must be configured to send all logs to centralized logging servers located on a management segment protected by a layer three firewall;
  • Logs must not be sent directly to a management console;
  • Logs must be available for online review for a minimum of six months;
  • Archived logs must be maintained for two years and safeguarded as per Corporate Policy on Information Sensitivity Classification;
  • Archived logs must be made available for online review within five business days;
  • Router and/or switch logs should include interface names/addresses; and
  • Routing, VLAN and PVLAN events (creation, modification, deletion) should be logged.

3.8 Remote access

  • Remote access to routers and switches must be conducted in a manner endorsed by Cyber Security Division (CSD), and employ multi-factor authentication (as per GO-ICA);
  • Remote administration of routers and switches must be established through access employing approved cryptography (e.g., IPSec or SSL/TLS VPN);
  • Discrete, out-of-band network interfaces should be used for administration;
  • If TFTP cannot be disabled due to business requirements, its use must be limited to access from an isolated, secure management network available only to authorized administrative staff; and
  • The use of out-of-band modems should be avoided unless business requirements dictate such functionality, in which case PSTN use should be avoided, and a TRA should be completed to identify the risk involved.

3.9 Change management

Change management procedures must be compliant with GO-ITS 25.0 General Security Requirements and the GO-ITS 35 Change Management standard. In addition to those requirements, the following are router and/or switch specific requirements:

  • Changes made to routers and switches must be tracked with details of the changes made (e.g., date, time, name of the person responsible, and the business requirement for the change);
  • All software configuration and hardware changes with potential impact to operations must be tested and verified in a lab environment, unless there are mitigating circumstances preventing these activities from taking place (i.e., a major emergency);
  • Security patches must be installed as soon as practical (based on severity of patch), after appropriate testing;
  • All router and/or switch change requests must include the following:
    • Requester information including name, contact information, Ministry/agency information, Cluster information, request date and implementation date;
    • Duration of validity (start date and end date);
    • Application information including name, owner, and owner contact information;
    • Business rationale for request;
    • Impact statement of request;
    • A test plan and back-out plan for the change; and
    • Sign off from Program Manager and relevant Change Advisory Board; and
  • Routers and switches must be centrally managed to provide a consistent level of security, and must be managed via a secure facility.

3.10 Configuration management

  • Router and switch configurations must be archived to a central server in a management segment;
  • The router and switch software base (including software patches, hot fixes and updates) must be obtained from a trusted source that includes integrity checking;
  • All default account names must be replaced with new IDs where possible, and passwords changed as per GO-ITS 25.0 password management requirements;
  • Device configurations must be backed up daily, and kept in a secure location;
  • Any major configuration changes with potential security implications must be communicated to CSD (e.g., firmware upgrades and patches, hardware changes, or alterations to enterprise VLAN or PVLAN strategy);
  • Configurations must be checked and tested, prior to and after implementation, for configuration errors and related vulnerabilities, and must be audited or reviewed on a regular basis to verify their accuracy and identify potential misconfigurations; and
  • Access to router and switch software repositories must be restricted to network administrators.

3.11 Time synchronization

All routers and/or switches must obtain system time from a redundant and validated reference time source as per GO-ITS 25.0 General Security Requirements.

3.12 Software-defined networking

In addition to Section 3.4, the following requirements apply to virtualized or software-defined networking (SDN) technologies, including software-defined wide area networks (SD-WAN), which combine software-defined security features and networking functions inside the same network devices:

  • Any unnecessary software or feature components of SDN or SD-WAN services (e.g., wireless access on SD-WAN edge devices or appliances) must be disabled unless required for the operation or maintenance, and additional mitigation has been employed to reduce the associated risk;
  • SDN or SD-WAN must include communications security to protect sensitive traffic between the control elements (e.g., controllers, dashboards), and should protect sensitive information in northbound/southbound communications where a TRA has identified such a requirement for high-risk environments;
  • SDN or SD-WAN should manage access to critical systems (e.g., controllers, dashboards) with identity and access management (IAM), multi-factor authentication (MFA) as per GO-ICA, and privileged access management (PAM) including separation of duties, least-privilege, role-based and/or time-based access (as per GO-ITS 25.0 General Security Requirements), where a TRA has identified such requirements for high-risk environments;
  • SD-WAN network devices must employ secure, zone-based network segmentation with application-aware traffic filtering policies enforced and managed by the control elements;
  • In a zero-trust SDN architecture such as a multi-tenant cloud hosting environment, micro-segmentation must use robust filtering techniques (e.g., not exclusively MAC address- or VLAN-based) to create a software-defined micro-perimeter to limit network access based on traffic policies between individual critical resources (e.g., workloads and applications);
  • SDN micro-segmentation gateways should work with IAM, MFA or existing techniques to strengthen access control; and
  • SDN or SD-WAN security features, such as transport encryption, application-aware firewalls, zone-to-zone access policies, and IPS/IDS, should be designed and deployed as per relevant GO-ITS security standards (e.g., GO-ITS 25.0 for general requirements, 25.6 for firewalls, 25.12 for approved cryptography, and 25.11 for security design).

3.13 Roles and responsibilities

3.13.1 Users

Users are responsible for:

  • Complying with Government directives, policies and agreements when using Government equipment and services;
  • Ensuring security safeguards installed to protect the computing devices assigned to them are not disabled or tampered with; and
  • Reporting any suspected security incidents or breaches to the OPS Service Centre.

3.13.2 Program managers

Program Managers are responsible for:

  • Reviewing and approving business cases for device change requests, for network devices that fall under Cluster responsibilities, and lie outside vendor support contracts; and
  • Completing Information Sensitivity Classification and Threat Risk Assessments for new projects involving the deployment of network technology.

3.13.3 Clusters

I&IT Clusters are responsible for:

  • Supporting program managers where required in the completion of Information Sensitivity Classification and Threat Risk Assessments;
  • Managing device changes for network devices that fall under Cluster responsibilities (if any), and lie outside central vendor support contracts; and
  • Monitoring Cluster device change requests (if any) to ensure that they comply with the requirements in this document and other Government policies and standards.

3.13.4 Infrastructure Technology Services (ITS)

ITS is responsible for:

  • Implementing, managing and operating delegated internal routers and switches in accordance with the requirements in this document and other applicable Government policies and standards;
  • Maintaining the configuration details for any internal routers and switches under ITS control;
  • Ensuring that appropriate security safeguards are in place to protect any internal routers and switches under ITS control, including those stipulated in this document;
  • Ensuring that the logs are securely maintained, available when needed for investigations, and retained in accordance with this and related standards;
  • Monitoring Government of Ontario networks for traffic patterns that may cause negative operational impact, and immediately notifying relevant CSD contacts for appropriate action; and
  • Ensuring that software-defined networking product lifecycles are compliant with secure development principles (e.g., quality assurance, testing, and code review) and reporting, tracking and mitigation of vulnerabilities are compliant with GO-ITS 42 Security Requirements for Enterprise Vulnerability Management.

3.13.5 Network Service Provider

The Network Service Provider is responsible for:

  • Implementing, managing and operating routers and switches within the scope of contractual arrangements, in accordance with the requirements in this document and other applicable Government policies and standards;
  • Maintaining the configuration details for the routers and switches it controls;
  • Ensuring that appropriate security safeguards are in place to protect the routers and switches within the scope of contractual arrangements, including those stipulated in this document;
  • Ensuring that the logs are securely maintained, available when needed for investigations, and retained in accordance with this and related standards; and
  • Monitoring Government of Ontario networks for undesirable traffic, and immediately notifying relevant CSD contacts for appropriate action.

3.13.6 Cyber Security Division (CSD)

CSD, or any successor organization, is responsible for:

  • Maintaining this standard and all other applicable IT security standards, policies, procedures and related guidance on behalf of the Government of Ontario;
  • Reviewing logs to detect malicious traffic and network attacks;
  • Assessing change requests and working with change managers to accommodate efforts;
  • Approving any relevant changes prior to their deployment in production environments;
  • Authorizing use of diagnostic probes or diagnostic modes on routers and switches; and
  • Conducting any required inspection, evaluation, and if necessary, removal of any resources that reduce the efficacy or defeat Government of Ontario network security practices (e.g., rogue, malfunctioning, and/or unknown hardware).

3.13.7 Ontario Internal Audit

The Ontario Internal Audit Division is responsible for:

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

4. Related standards and impacted infrastructure

4.1 Impacts to existing standards

GO-ITS standardImpactRecommended action
GO-ITS 25.6 Security Requirements for FirewallsSoftware-defined networking section refers to secure segmentation and micro-segmentation in virtualized, SDWAN/SDN environments. This standard is considered an informative reference for GO-ITS 25.6.Update only, no impact on existing networks, systems or applications.

4.2 Impacts to existing infrastructure

Impacted infrastructureImpactRecommended action
None to existing infrastructureNot applicableNot applicable

5. Compliance requirements

The intention of the OCCIO is to advertise and promote this standard as being a mandatory component throughout Government. In order to manage the effectiveness and implementation of this standard, Ministries, I&IT Clusters and applicable agencies are expected to adopt and monitor compliance.

6. Contact information

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

Contact informationContact 1Contact 2Contact 3
Name/TitleAlex Fanourgiakis, Senior ManagerTim Dafoe, Senior Security Policy AdvisorBill Zeng, Security Policy Advisor
Organization/MinistryMinistry of Public and Business Service DeliveryMinistry of Public and Business Service DeliveryMinistry of Public and Business Service Delivery
DivisionCyber Security DivisionCyber Security DivisionCyber Security Division
BranchCyber Security Strategy, Risk Management & Architecture BranchCyber Security Strategy, Risk Management & Architecture BranchCyber Security Strategy, Risk Management & Architecture Branch
Section/UnitSecurity Policy and Standards UnitSecurity Policy and Standards UnitSecurity Policy and Standards Unit
Office Phone(647) 982-5216(416) 327-1260(416) 212-6825
E-mailAlex.Fanourgiakis@ontario.caTim.Dafoe@ontario.caBill.Zeng@ontario.ca

7. Roles and responsibilities for this standard

Accountable role (standard owner) definition

The individual or committee ultimately accountable for the effectiveness of a standard and for its full life-cycle, including development, reviews, revisions, updates, evaluations, and rescindment. Where a committee owns the standard, the committee Chair is accountable for the standard. There must be exactly one accountable role identified.

Accountable Role: Alex Fanourgiakis 
Title: Senior Manager 
Ministry/I&IT Cluster: MPBSD
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: MPBSD
Division: Cyber Security Division

Support role definition

The support role is the resource(s) to whom the responsibility for maintaining this standard has been assigned. Inquiries, feedback, and suggestions should be sent to this resource.

Support role (editor)

Ministry/I&IT Cluster: MPBSD
Division: Cyber Security Division 
Branch: Cyber Security Strategy, Risk Management & Architecture
Section: Security Policy and Standards Unit
Job Title: Senior Security Policy Advisor

Name: Tim Dafoe 
Phone: 416-327-1260 
Email: Tim.Dafoe@ontario.ca

2nd Support Role

Section: Security Policy and Standards Unit
Job Title: Security Policy Advisor

Name: Bill Zeng
Phone: 416-212-6825 
Email: Bill.Zeng@ontario.ca

8. Consultations

 

Organization Consulted (Ministry/I&IT Cluster)DivisionBranchDate
MPBSDCSDStrategy, Risk Management & Architecture (SPSU internal consultation)Mar-Oct 2022
MPBSDITSTelecom ServicesMar-Jun 2022
MPBSDITSEPPDS and DCNMar-Jun 2022
MPBSDCSDSecurity OperationsJun-Jul 2022
MPBSDCSDSecurity OperationsJun-Jul 2022
MPBSDCSDStrategy, Risk Management & ArchitectureJul 2022

Other consultations

Committee/Working Group/Council/Individual ConsultedDate
Internal SPSU ConsensusAug-Oct 2022
Cyber Security Management2023
Architecture Review Board (ARB)2023
Enterprise Architecture Management Working Group (EAMWG)October 4, 2023

9. Document history

 

DateSummary
2003-01-14Version 1.0 approved by Architecture Review Board (ARB)
2008-09-17Version 1.1 endorsed by IT Standards Council (ITSC)
2008-10-01
  • Changed contact information to reflect organizational changes
  • Added details based on feedback received from OCCIO ITS end-users
  • Adjusted to reflect enterprise solution being piloted and readied for deployment
  • Minor changes to language to improve clarity and technical correctness
  • Adjusted roles and responsibilities to reflect new agreement with integrated network provider
  • Edits to move some address references to CIDR notation
  • Expanded base configuration requirements
  • Adjusted content based on technical input from network operations

Adjusted roles based on ITSC feedback

2008-10-16Version 1.1 approved by ARB
2012-03-14
  • Organizational updates
  • Updated hyperlinks and references
  • Minor errata
2012-06-12Updated consultation list
2012-11-15Minor changes approved by Information Technology Executive Leadership Council (ITELC). Approved document version number set to 1.2
2015-01-19Minor changes as per ARB rationale (administrative/organizational updates, ISO/IEC alignment), draft document version changed to 1.3
2015-03-18Endorsed by ARB
2015-04-16Approved by ITELC
2023Technical content, language and organizational updates, stakeholder consultation, draft document version changed to 1.4
2023-11-01Architecture Review Board endorsement
2024-02-14Information Technology Executive Leadership Council approval. Approved document version number set to 1.4

10. Glossary

Access:
Gaining entry to an electronic network provided by the Government to its employees and other authorized individuals on or outside government premises, including telework.
Access Controls:
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).
Address Resolution Protocol (ARP):
A layer two protocol commonly used for translating hardware assigned Ethernet MAC addresses to IP addresses on a network.
Authorize:
To grant permission to access resources according to a predefined approval scheme.
Border Gateway Protocol (BGP):
The core routing protocol of the Internet. It works by maintaining a table of IP networks or 'prefixes' which designate network reachability among autonomous systems (AS). It is described as a path vector protocol. BGP does not use traditional IGP metrics, but makes routing decisions based on path, network policies and/or rulesets.
Confidentiality:
The preservation of a degree of secrecy consistent with the sensitivity of information, competitive position, and legislative requirements (e.g., FIPPA).
Data:
Any formalized representation of facts, concepts or instructions suitable for communication, interpretation or processing by a person or by automatic means.
Denial of Service (DoS):
It is an attempt to make a computer resource unavailable to its intended users. Although the means to, motives for, and targets of a DoS attack may vary, it generally consists of the concerted, malevolent efforts of a person or persons to prevent an Internet site or service from functioning efficiently or at all, temporarily or indefinitely.
Domain Name Service (DNS):
The service that provides for domain names, serving as a "phone book" for the Internet by translating human-readable computer hostnames (e.g., www.example.com) into the IP addresses (e.g., 208.77.188.166) required by networking equipment to deliver information. The service is an essential component of contemporary Internet use.
Dynamic Host Configuration Protocol (DHCP):
A protocol used by networked devices (clients) to obtain various parameters necessary for the clients to operate in an Internet Protocol (IP) network. By using this protocol, system administration workload greatly decreases, and devices can be added to the network with minimal or no manual configurations.
Encryption:
The transformation of data using cryptography into a form unreadable by anyone without a secret decryption key. Its purpose is to ensure confidentiality by keeping the information hidden from anyone for whom it was not intended, including those who can see the encrypted data.
Firewall:
Software or a hardware device that acts as a barrier between two networks and mediates access between those two networks according to an approved set of rules.
File Transfer Protocol (FTP):
A network protocol used to transfer data from one computer to another through a network, such as over the Internet. FTP is a commonly used protocol for exchanging files over any TCP/IP based network to manipulate files on another computer on that network regardless of which operating systems are involved (if the computers permit FTP access).
Finger:
The finger protocol is a deprecated simple network information exchange for human-oriented status and user information. Supplying detailed information as e-mail addresses and full names was considered acceptable and convenient in the early days of the Internet, but is now considered inappropriate for privacy and security reasons. In the past, finger information was a frequent source of initial data when attackers planned attacks.
Hardening:
The systematic elimination of known vulnerabilities through software or firmware updates and patches, and through proper system and security configuration.
HVAC:
A commonly used acronym that denotes heating, ventilating, and air conditioning (for reference to environmentally managed facilities).
Internet Control Message Protocol (ICMP):
One of the core protocols of the Internet protocol suite. It is chiefly used by networked computers' operating systems to send error messages, indicating, for instance, that a requested service is not available or that a host or router could not be reached.
Information:
The meaning derived from or assigned to facts or data, within a specified context.
Information Technology Resources:
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:
The authenticity, accuracy and completeness of data that can be affected by unauthorized or accidental additions, changes and/or deletions.
Micro-segmentation:
A software-only approach to SDN security, which uses network virtualization technology to create increasingly granular network security segments (see Segmentation) in cloud deployments and isolate and secure each segment at the workload or application level. The appropriate level of security remains with the applications as the latter are moved and scaled.
Network:
IT systems that can be made of one or both of the following components:
  • Local Area Network (LAN) - Network of Information technology systems wholly situated at one geographical address;
  • Wide Area Network (WAN) - located over more than one geographical site.
Packet Filtering:
Packet filtering acts by inspecting the "packets" which represent the basic unit of data transfer between computers on the Internet. If a packet matches the packet filter's set of rules, the packet filter will drop (silently discard) the packet, or reject it (discard it, and send "error responses" to the source).
Program:
A specific program or service within a Ministry.
Program Manager:
The person responsible for the continued development, operational control, implementation, monitoring, etc. of a specific program or service within a Ministry.
PVLAN:
A private, logically isolated virtual LAN segment supported by a network switch that has enhanced levels of segregation from other systems on the same segment, due to strong layer two controls on devices with such support.
r Services:
r-services provide a variety of methods for executing commands via a remote host, but they also generate serious security concerns. Some examples of these include rlogin and rexec.
Routing Information Protocol (RIP):
A commonly used interior gateway protocol (IGP) routing protocol on internal networks (and to a lesser extent, networks connected to the Internet), which helps routers/firewalls dynamically adapt to changes of network connections by communicating information about which networks each router/firewall can reach and how far away those networks are.
Responsibility:
The obligation to perform a given task or tasks associated with a specific role.
Risk:
A potential opportunity or threat that may impact on an organization’s ability to meet its business objectives.
Safeguard:
A protective and precautionary measure to prevent a security threat from happening.
Segmentation:
A network architectural approach that divides a network into multiple network segments (subnets) with each functioning as a smaller and distinct network. Segmentation not only improves network performance by removing unnecessary traffic in a particular segment and reducing network congestion, but it also ensures network security by enabling control of traffic flow to and from each network segment based on security policies.
Sensitive Information:
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.
Small Services:
A suite of simple network servers intended for diagnostic use, present on some network services and servers. These services can be abused, and are considered deprecated.
SNMP (Simple Network Management Protocol):
This protocol forms part of the Internet Protocol suite as defined by the Internet Engineering Task Force (IETF). SNMP is used in network management systems to monitor network devices for conditions that warrant administrative attention. The latest revision (SNMP version 3) offers important security services (authentication, communications security, and access control).
Software-Defined Networking (SDN):
A technological approach to network administration that uses software-based controllers to communicate with underlying network infrastructure devices through application programming interfaces (APIs) to control and direct network traffic. Rather than using dedicated network devices traditionally managed by network administrators to control network traffic, SDN creates and controls a virtual network, or controls traditional hardware devices, using software. With centralized, software-based controllers, SDN speeds deployment of network resources, automates network segregation and administrative functions, and distributes network policies, configurations and traffic forwarding decisions to underlying infrastructure devices.
Software-Defined Wide Area Network (SD-WAN):
An approach similar to SDN (see Software-Defined Networking) that is applied to a wide area network (WAN).
Source Routing:
A routing feature that permits sender of a packet to specify the route the packet takes through the network. Source routing is widely disabled on modern-day LANs and WANs.
Spoofing:
A situation in which one person or program successfully masquerades as another by falsifying data, thereby gaining leverage over a process or trust relationship.
Telnet:
A terminal emulation program for TCP/IP networks such as the Internet, commonly used to initiate interactive sessions with remote hosts. Telnet was designed in the early days of networked computers, and is considered both deprecated and vulnerable to attack.
Trivial File Transfer Protocol (TFTP):
A simple file transfer protocol, with the functionality of a very basic form of FTP. It is still used to transfer small files between hosts on a network, such as when a remote X Window System terminal or a thin client boots from a network server.
User:
A person authorized to access and use Information and Information Technology resources.
Unix to Unix Copy (UUCP):
A suite of computer programs and protocols allowing remote execution of commands and transfer of files and email between computers.
Virtual Private Network (VPN):
A communications network tunneled through another network, and dedicated for a specific network. One common application is secure communications through the public Internet, but a VPN need not have explicit security features, such as authentication or content encryption. VPN, for example, can be used to separate the traffic of different user communities over an underlying network with strong security features.
VLAN:
A logically isolated virtual LAN segment supported by a network switch.
VTP:
VLAN Trunking Protocol, a dynamic protocol intended to help administrators with the burden of managing VLAN creation and deletion on enterprise networks. In some configurations, VTP can be vulnerable to subversion by attackers.

11. Appendices

Normative references

Governance and Management of Information Technology Directive

Government of Ontario Standards (GO-ITS)

Corporate Policy on Information Sensitivity Classification

Corporate Policy on the Government of Ontario’s Identity and Credential Assurance (GO-ICA)

Note:  a normative reference specifies a supporting document or Standard (in the case of the Government of Ontario's I&IT infrastructure, often another I&IT authorized publication) that must be read to fully understand or implement the subject matter of the main Standard. Such authoritative or de facto references may be external and may, or may not be, owned/controlled by the Standard owner.

Informative references

ISF Standard of Good Practice for Information Security 2022

NIST 800-53 - Security and Privacy Controls for Information Systems and Organizations

IANA RFC 1918, February 1996

IANA RFC 3300, September 2002

Note: an informative reference is not normative; rather, it provides only additional background information.