Document history

2003-01-14Created:  GO-ITS 25.0  DRAFT v0.1
2008-01-07New draft number changed to version 1.1
2008-02-19Aligned with ISO 27002:2005, Input from 2007-2008 review process incorporated
2008-02-20Approved by IT Standards Council
2008-04-09Minor corrections and changes to more closely align with ISO 27002:2005, Adjustment to include access control and monitoring sections as per consultations with Ontario Internal Audit Division
2008-04-17Approved by Architecture Review Board
2012-04-14Organizational updates, updated hyperlinks and references, minor adjustment and errata
2012-04-19GO-ITS 25.19 content has been merged
2012-06-12Document format updated, minor adjustments
2012-11-15Minor updates approved by Information Technology Executive Leadership Council (ITELC). Approved document version number set to 1.2
2015-01-19Minor updates per rationale to ARB in Dec. 2014 (administrative updates, ISO/IEC alignment), draft version number set to 1.3
2015-03-06Minor update per received ARB feedback
2016-01-26Updated guidance regarding generic/shared/privileged account management, least privilege applicability, version number set to 1.4
2016-02-03Endorsed by Architecture Review Board
2016-03-31Approved by IT Executive Leadership Council

1. Foreword

Government of Ontario Information Technology Standards (GO ITS) are the official publications on the IT standards adopted for use across the government’s IT infrastructure.

These publications support the responsibilities of the Treasury Board Secretariat (TBS) 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 standards.

All GO-ITS 25 Standards are based on the work of recognized global authorities in information and operational security, both in government and industry.

2. Introduction

This document defines general security requirements for the protection of the integrity, confidentiality and availability of Government of Ontario networks and computer systems. This document is one in a series, which define platform-independent technical security requirements.

This document references the following four sections from ISO/IEC 27002:2013 “Information technology - Security techniques - Code of practice for information security controls”:

  • Section 9 – Access control
  • Section 12 – Operations security
  • Section 13 – Information systems acquisition, development and maintenance
  • Section 18 – Compliance

Security requirements are determined by both government and industry, and are published both internally and to the public. The requirements in this document may reflect advances in knowledge since the publication of the ISO/IEC code of practice, and must be implemented unless exigent business or functional requirements preclude doing so, and exemptions are approved.

2.1. Background and rationale

The GO-ITS 25 Security Standards describe parameters, features, or configurations that define the context-specific requirements. The implementing business unit may choose the appropriate method to satisfy the standard, as long as the security objective of the standard is met or exceeded.

The GO-ITS 25 documents will be reviewed on an ongoing basis to take into account the evolution of security and other related technologies. Changes or additions to the GO-ITS 25 Security Standards will be established in writing and communicated to all appropriate personnel.

It is intended that context-specific, step-by-step implementation procedures will be derived from the GO-ITS 25 Security Standards by business units. These specific procedures may be influenced by requirements arising from any or all of the following:

  • Threat and Risk Assessments (TRA);
  • Privacy Impact Assessments (PIA);
  • Security Testing and Evaluation (STE) (Vulnerability Assessments [VA], Penetration Testing, Code Review, etc.);
  • Provincial Privacy laws. (FIPPA, MFIPPA, PHIPA); and
  • Federal Privacy laws. (Privacy Act, PIPEDA).

2.2. Target audience

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

  • TRA and PIA analysts
  • Internal auditors
  • Developers
  • Technical implementers
  • Procurement staff
  • Program managers

2.3 Scope

2.3.1. In scope

GO-ITS 25 Security requirements apply to all vendors, ministries, former Schedule I and IV agencies, and 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 scope of this document is to provide a working set of general requirements that provide guidance and direction with regards to information security. Its primary focus is on the integrity of the infrastructure and processes required for delivering applications and services throughout the various Ontario government networks and environments. Additional documents in this series will cover more specific themes and requirements, and it is recommended that they be consulted for more specific guidance.

2.3.2. Out of scope


2.4. Applicability statements

2.4.1. Organization

