GO-ITS Number 25.0 General Security Requirements

Transcription

Government of Ontario IT Standard (GO ITS)
GO-ITS Number 25.0
General Security Requirements
Version # : 1.2
Status: Approved
Prepared under the delegated authority of the Management Board of Cabinet
UNCLASSIFIED
© Queen's Printer for Ontario, 2012
Last Review Date: 2012-11-15
Sensitivity: Unclassified
Approved
Version #: 1.2
Copyright & Disclaimer
Government of Ontario reserves the right to make changes in the information contained in this
publication without prior notice. The reader should in all cases consult the Document History to
determine whether any such changes have been made.
 2012 Government of Ontario. All rights reserved.
Other product or brand names are trademarks or registered trademarks of their respective holders. This
document contains proprietary information of Government of Ontario, disclosure or reproduction is
prohibited without the prior express written permission from Government of Ontario.
Template Info
Template Name
Template #
Template
Version No.
GO ITS
Template
12.02.10
2.4
Template Author
Template
Completion Date
Design: PMCoE
2012-06-12
Boilerplate: SPPB/ICS
Document History
Date
Summary
2003-01-14
Created: GO-ITS 25.0 DRAFT v0.1
2008-01-07
New draft number changed to version 1.1
2008-02-19
Aligned with ISO 27002:2005, Input from 2007-2008 review process incorporated
2008-02-20
Approved by IT Standards Council
2008-04-09
Minor 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-17
Approved by Architecture Review Board
2012-04-14
Organizational updates, updated hyperlinks and references, minor adjustment and errata
2012-04-19
GO-ITS 25.19 content has been merged
2012-06-12
Document format updated, minor adjustments
2012-11-15
Minor updates approved by Information Technology Executive Leadership Council (ITELC).
Approved document version number set to 1.2
GO-ITS 25.0 General Security Requirements
Page 2 of 40
Approved
Version #: 1.2
Table of Contents
1.
2.
FOREWORD .........................................................................................................................................................................................................5
INTRODUCTION..................................................................................................................................................................................................6
2.1.
Background and Rationale............................................................................................................................................................................6
2.2.
Target Audience................................................................................................................................................................................................6
2.3.
Scope ...................................................................................................................................................................................................................7
2.3.1. In Scope ............................................................................................................................ 7
2.3.2. Out of Scope ..................................................................................................................... 7
2.4.
Applicability Statements...................................................................................................................................................................................7
2.4.1. Organization ...................................................................................................................... 7
2.4.2. Other Applicability ............................................................................................................. 7
2.4.3. Terms ................................................................................................................................ 8
2.5.
Roles and Responsibilities..............................................................................................................................................................................8
2.5.1. Contact Information........................................................................................................... 8
3.
TECHNICAL SPECIFICATION......................................................................................................................................................................9
3.1.
Operational procedures and responsibilities .............................................................................................................................................9
3.1.1. Access control procedures................................................................................................ 9
3.1.2. Access control systems .................................................................................................... 9
3.1.3. Documented operating procedures ................................................................................ 10
3.1.4. Operational change control ............................................................................................. 11
3.1.5. Incident management procedures .................................................................................. 12
3.1.6. Segregation of duties ...................................................................................................... 14
3.1.7. Separation of development and operational facilities ..................................................... 15
3.1.8. External facilities management ....................................................................................... 16
3.2.
System planning and acceptance............................................................................................................................................................17
3.2.1. Capacity planning ........................................................................................................... 17
3.2.2. System acceptance ......................................................................................................... 18
3.3.
Protection against malicious software......................................................................................................................................................19
3.3.1. Controls against malicious software ............................................................................... 19
3.4.
System administration ..................................................................................................................................................................................20
3.4.1. Information back-up ........................................................................................................ 20
3.4.2. Activity logging ................................................................................................................ 21
3.4.3. Fault logging ................................................................................................................... 21
3.5.
Network management.................................................................................................................................................................................22
3.5.1. Management: .................................................................................................................. 22
3.5.2. Identification and authentication ..................................................................................... 23
3.5.3. Privileges and parameters .............................................................................................. 23
3.5.4. Confidentiality, integrity, availability, and non-repudiation .............................................. 23
3.5.5. Monitoring, response, recovery, and review ................................................................... 23
3.5.6. Planning, implementation, management, review and audit ............................................ 24
3.6.
Media handling and security.......................................................................................................................................................................24
3.6.1. Management of removable computer media .................................................................. 24
3.6.2. Information handling procedures .................................................................................... 25
3.6.3. Security of system documentation .................................................................................. 26
3.7.
Exchanges of information and software..................................................................................................................................................26
3.7.1. Information and software exchange agreements ........................................................... 26
3.7.2. Security of media in transit.............................................................................................. 28
3.7.3. Electronic commerce security ......................................................................................... 28
3.7.4. Security of electronic mail ............................................................................................... 28
3.7.4.1.
Security risks ............................................................................................................... 28
3.7.4.2.
Procedures for electronic mail ..................................................................................... 29
3.7.5. Security of electronic office systems ............................................................................... 29
Page 3 of 40
Approved
Version #: 1.2
3.7.6. Publicly available systems .............................................................................................. 30
3.7.7. Other forms of information exchange ............................................................................. 31
4.
RELATED STANDARDS..............................................................................................................................................................................32
4.1.
Impacts to Existing Standards....................................................................................................................................................................32
4.2.
Impacts to Existing Environment...............................................................................................................................................................32
5.
COMPLIANCE REQUIREMENTS............................................................................................................................................................32
5.1.
Internal compliance........................................................................................................................................................................................32
5.1.1. Access to accounts and information ............................................................................... 32
5.2.
External compliance......................................................................................................................................................................................33
5.2.1. Compliance with legal requirements ............................................................................... 33
5.2.2. Intellectual property and copyright .................................................................................. 33
5.2.3. Organizational records .................................................................................................... 34
5.2.4. Data protection and privacy of personal information ...................................................... 34
5.2.5. Cryptography .................................................................................................................. 34
5.3.
Audit....................................................................................................................................................................................................................34
5.3.1. Impact ............................................................................................................................. 35
5.3.2. Monitoring ....................................................................................................................... 35
5.4.
Implementation and Metrics........................................................................................................................................................................35
6.
ACKNOWLEDGEMENTS............................................................................................................................................................................36
7.
RECOMMENDED VERSIONING AND/OR CHANGE MANAGEMENT.................................................................................37
7.1.
Publication Details..........................................................................................................................................................................................37
7.1.
Requirements Levels....................................................................................................................................................................................38
8.
APPENDICES ....................................................................................................................................................................................................38
8.1.
Normative References.................................................................................................................................................................................38
8.2.
Informative References................................................................................................................................................................................38
9.
GLOSSARY ........................................................................................................................................................................................................39
Page 4 of 40
Approved
Version #: 1.2
1. Foreword
Government of Ontario Information Technology Standards (GO ITS) are the official publications on the IT
standards adopted by the Ministry of Government Services for use across the government’s IT infrastructure.
These publications support the responsibilities of the Ministry of Government Services (MGS) 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.
Copies of cited GO-ITS standards may be obtained as follows:
Intranet: http://intra.collaboration.gov.on.ca/mgs/occio/occto/our-services/technology-adoption/technicalstandards-1/approved-go-its-standards/
Internet: http://www.ontario.ca/itstandards/
Page 5 of 40
Approved
Version #: 1.2
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:2005 “Information technology Security techniques - Code of practice for information security management”:

Communications and operations management

Access control

Information systems acquisition, development and maintenance

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
Page 6 of 40
Approved
Version #: 1.2
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
This document has no specific out of scope requirements associated with it. It is intended as a baseline for
all Government of Ontario I&IT projects and services.
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 and risk mitigation mechanisms
are in place and employed. For the purposes of this document, any reference to ministries or the
Government includes applicable agencies.
2.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
Page 7 of 40
Approved
Version #: 1.2
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
Should
The requirement is mandatory. Without it, the system is not considered secure.
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
Provide the following information:
Accountable Role (Standard Owner) Definition
The individual or committee ultimately accountable for the process of developing this standard. Where a
committee owns the standard, the committee Chair is accountable for developing the standard including
future updates. There must be exactly one accountable role identified. The accountable person also signs
off as the initial approver of the proposed standard before it is submitted for formal endorsement to
Architecture Review Board (ARB) and approval by ITELC. (Note: in the OPS this role is normally at the IT
executive or manager level).
Accountable Role:
Title: Manager, Security Policy and Administration
Ministry/Cluster: MGS
Division: OCCIO
Responsible Role Definition
The organization(s) responsible for the development of this standard. There may be more than one
responsible organization identified if it is a partnership/joint effort. (Note: the responsible organization(s)
provides the resource(s) to develop the standard).
Responsible Organization(s):
Ministry/Cluster: Ministry of Government Services
Division: OCCIO
Branch: Corporate Security Branch
Support Role Definition
The support role is the resource(s) to whom the responsibility for actually completing the work and
developing the standard has been assigned. If there is more than one support role, the first role identified
should be that of the editor – the resource responsible for coordinating the overall effort.
Support Role (Editor):
Ministry/Cluster: Ministry of Government Services
Division: OCCIO
Branch: Corporate Security Branch
Section: Policy and Administration
Page 8 of 40
Approved
Version #: 1.2
Job Title: Senior Security Policy Advisor
Name: Tim Dafoe
Phone: (416) 327-1260
Email: [email protected]
The above individual will be contacted by the Innovation Controllership and Strategy (ICS) division, once
a year, or as required, to discuss and determine potential changes and/or updates to the standard
(including version upgrades and/or whether the standard is still relevant and current).
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:
a) 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;
b) System roles and duties must be assigned to individual and accountable users, and the
use of shared or role accounts for any purpose must be avoided;
c) Access must only be provided after formal authorization is granted, via unique identifiers
and credentials, with formal records documenting the provision of access;
d) 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 if the duties of the associated user change
such that access is no longer required;
e) Elevated privileges (i.e., those typically used for system administration, user account
administration, or content management) must be assigned to 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
f)
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:
Page 9 of 40
Approved
Version #: 1.2
a) Access control systems must be centrally deployed and managed;
b) The design and operation of centralized access control systems must include resilience
and redundancy to reduce impact if failures occur;
c) Access must be granted only after authorization and authentication procedures are
complete, and a successful result has been returned for the credentials presented and/or
the initiated session;
d) Access control systems must support documented business and security requirements
(e.g., the rationale for deploying the access control system);
e) 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);
f)
Access control systems must be managed such that authorized user accounts or
credentials that are no longer in use, or no longer required (e.g., due to a change in
employee role) are identified and removed with 24 hours of notification;
g) 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);
h) In instances where passwords are assigned, password management techniques must be
consistent with the direction described in GO-ITS 25.15 Security Requirements for
Password Management and Use;
i)
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;
j)
Log and audit information associated with elevated privileges must be subject to more
frequent review;
k) 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;
l)
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
m) 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.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:
a) Processing and handling of information;
b) Scheduling requirements, including interdependencies with other systems, and
mandatory start/stop times for system work, maintenance windows, or changes, if
applicable;
Page 10 of 40
Approved
Version #: 1.2
c) Instructions for handling errors or other exceptional conditions including restrictions on
the use of system privileges and utilities;
d) Support contacts in the event of unexpected operational or technical difficulties;
e) 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
f) 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,
back-up, equipment maintenance, data centre procedures, and mail handling
management/safety.
3.1.4.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. Wherever possible, operational and application change
control procedures should be integrated; these procedures should address 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:
a)
b)
c)
d)
e)
f)
g)
h)
i)
System composition and configuration (hardware, software, etc.);
Practices and procedures;
Confidentiality, availability, and integrity requirements of existing systems and data;
Identification and authentication mechanisms, assigned privileges, and credentials;
Monitoring of, response to, and recovery from events, and review of related procedures;
Planning, implementation, management, review and audit of systems and procedures;
Resource utilisation, particularly as it affects adjacent systems;
Required changes to existing Service Level Agreements (SLAs); and
Required changes to agreements, contracts, or licences.
Page 11 of 40
Approved
Version #: 1.2
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.5.Incident management procedures
Incident management responsibilities and procedures must be established to ensure a quick,
effective and orderly response to security incidents. 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:
a) 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; and
5) Unauthorized use, access, change, or other loss of integrity.
b) 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;
4) Communication with those affected by or involved with recovery from the incident;
and
5) Reporting the action to the appropriate authority.
c) 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.
Page 12 of 40
Approved
Version #: 1.2
d) 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:
a) 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.
b) 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):
a) Limiting or denying access, based on source or location of connection attempts;
b) Changing network connection mechanisms, telephone numbers, or other means of
access;
c) Locking accounts;
d) Auditing accounts for:
1. Inactivity;
2. Unauthorized creation;
3. Weak passwords;
4. Inappropriate permissions;
5. Administrative privilege activity; and
6. Expired or revoked access.
Page 13 of 40
Approved
Version #: 1.2
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 CSB 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:
a) Limiting or denying access, based on source or location of connection attempts;
b) A single point of contact to co-ordinate handling of the incident, and a backup in case
they cannot be reached;
c) A contact escalation chain, with milestones or times at which an event must be
escalated;
d) Backup contacts for each point in the escalation chain;
e) A response checklist with room for comments; and
f) 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) for:
a)
b)
c)
d)
Client activity or requests (both allowed and denied);
Server configuration changes and/or administrator login and use of privilege;
System activity; and
Interpreted events as reported by Intrusion Detection/Prevention Systems.
3.1.6.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:
a) Roles or duties required to enable unauthorized access, theft, or fraud must be
segregated;
Page 14 of 40
Approved
Version #: 1.2
b) 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
c) 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.
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.7.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 or malicious code.
Untested and/or malicious code 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:
a) 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;
Page 15 of 40
Approved
Version #: 1.2
b) 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;
c) Compilers, source code, editors and other system utilities should not be accessible from
operational systems when not required;
d) 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
e) 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 and depersonalized, the test environment must be protected using the same
measures as are used to protect 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 Operating Procedures for Disposal, Loss and
Incident Reporting of Computerized Devices.
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.8.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:
a)
b)
c)
d)
e)
Identifying sensitive or critical applications better retained in-house;
Obtaining the approval of business application owners;
Identifying implications for business continuity plans;
Specifying security standards, and the process for measuring compliance;
Allocation of specific responsibilities and procedures to monitor all relevant security
activities in an effective manner;
Page 16 of 40
Approved
Version #: 1.2
f)
Definition and documentation of responsibilities and procedures for reporting and
handling security incidents;
g) Protecting personal information and sensitive data from unauthorized access; and
h) 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:
a) 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;
b) Periodically audited by a third party, one approved by the Government of Ontario, to
confirm adherence to those principles, requirements, and best practices; and
c) 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:
a)
b)
c)
d)
e)
3.2.
Service outage;
Perimeter breach and/or unauthorized release of sensitive data;
Privacy breach and/or unauthorized disclosure of personal information;
Failure to follow documented procedures; and
Third-party certification of external facilities, with respect to agreed service levels.
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 that resources such as 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.
Page 17 of 40
Approved
Version #: 1.2
Capacity planning must take into account 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:
a)
Fail over to a high security or access denied state in the event of critical resource
(e.g., CPU, bandwidth, etc.) shortage;
b)
Record authorization and/or authentication events, both failed and successful; and
c)
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 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:
a)
b)
c)
d)
e)
f)
g)
Performance and computing capacity requirements;
Error recovery and restart procedures, and contingency plans;
Preparation and testing of routine operating procedures to defined standards;
Agreed set of security controls in place;
Effective manual procedures;
Business continuity arrangements, as required;
Evidence that installation of the new system will not adversely affect existing systems,
particularly at peak processing times, such as month end;
h) Evidence that consideration has been given to the effect the new system has on the
overall security of the organization; and
i) 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.
Page 18 of 40
Approved
Version #: 1.2
3.3. Protection against malicious software
Controls are required to prevent and detect the introduction of malicious software to the environment.
Software and information processing facilities are vulnerable to the introduction of malicious software.
Users should be made aware of the dangers of unauthorized or malicious software, and managers
should, where appropriate, introduce special controls to detect or prevent its introduction.
3.3.1.Controls against malicious software
Detection and prevention controls to protect against malicious software and appropriate user
awareness procedures must be implemented. Protection against malicious software should be
based on security awareness, appropriate system access and change management controls.
All systems must employ controls to protect against malicious code.
The following controls should be considered when planning a strategy for malicious code control:
a) Formal procedures requiring compliance with software licenses and prohibiting the use of
unauthorized software;
b) 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;
c) Installation and regular update of anti-virus detection and repair software to scan
computers and media either as a precautionary control or on a routine basis for certain
types of malicious code;
d) Conducting regular software review for systems supporting critical business processes.
The presence of any unapproved files or unauthorized software should be formally
investigated;
e) Checking any files on electronic media of uncertain or unauthorized origin, or files
received over unknown networks, for malicious software, prior to use;
f) Checking any electronic mail attachments and downloads for malicious software before
use. This check may be carried out at different places (e.g., at electronic mail servers,
desktop computers or when joining the network of the organization);
g) Management procedures and responsibilities to deal with virus protection on systems,
training in their use, reporting and recovering from attacks;
h) Appropriate business continuity plans for recovering from attacks, including all necessary
data and software back-up and recovery arrangements; and
i) Procedures to verify all information relating to malicious software, 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.
Malicious code 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 checked and verified against
known signatures of malicious code. Attack signatures must be monitored on a daily basis and
updated immediately upon release for detection functions to remain effective. In addition:
a) The installation of software must be restricted to administrative staff;
Page 19 of 40
Approved
Version #: 1.2
b) Anti-virus software must be installed, operated, and updated regularly for both clients
and servers, as appropriate; and
c) 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 must comply with the
requirements described in GO-ITS 42 Operating Procedure for Patch Management.
3.4. System administration
Routine procedures should be established for carrying out an approved back-up strategy, taking
back-up copies of data and rehearsing their timely restoration, logging events and faults and, where
appropriate, monitoring the equipment environment to maintain the integrity and availability of
information processing and communication services.
3.4.1.Information back-up
Back-up copies of essential business information and software must be taken regularly.
Adequate back-up facilities should be provided to ensure that all essential business information
and software could be recovered following a disaster or media failure. Back-up 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:
a) A minimum level of back-up information, together with accurate and complete records of
the back-up copies and documented restoration 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 back-up information should be retained
for critical business applications;
b) Back-up 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 back-up site;
c) Back-up media should be regularly tested, where practicable, to ensure that they can be
relied upon for emergency use when necessary;
d) 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;
e) The retention period for the back-up media should be determined; and
f) 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 back-up.
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.
Page 20 of 40
Approved
Version #: 1.2
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 logs must be stored on a centralized, secure
log server. These logs must include, as a minimum requirement:
a)
b)
c)
d)
e)
f)
g)
h)
i)
System start and halt times;
System errors and any corrective action taken in response;
Confirmation of the correct boot procedure, and handling of data and output;
The identity of the individual invoking commands or functions resulting in a log entry;
The timestamps associated with the beginning and end of any user or operator session;
The issuance and use of privilege if granted;
Errors and related messages associated with user or operator activities;
Connections and session initiations related to user or operator access to the system;
The origin of user or operator sessions, be this an indication of node, terminal, client, or
other mode of specifying session origin, if the session is not conducted from the system
console;
j) Changes to system mode, run level, or security context where applicable; and
k) A timestamp indicating when the log entry was generated by the system, with system
time synchronized to a redundant and validated 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:
a) Review of fault logs to ensure that faults have been satisfactorily resolved; and
b) 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:
a) Monitoring of all network interfaces should increase in detail;
b) Monitoring of servers and services should increase in detail; and
c) 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:
a)
b)
c)
d)
User or system ID associated with the fault;
Operator name;
Date and time fault occurred;
Description of fault;
Page 21 of 40
Approved
Version #: 1.2
e) Description of actions that caused fault (if possible); and
f) 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:
a)
b)
c)
d)
e)
f)
g)
Device errors and status messages;
File or other resource access failures;
Licensing activities;
Authentication failures;
Session duration;
New device detection;
Network connection activities (e.g., host up/down, connectivity problems, changes
involving network interfaces, or the system hardware/network addresses, etc.);
h) Operator activities (e.g., backups, restores, rollback, etc.);
i) Remote connections to/from the system;
j) Any security alerts not captured by operator, system, or audit logs);
k) System or application error messages;
l) Use of privileged commands, and/or attempts to invoke a privileged mode or alter system
mode, security context, or run level; and
m) 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:
a) Operational responsibility for networks should be separated from computer operations
where appropriate;
b) Responsibilities and procedures for the management of remote equipment, including
equipment in user areas, should be established;
c) 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;
d) 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;
Page 22 of 40
Approved
Version #: 1.2
e) 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;
f) 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;
g) Discrete hardware implementations of Security Zones should leverage multiple platforms
to increase the technical difficulty of subverting defence in depth controls; and
h) 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
a) 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
a) 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
a) Sensitive communications must be protected from malicious observation or modification;
b) System technologies from different vendors must integrate so as to not cause an
aggregate reduction in the efficacy of combined security features;
c) Operating systems of clients and servers must be hardened, as per approved Corporate
Security recommendations and relevant build books;
d) All access must default to ‘prohibited’, and all ports must default to ‘closed’, upon poweron or warm reset of network equipment;
e) Firewalls that employ enterprise-grade stateful layer three designs for control must be
used to enforce network policy by forwarding only pre-approved connections;
f) Systems must be placed between firewalls (as described above) in a DMZ network
segment, to protect them from internal and external threats; and
g) 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
a) Network traffic must be monitored and analysed by an Intrusion Detection System (IDS)
or Intrusion Prevention System (IPS);
b) Incident response procedures must exist, and be practised, in anticipation of hostile
network events;
c) Business Continuity Management must be exercised, to ensure that network resources
are available during, and restored as quickly as possible after, a hostile event;
Page 23 of 40
Approved
Version #: 1.2
d) Processes and procedures for dealing with hostile events must be reviewed after
practice or exercise, and must be updated to reflect lessons learned; and
e) 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
a) Proposed systems must have their security measures validated via testing and
evaluation, prior to implementation in a production environment;
b) Changes may not be made to proposed plans during implementation, without approval of
the project owner and the security team;
c) Documentation must be updated to include exceptions made during implementation to
proposed designs;
d) Remote access to systems must be securely managed as described in relevant GO-ITS
25 series documents;
e) A change control process must manage requests for a change in, or granting of, access;
f) Users must be educated as to what security mechanisms exist, the reasons for their use,
and the requirements for compliance with those mechanisms; and
g) 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.
a) 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;
b) 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;
c) All media should be stored in a safe, secure environment, in accordance with
manufacturers’ specifications; and
d) 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
Page 24 of 40
Approved
Version #: 1.2
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:
a)
b)
c)
d)
Labelling of all media, in accordance with ISPC Policy requirements;
Access restrictions, badge procedure, etc. to identify unauthorized personnel;
Maintenance of a formal record of the authorized recipients of high sensitivity data;
Ensuring that input data is complete, that processing is properly completed and that
output validation is applied;
e) Protection of spooled data awaiting output to a level consistent with its identified
sensitivity;
f) Storage of media in an environment which accords with manufacturer specifications;
g) Keeping the distribution of data to a minimum in accordance with the principle of least
privilege;
h) Clear marking of all copies of data for the attention of the authorized recipient; and
i) 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:
a) Transmitted and stored information that has been classified as high sensitivity data must
be protected through use of encryption of a type and strength identified by Corporate
Security as sufficient to withstand attack, as documented in GO-ITS 25.12 Use of
Cryptography;
b) 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
c) Access to backup media must be limited to authorized personnel.
Page 25 of 40
Approved
Version #: 1.2
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:
a) System documentation should be classified, labelled, and stored securely;
b) The access list for system documentation should be kept to a minimum and authorized
by the application owner; and
c) 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:
a) Access rights;
b) User and group ownership (i.e., unauthenticated or unauthorized users must not have
access to information); and
c) 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:
a) 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);
b) All documentation must be secured when not in use;
c) Security documentation must not be left unattended;
d) Security documentation must not be removed from secure areas; and
e) 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.
Page 26 of 40
Approved
Version #: 1.2
The security provisions present in such an agreement should reflect the sensitivity of the
business information involved.
Agreements on security provisions should include:
a) Management responsibilities for controlling and notifying transmission, dispatch and
receipt;
b) Procedures for notifying sender, transmission, dispatch and receipt;
c) Minimum technical standards for packaging and transmission;
d) Courier identification standards;
e) Responsibilities and liabilities in the event of loss of data;
f) 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;
g) Information and software ownership and responsibilities for data protection, software
copyright compliance and similar considerations;
h) Technical standards for recording and reading information and software; and
i) 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:
a) Protection from unintended use, sharing, or duplication; and
b) 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:
a)
b)
c)
d)
Follow practices that meet or exceed Government of Ontario internal security practices;
Submit to regular Government of Ontario and/or external audit of those practices;
Agree to penalties for failure to adhere to all agreements; and
Agree to be held liable for all repercussions arising from a failure to adhere to all
agreements.
Page 27 of 40
Approved
Version #: 1.2
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 protected from unauthorized access, misuse or corruption. For
example:
a) 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;
b) Packaging should be sufficient to protect the contents from any physical damage likely to
arise during transit and in accordance with manufacturers’ specifications; and
c) 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, contract dispute and disclosure 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, 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.
3.7.4.1.
Security risks
The following security risks should be addressed:
a) Vulnerability of messages to unauthorized access/interception, modification, or denial
of service;
b) Vulnerability to error (e.g., incorrect addressing or misdirection, and the general
reliability and availability of the service);
c) 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);
Page 28 of 40
Approved
Version #: 1.2
d) Legal considerations, such as the potential need for proof of origin, dispatch, delivery
and acceptance;
e) Implications of publishing e-mail distribution lists that reach internal addresses or
many staff; and
f) Controlling remote user access to electronic mail accounts.
3.7.4.2.
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:
a) Attacks on electronic mail (e.g., malicious attachments, social engineering, viruses,
interception);
b) Protection of electronic mail attachments;
c) Guidelines on when not to use electronic mail;
d) Employee education regarding inappropriate use (e.g., sending defamatory electronic
mail, use for harassment, or unauthorized purchasing);
e) Use of approved cryptographic techniques to protect the confidentiality and integrity of
electronic messages, such as GO-PKI; and
f) 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:
a)
b)
c)
d)
Scanning of SMTP traffic for illegal commands;
Scanning of traffic for hostile executable and/or malicious content;
Removal of executable and/or otherwise malicious content; and
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:
a) Vulnerabilities of information in office systems (e.g., recording phone calls or conference
calls, confidentiality of calls, storage of faxes, opening mail, distribution of mail,
increasing complexity of multi-function office devices with network interfaces, remote
management, and local storage);
b) Procedures and appropriate controls to manage information sharing (e.g., the use of
corporate electronic bulletin boards);
c) Excluding categories of sensitive business information if the system does not provide an
appropriate level of protection;
Page 29 of 40
Approved
Version #: 1.2
d) The suitability, or otherwise, of the system to support business applications such as
communicating orders or authorizations;
e) Categories of staff, contractors or business partners allowed to use the system and the
locations from which it may be accessed;
f) 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);
g) Identifying the status of users (e.g., employees of the organization or contractors in
directories for the benefit of other users);
h) Retention and back-up of information held on the system; and
i) 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:
a) Information is obtained in compliance with any data protection legislation;
b) Information input to, and processed by, the publishing system will be processed
completely and accurately in a timely manner;
c) Sensitive information will be protected during the collection process and when stored;
and
d) 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:
a) 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;
b) 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;
Page 30 of 40
Approved
Version #: 1.2
c) 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);
d) Backups must be performed daily on public systems (at least incrementally) to ensure
minimal loss of data;
e) If a public system is used for processing transactions, a secure transport protocol must
be used along with server certificates;
f) 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;
g) 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);
h) 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
i) 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 MGS Corporate Security Branch is the cryptographic authority for the Government of
Ontario; algorithms, implementations, effective key length, and other factors must meet
Corporate Security 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.
Page 31 of 40
Approved
Version #: 1.2
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 Standard
All GO-ITS 25 standards
Impact
All standards in this series
refer to this document; this
document is considered a
normative reference for the
entire series.
Recommended Action
Update only, no impact.
Compliance with all standards
is mandatory.
4.2. Impacts to Existing Environment
Impacted Infrastructure
Impact
Recommended 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
Page 32 of 40
Approved
Version #: 1.2
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
where these limits are not clear.
In particular, the following safeguards should be implemented:
a)
b)
c)
d)
e)
f)
Use existing procurement and vendor of record channels to obtain software and media;
Maintain awareness among staff regarding acquisition of software products;
Maintain asset inventory, including proof of license ownership, master copies, etc.;
Maintain controls to ensure fixed seat licenses are not inadvertently exceeded;
Monitor the installation of acquired packages and control inappropriate installation; and
Maintain license conditions and remove software where license status is unknown.
Page 33 of 40
Approved
Version #: 1.2
5.2.3.Organizational records
Records must be protected from loss, 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.1.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:
a)
b)
c)
d)
Determination of import/export status for cryptographic hardware and software;
Determination of import/export status for items to which cryptography is to be added;
Determination of use of any cryptography in any jurisdiction where not sanctioned; and
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.
Page 34 of 40
Approved
Version #: 1.2
5.3.1.Impact
To reduce the potential impact or risk of such audit on operational systems:
a)
b)
c)
d)
e)
Audit scope and requirements should be discussed and controlled prior to audit activities;
Audit activity should be conducted without write/modify privileges where possible;
Access provided during audit activities should be monitored and supervised;
All relevant procedures required to conduct the audit should be provided in advance; and
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, activity and fault logs must be routinely monitored (by staff trained to identify
relevant events) 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:
a) Log data must be forwarded to a log host. The log host must be a dedicated, purposebuilt, 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;
b) 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;
c) Timestamps for messages from all monitored systems and other log-generating devices
(firewalls, routers, servers, etc.) must be synchronized to a redundant and validated time
source; and
d) 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
The intention of the OCCIO is to advertise and promote this standard as being a mandatory component
throughout government. However, in order to effectively manage its implementation, ministries, clusters and
applicable agencies are expected to adopt and monitor compliance to this standard.
Page 35 of 40
Approved
Version #: 1.2
6. Acknowledgements
Consulted
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)
CSB Internal Consultation
Ontario Internal Audit Division
OCIPO (now IPA)
Division
Branch
Date
MGS OCCIO
Finance
OCIPO / IPA
CSB
OIAD
Privacy
Jan./Feb. 2008
Mar. 2008
Jan./Feb. 2008
Committee/Working Group Consulted
SADWG
Date
Jan./Feb. 2008
Informed
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)
Division
Committee/Working Group Informed
IT Standards Council (Dissolved) (For Information)
Branch
Date
Date
Feb. 2008
Page 36 of 40
Approved
Version #: 1.2
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, ICS as
custodians of the I&IT Rules Refresh 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 OCCIO Intranet web site.
Please indicate with a checkmark below if this standard is also to be published on the public, GO ITS
Internet Site.
Standard to be published on both the OPS Intranet and the GO ITS
Internet web site (available to the public, vendors etc.)