All ministries and 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 OPS information and information technology products or services are required to comply with Government of Ontario IT standards if they are subject to 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 (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, risk mitigation, and control selection mechanisms are in place and employed. For the purposes of this document, any reference to ministries or the Government includes applicable agencies.

2.4.2. Other applicability

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

These considerations make it mandatory that every Ontario public service 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, given the existence of Alternative Service Delivery (ASD) methods, security requirements and procedures must also form part of any contract or agreement affecting the computer-based environments of the Ontario government, and will apply with equal force to third party contractors (and sub-contractors) as to Ontario government employees.

2.4.3. Terms

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.

2.5. Roles and responsibilities

2.5.1. Contact information

If you have 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:

Contact informationContact 1Contact 2
Name/TitleAlex Fanourgiakis, ManagerTim Dafoe, Senior Security Policy Advisor
Organization/MinistryMinistry of Government and Consumer ServicesMinistry of Government and Consumer Services
DivisionCyber Security DivisionCyber Security Division
BranchCyber Security Strategy, Risk Management & Architecture BranchCyber Security Strategy, Risk Management & Architecture Branch
Section/UnitSecurity Policy and Standards UnitSecurity Policy and Standards Unit
Office Phone(647) 982-5216(416) 327-1260

3. Technical specification

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

3.1. Operational procedures and responsibilities

Responsibilities and procedures for the management and operation of all information systems should be established. This includes the development of appropriate operating instructions and incident response procedures.

3.1.1. Access control procedures

Management of user access and privileges must be conducted in a comprehensive manner to ensure that only those users and operations staff with formal authorization from system owners can access associated data and services.

The following requirements must be addressed within access control procedures:

  1. Segregation of duties and least privilege principles must be implemented to reduce the risk of external intrusion and negligent or deliberate system misuse within the organization;
  2. Access must only be provided after formal authorization is granted, via unique identifiers and credentials, with formal records documenting the provision of access;
  3. Access assignment and revocation must be formally documented, with procedures for periodic validation (e.g., frequent and routine searches for redundant or duplicate entries in access control databases) to ensure only authorized users maintain access to the system, and to ensure access will be revoked and assets protected if the duties of the associated user change such that access is no longer required;
  4. System roles and duties must be assigned to individual and accountable users, and the use of generic, shared, or role accounts must be avoided wherever possible;
  5. Where the use of generic, shared, or role accounts cannot be avoided due to a business requirement, such accounts must not be created for use on behalf of a specific individual and/or in the name of a specific individual;
  6. Generic, shared, or role accounts must be documented, tracked, continuously managed, and removed when no longer required for business reasons;
  7. Generic, shared, or role accounts must be subject to the same password expiry/change requirements as typical, individually-assigned accounts issued to regular users;
  8. Elevated privileges (i.e., those typically used for system administration, user account administration, or content management) must be assigned to secondary accounts not used for routine access, granted on a strict least privilege basis, with assignment subject to more frequent routine review (to ensure only authorized users are granted such privileges due to an ongoing business requirement); and
  9. Management of user access and privileges must be conducted in a comprehensive manner to ensure that only those users and operations staff with formal authorization from system owners can access associated data and services.

3.1.2. Access control systems

The following operational requirements must be addressed by access control systems:

  1. Access control systems must be centrally deployed and managed;
  2. The design and operation of centralized access control systems must include resilience and redundancy to reduce impact if failures occur;
  3. Access must be granted only after all authorization and authentication procedures are complete, and a successful result has been returned for the credentials presented and/or the initiated session;
  4. Access control systems must support documented business and security requirements (e.g., the rationale for deploying the  access control system);
  5. Access control systems must be managed such that all authorized users of the system (and the roles, rules and/or privileges associated with their accounts or credentials) are individually authorized by the relevant, responsible program manager (with documentation);
  6. Access control systems must be managed such that authorized user accounts or credentials that are no longer in use beyond 45 days, or no longer required (e.g., due to a change in employee role), are identified and removed with 24 hours of detection and/or notification unless a valid business reason exists;
  7. Expired entries in access control databases must not be assigned to new users (to prevent expired privileges being provided to users who do not require them);
  8. Elevated privileges must be assigned on a “need for use” basis (or per event), such that these privileges are not provided for an unnecessary duration (and where possible, avoided using automation or other routines and tools);
  9. Log and audit information associated with elevated privileges must be subject to more frequent review, to assist in detecting unauthorized access or misuse;
  10. Specific accounts assigned with elevated privileges must be documented, tracked, and continuously managed;
  11. In virtualized and/or software-defined environments, elevated privileges must be subject to assignment according to least privilege (e.g., limited “super” administrative roles, elevated privileges across planes or categories of service, etc.);
  12. Where possible, accounts assigned with elevated privileges should be limited from access to typical avenues of security exposure (e.g., e-mail);
  13. The robustness (e.g., the degree of identity assurance associated with credentials, and/or the number of authentication factors required as credentials) for a given access control system should be increased if sensitive information is to be processed or stored;
  14. Access control systems should be managed in a manner that requires authorized users to be provided with a written statement of the access rights and responsibilities for the system; and
  15. Access control systems should be managed in a manner that requires authorized users to sign a use agreement that indicates their acceptance of disclosed access rights and responsibilities.

Additional, situation-specific access control guidance is provided throughout this document. Other GO-ITS 25 standards should be also consulted for technology-specific advice.

3.1.3. Password management

Passwords are the most common credentials or authentication information deployed within OPS access control systems. The following password management requirements must be addressed by access control systems intended to protect Government of Ontario I&IT assets:

  1. Passwords are highly sensitive, and must be protected in accordance with the ISPC Policy and Operating Procedure (i.e., encrypted both in storage and transmission, as to be irretrievable from authentication and system processes);
  2. Passwords must be issued directly to the user (in person, by telephone, or through GO-PKI protected e-mail) and never displayed upon entry;
  3. Initial passwords must require the user to change passwords upon first login, and where technically possible, initial passwords should expire within five days of issuance;
  4. Managers must assist users in understanding the risk of improper password use and maintenance, make required technical tools required available to staff to this end, and participate in efforts to revoke credentials when they are no longer required;
  5. Password strength and complexity must be enforced by automatic validation, use of tools to detect and prohibit low-entropy passwords where technically possible, periodic audit of password strength/entropy, immediate correction of weak passwords, and audit methods for new systems made active upon their deployment;
  6. A mechanism must be in place to ensure password values are not reused by the same user within a span of twelve consecutive months;
  7. Software with the ability to capture unencrypted passwords must not be allowed on OPS systems, unless for authorized OCCIO use (e.g., forensics, investigations);
  8. Passwords for authorized vendor service/field/support accounts must be reset upon each use;
  9. Password re-entry must be enforced upon inactivity timeouts, such as screen “blanking” or device/application session locking;
  10. Administrators with broad rights to I&IT assets and infrastructure must, through separation of duties, not also share the job function of user password maintenance;
  11. Administration and use of passwords must be consistent, uniform, and documented;
  12. Error/exception messages for denial of access associated with password creation, entry, or change failures must provide the briefest possible explanation for denied access;
  13. Controls must be in place to ensure that emergency passwords are changed after use, with details regarding use of emergency accounts/passwords submitted to management (e.g., how, why, when, and by who);
  14. Access must be denied after the fifth consecutive incorrect password entry; users must  contact the appropriate area (e.g., Service Desk) to enable further attempts or reset the account password (upon strong, positive user/requestor authentication), with access failures recorded in regularly reviewed, investigated, and appropriately escalated audit or system logs;
  15. If encrypted passwords are stored in files, there must be no descriptive indication of what use or systems the passwords correspond to, unless this information is also encrypted;
  16. Passwords must never be hard-coded into applications, automated login processes, scripts, macros, or function keys, as these are often discovered by attackers; and
  17. Passwords must not be cached or stored locally in unencrypted form.

3.1.4. Password requirements

Users must be aware of their responsibilities and the risks to I&IT assets, and adhere to the following password selection requirements:

  1. Passwords must be chosen so they can be reliably recalled, but not so easily that they can be guessed or deduced by others;
  2. Passwords must be at least eight characters in length, with the exception of Blackberry devices;
  3. Passwords must contain at least one numeric digit, and at least one upper case and one lower case letter;
  4. For Blackberry devices, passwords must be at least six characters in length;
  5. Blackberry devices must lock after 20 min. of inactivity, with ten consecutive password failures causing the device to be disabled and wiped of information (users must contact Service Desk to reinitiate device activation);footnote 1
  6. Passwords must not be blank (null passwords are prohibited), and all vendor-supplied (e.g., hardware, software) default passwords, including “guest” account passwords, must be changed upon deployment (these values are known to attackers);
  7. Users must not include easily obtained or deduced personal information (e.g., hobbies, family member names, type or name of pets, birthdays, etc.), any portion of their given name or username, or words, phrases, or acronyms that are part of the broader/recognized OPS culture within chosen password values;
  8. The strength and complexity of a password, past the minimum requirements, must be commensurate with the business requirements and I&IT assets involved (as expressed through some or all of confidentiality, availability, and integrity);
  9. Users must select unique passwords for Remote Access Services (RAS), and for access to different platforms (to deter reuse of a compromised credential); and
  10. In instances where technology allows, the use of passphrases is preferable to the use of shorter password values.

3.1.5. Password use

Users must adhere to the following password use requirements:

  1. Users must not disclose their passwords to anyone, and understand their accountability for any access to I&IT assets gained through use of their password;
  2. Users must not install or use password completion software or plug-ins, and must disable it if provided within an application;
  3. Users must know whom to contact for assistance with their password, and how and when to report confirmed or even suspected breach/leakage or disclosure of a password; and
  4. Users must immediately change any confirmed or suspected compromised password, unless directly instructed otherwise by OCCIO.

3.1.6. Password change and maintenance

The following password change and maintenance requirements must be addressed by OPS access control systems:

  1. Regular users must be required to change their passwords at least once every 90 days, with the exception of Blackberry device users, where this is instead a recommended practice;
  2. System administrators (i.e., those assigned privileged accounts) must be required to change their passwords at least once every 30 days, and practice the highest standard of care regarding the security of their credentials;
  3. These intervals must be enforced by automated means that cannot be bypassed, or if not feasible through automation, by means of administrator and/or manager intervention and verification; and
  4. Password changes must not involve trivial alterations or the use of easily-recognized patterns/iteration (e.g., changing the example password comPop10 to comPop11).

Reasonable compensating controls must be used if compliance with these requirements cannot be immediately met.

Access to backup media that contains, or may contain, passwords (in any format) must be limited to authorized personnel. Authorized personnel must not discuss or transmit password values or password/authentication security details with, or in the vicinity of, staff who are not authorized to receive the information, or contractors that have not signed a non-disclosure agreement.

3.1.7. Documented operating procedures

System operating procedures should be documented and maintained. Operating procedures should be treated as formal documents.

Revisions to operating procedures must be reviewed and approved by management. The procedures should specify all system operation instructions including the following:

  1. Processing and handling of information;
  2. Scheduling requirements, including interdependencies with other systems, and mandatory start/stop times for system work, maintenance windows, or changes, if applicable;
  3. Instructions for handling errors or other exceptional conditions including restrictions on the use of system privileges and utilities;
  4. Support contacts in the event of unexpected operational or technical difficulties;
  5. Special output handling instructions, such as the use of special stationery or the management of confidential output, including procedures for secure disposal of equipment and/or data; and
  6. System contingency, restart and recovery procedures for use in the event of system failure.

Documented procedures should also be prepared for system administration activities associated with information processing and communication facilities, such as boot and halt procedures, backup, equipment maintenance, data centre procedures, and mail handling management/safety.

3.1.8. Operational change control

Changes to information processing facilities and systems must be controlled. Inadequate control of changes to information processing facilities and systems is a common cause of system or security failures. Formal management responsibilities, policies, and procedures should be in place to ensure satisfactory control of all changes to equipment, software or procedures.

Operational programs should be subject to strict change control. When programs are changed, an audit log containing all relevant information should be retained. Changes to the operational environment can impact applications (and vice versa). Wherever possible, operational and application change control procedures should be integrated; these procedures should address business criticality and all requirements described in GO-ITS 35 OPS Enterprise Change Management.

All changes, however minimal, have a measurable impact on both the systems being changed, and adjacent systems that interact or share resources with the system being changed. Change control processes are intended to reflect this reality, and must manage the lifecycle of a system, from planning, through implementation and management, to removal and disposal. The administrator of the system must be responsible for ensuring that change control records are accurately and promptly filed.

Change control must detail system changes, and how changes affect the enforcement of security policy.

Changes must be reviewed to ensure that the security posture of the changed environment has not been reduced in robustness or effect. Changes may increase the relative complexity of an environment, and increase the demands on security components.

To ensure security, the following must be detailed during change control:

  1. System composition and configuration (hardware, software, etc.);
  2. Practices and procedures;
  3. Confidentiality, availability, and integrity requirements of existing systems and data;
  4. Identification and authentication mechanisms, assigned privileges, and credentials;
  5. Monitoring of, response to, and recovery from events, and review of related procedures;
  6. Planning, implementation, management, review and audit of systems and procedures;
  7. Resource utilisation, particularly as it affects adjacent systems;
  8. Required changes to existing Service Level Agreements (SLAs); and
  9. Required changes to agreements, contracts, or licences.

The change approval procedure must include security oversight, as well as approvals from managers of both the systems requesting change, and systems affected by the change.

Security Testing and Evaluation (STE), such as a vulnerability assessment (VA) and/or penetration test, should be performed against production environments prior to being returned to operations to verify that any changes made have not compromised the intended level of security. This holds true especially in the event of a significant change to hardware, software, or configuration.

Procedures must exist for retroactively documenting an unscheduled, but unavoidable change (e.g., in response to an emergency discovery of vulnerability, or patch release). These procedures must include a definition of what constitutes a reasonable exception to the proactive change control procedures.

For significant changes (e.g., replacement, removal, or addition of a system) a vulnerability assessment and/or penetration test must be performed to re-validate the security of the system, prior to that system returning to production use.

Changes must be tested to confirm that the change was successful, and that the security posture of the environment was not weakened. Roll back procedures must exist for reversing unsuccessful changes.

3.1.9. Incident management procedures

Incident management responsibilities and procedures must be established to ensure a quick, effective and orderly response to security incidents, and enable post-incident analysis. Incident response and management must comply with the requirements described in GO-ITS 37 Incident Management.

To prepare for security events and incidents, the following controls must be implemented:

  1. Procedures should be established to cover all potential types of security incidents, including:
    1. Information system failures or critical errors;
    2. Denial of service, or other loss of availability;
    3. Errors resulting from incomplete or inaccurate business data;
    4. Breaches of confidentiality / leakage of information; and
    5. Unauthorized use, access, change, or other loss of integrity.
  2. In addition to normal contingency plans (designed to recover systems or services as quickly as possible) the procedures should also cover:
    1. Analysis and identification of the cause of the incident;
    2. Planning and implementation of remedies to prevent recurrence, if necessary;
    3. Collection of audit trails and similar evidence, with documented chain of custody and protection of evidence;
    4. Communication with those affected by or involved with recovery from the incident; and
    5. Escalating and reporting the action to the appropriate authority.
  3. Audit trails and similar evidence should be collected and secured by qualified professionals, as appropriate, for:
    1. Internal problem analysis;
    2. Use as evidence in relation to a potential breach of contract, breach of regulatory requirement or in the event of civil or criminal proceedings; and
    3. Negotiating for compensation from software and service suppliers.
  4. Action taken to recover from security breaches and correct system failures should be carefully and formally controlled. The procedures should ensure that:
    1. Only clearly identified and authorized staff are allowed access to live systems and data;
    2. All emergency and/or forensic actions taken are documented in detail;
    3. Emergency action is reported to management and reviewed in an orderly manner; and
    4. The integrity of business systems and controls is confirmed with minimal delay.

A document detailing responses to anomalous events, with response measures corresponding to the frequency or severity of the event must exist. Response measures must be practiced and the results of such exercises reviewed to evaluate the effectiveness of the measures. Examples of events with security implications that must be detailed include but are not limited to the following:

  1. Denied connection or transaction attempts based on incorrect data or conditions, including:
    1. User ID or password failure;
    2. Client certificate;
    3. Challenge/response;
    4. Time of day;
    5. Source/client location; and
    6. Violation of connection rules.
  2. Patterns of activity which may not have been denied, but which are suspicious:
    1. Anomalous connection behaviour with multiple invalid user IDs;
    2. Anomalous connection behaviour with a valid user ID (frequency, concurrency, time and date, widely varying location, multiple access from disparate locations and/or hardware IDs, etc.); and
    3. Sequential or random anonymous connection attempts (port/service, network address, etc.).

Responses to suspected intrusions, or persistent intrusion attempts, must include an attempt to determine whether a compromise has occurred, and help to deter future intrusion attempts. These measures must include, but are not limited to, the following (as appropriate):

  1. Limiting or denying access, based on source or location of connection attempts;
  2. Changing network connection mechanisms, telephone numbers, or other means of access;
  3. Locking accounts;
  4. Auditing accounts for:
    1. Inactivity;
    2. Unauthorized creation;
    3. Weak or unchanged passwords;
    4. Inappropriate permissions;
    5. Administrative privilege activity; and
    6. Expired or revoked access.

Systems involved in a security incident must be removed from the network if it is determined that they are adversely affecting, propagating problems of some type to, or jeopardizing the security of, other systems or data.

Systems involved in incidents must not be turned off without consultation with the responsible security authority for the group and/or Ministry involved. If they have been shut down, for whatever reason, they must not be started again, and administration of the system must be turned over to the relevant security operations group and/or appropriate OCCIO analysts.

Security administrators and forensic analysts may power the system on under controlled circumstances to capture and record system state information. Precautions must be taken to safeguard any sensitive information on devices under forensic review.

Incident response procedures for incidents involving specific systems should include the following:

  1. Limiting or denying access, based on source or location of connection attempts;
  2. A single point of contact to co-ordinate handling of the incident, and a backup in case they cannot be reached;
  3. A published and current contact escalation chain, with milestones, timeframes, or criteria to indicate points at which an event must be escalated;
  4. Backup contacts for each point in the escalation chain;
  5. A response checklist with room for comments; and
  6. Post-event review and revision of procedures, based on exceptions to the prepared plan.

There must also be procedures for secure handling, and preservation, of an evidence trail (with documented chain of custody and protection of evidence) for:

  1. Client activity or requests (both allowed and denied);
  2. Server configuration changes and/or administrator login and use of privilege;
  3. System activity; and
  4. Interpreted events as reported by Intrusion Detection/Prevention Systems.

3.1.10. Segregation of duties

Duties and areas of responsibility must be segregated in order to reduce opportunities for unauthorized access, modification, or other misuse of information or services.

Small organizations may find this method of control difficult to achieve, but the principle should be applied as far as is possible and practicable. Whenever it is difficult to segregate, other controls such as monitoring of activities, audit trails and management supervision must be implemented. It is important that security audit remains independent.

The initiation of an event should be separated from its authorization. If the ability of a single individual to perpetrate theft or fraud in their area of responsibility without being detected is controlled, collusion is forced. An audit mechanism should be used to detect collusion attempts. The following controls must be implemented:

  1. Roles or duties required to enable unauthorized access, theft, or fraud must be segregated;
  2. Basic separation of duties requires a minimum of two roles (e.g., separate actors for raising a purchase order and verifying that the goods have been received, or authorizing cheques and having physical access to cheque printing equipment); and
  3. If there is a documented high danger of theft or fraud, and a high impact associated with successful collusion, processes and controls must be devised such that three or more actors need be involved to satisfy unique roles.

To satisfy the requirement that the duties of administration and configuration be separated, there should be segregation between the administrator of the operation of the system, the administrator of the configuration of the system (if the system supports such a distinction), and all administrators of external support applications (e.g., PKI, IDS, IPS, firewalls, etc.). Different staff members must hold these accounts. This principle should also be extended to virtualized and/or software-defined environments.

Applications running persistently (i.e., as services) must be configured to run under their own accounts and privileges, where possible. Permissions on application accounts must be at least as restrictive as those on user accounts, denying access by default, and allowing file or resource access only as required.

3.1.11. Separation of development and operational facilities

Development and testing facilities must be physically (not logically or virtually) separated from operational facilities when data confidentiality is at a High Sensitivity level, or due to other estimated criticality factors (e.g., documented integrity or availability concerns, or due to reasons of sensitive data aggregation). Other sensitivity levels must provide logical isolation as a minimum requirement. Rules for the transfer of software from development to operational status should be defined and documented.

Development and test activities can cause serious problems, including unwanted modification of files or the system environment, disclosure of confidential information, or system failure. A strong degree of separation is necessary between operational, test and development environments to prevent operational problems. A similar separation should also be implemented between development and test functions, to maintain a stable control environment in which to perform meaningful tests and to prevent inappropriate developer access during testing. Mutual separation of development, test and operational facilities will reduce the risk of accidental change, unauthorized access to operational software and business data, and interference with the quality of testing.

If development or test staff have access to the operational system and its information, they may be able to introduce unauthorized and untested code or alter operational data. On some systems this capability could be misused to commit fraud, or introduce untested code or malware. Untested code and/or malware can result in serious security and operational problems.

Developers and testers can pose potential threat to the confidentiality of operational information. Development and testing activities may cause unintended changes to software and information if they share the same computing environment.

The following controls should be implemented:

  1. Development, test, and operational software should be run on different computer equipment (e.g., separate memory, processor, bus, etc.), and must be, in the case of High Sensitivity data or requirements for a high degree of integrity or availability. A virtual environment (one employing logical components to enforce separation) does not fully meet these criteria;
  2. Development and testing activities should be reliably separated from production operations, and physical segregation (not logical or virtual) must be employed in instances of High Sensitivity data processing and/or storage;
  3. Compilers, source code, editors and other system utilities should not be accessible from operational systems when not required;
  4. Different authentication procedures and credentials should be used for operational and test systems, to reduce the risk of error and/or loss of credentials. Users must use different passwords for these systems, and menus should display appropriate identification messages; and
  5. Development staff must only have access to operational passwords where required for support purposes. Controls should ensure that such passwords are changed after use or when such support is no longer required.

Changes to systems must be validated in a test environment with the same services as those in production. Changes must be tested against existing services, existing security mechanisms, and current server and client connection mechanisms.

Testing must be done within isolated networks, using anonymous and depersonalized data taken from the production environment or random information. If data cannot be effectively made anonymous or strongly de-identified, the test environment must be protected using equivalent controls with regard those protecting the production environment. In general, personal information should not be introduced to any test or development environment.

Isolated network environments must be within a physically secure location to prevent against observation of, or interference with, test systems. Clients or systems accessing the test environment must not be able to access a production environment, so as to avoid potentially damaging communication (be it intentional or otherwise) between test and production environments, or operator confusion during administration.

Test systems must have all data securely removed before being relinquished for other use. The data must be securely removed as described in the GO-ITS 25.20 standard and related operating procedure for Disposal, Loss and Incident Reporting of Computerized Devices & Digital Storage Media.

Systems must not be migrated directly from development to production environments. Production components must be “built from scratch”, based on the system assembly instructions compiled in the test environment (e.g., the “build book”).

3.1.12. External facilities management

The use of an external contractor to manage information systems may introduce potential security exposures, such as the possibility of compromise, damage, or loss of data at the contractor’s site. Prior to using external facilities management services, the risks must be identified and appropriate controls agreed to with the contractor, and incorporated into any agreements.

Particular issues that should be addressed include:

  1. Identifying sensitive or critical applications better retained in-house;
  2. Supply chain security;
  3. Obtaining the approval of business application owners;
  4. Identifying implications for business continuity plans;
  5. Specifying security standards, and the process for measuring compliance;
  6. Allocation of specific responsibilities and procedures to monitor all relevant security activities in an effective manner;
  7. Definition and documentation of responsibilities and procedures for reporting and handling security incidents;
  8. Protecting personal information and sensitive data from unauthorized access; and
  9. Privacy breach notification according to Government of Ontario direction and/or requirements.

External parties who are managing facilities on behalf of the Government of Ontario must agree to:

  1. Be bound by the principles, requirements, and best practices under which the Government of Ontario operates, including GO-ITS and Information Security and Privacy Classification (ISPC) Policy requirements;
  2. Access for audit, periodic audit by the OPS (or third party approved by the Government of Ontario) to confirm adherence to those principles, requirements, and best practices; and
  3. Oblige other customers and business partners via agreements to adhere to practices that are as, or more, secure than Government of Ontario’s in circumstances where they may influence the security of Government of Ontario I&IT operations.

Liabilities and recourse due to failure to comply with these requirements must be specified in advance.

Circumstances under which mutual obligations must be stipulated include, but are not limited to:

  1. Service outage;
  2. Perimeter breach and/or unauthorized release of sensitive data;
  3. Privacy breach and/or unauthorized disclosure of personal information;
  4. Quality, security issues with designs, developed code, presence of malware;
  5. Failure to follow documented procedures; and
  6. Third-party certification of external facilities, with respect to agreed service levels.

3.2. System planning and acceptance

Advance planning and preparation are required to ensure the availability of adequate capacity and resources to minimize the risk of systems failure.

The operational, functional, and non-functional requirements of new systems should be established, documented and tested prior to their acceptance and use.

3.2.1. Capacity planning

Capacity demands must be monitored and projections of future capacity requirements made to ensure the availability of facilities, such that resources including adequate processing power, network capacity, and storage are available. These projections should take account of new business and system requirements and current and projected trends in the organization’s information processing needs.

Mainframe computers require particular attention because of the much greater cost and lead time required for procurement of new capacity. Managers of mainframe services should monitor the utilisation of key system resources, including processors, main storage, file storage, printers and other output devices, and communications systems. Trends in system use should be identified. Managers should use trend information to identify and avoid potential bottlenecks that might present a threat to system security or user services, and plan appropriate remedial action.

Capacity planning must take into account business criticality, the demands of providing functionality, and the requirement to maintain accurate activity records under both typical and peak loads.

To ensure security is enforced in capacity planning, all specified access control systems must:

  1. Fail over to a high security or access denied state in the event of critical resource (e.g., CPU, bandwidth, etc.) shortage;
  2. Record authorization and/or authentication events, both failed and successful; and
  3. Properly manage the authentication of users throughout the performance of functions such as stateful or stateless session management.

Consideration must be given to the length of time required to acquire additional components as per vendor availability. Larger and more complex systems generally incur an increased lead-time for resource procurement. Enough lead-time should be taken to acquire additional resources, if projections indicate an increase in traffic volume.

Business and mission critical systems must not be deployed such that they represent a single point of failure. Fail-over capacity and redundancies adequate to meet availability requirements must be designed into these systems, minimally providing an ‘N+1’ architecture (where ‘N+1’ dictates that there must always be one more than the bare minimum number of components necessary to deliver a functional system).

3.2.2. System acceptance

Acceptance criteria for new information systems, upgrades and new versions must be established and suitable tests of the system carried out prior to acceptance. System owners and program managers should ensure that the requirements and criteria for acceptance of new systems are clearly defined, agreed, documented and tested.

The following controls should be considered when planning an acceptance strategy:

  1. Performance and computing capacity requirements;
  2. Error recovery and restart procedures, and contingency plans;
  3. Preparation and testing of routine operating procedures to defined standards;
  4. Agreed set of security controls in place;
  5. Effective manual procedures;
  6. Business continuity arrangements, as required;
  7. Evidence that installation of the new system will not adversely affect existing systems, particularly at peak processing times, such as month end;
  8. Evidence that consideration has been given to the effect the new system has on the overall security of the organization; and
  9. Training in the operation or use of new systems.

For major projects, the operations function and users should be consulted at all stages in the development process to ensure the operational efficiency of the proposed system design. Appropriate tests should be carried out to confirm that all acceptance criteria are fully satisfied.

Prior to deployment, new systems must be evaluated to ensure that business and security requirements have been met. Systems must be subject to Security Testing and Evaluation (STE) methods geared to the sensitivity level of processing prior to being accepted for production use. In critical instances, systems should be subjected to external assessment via a third-party expert group in Security Testing and Evaluation prior to initial deployment, and whenever major changes have been made to the system configuration or composition.

3.3. Protection against malware

Controls are required to prevent and detect the introduction of malware to the environment.

Software and information processing facilities are vulnerable to the introduction of malware. Users should be made aware of the dangers of unauthorized or malware, and managers should, where appropriate, introduce special controls to detect or prevent its introduction.

3.3.1. Controls against malware

Detection and prevention controls to protect against malware and appropriate user awareness procedures must be implemented. Protection against malware should be based on security awareness, reduction of vulnerability to malware, appropriate system access, and change management controls.

All systems must employ controls to protect against malware.

The following controls should be considered when planning a strategy for malware control:

  1. Formal procedures requiring compliance with software licenses and prohibiting the use or installation of unauthorized software, or changes to authorized packages;
  2. Formal procedures to protect against risks associated with obtaining files and software either from or via external networks, or on any other medium, indicating what protective measures should be taken;
  3. Installation and regular update of anti-malware detection and repair software to scan computers and media either as a precautionary control or on a routine basis for certain types of malware;
  4. Conducting regular software review for systems supporting critical business processes. The presence of any unapproved files or unauthorized software should be formally investigated;
  5. Scanning any files on electronic media of uncertain or unauthorized origin, or files received over unknown networks, for malware, prior to use;
  6. Scanning any electronic mail attachments and downloads for malware before use. This may be carried out at different places (e.g., at electronic mail servers, desktop computers or when joining the network of the organization);
  7. Management procedures and responsibilities to deal with malware protection on systems, training in their use, reporting and recovering from attacks;
  8. Appropriate business continuity plans for recovering from attacks, including all necessary data and software backup and recovery arrangements; and
  9. Procedures to verify all information relating to malware, and ensure that warning bulletins are accurate and informative. Managers should ensure that qualified sources of information are used to differentiate between hoaxes and real incidents.

Staff should be made aware of the problem of hoaxes and what to do on receipt of them. In addition all users should be made familiar with their obligations under the published Guidelines for Acceptable Use of I&IT Resources Policy.

Malware may be present as executable or interpretable scripts, shell code, or program commands in files, e-mail or web content. All of these should be scanned and verified against known signatures/indicators of malware. Attack signatures must be monitored on a daily basis and updated immediately upon release for detection functions to remain effective. In addition:

  1. The installation of software must be restricted to administrative staff;
  2. Anti-malware software must be installed, operated, and updated regularly for both clients and servers, as appropriate; and
  3. Firewall devices or software must manage and limit both incoming and outgoing network connections to a pre-defined spectrum of approved connections, services and applications.

Software updates must only be downloaded from authoritative sites; cryptographic signatures or certificates of origin for the software must be provided by the vendor, and must be confirmed to be accurate prior to installation. Patch management operations can help protect assets from malware, and must comply with the requirements and metrics described in GO-ITS 42 Operating Procedure for Patch Management.

3.4 System administration

Routine procedures should be established for carrying out an approved backup strategy, taking backup copies of data and rehearsing their timely restoration, logging events and faults and, where appropriate, monitoring the equipment environment to protect the integrity and availability of information processing and communication services.

3.4.1. Information backup

Backup copies of essential business information and software must be taken regularly. Adequate backup facilities should be provided to ensure that all essential business information and software could be recovered following a disaster or media failure. Backup arrangements for individual systems should be regularly tested to ensure that they meet the requirements of business continuity plans. The following controls should be considered:

  1. A minimum level of backup information, together with accurate and complete records of the backup copies and documented retention and restoration requirements/procedures, should be stored in a remote location, at a sufficient distance to escape any damage from a disaster at the main site. At least three generations or cycles of backup information should be retained for critical business applications;
  2. Backup information should be given an appropriate level of physical and environmental protection consistent with the standards applied at the main site. The controls applied to media at the main site should be extended to cover the backup site;
  3. Backup media should be regularly tested, where practicable, to ensure that they can be relied upon for emergency use when necessary;
  4. Restoration procedures should be regularly checked and tested to ensure that they are effective and that they can be completed within the time allotted in the operational procedures for recovery;
  5. The retention period for the backup media should be determined; and
  6. Information from systems processing High Sensitivity information, or data sets that by nature of inherent confidentiality or aggregation constitute High Sensitivity information (as defined by the ISPC Policy), must be encrypted using approved methods for the purposes of backup.

The frequency of data backups must be based upon availability requirements, as defined by the business case for the system. Storage must take place in a secure off-site facility, and system restoration procedures must be tested regularly.

Configuration of systems must be stored offline, such that they may not be viewed, copied, or modified by unauthorized staff.

3.4.2. Activity logging

The activities and events on a system must be logged and archived for the purpose of routine monitoring and audit. Operator, system, and audit/event logs must be stored on a centralized, secure log server. These logs must include, as a minimum requirement:

  1. System start and halt times;
  2. System activities, errors, and any corrective action taken in response;
  3. Confirmation of the correct boot procedure, and handling of data and output;
  4. The identity of the individual invoking commands or functions resulting in a log entry;
  5. The timestamps associated with the beginning and end of any user or operator session;
  6. The issuance and use of privilege if granted;
  7. Errors, success/failure, and related messages associated with user or operator activities;
  8. Connections and session initiations related to user or operator access to the system;
  9. The origin of user or operator sessions, be this an indication of node, device, client, location, or other mode of specifying session origin, if the session is not conducted from the system console;
  10. Changes to system mode, run level, or security context where applicable; and
  11. A timestamp indicating when the log entry was generated by the system, with system time synchronized to a redundant and validated reference time source.

System logs must also be generated to capture output resulting from automated processes. Specific details of files accessed or modified should be recorded in the audit logs, where applicable and given the configuration of the system.

3.4.3. Fault logging

Faults must be reported and corrective action taken. Faults reported by users regarding problems with information processing or communications systems should be logged. There should be clear rules for handling reported faults including:

  1. Review of fault logs to ensure that faults have been satisfactorily resolved; and
  2. Review of corrective measures to ensure that controls have not been compromised, and that the action taken is fully authorized.

The following measures should be taken, depending on the frequency and nature of the faults, once detected:

  1. Monitoring of all network interfaces should increase in detail;
  2. Monitoring of servers and services should increase in detail; and
  3. Escalate the event and notify support/security staff, as dictated by relevant incident response procedures.

In the event of a critical system fault, the administrative contact for the system must be notified, and provided with the following information:

  1. User or system ID associated with the fault;
  2. Operator and process name(s);
  3. Date and time fault occurred;
  4. Description of fault;
  5. Description of actions that caused fault (if possible); and
  6. Description of responsive action taken (if any).

If it is determined that the fault is security related, the incident must be escalated to the security contact for the system. Escalation and incident response processes should reference the requirements expressed in GO-ITS 37 Incident Management.

Fault logs are intended to track systems errors that occur during normal system operation. They may also indicate an attack on the system, the network, or adjacent systems.

Logging must include, but is not limited to, the following events:

  1. Device errors and status messages;
  2. File or other resource access failures;
  3. Licensing activities;
  4. Authentication failures;
  5. Session duration;
  6. New device detection;
  7. Network connection activities (e.g., host up/down, connectivity problems, changes involving network interfaces, or the system hardware/network addresses, etc.);
  8. Operator activities (e.g., backups, restores, rollback, etc.);
  9. Remote connections to/from the system;
  10. Any security alerts not captured by operator, system, or audit /event logs);
  11. System or application error messages;
  12. Use of privileged commands, and/or attempts to invoke a privileged mode or alter system mode, security context, or run level; and
  13. User logons.

3.5. Network management

The security management of networks that span organizational boundaries requires attention. Additional controls should be implemented to protect sensitive data passing over public networks and the supporting infrastructure.

Network managers must implement controls to ensure the security of data in networks, and the protection of connected services from unauthorized access. In particular, the following controls should be implemented:

3.5.1 Management:

  1. Operational responsibility for networks should be separated from computer operations where appropriate;
  2. Responsibilities and procedures for the management of remote equipment, including equipment in user areas, should be established;
  3. If necessary, special controls should be established to safeguard the confidentiality and integrity of data passing over public networks, and to protect the connected systems. Special controls may also be required to maintain the availability of the network services and computers connected;
  4. Management activities should be closely co-ordinated both to optimize the service to the business and to ensure that controls are consistently applied across the infrastructure;
  5. Logical or virtual network segmentation must not be used as a primary safeguard in environments where High Sensitivity processing is performed and/or threats have been identified via a TRA ;
  6. Security Zones must be employed to separate operations on the network, such as the components or layers of an application. The boundaries between such zones must be physical and robust in nature (discrete hardware instances, not logically or virtually enforced):
    1. Where High Sensitivity data is processed or stored;
    2. Where a TRA identified a requirement for high levels of integrity and/or availability; and
    3. Where the boundary is considered to be an external perimeter;
  7. Discrete hardware implementations of Security Zones should leverage multiple platforms to increase the technical difficulty of subverting defence in depth controls; and
  8. All hardware network components of logically or virtually enforced implementations of Security Zones must be managed as security or policy enforcement devices, with a commensurate degree of rigour in operation and change control.