Page 37 of 40
Approved
Version #: 1.2
7.1. 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
requirement.
Should
This word, 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, cost) must be understood and carefully weighed before
choosing a different course.
8. Appendices
8.1. Normative References
Management and Use of Information & Information Technology (I&IT) Directive:
http://intra.ops.myops.gov.on.ca/cms/tiles.nsf/(vwReadResourcesByRefId_Content)/cpd2008.04.11.0
9.46.33.J6N_res/$File/ManagementOfITDir.pdf
Corporate Policy on Information and Information Technology (I&IT) Security:
0.22.28.JV4_res/$File/corporatePolicyIandITSecurity.pdf
Information Security & Privacy Classification Policy
4.34.52.PSU_res/$File/InformationSecurity&PrivacyClassificationPolicy-Aug05.pdf
8.2. Informative References
ISO/IEC Standards:
http://www.iso.org
Page 38 of 40
Approved
Version #: 1.2
9. Glossary
Access: 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).
Accountability: The obligation to answer for results and the manner in which responsibilities are
discharged. Accountability cannot be delegated.
Authentication: To establish the validity of a claimed identity of a user prior to gaining access (e.g.,
passwords, access cards).
Authorization: To grant permission to access resources according to a predefined approval scheme.
Availability: The degree of readiness expected of information systems and IT resources to deliver an
appropriate and timely level of service, regardless of circumstances.
Confidentiality: 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).
Credentials: Evidence provided to prove the claimed identification (e.g., presenting related contextual
information or tokens in order to access electronic resources).
Cryptography: 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.
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.
Information: 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.
Integrity: The authenticity, accuracy and completeness of data that can be affected by unauthorized or
accidental additions, changes and/or deletions.
Network: IT systems that can be made of one or both of the following components:

Local Area Network (LAN) - Network of Information technology systems wholly situated at one
geographical address;

Wide Area Network (WAN) - located over more than one geographical site.
Non-repudiation: 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.
Password: A string of characters (letters, numbers and other symbols) that are used to authenticate an
identity or to verify access authorization.
Privacy: 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
Page 39 of 40
Approved
Version #: 1.2
authority is required to collect and use the personal information needed for the delivery of a specific
program or service.
Program: A specific program or service within a Ministry.
Program Manager: The person responsible for the continued development, operational control,
implementation, monitoring, etc. of a specific program or service within a Ministry.
Responsibility: The obligation to perform a given task or tasks associated with a specific role.
Risk: A potential opportunity or threat that may impact on an organization’s ability to meet its business
objectives.
Safeguard: A protective and precautionary measure to prevent a security threat from happening.
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 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 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.
Page 40 of 40

GO-ITS Number 25.0 General Security Requirements

Transcription

Similar documents

Lake Manitouwabing

ERL-0631-GD PR

TRAINING AND DEVELOPMENT 1

energy storage: the holy grail of renewable energy

TBDHU.COM/CAREERS

Requisition for Diagnostic or Monitoring Sample Analysis Patient Information Ordering Doctor’s Information

poolplayers.ca - CPA Southern Ontario

landscape industry show - California Landscape Contractor`s

Explore your options at ontariocolleges.ca

DATA INTEGRITY AND SECURITY By Mrs. Smith