3.5.2. Identification and authentication

  1. Authentication requests must be denied by default, and permitted only upon presentation of the proper combination of password and/or credentials, and user ID.

3.5.3. Privileges and parameters

  1. Assignment of access rights must be limited, based on use cases, and granted according to the principle of least privilege.

3.5.4. Confidentiality, integrity, availability, and non-repudiation

  1. Sensitive communications must be protected from malicious observation or modification;
  2. System technologies from different vendors must integrate so as to not cause an aggregate reduction in the efficacy of combined security features;
  3. Operating systems of clients and servers must be hardened, as per OCCIO recommendations, applicable industry best practice, and relevant build books;
  4. All access must default to ‘prohibited’, and all ports must default to ‘closed’, upon power-on or warm reset of network equipment;
  5. Firewalls that employ enterprise-grade stateful layer three designs (or technology approved per section 2.1.2 of GO-ITS 25.11) must be used to enforce network policy by forwarding only pre-approved connections;
  6. Systems must be placed between firewalls (as described above) in a DMZ network segment, to protect them from internal and external threats; and
  7. Networks with physical media that cannot be effectively managed, or is public, must employ additional confidentiality and integrity safeguards.

3.5.5. Monitoring, response, recovery, and review

  1. Network traffic must be monitored and analysed by an Intrusion Detection System (IDS) or Intrusion Prevention System (IPS);
  2. Incident response and escalation procedures must exist, and be practised, in anticipation of hostile network events;
  3. Business Continuity Management must be exercised, to ensure that network resources are available during, and restored as quickly as possible after, a hostile event;
  4. Processes and procedures for dealing with hostile events must be reviewed after practice or exercise, and must be updated to reflect lessons learned; and
  5. Interactive network activity from client systems must be reliably associated with a specific user account at any given time.

3.5.6. Planning, implementation, management, review and audit

  1. Proposed systems must have their security measures validated via testing and evaluation, prior to implementation in a production environment;
  2. Changes may not be made to proposed plans during implementation, without approval of the project owner and the security team;
  3. Documentation must be updated to include exceptions made during implementation to proposed designs;
  4. Remote access to systems must be securely managed as described in relevant GO-ITS 25 series documents;
  5. A change control process must manage requests for a change in, or granting of, access;
  6. Users must be educated as to what security mechanisms exist, the reasons for their use, and the requirements for compliance with those mechanisms; and
  7. Security mechanisms must periodically be reviewed, to validate the sufficiency of their protection in the context of current intrusion techniques and technology. 

Security mechanisms must periodically be audited to ensure that they are functioning as designed, as safeguard efficacy is required if they are to reduce risk.

3.6. Media handling and security

The management of removable computer media, such as tapes, disks, cassettes and printed reports must be controlled and physically protected to prevent damage to assets and interruption of business activities.

Media must be disposed of securely and safely in accordance with ISPC Policy requirements when no longer required. Sensitive information may be inadvertently disclosed to unauthorized persons through careless disposal of media, causing harm to the Government or citizens.

3.6.1. Management of removable computer media

Appropriate operating procedures must be established to protect documents, computer media (tapes, disks, cassettes), input/output data and system documentation from damage, theft and unauthorized access.

  1. If no longer required, the previous contents of any re-usable media that are to be removed from the organization should be erased permanently and completely using secure methods;
  2. Authorization should be required for all media removed from the organization and a record of all such removals to maintain an audit trail should be kept;
  3. All media should be stored in a safe, secure environment, in accordance with manufacturers’ specifications; and
  4. All procedures and authorization levels should be clearly documented.

Intrusion Detection System (IDS) or Intrusion Prevention System (IPS) components should not be equipped with removable media devices. If a removable media device is required as part of installation, it should be removed (if possible) once the installation is complete. This reduces the possibility that the system could be easily booted via removable media (floppy, CD, etc.) and compromised. This also reduces the likelihood that staff with physical access to systems will remove data without authorization.

Removable media must be stored according to the environmental requirements of the media, and must be stored such that only staff authorized to perform backup and recovery of data have access to the media. Accountability for media must be enforced before, during, and after use.

3.6.2. Information handling procedures

All Government of Ontario information must be classified and handled according to ISPC Policy requirements, to protect I&IT assets from unauthorized disclosure or misuse.

Processes for handling data related to documents, computing systems, networks, mobile computing, mobile communications, mail, voice mail, voice communications, multimedia, postal services or facilities, use of fax machines and any other sensitive items (e.g. blank cheques, blank card stock, or invoices) must be consistent with asset classification and adhere to ISPC policy.

The following controls must be implemented:

  1. Labelling of all media, in accordance with ISPC Policy requirements;
  2. Access restrictions, badge procedure, etc. to identify unauthorized personnel;
  3. Maintenance of a formal record of the authorized recipients of High Sensitivity data;
  4. Ensuring that input data is complete, that processing is properly completed and that output validation is applied;
  5. Protection of spooled data awaiting output to a level consistent with its identified sensitivity;
  6. Storage of media in an environment which accords with manufacturer specifications;
  7. Keeping the distribution of data to a minimum in accordance with the principle of least privilege;
  8. Clear marking of all copies of data for the attention of the authorized recipient; and
  9. Review of distribution lists and lists of authorized recipients at regular intervals.

When handling sensitive data such as configuration files and passwords, the following precautions must be taken:

  1. Transmitted and stored information that has been classified as High Sensitivity data must be protected through use of encryption of a type and strength sufficient to withstand attack, as documented in GO-ITS 25.12 Use of Cryptography;
  2. Unencrypted password or credential information must not be cached, and must be encrypted when in transport or during session initiations (e.g., over a network); and
  3. Access to backup media must be limited to authorized personnel.

3.6.3. Security of system documentation

System documentation may contain a range of sensitive information (e.g., descriptions of applications processes, procedures, data structures, and authorization processes). As such, system documentation must be protected from unauthorized access, and kept current. The following controls should be implemented:

  1. System documentation should be classified, labelled, and stored securely;
  2. The access list for system documentation should be kept to a minimum and authorized by the application owner; and
  3. System documentation held on a public network, or supplied via a public network, should be appropriately protected.

Access to documentation, whether in printed format or online, must be restricted to authorized staff. Online documentation must be protected through application of:

  1. Access rights;
  2. User and group ownership (i.e., unauthenticated or unauthorized users must not have access to information); and
  3. Approved encryption (for documentation dealing with security configuration settings).

In addition, online documentation must not be copied, transmitted, or modified without permission.

Printed documentation must be protected through the following restrictions:

  1. All documentation must be retrieved from printers as soon as printing is complete, or the security feature available on some printers must be used (a code, once entered, prints the job while the user is present at the printer);
  2. All documentation must be secured when not in use;
  3. Security documentation must not be left unattended;
  4. Security documentation must not be removed from secure areas; and
  5. Security documentation must not be copied without permission.

Third party maintenance personnel who require access to system documentation must sign a Non-Disclosure Agreement. In addition, third party personnel must not be permitted to remove system documentation.

3.7. Exchanges of information and software

Exchanges of information and software between organizations must be controlled, and must be compliant with both ISPC Policy and any relevant legal requirements (e.g., privacy legislation).

Exchanges must be carried out on the basis of agreements. Procedures and standards to protect information and media in transit must be established. The business and security implications associated with electronic data interchange, electronic commerce, electronic mail and the requirements for controls must be considered.

3.7.1. Information and software exchange agreements

Agreements must be established for the electronic or manual exchange of information and software between organizations.

The security provisions present in such an agreement should reflect the sensitivity of the business information involved.

Agreements on security provisions should include:

  1. Management responsibilities for controlling and notifying transmission, dispatch and receipt;
  2. Procedures for notifying sender, transmission, dispatch and receipt;
  3. Minimum technical standards for packaging and transmission;
  4. Courier identification standards;
  5. Responsibilities and liabilities in the event of loss, leakage, redirection of data;
  6. Use of labels according to ISPC Policy requirements, to ensure the meaning of the labels is immediately understood throughout the OPS, and that the information can be appropriately protected;
  7. Information and software ownership and responsibilities for data protection, software copyright compliance and similar considerations;
  8. Technical standards for recording and reading information and software; and
  9. Any special controls that may be required to protect sensitive items, such as cryptographic measures.

Agreements as to the use, protection, duplication, and re-transmission of shared information and software must exist and be agreed to prior to any transmission of data between organizations. High Sensitivity information must not be distributed without written permission from the relevant program manager (or a delegated authority).

These agreements must specify intent and usage parameters for all shared data. Remedies must be specified to enforce agreed-upon usage and protection standards, and to provide recourse for failure to adhere to those standards.

Where ongoing measures must be taken, both parties must have an agreement regarding the type of service that must be provided, how the provision of that service may be verified, and penalties for failure to provide the agreed upon level of service.

Measures for the control of data must be defined both while in transmission, and in storage at the recipient’s location. Security provisions must include:

  1. Protection from unintended use, sharing, or duplication; and
  2. Means by which the operation of data protection mechanisms may be verified.

Protection of data must take into account current legislation, which may prohibit certain uses, or require specific data handling measures.

External data sharing partners must:

  1. Follow practices that meet or exceed Government of Ontario internal security practices;
  2. Submit to regular Government of Ontario and/or external audit of those practices;
  3. Agree to penalties for failure to adhere to all agreements; and
  4. Agree to be held liable for all repercussions arising from a failure to adhere to all agreements.

3.7.2. Security of media in transit

Information can be vulnerable to unauthorized access, misuse or corruption during physical transport, for instance when sending media via the postal service or via courier. As such, media being transported must be stored securely, and protected from unauthorized access, misuse or corruption. For example:

  1. Reliable transport or couriers should be used. A list of authorized couriers should be agreed with management and a procedure to check the identification of couriers implemented;
  2. Packaging should be sufficient to protect the contents from any physical damage likely to arise during transit and in accordance with manufacturers’ specifications; and
  3. Special security provisions should be adopted, where necessary, to protect sensitive information from unauthorized disclosure, modification, or removal. Examples include:
    1. Use of locked containers;
    2. Use of item / cargo / document manifests and records of receipt;
    3. Delivery by hand;
    4. Tamper-evident packaging (which reveals attempt to gain access);
    5. In exceptional cases, splitting of the consignment into more than one delivery and dispatch by different routes; and
    6. Use of digital signatures and approved cryptography at a level and of a type that meets GO-ITS 25.12 and ISPC Policy requirements.

3.7.3. Electronic commerce security

Electronic commerce can involve the use of electronic data interchange (EDI), electronic mail and online transactions. Electronic commerce is vulnerable to a number of network threats that may result in fraudulent activity, redirected or incomplete transactions, contract dispute, and leakage or modification of information, and must be protected against these threats.

Consideration should be given to the resilience to attack of the host used for electronic commerce, protection of key documents/information, and the security implications of any network interconnection required for its implementation. Software used for electronic commerce systems must also be subject to STE practices, such as a vulnerability assessment, before initial deployment.

3.7.4. Security of electronic mail

Electronic mail differs from traditional forms of business communications due to its speed, message structure, degree of informality and vulnerability to unauthorized actions. Consideration should be given to the need for controls to reduce security risks created by electronic mail. Security risks

The following security risks should be addressed:

  1. Vulnerability of messages to unauthorized access/interception, modification, or denial of service;
  2. Vulnerability to error (e.g., incorrect addressing or misdirection, and the general reliability and availability of the service);
  3. Impact of a change of communication media on business processes (e.g., the effect of increased speed of dispatch or the effect of sending formal messages from person to person rather than company to company);
  4. Legal considerations, such as the potential need for proof of origin, dispatch, delivery and acceptance;
  5. Implications of publishing e-mail distribution lists that reach internal addresses or many staff; and
  6. Controlling remote user access to electronic mail accounts. Procedures for electronic mail

Procedures for the use of electronic mail must be developed and controls put in place to reduce security risks created by electronic mail. These controls should address the following:

  1. Attacks on electronic mail (e.g., malware, social engineering, interception);
  2. Protection of electronic mail attachments;
  3. Guidelines on when not to use electronic mail;
  4. Employee education regarding inappropriate use (e.g., sending defamatory electronic mail, use for harassment, or unauthorized purchasing);
  5. Use of approved cryptographic techniques to protect the confidentiality and integrity of electronic messages, such as GO-PKI ; and
  6. Additional controls for vetting messaging that cannot be authenticated.

If e-mail is used to provide alerts or other communications to analysts within IDS or IPS operating environments, these mail messages must be protected from observation or modification if they will travel over a non-private network.

E-mail messages must be sent at appropriate intervals so as not to overwhelm the end user’s channel of communications.

If available on mail servers, the following features must be configured and enabled:

  1. Scanning of SMTP traffic for illegal commands;
  2. Scanning of traffic for hostile executable and/or malicious content;
  3. Removal of executable and/or otherwise malicious content; and
  4. Control over abuse, such as the unauthorized use of SMTP relay or user enumeration.

3.7.5. Security of electronic office systems

Procedures and guidelines must be prepared and implemented to control the business and security risks associated with electronic office systems.

Consideration given to the security and business implications of interconnecting such systems should include:

  1. Vulnerabilities of information in office systems (e.g., recording phone calls or conference calls, confidentiality of calls, video conferencing equipment, storage of faxes, opening mail, distribution of mail, increasing complexity of multi-function office devices with network interfaces, remote management, and local storage);
  2. Procedures and appropriate controls to manage information sharing (e.g., the use of corporate electronic messaging or collaboration systems);
  3. Excluding categories of sensitive business information if the system does not provide an appropriate level of protection;
  4. The suitability, or otherwise, of the system to support business applications such as communicating orders or authorizations;
  5. Categories of staff, contractors or business partners allowed to use the system and the locations from which it may be accessed;
  6. Restricting selected access to specific categories of user (e.g., restricting access to sensitive project information by limiting collaboration materials to the staff working on that project);
  7. Identifying the status of users (e.g., employees of the organization or contractors in directories for the benefit of other users), and managing changes to their status (i.e., change or termination of responsibilities);
  8. Retention and backup of information held on the system; and
  9. Fallback requirements and arrangements.

Communication between interconnected components, and other network policy enforcement systems, must adhere to the activity logging requirements described in section 2.4 of this document.

3.7.6. Publicly available systems

Care must be taken to protect the integrity of electronically published information and publicly accessible information systems, to prevent unauthorized modification that could jeopardize transactions and/or harm the reputation of the publishing organization.

Information on a publicly available system (e.g., information on a Web server accessible via the Internet), may need to comply with laws, rules and regulations in the jurisdiction in which the system is located or where trade is taking place. In addition, publicly available Web servers must abide by GO-ITS 23 Web Standard and ISPC Policy requirements. There must be a formal authorization process before information is made publicly available, and the integrity of such information must be protected to prevent unauthorized modification.

Software, data and other information requiring a high level of integrity, made available on a publicly accessible system, should be protected by appropriate mechanisms (e.g., cryptography, digital signatures, etc.). Electronic publishing systems, especially those that permit feedback and direct entering of information, should be carefully controlled so that:

  1. Information is obtained in compliance with any data protection legislation;
  2. Information input to, and processed by, the publishing system will be processed completely and accurately in a timely manner;
  3. Sensitive information will be protected during the collection process and when stored; and
  4. Access to the publishing system does not allow unintended access to networks to which it is connected.

Measures taken to ensure the confidentiality, integrity, availability, and authenticity of publicly observable systems, and their communications, must periodically be reviewed to ensure their adequacy given current intrusion techniques and technology. These measures must include, but are not limited to:

  1. Systems that are publicly available (e.g., a public web server) must have security controls in place to ensure that the integrity of the data is protected;
  2. Services that require public access for functionality (e.g., a public web server would require public access to HTTP and HTTPS services) should be the only services that are enabled on the system, in keeping with the principle of least privilege;
  3. All services that do not require public access must be disabled and/or removed after review of technical and functional requirements (for example, a public web server would have TCP/UDP small servers disabled, and services such as networked file systems, SMTP, POP, and TELNET disabled and removed, if supported);
  4. Backups must be performed daily on public systems (at least incrementally) to ensure minimal loss of data;
  5. If a public system is used for processing transactions, a secure transport protocol must be used along with server certificates;
  6. Sensitive or personal information (e.g., names, credit card numbers, etc.) must not be stored on publicly accessible components of a transaction processing system any longer than required for the completion of a transaction;
  7. Sensitive or personal information stored on a system for the purpose of completing a transaction must be isolated such that it cannot be interpreted or modified by the system (e.g., secure application design);
  8. Transactions must be monitored (inbound and outbound). Traffic data must not include potentially harmful or sensitive content, for example:
    1. System structure or configuration information;
    2. Networking configuration;
    3. System account information;
    4. Executable or interpretable code, unless required; and
    5. Non-alphanumeric characters, unless required; and
  9. Input or output content must be subject to inspection techniques such as bounds checking, and must not exceed identified acceptable values.

Data confidentiality and integrity must be maintained via a cryptographic system, when sharing data or performing transactions between servers, via public networks. Cryptographic systems deployed within the Government of Ontario must be evaluated (ideally by a third party and/or via a recognized evaluation scheme) for suitability against current attack techniques and technology. The strength of deployed cryptography must be appropriate given the sensitivity of transmitted data, and compliant with GO-ITS 25.12.

The I&IT Strategy and Cyber Security (SCS) Division, or a successor organization, is the cryptographic authority for the Government of Ontario; algorithms, implementations, effective key length, and other factors must meet SCS requirements.

3.7.7 Other forms of information exchange

Verbal discussion of security mechanisms, system configuration, access controls, credentials, user accounts, use of cryptography, or other similar sensitive information should not be conducted in public areas, before personnel who lack appropriate administrative authorization (or whose authorization is unknown), or before staff who have not been subject to personnel screening and signed an NDA or relevant Government of Ontario security documentation.

4. Related standards

4.1. Impacts to existing standards

Identify any Standards that reference or are referenced by this Standard and describe the impact.

GO-IT StandardImpactRecommended Action
All GO-ITS 25 standardsAll standards in this series refer to this document; this document is considered a normative reference for the entire series.Update only, no impact. Compliance with all standards is mandatory.

4.2. Impacts to existing environment

Impacted InfrastructureImpactRecommended Action

5. Compliance requirements

5.1. Internal compliance

Managers must ensure that all security operations within their area of responsibility are carried out correctly and in a manner that meets security requirements. All areas within the organization must be subject to regular review to ensure compliance with the information technology requirements and additional standards outlined in this document.

Owners of information systems, programs, and/or data should support regular review of their compliance with all relevant directives, policies, standards, and procedures to ensure that security requirements have been properly addressed, and safeguards are appropriately deployed.

5.1.1. Access to accounts and information

For computing environments and access control systems within the scope of this document, program managers must not be permitted to request the following:

  • Access to a user’s credential or identity as assigned by an access control system;
  • Access to data, files, etc. stored by a user whereby access to such information is managed by an access control system; and/or
  • Information encrypted by a user through the use of a key or cryptographic process controlled by an access control system, even if desired for recovery purposes.

Program managers must ensure that employees use central repositories, shared folders, or other mechanisms such that any critical work products remain accessible to relevant staff. In such instances, effective management of project information is the primary means by which access to such information should be safeguarded.

Program managers must act to protect the integrity of credentials granted to users. This must include the following:

  • Ensuring appropriate handling of user credentials;
  • Ensuring appropriate education for users regarding the use and security of their credentials, and any related access control system or identity service (e.g., GO-PKI ); and
  • Ensuring that inappropriate requests that could harm the integrity of user accounts, assigned credentials, or electronic identities are not accepted.

It is incumbent on staff with Director-level authority (or greater) to diligently review and authorize requests for the recovery of the information described above.

5.2. External compliance

Several areas of external compliance requirements exist. Government of Ontario I&IT assets must be managed appropriately to comply with these requirements. All external vendors and service operators must be subject to regular review to ensure compliance with the information technology requirements and additional standards outlined in this document.

5.2.1. Compliance with legal requirements

The design, operation, and management of information systems are subject to statutory, regulatory, and contractual requirements that may influence security considerations. Advice on specific legal issues should be sought in instances where security techniques may contravene legal requirements (i.e., system monitoring) or when these techniques must be used in other jurisdictions.

5.2.2. Intellectual property and copyright

Procedures should be implemented to ensure compliance with legal restrictions on the use of software and copyrighted intellectual property. Failure to comply with requirements can lead to legal action and financial consequences.

Legislative, regulatory, and/or contractual requirements may exist that place restrictions on the kinds of reproduction or transmission permitted for proprietary materials or materials in respect of which there may be an intellectual property right. Legal advice should be sought in instances (or jurisdictions) where these limits are not clear.

In particular, the following safeguards should be implemented:

  1. Use existing procurement and vendor of record channels to obtain software and media;
  2. Maintain awareness among staff regarding acquisition of software products;
  3. Maintain asset inventory, including proof of license ownership, master copies, etc.;
  4. Maintain controls to ensure fixed seat licenses are not inadvertently exceeded;
  5. Monitor the installation of acquired packages and control inappropriate installation; and
  6. Maintain license conditions and remove software where license status is unknown.

5.2.3. Organizational records

Records must be protected from loss, unauthorized release, destruction, and falsification. Some types of organizational records may need to be securely retained to meet statutory or regulatory requirements, as well as to support essential business activities (such as those records which confirm financial status).

Records should be categorized, with retention periods and storage requirements made clear for each type of record that is identified for the program area. Consideration should be given to the archival procedure used for the storage of records to ensure they are protected. Technology change and integrity protection should be factors in the choice of medium for electronic records, to ensure they can be accessed, and cannot be modified.

5.2.4. Data protection and privacy of personal information

The Government of Ontario is bound by legislative requirements at both the provincial and federal level regarding the protection of personal privacy (as outlined in the Introduction of this document). Security techniques and methods must fully comply with ISPC Policy requirements and all relevant federal and provincial privacy legislation.

Processes such as Privacy Impact Assessments should be employed to identify areas of privacy risk, and legal advice should be obtained where uncertainty exists regarding privacy impact, particularly when data is being archived, aggregated, transferred to third parties, or transmitted to other jurisdictions. If personal information is subject to disclosure due to a breach, any duties under Government of Ontario privacy breach procedures, or those outlined within any relevant legislation, must be undertaken.

5.2.5. Cryptography

Controls must be in place to ensure compliance with national and international agreements, laws, regulations, and/or other instruments regarding use, import, and export of cryptographic software and devices. The cryptographic mechanisms described or implied in this document are robust and may not be legal for use or import/export in all jurisdictions. Required review may include:

  1. Determination of import/export status for cryptographic hardware and software;
  2. Determination of import/export status for items to which cryptography is to be added;
  3. Determination of use of any cryptography in any jurisdiction where not sanctioned; and
  4. Lawful access requirements of other jurisdictions.

Cryptography deployed as a technical safeguard within an access control system (e.g., to pass credentials and/or provide for integrity assurance), or to provide for communications security, must meet the requirements described in GO-ITS 25.12 Use of Cryptography.

Legal advice should be obtained to ensure compliance with all relevant requirements, particularly if any solution employing cryptographic methods is to be located in another jurisdiction.

5.3. Audit

Periodic audit is required to ensure that security practices and safeguards meet the minimum requirements expressed in this document and that the operation of a given project or environment is sound.

5.3.1. Impact

To reduce the potential impact to operations and other risk of such audit on production systems:

  1. Audit scope and requirements should be discussed and controlled prior to audit activities;
  2. Audit activity should be conducted without write/modify privileges where possible;
  3. Access provided during audit activities should be monitored and supervised;
  4. All relevant procedures and resources required to conduct the audit should be planned for and provided in advance; and
  5. Audit tools should be protected from unauthorized use or modification.

5.3.2. Monitoring

Systems must be monitored on an ongoing basis, in accordance with any legal (e.g., privacy or regulatory) requirements, to detect failure or subversion of safeguards and controls. Operator, system, audit/event, and activity logs must be routinely monitored (by staff trained to identify relevant events, user transactions, and system activity) for this purpose; the extent of monitoring should be commensurate with the operational criticality of the system, the extent of system interconnection, nature of any prior incidents, and data sensitivity (as determined by ISPC Policy). Appropriate separation of duties must be maintained during monitoring activity, and the integrity of log information must be protected against both deliberate acts and automated alteration due to overwriting or other action of a process or service.

As maintenance of an evidentiary trail requires consistent business practices and safeguards, the following measures must be followed as a part of normal daily activities:

  1. Log data must be forwarded to a log host. The log host must be a dedicated, purpose-built, and hardened system on a separately managed network, whose only function is to receive and store activity data; stored data must be protected against modification or overwriting, even by privileged users;
  2. Data for the log host should be encrypted while in transit, and the log host should generate an alert if a monitored device fails to send data for a given period of time;
  3. Timestamps for messages from all monitored systems and other log-generating devices (firewalls, routers, servers, etc.) must be synchronized to a redundant and validated reference time source; and
  4. Consider sending the activity logs to a dedicated printer in a secure room in situations where such logging is absolutely essential (e.g., preserving evidentiary data in an ongoing investigation).

5.4. Implementation and metrics

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

6. Acknowledgements


Please indicate who was consulted as part of the development of this standard. Include individuals (by role and organization) and committees, councils and/or working groups. (Note: consulted means those whose opinions are sought, generally characterized by two-way communications such as workshops):

Organization consulted (Ministry/Cluster)DivisionBranchDate
CSB Internal ConsultationMGS OCCIOCSBJan./Feb. 2008
Ontario Internal Audit DivisionFinanceOIADMar. 2008
OCIPO (now IPA)OCIPO / IPAPrivacyJan./Feb. 2008
Committee/Working Group consultedDate
SADWG (Dissolved)Jan./Feb. 2008
Architecture Review BoardDec. 2014
Architecture Review BoardFeb. 2016
ITELCMar. 2016


Please indicate who was informed during the development of this standard. Include individuals (by role and organization) and committees, councils and/or working groups.

(Note: informed means those who are kept up-to-date on progress, generally characterized by one-way communication such as presentations):

Organization informed (Ministry/Cluster)DivisionBranchDate
Committee/Working Group informedDate
IT Standards Council (Dissolved) (For Information)Feb. 2008

7. Recommended versioning and/or change management

Changes (i.e., all revisions, updates, versioning) to the standard require authorization from the “responsible” organization(s).

Once a determination has been made by the responsible organization to proceed with changes, OCCIO as custodians of the I&IT Rules Management Plan 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 fall into one of two categories:

Minor updates - require confirmation from ARB, and communication to stakeholders and ITELC. Changes are noted in the “Document History” section of the standard. Minor updates generally consist of:

  • Editorial corrections (spelling, grammar, references, etc.) made with the intention to eliminate confusion and produce consistent, accurate, and complete work.
  • Formatting changes (due to template updates or to improve readability of document).
  • Documented organizational changes e.g., renaming of committees, approved transition of committee responsibilities, approved reporting relationship changes.

Standard revisions - require consultation with stakeholders, ARB endorsement, and ITELC approval. Standard revisions consist of any updates to the I&IT Rules Refresh Plan that are not considered minor and may:

  • represent new standard or significant revision to an existing standard
  • represent a major version change to one or more specifications
  • impact procurement
  • require configuration changes to current solutions
  • impact other standards
  • respond to legislative, policy or procurement changes

7.1. Publication details

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

Publication of GO-ITS standardYes/No

Standard to be published on both the OPS Intranet and the GO ITS Internet web site (available to the public, vendors etc.)


7.2. 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.

8. Appendices

8.1. Normative references

Management and Use of Information & Information Technology (I&IT) Directive:

Corporate Policy on Information and Information Technology (I&IT) Security:

Information Security & Privacy Classification Policy

GO-ITS standards

8.2. Informative references

ISO/IEC Standards:

9. Glossary

  • 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.
Entry to an electronic network provided by the government to its employees and other authorized individuals on or outside government premises, including telework situations.
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 stored data (logical access controls).
The obligation to answer for results and the manner in which responsibilities are discharged. Accountability cannot be delegated.
To establish the validity of a claimed identity of a user prior to gaining access (e.g., passwords, access cards).
To grant permission to access resources according to a predefined approval scheme.
The degree of readiness expected of information systems and IT resources to deliver an appropriate and timely level of service, regardless of circumstances.
Ensuring that information is accessible only to those authorized to have access.  Unauthorized disclosure of the information constitutes a loss of confidentiality. The protection of confidentiality must be consistent with the sensitivity of information and legislative requirements (e.g., FIPPA, PHIPA).
Evidence provided to prove the claimed identification (e.g., presenting related contextual information or tokens in order to access electronic resources).
The transformation of data into a form unreadable by anyone (encryption) without the correct decryption key, ensuring confidentiality by keeping the information hidden from anyone for whom it was not intended, including those who can see the encrypted data.
Any formalized representation of facts, concepts or instructions suitable for communication, interpretation or processing by a person or by automatic means.
Elevated privileges:
Enhanced rights and/or administrative control, assigned to a user, over a particular I&IT resource or class of resources.
The meaning derived from or assigned to facts or data, within a specified context.
Information Technology assets:
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.
The authenticity, accuracy and completeness of data that can be affected by unauthorized or accidental additions, changes and/or deletions.
Software and/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.
IT systems that can be made of one or both of the following components:
The quality embodied by services where transaction and identity assurance are managed to the degree that receipt of information or completion of transactions cannot reasonably be denied by participants.
A string of characters (letters, numbers and other symbols) that are used to authenticate an identity or to verify access authorization.
The ability of an individual or group to control personal information and prevent it from being used by people or for purposes other than those they consented to when they provided the information. Organizations must have controls to restrict the collection, use and/or disclosure of personal information to that authorized by the individual or group. In the case of Government organizations, legislative authority is required to collect and use the personal information needed for the delivery of a specific program or service.
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.
The obligation to perform a given task or tasks associated with a specific role.
A potential opportunity or threat that may impact on an organization’s ability to meet its business objectives.
A protective and precautionary measure to prevent a security threat from happening.
Security Testing and Evaluation (STE):
Any collection of processes or assessment models whereby the functional capabilities and security assurance of a given safeguard or system is examined (e.g., vulnerability assessment, penetration testing, code review). STE can be conducted according to formal methodologies, or performed informally for a basic degree of validation (e.g., the security portion of a generic acceptance testing procedure). In the case of physical facilities, STE activities may include audits of physical design, facility construction, access control systems, and compliance with minimum standards.
Threat and Risk Assessment (TRA):
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: A person authorized to access and use Information and Information Technology resources.