Government of Ontario IT Standard (GO-ITS)

weyrharrasAI and Robotics

Nov 21, 2013 (3 years and 8 months ago)

83 views


____________________________________________________________________________



Government of Ontario IT Standard (GO-ITS)

Number 25.12
Security Requirements for the Use of Cryptography

Version #: 1.1
Status: Approved


Prepared for the Information Technology Standards Council (ITSC) under the
delegated authority of the Management Board of Cabinet


UNCLASSIFED


© Queen's Printer for Ontario, 2008 Last Review Date: 2008-10-24

GO-ITS 25.12 Status: Approved Version 1.1
Foreword
Government of Ontario Information Technology Standards (GO-ITS) are the official publications
on the guidelines, preferred practices, standards and technical reports adopted by the
Information Technology Standards Council (ITSC) under delegated authority of the
Management Board of Cabinet (MBC). 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. Publications that set new or
revised standards provide enterprise architecture guidance, policy guidance and administrative
information for their implementation. 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 standards may be obtained as follows:

Intranet:
http://intra.collaboration.gov.on.ca/mgs/occio/occto/our-services/technology-
adoption/technical-standards-1/approved-go-its-standards/
Internet:
http://www.itstandards.gov.on.ca/
Summary
The Information and Information Technology (I&IT) Security Directive requires that Government
of Ontario employees protect information that is received, created, held by, or retained on behalf
of, Ontario ministries and agencies. Programs are responsible for the implementation of
appropriate safeguards, based on an assessment of the risks involved.
Cryptography is an industry standard practice for the protection of data confidentiality and
integrity. All Government of Ontario staff members are required to be aware of the sensitivity of
program information, and the practices and safeguards needed to ensure the ongoing security
of information.
The MGS Corporate Security Branch (CSB) is the cryptographic authority for the Government of
Ontario.







UNCLASSIFIED
2
GO-ITS 25.12 Status: Approved Version 1.1

Version control and change management

Date
Version
Author
Comment
September 17, 2008
1.0
Tim Dafoe, CSB
Endorsed by IT Standards Council
October 16, 2008
1.0
Tim Dafoe, CSB
Approved by Architecture Review Board
October 24, 2008
1.1
Tim Dafoe, CSB
Changes per document history section
Ongoing ownership and responsibility for maintenance and evolution of this document resides
with the Corporate Security Branch, Office of the Corporate Chief Information Officer. The
Corporate Security Branch will provide advice on the interpretation and application of these
security requirements and manage any updates to the document when the need arises.


Contact information

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


Contact 1
Contact 2
Name/Title
Charlotte Ward, Manager, Policy &
Administration
Tim Dafoe, Senior Security Policy
Advisor
Organization/Ministry
Ministry of Government Services
Ministry of Government Services
Division
OCCIO
OCCIO
Branch
Corporate Security Branch
Corporate Security Branch
Section/Unit
Policy & Administration
Security Policy
Office Phone
(416) 327-9385
(416) 327-1260
E-mail
Charlotte.Ward@ontario.ca
Tim.Dafoe@ontario.ca
UNCLASSIFIED
3
GO-ITS 25.12 Status: Approved Version 1.1
Table of Contents
1.

INTRODUCTION...................................................................................................................5

1.1

Purpose of the standard.....................................................................................................5

1.2

Terms.................................................................................................................................5

1.3

Application and scope........................................................................................................5

1.4

Out of scope.......................................................................................................................6

1.5

Background........................................................................................................................6

1.6

Principles............................................................................................................................8

2.

REQUIREMENTS..................................................................................................................9

2.1

Education and training.......................................................................................................9

2.2

Information in storage........................................................................................................9

2.3

Communications security.................................................................................................10

2.4

Management of cryptography..........................................................................................11

3.

RESPONSIBILITIES...........................................................................................................15

4.

ACKNOWLEDGEMENTS...................................................................................................19

5.

DOCUMENT HISTORY.......................................................................................................20

6.

APPENDIX A: APPROVED ALGORITHMS AND PROTOCOLS.......................................21

7.

APPENDIX B: DEFINITIONS..............................................................................................24

8.

APPENDIX C: ACRONYMS................................................................................................29

9.

APPENDIX D: ADDITIONAL INFORMATION....................................................................31


UNCLASSIFIED
4
GO-ITS 25.12 Status: Approved Version 1.1
1. INTRODUCTION
This document is one in a series that defines operational principles, requirements and best
practices for the protection of Government of Ontario networks and computer systems.
1.1 Purpose of the standard
This document outlines the context and requirements for appropriate use of cryptography
within the Government of Ontario.
The objective of this document is to ensure that cryptography of an appropriate type and
strength is employed to protect Government of Ontario I&IT resources.
This document has been produced in consultation with stakeholder groups (primarily from
privacy and security centres of excellence) within the Government of Ontario. It makes
reference to the section “Information systems acquisition, development and maintenance”
from the ISO/IEC 27002:2005 code of practice, and technical requirements within are stated
in accordance with both ISO/IEC 27002:2005 recommendations and external guidance
received by CSB.
1.2 Terms
Within this document, certain wording conventions are followed. There are precise
requirements and obligations associated with the following terms:

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

1.3 Application and 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.
All cryptographic mechanisms protecting Government of Ontario I&IT resources must
adhere to the requirements in this document (e.g., approved cryptographic algorithms, key
lengths, and related protocols). Please consult Appendix A of this document for specific
information.
UNCLASSIFIED
5
GO-ITS 25.12 Status: Approved Version 1.1
For security involving sensitive information
1
, if it becomes known that sensitive information is
deemed to be at serious risk, immediate remedial action must be taken to mitigate the risk
by applying appropriate tools, methods, and procedures as per the relevant GO-ITS security
document.
As new GO-ITS standards are approved, they are deemed mandatory for all project
development and procurement opportunities.
The GO-ITS 25.12 Security Requirements for the Use of Cryptography must be understood
to apply to:
• All entities identified above and/or which use the Government of Ontario Integrated
Network; and
• All information for which the Government of Ontario is accountable, during any type
of transmission or transport, and while stored on any type of computing or data
storage device.
For the purposes of this document all references to “information” refer to digital information
and data.
The MGS Corporate Security Branch should be contacted if application of this standard is
not clear relative to a given environment, program, or application.

1.4 Out of scope
This document does not provide requirements for the registration of individuals or devices
for the issuance of cryptographic keys, or describe specific password or pass phrase
requirements for the protection of keys or related access controls. Such controls are
addressed in separate documents. Enterprise key management policies, requirements, and
strategies for the Government of Ontario are described in additional documentation (e.g.,
GO-PKI Certificate Policy). Questions about out of scope items should be directed to the
contacts for this document.
1.5 Background
The Information Security and Privacy Classification (ISPC) Policy requires that “classified
information must be safeguarded based on an assessment using the Threat Risk
Assessment (TRA) process”. The Information and Information Technology Security
Directive
2
states that proper “management of information and information technology in the
OPS” requires that “confidentiality, integrity, availability and reliability of information and
information systems and resources is ensured and security risks are prudently managed”.
Cryptography is the industry standard means to assure the confidentiality and integrity of
sensitive data, and is referenced in the ISO/IEC 27002:2005 code of practice.


1
As determined via the Government’s Information Security and Privacy Classification (ISPC) policy
(
http://intra.pmed.mbs.gov.on.ca/mbc/pdf/InformationSecurity&PrivacyClassificationPolicy-Aug05.pdf
)
and/or TRA process.
2
The Information and Information Technology Security Directive can be found at:

http://intra.pmed.mbs.gov.on.ca/mbc/pdf/Management_of_IT-Dir.pdf

UNCLASSIFIED
6
GO-ITS 25.12 Status: Approved Version 1.1
Cryptography is also commonly used to provide for reliable message authentication
3
, and
enable the use of secure digital signatures
4
. Proper use of cryptography produces a result
where it is computationally infeasible for attackers to compromise the confidentiality and/or
integrity of the information, communication, or exchange that has been protected.
Three cryptographic techniques in particular are widely used for these purposes:
• Symmetric key (or secret key) techniques involve a single key that is used both to
encrypt and decrypt information. This key is shared out of band to authorized
recipients, via an alternate secure channel. The key is otherwise kept secret and
protected from unauthorized access. Symmetric key techniques are primarily used
as a tool to ensure confidentiality.
• Asymmetric key (or public key) techniques assign unique key pairs to each user; a
key pair consists of a public encryption key that can be revealed to anyone (even
over insecure channels, useful when no secure channel is available), and a private
decryption key that is never shared, and must be kept secret.
• Hash Functions map variable length input (e.g., a file or piece of data) to a fixed
length bit string. Hash functions must be collision resistant (e.g., sets of unique input
data must not produce the same output result) to provide for security. Secure hash
functions are primarily used as a tool to assure data integrity (e.g., detection of
errors, modifications, and/or corruption for data in storage or transmission).
The main advantages of asymmetric cryptography include support for digital signatures, and
practical key management within large groups of users (in particular, the ability to manage
and distribute unique public keys over public networks). The primary advantage of
symmetric cryptography is its high speed of operation (as implementations of symmetric
cryptography typically offer significantly higher performance, given identical resources), and
low overhead for the distribution of shared keys within small groups of users (or devices).
In general, asymmetric cryptography should be used for an open multi-user environment, or
public infrastructure where secure out of band channels are not available or economically
feasible. The overhead associated with the use of symmetric cryptography in such
environments (e.g., the protection of secret keys while they are being shared and
distributed) can quickly become difficult to manage.
Asymmetric and symmetric cryptography are frequently used in concert to obtain the key
management advantages of a public key system, and the computational advantages of
symmetric encryption. For example, an asymmetric system can be used to authenticate
identities and to protect the transmission of symmetric keys over insecure media, which are
used in turn to quickly encrypt large amounts of information (via a symmetric block cipher).
In situations where symmetric keys can be readily and securely managed, symmetric


3
Message authentication codes involve the use of cryptography to detect both accidental (e.g., errors)
and intentional (e.g., attacks) modifications to transmitted information.
4
Digital signatures are used to authenticate the identity of an individual either prior to providing access to
information or services, or subsequently, to verify the author/source of a document or transaction (e.g.,
non-repudiation). Digital signatures can also be used to detect unauthorized changes to a document or
transaction (e.g., electronic payments, funds transfers, contracts).
UNCLASSIFIED
7
GO-ITS 25.12 Status: Approved Version 1.1
cryptography alone may be sufficient (e.g., within small environments or for a small number
of managed devices with static key configuration and a secure keying method).

1.6 Principles
The following guiding principles support, and are stated in accordance with, the I&IT
Security Directive and the ISPC policy:
• Cryptography alone cannot address the entire range of security concerns associated
with the storage, processing, and transmission of sensitive information
5
; its use does
not diminish the need for Program Managers to ensure that formal, documented risk
assessments are conducted, employees are trained, and appropriate physical and
logical access controls are implemented to protect Government assets;
• The Government of Ontario retains ownership of cryptographic keys that it has
created, or otherwise relies upon, to protect Government information;
• The secure management of cryptographic keys is essential to the effective use of
cryptographic techniques. Any compromise or loss of key material may lead to a
compromise of the confidentiality, integrity, and availability of information;
• Confidence in the strength of a given cryptographic system generally decreases with
the passage of time, as both the efficacy of techniques and processing power
available to potential attackers are likely to increase;
• Program Managers have a responsibility to ensure that all legislative/regulatory and
legal discovery requirements applicable to their operations can be satisfied when
data encryption is deployed as a technical safeguard;
• The use of encryption should not disrupt other critical security mechanisms and
processes (e.g., implementation of security patches or software upgrades), nor
should it create unintentional and adverse impact to the availability of time-critical
information (e.g., in emergency situations); and
• Cryptographic material (e.g., a key) intended to protect sensitive information will
require protection itself, at a level commensurate with the sensitivity of that
information.



5
Sensitive information refers to sensitivity as defined within ISPC policy.
UNCLASSIFIED
8
GO-ITS 25.12 Status: Approved Version 1.1
2. REQUIREMENTS

Cryptographic material must be securely protected and managed. This includes secure
processes for the issuance, renewal, revocation, destruction, and recovery of cryptographic
keys. The following requirements are mandatory for all cryptographic implementations and
technology deployments governed by this document:
2.1 Education and training
Technical staff that develop, implement, and/or manage systems must be aware of the
requirements regarding the use of cryptography as described in this document.
All Government staff must be aware of the sensitivity of program information and the
procedures and practices (e.g., ISPC) needed to protect sensitive information, including
relevant legislative requirements or directives.
2.2 Information in storage
Sensitive electronic information that requires a significant degree of protection as stated
within ISPC policy and procedures should be encrypted in storage, or when operationally
feasible, stored as a hash
6
. The Privacy Impact Assessment (PIA) or TRA for the relevant
program area may also indicate that an enhanced level of cryptographic protection is
required for high-risk environments (please consult Appendix A of this document).
Encrypted sensitive information held as data in storage for more than two years
7
must be
encrypted in a manner suitable for a high-risk environment (see Appendix A).
If the responsibility for encrypted information is transferred to a different organization, and
access by the previous owner is no longer authorized, the transferred information must be
encrypted with a new key by the new organization/custodian.
Digital signatures should be applied to stored information when needed to address risks
relating to integrity and/or non-repudiation (as determined by a TRA or through other
means). Digital signature implementations should include the use and checking of
timestamps generated from a validated time source.
If practical, a central, securely managed automatic encryption mechanism (e.g., an
application intended for this function) should be used to encrypt sensitive information.
The following additional requirements apply to specific modes of storage:



6
Hashes are commonly used to store password values, but can also be considered for other types of
sensitive information if a comparison operation with a hash value will be sufficient for the business
operation, and the information itself need not be stored.
7
When systems are migrated to new technologies, compatibility issues may be introduced for encrypted
information in long-term storage (e.g., archives); such eventualities should be identified and addressed.
UNCLASSIFIED
9
GO-ITS 25.12 Status: Approved Version 1.1
2.2.1 Mobile devices
Government of Ontario mobile devices (e.g., portable computers) intended to process or
store sensitive information must incorporate functionality whereby the entirety of storage
capacity can be encrypted. Similar techniques should be used for other forms of mobile
storage (e.g., integrated PDA devices and removable media).
Mobile encryption systems must be centrally managed. Such systems must be
endorsed by CSB for such use with the Government of Ontario, must offer
comprehensive protection via cryptographic and other security mechanisms, and must
be suitable for high-risk environments.
2.2.2 Desktop computers
Government desktop computers are typically not adequately protected against high
resource threat agents (e.g., a focused and determined electronic attacker or an
organized group, potentially with funding). Their local storage capacity should not be
used to store sensitive information. If operations requirements are such that it is
necessary to store sensitive information on a desktop computer, the information must be
encrypted using an encryption mechanism specifically endorsed by CSB for this
purpose, and additional security measures may be required for high-risk environments.
2.2.3 Data repositories
Sensitive information must be encrypted at the data field level before it is written to a
data repository, when such protection is required by ISPC or a TRA. When operationally
feasible, hashes of sensitive information should be used for comparisons and verification
(thereby avoiding storage of the actual sensitive information). Such hash values must be
generated using a secure hash function endorsed by CSB (see Appendix A).
When deploying encryption within data repositories, careful consideration should be
given to any limitations present within the encryption options, and any impact on
software development, deployment, performance, administration, or legal duties.
2.3 Communications security
Sensitive information must be safeguarded when transmitted.
2.3.1 General transmission and communication
Sensitive information must be encrypted using appropriate means (see Appendix A) for
all types of communications, other than those that occur within the same designated
Zone (and do not employ wireless technology).
Wireless transfers of Government of Ontario information (e.g., 802.11 wireless LAN,
mobile wireless data
8
, satellite, or Bluetooth) must be further encrypted using approved


8
Wireless data communications protocols alone (e.g., GSM, CDMA) do not provide for an adequate
degree of communications security, and must not be relied upon to safeguard confidentiality.
UNCLASSIFIED
10
GO-ITS 25.12 Status: Approved Version 1.1
means (see Appendix A) during data communications. This functionality is present in
some wireless protocols, and should be investigated prior to use.
The integrity of sensitive data, business information, or transactions sent via a wireless
protocol, or that crosses a WAN managed perimeter boundary in either direction, must
be verified using an approved message authentication code (e.g., HMAC) or a digital
signature upon receipt. This functionality is present in many such systems, and should
be investigated prior to use.
Digital signatures must be used if the identified integrity requirements (e.g., documented
in a TRA) include support for high-risk environments and/or non-repudiation, even if
sensitive data does not cross the managed perimeter boundary. This functionality is
available in several existing messaging protocols, and should be investigated prior to
use.
Digital signature implementations must include the use and checking of an accurate
timestamp from a validated and redundant time source.
2.3.2 Mainframe communications
Mainframe SNA traffic (such as SNA over IP) must be encrypted within the Government
of Ontario if the communication includes sensitive information, and does not occur within
the same designated Zone (e.g., via a dedicated physical connection).
2.4 Management of cryptography
Cryptography must be appropriately deployed and managed if it is to be effective. All
cryptographic schemes and internal key management procedures deployed within the
Government of Ontario must be managed and documented.
2.4.1 Procurement of cryptography
All products supporting cryptography that are procured for use within the Government of
Ontario must comply with the requirements in this document. Other relevant sources of
information may be consulted for general guidance (e.g., CAVP standards, CMVP FIPS
140-2 evaluations, and ISO/IEC 19790:2006).
Cryptographic products must be configurable using administrator-controlled rules
including:
• Specific cryptographic algorithm(s), mode of operation, and the minimum
effective key lengths to be used; and
• Password and authentication schemes that meet the security requirements
described in GO-ITS 25.15 Security Requirements for Password Management
and Use 25.15.
UNCLASSIFIED
11
GO-ITS 25.12 Status: Approved Version 1.1
2.4.2 Deployment of cryptography
Cryptographic mechanisms within the Government must be deployed and configured in
compliance with the requirements in this document (please consult Appendix A),
applicable implementation standards, and any requirements mandated through the TRA
process. CSB should be consulted to determine how best to address security
requirements.
The ability to modify the configuration of cryptographic mechanisms must be restricted
to qualified and specifically authorized administrators.
Cryptographic mechanisms deployed for users, applications and services must be kept
current and updated when necessary to address vulnerabilities, as advised by CSB.
All applications and services using cryptography must:
• Employ a random number generation (RNG) or high-quality pseudo-random
number generation (PRNG) implementation considered (and validated, in high-
risk environments) to be cryptographically adequate (consult CMVP materials,
FIPS 140-2 and ISO/IEC 18031:2005 for more information);
• Check the validity of certificates, and not use certificates that are revoked,
expired, or otherwise invalid; and

Securely delete decrypted information retained in temporary memory and/or
caches immediately upon completion of the related transaction or activity.

Applications and services that provide access to sensitive information must undergo
security testing and evaluation (STE) prior to implementation, and when changes are
made that may introduce vulnerabilities.
2.4.3 Development of cryptography
Ministries and agencies of the Government of Ontario must not develop any type of
unique or proprietary cryptographic algorithm, protocol, RNG, PRNG, or cryptographic
implementation for the purpose of safeguarding information; all cryptography used to
secure Government of Ontario I&IT assets within the scope of this document must be
acquired via peer-reviewed, industry standard products, software, or services endorsed
by CSB. Such products, software, and services must meet the requirements in this
document, and be procured through appropriate channels.
2.4.4 Protection of cryptographic material
Access to cryptographic material must be limited to its intended use and restricted to
authorized entities (e.g., an individual, application, or service).
Cryptographic material for Government use and all technology used for its generation,
transmittal, use, storage, and disposal must be protected using physical, network, and
personnel security measures, in addition to other applicable security guidance.
Cryptographic keys must be protected to a degree commensurate with the sensitivity of
the information they are intended to protect, while in storage or in transit. The integrity of
the material should be confirmed prior to each use (e.g., validation of a digital signature
or MAC).
UNCLASSIFIED
12
GO-ITS 25.12 Status: Approved Version 1.1
Keys or certificates must be generated by the Government of Ontario, or supplied by an
organization endorsed by CSB as a provider of cryptographic services (see the section
entitled Management of Cryptographic Services). Keys should be generated via a secure
module (e.g., FIPS 140-2 level 2 or better) where possible.
If cryptographic material protecting sensitive program information is assigned to an entity
other than a person (e.g., an application or service):
• A responsible, accountable custodian role must be devised and assigned for the
protection of the key material, and to ensure that it is deployed in compliance
with applicable requirements;
• Protection of the assigned cryptographic material must be changed when a new
individual is appointed (e.g., the previous appointee or custodian must no longer
have access);
• The Program Manager must be aware of the current appointee’s contact
information and responsibilities, and the other positions that require access to the
cryptographic material to fulfill their responsibilities (e.g., members of operations
units); and
• The appointee must document all access to the cryptographic material (by name
of the individual granted access) and must take caution and/or measures to
prevent access by an individual who is no longer authorized.
2.4.5 Key management
Internal key management procedures must be developed for all applications employing
cryptographic systems for the protection of sensitive information. These procedures
must address separation of duties, re-keying requirements, key generation, key
assignment, revocation processes (including related timelines), secure distribution, and
secure destruction of cryptographic material.
Cryptographic keys issued for test purposes must not be used in a production
environment, and production cryptographic keys must not be used in a test
environment.
Internal staff responsible for the issuance and/or management of cryptographic keys
should be organizationally separated from operations (e.g., separation of duties) and
must possess a valid Government of Ontario Personnel Screening result.
2.4.6 Recovery of encrypted information
The cryptography service must include a secure mechanism for the recovery of
symmetric and asymmetric decryption keys when needed to recover encrypted
information in storage (e.g., lost password, departing employee, corrupted key, legal
discovery requirements, or forensics investigation). Government of Ontario key material
must not however be held in escrow by a third party (please see definition of key escrow
in the glossary for this document).
The potential for regulatory and/or legal obligations to provide information that may have
been encrypted must be considered for all encryption systems. Decryption keys must
be recoverable after their expiry or termination to enable the future decryption of
information, including archived back-ups.
UNCLASSIFIED
13
GO-ITS 25.12 Status: Approved Version 1.1
Only the user or the responsible area Director may request recovery of encrypted
information. The identity of the requester must be verified before the recovery is carried
out. The responsible Director must confirm the legitimacy of requests for access to
encrypted information (e.g., court order or other authority) before requesting recovery.
If the recovery of encrypted information causes the generation of an identity credential
under the user's name, the recovery procedure must prevent the use of the identity
credential by anyone other than the user.
A secure self-recovery mechanism endorsed by CSB should be provided for users
to recover encrypted material themselves when they cannot recover (or remember) their
credentials (e.g., without interactive assistance from an administrator or help desk).

2.4.7 Management of cryptographic services
An organization that provides cryptographic services for the Government of Ontario
must establish and adhere to operating policy and procedures that comply with the
requirements in this document, and other relevant government security standards and
policies (e.g., other GO-ITS 25 series standards, and ISPC).


UNCLASSIFIED
14
GO-ITS 25.12 Status: Approved Version 1.1
3. RESPONSIBILITIES
Users
All Government of Ontario employees and staff using I&IT resources are responsible for:

Complying with directives, policies and agreements when accessing or using
Government of Ontario information, equipment and services;

Understanding information sensitivity and their duties to protective sensitive information
as per the ISPC policy and operating procedures;

Using the cryptographic technology provided to them for the protection of Government
information; and

Reporting any suspected security breaches to the IT Helpdesk.

Program managers
Program managers are responsible for:

Being aware of any custodian roles within their area;

Maintaining relevant contact information and organizational details regarding those
interacting with custodians;

Ensuring ISPC compliance and the completion of PIA and TRA work products, with the
support of the relevant Cluster Security Officer;

Ensuring required security safeguards are in place to protect Government of Ontario
information, including additional safeguards recommended and approved via the PIA
and TRA processes; and

Reporting any security exposures or suspected security incidents.

Directors
Directors are responsible for:

Ensuring that staff members are aware of and adequately trained in their
responsibilities as set out in this document, ISPC, and other relevant policies and
standards;

Ensuring that agreements with consulting firms and service providers include
provisions that outline the organization’s responsibilities for the cryptographic
protection of Government I&IT resources;

Ensuring required security safeguards are in place to protect Government of Ontario
information, including additional safeguards recommended and approved via the PIA
and TRA processes;

Initiating and managing requests for recovery from encryption keys;

Confirming the legitimacy of any such requests that originate from within their area; and

Reporting any security exposures or suspected security incidents.
UNCLASSIFIED
15
GO-ITS 25.12 Status: Approved Version 1.1
I&IT clusters
The I&IT clusters are responsible for:

Supporting Program Managers and Directors in ensuring that Government information
is protected by appropriate security safeguards, and in accordance with ISPC
requirements;

Procuring, deploying and maintaining information technology products that incorporate
cryptographic components, in compliance with these requirements;

Ensuring that applications and services appropriately employ cryptography in
compliance with these requirements;

Providing users with instruction and support;

Supporting security incident reporting and handling procedures as required;

Ensuring that agreements with service providers address security requirements; and

Monitoring for compliance with this document.

Cluster security officers
Cluster security officers are responsible for:
• Supporting Program Managers, Directors, and their I&IT Cluster in ongoing
compliance with these requirements;
• Supporting Program Managers during the creation of Threat Risk and Privacy Impact
Assessment work products; and
• Monitoring that the deployment, use and support of security safeguards and services
adhere to these requirements.
Infrastructure Technology Services (ITS)
ITS is responsible for:

Ensuring that agreements that they enter into with cryptographic service providers will
address the requirements in this document;

Monitoring provided services for compliance with the requirements in this document;
and


Operation of the IT Service Desk, and provision of assistance to clients.

Custodians
Any appointed custodian of cryptographic material is responsible for:

Ongoing management and due protection of any key material assigned, at an
appropriate level, given the role of the assigned material and sensitivity of associated
protected information;

Formally documenting all access to the protected cryptographic material, subsequent
to validation of all requests to ensure they are authorized;
UNCLASSIFIED
16
GO-ITS 25.12 Status: Approved Version 1.1

Appropriate management of responsibilities, including relinquishing the custodian role
to any appointed replacement custodian as required; and

Reporting any security exposures or suspected security incidents.

Cryptographic service providers
Any Cryptographic service provider to the Government of Ontario is responsible for:

Establishing and adhering to operating policy and procedures that comply with this
standard, relevant Government directives and policies, and applicable industry
standards and practices;

Due diligence in the operation of all systems and processes related to the
cryptographic services provided; and

Accommodation of audit to validate sound operation of systems and processes, and
due co-operation regarding disclosure of practices and documentation.

Corporate Security Branch
The MGS Corporate Security Branch is responsible for:

Authorship of security policies and standards for the Government of Ontario, subject to
the approval of the Information Technology Standards Council (ITSC) and Architecture
Review Board (ARB);

Securely managing and operating the Certificate Authority for the Government of
Ontario PKI service (GO-PKI) for the Ontario Public Service (OPS) and its service
partners;

Monitoring the evolution of technology and products, assessing their strengths and
vulnerabilities, and endorsing cryptography for Government use;

Supporting procurement processes for and evaluation of cryptographic products for the
OPS;

Advising appropriate levels of protection to address business risks relative to identified
threats, and identifying technology best suited to address such security and business
requirements;

Providing timely guidance on the deployment and use of security products and
services to OCCIO ITS and the I&IT Clusters;

Monitoring compliance with security requirements and obligations in conjunction with
OCCIO ITS and the I&IT Clusters; and

Liaising with cryptographic and security authorities at other levels of Government.

UNCLASSIFIED
17
GO-ITS 25.12 Status: Approved Version 1.1
Ontario Internal Audit
The Ontario Internal Audit Division is responsible for:

Conducting periodic audits of pertinent activities to test compliance with security
standards;

Communicating with appropriate management about the risks identified and the severity
of those risks; and

Working with management to identify the needed management action plans to mitigate
the risks noted during the course of an audit and conducting follow-up as required.

UNCLASSIFIED
18
GO-ITS 25.12 Status: Approved Version 1.1
4.
ACKNOWLEDGEMENTS

4.1 Editors
Full Name
Cluster, Ministry and/or Area
Tim Dafoe
MGS Corporate Security Branch



4.2 Contributors
Full Name
Cluster, Ministry and/or Area
Earl Kuntz
MGS Corporate Security Branch



4.3 Consultations
The following individuals were consulted:
Charlotte Ward, MGS Corporate Security Branch
Pat Antliff, MGS Corporate Security Branch
Muriel Petersen, MGS OCIPO

Lynette Craig, MGS OCIPO

Brady Thompson, MGS OCIPO


4.4 Reviewers
The following groups have reviewed this standard:
Security Architecture Domain Working Group

Cluster Security Officers




UNCLASSIFIED
19
GO-ITS 25.12 Status: Approved Version 1.1
5. DOCUMENT HISTORY

Endorsed: 2008-09-17
• IT Standards Council
Approved: 2008-10-16
• Architecture Review Board
Revised: 2008-10-24
• Updated to enhance technical specificity; document version set to Version 1.1:
o Page 10 - Changed "security zone" to "Zone" to align with CSB development efforts
o Page 10 - Added a reference to NIST CAVP
o Page 11 - Changed "security zone" to "Zone" to align with CSB development efforts
o Page 21 - Added a reference to permit for special purpose cryptography
o Page 22 - Added Secure Shell protocol version 2.0
o Page 22 - Added a reference to permit for special purpose protocols
o Page 28 - Changed the Zone definition to align with CSB development
o Page 29 - Added CAVP to acronym list
o Page 34 - Added CAVP to references list

UNCLASSIFIED
20
GO-ITS 25.12 Status: Approved Version 1.1
6. APPENDIX A: APPROVED ALGORITHMS AND PROTOCOLS
Cryptographic algorithms

The cryptographic algorithms, key lengths, and operating modes approved for Government of
Ontario use are listed below, including those required for high-risk situations as determined by a
TRA.

9
Higher cryptographic strengths are required beyond 2010 as per National Institute of
Standards and Technology (NIST) publication SP800-57 and external guidance received by
CSB. When determining the cryptographic requirements for the system, consideration must be
given not only to the present extent of identified risk, but also the anticipated lifetime of the
system and resulting retention of associated information.
Table 1: Approved cryptographic algorithms and minimum key lengths
Required Strength
Until 2010
Required Strength
Beyond 2010
Type
Approved
Algorithms
Minimum key
length
High-risk
Situations
Minimum
length
High-risk
Situations
Requirements / Comments
Triple DES
(3DES)
(FIPS 46-3)
Must use 2
unique 56 bit
keys, and
should use 3
(EDE2/EDE3)
Must use 3
distinct 56
bit keys
(EDE3)
Must use 3
distinct 56
bit keys
(EDE3)
Should not
use 3DES
Symmetric
Cryptography
AES
(FIPS 197)
128
128-256
128-256
256
Use AES for all new implementations.
CAST5-128 (RFC 2144) is an acceptable
alternative to AES-128 if the latter presents an
implementation challenge for a particular
system.
Applications using 3DES or unapproved
algorithms (e.g., DES) should migrate to AES
wherever practical.
64 bit DES keys are effectively 56 bits long;
this reduction in effective length similarly
impacts 3DES implementations and should be
considered prior to deployment.
RSA
(ANSX9.31 /
FIPS 186-2)

1024
2048
2048
3072

DSA
(FIPS 186-2 /
(ANSX9.42)



L = 1024
N = 160
L = 2048
N = 224
L = 2048
N = 224
L = 3072
N = 256
Asymmetric
Cryptography
ECC
(ANSX9.62 &
9.63 /
FIPS 186-2)

P-192
B-163
P-224
B-233
P- 224
B-233
P-256
B-283



Non-compliant implementations should be
migrated wherever practical.


The symbols “L” and “N” refer to public and
private DSA key lengths respectively.


The minimum key length for Elliptic Curve
systems depends on whether the curve is
defined over a prime (P) or binary (B) field
(e.g., P-xxx, B-xxx). Deploy validated and
cryptographically secure implementations only.



9
Special purpose cryptography may be endorsed by CSB for specific use and/or high-risk environments.
UNCLASSIFIED
21
GO-ITS 25.12 Status: Approved Version 1.1
Required Strength
Until 2010
Required Strength
Beyond 2010
Type
Approved
Algorithms
Minimum key
length
High-risk
Situations
Minimum
length
Requirements / Comments
High-risk
Situations
Secure Hash
Functions
Digital
Signatures
and Hashes
(FIPS 180-2)
SHA-1 or
stronger
Should not
use SHA-1
(e.g., use
SHA-256 or
stronger)
SHA-256 or
stronger
SHA-256 or
stronger
Legacy hash function implementations (e.g.,
MD5) must be migrated whenever practical to
SHA-256 or stronger.
New implementations should not use SHA-1.
The risk of hash collisions must be assessed
and addressed appropriately.
HMAC

(ANSI X9.71-2000
/ FIPS 198)
SHA-1 or
stronger
Should not
use SHA-1
(e.g., use
SHA-256 or
stronger)
SHA-256 or
stronger
SHA-256 or
stronger
New HMAC implementations should not be
based on SHA-1.
The cryptographic strength of HMAC depends
on the underlying hash function.
Message
Authentication
Codes
CBC-MAC /
CMAC / CCM
(SP 800-38
A/B/C)
See Symmetric Cryptography for approved key lengths.
AES should be used as the block cipher for MAC
operation wherever practical.
The same symmetric key should not be used
for encryption and MAC operations that are
performed separately.
CCM is a component within the 802.11i
standard for authentication & encryption.

Modes of operation
Various modes of operation may be used for symmetric block cipher algorithms. Five of these
modes are defined in NIST SP800-38A (please consult the references for this document for
more information).
The Electronic Codebook (ECB) mode of operation must not be used. Caution must be
exercised and an appropriate mode deployed if the mode of operation for a block cipher must
be manually determined or selected within a given system.
Approved modes of operation for authentication and confidentiality are listed under Message
Authentication Codes in the table above. More information is also available from Modes of
Operation sections of the NIST Cryptographic Toolkit site (please consult the references for this
document).
The Corporate Security Branch monitors the evolution of modes of operation and must be
consulted prior to the deployment of new modes.

Approved key establishment and exchange protocol implementations
With the exception of GO-PKI and related infrastructure, the following implementations of
asymmetric key protocols must be used for the establishment and exchange of a symmetric key
for the encryption of subsequent communications:
• Secure Shell protocol 2.0 or newer/stronger;
• Secure Sockets Layer (SSL) v3.0 or newer/stronger;
• Transport Layer Security (TLS) v1.0 or newer/stronger;
UNCLASSIFIED
22
GO-ITS 25.12 Status: Approved Version 1.1
• Wireless TLS;
• Internet Key Exchange (used by Internet Protocol Security [IPsec]); and
• Special purpose protocols endorsed by CSB for specific use and/or high-risk environments.
TLS/SSL support and implementation

Government supplied Internet clients / browsers must support TLS. Versions of SSL prior to 3.0
should not be supported (as they do not provide for acceptable levels of security, and suffer
from documented weaknesses). More recent versions of these protocols should be used as they
become validated and available.
The selection of TLS/SSL cipher suites must be performed in a manner such that all
components of the cipher suite satisfy the requirements of the Approved cryptographic
algorithms and minimum key lengths table published in this document (relative to the sensitivity
of the data being passed via the TLS/SSL session). Client or server connections requesting
weaker protocols or a reduction in the strength of cryptographic systems must be denied.
Implementations of various network services may use the above (or similar) protocols to
establish a secure connection; these protocols should be identified, and only used in
conjunction with cryptography that satisfies the Approved cryptographic algorithms and
minimum key lengths table published in this document.



UNCLASSIFIED
23
GO-ITS 25.12 Status: Approved Version 1.1
7. APPENDIX B: DEFINITIONS

Access: The ability to enter a physical area or use a r
esource
, which may include viewing,
adding, modifying or deleting data, and/or executing applications (running computer programs).
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).
Authenticate: To establish confidence in the reliability of an assertion (e.g., use of passwords,
access cards, or other credentials), and verify the claimed identity of a user prior to granting
access.
Authentication: A process of testing assertions to establish a level of confidence (assurance)
in their reliability as an indication of identity.
Authorization: The procedural and technical allowance of specific privileges and access.
Availability: The degree of readiness expected of information systems and IT resources to
deliver an appropriate and timely level of service, regardless of circumstances.
Block cipher: A cryptographic algorithm that processes fixed units of information as plaintext
input, and produces encrypted output of that length via the use of a static key (e.g., AES).
Certificate: The public key of an entity, together with other information, made authentic when
digitally signed with the private key of the CA that issued it. Certificate formats are described
within the X.509 and RFC 2459 specifications.
Communications Security Establishment Canada: “Canada's national cryptologic agency …
[it] provides the Government of Canada with two key services: foreign signals intelligence in
support of defence and foreign policy, and the protection of electronic information and
communication …” [from the CSEC public web site].
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).
Cryptography: The discipline which embodies principles, means and methods for the
transformation of data in order to hide its information content, detect unauthorized modification,
or prevent its unauthorized use. Cryptography is commonly used to provide confidentiality,
integrity, message authentication, identity authentication and digital signatures.
Cryptographic algorithm: A well-defined computational procedure that takes variable inputs
including a cryptographic key and produces an output.
Cryptographic key: A parameter used in conjunction with a cryptographic algorithm that
determines its operation in such a way that an entity with knowledge of the key can reproduce
or reverse the operation, while an entity without knowledge of the key cannot.

Data: Any formalized representation of facts, concepts or instructions suitable for
communication, interpretation or processing by a person or by automatic means.
UNCLASSIFIED
24
GO-ITS 25.12 Status: Approved Version 1.1
Decryption: The process of changing ciphertext (encrypted information) into plaintext using a
cryptographic algorithm and key.
Digital signature: A cryptographic technique based on a uniquely related pair of keys where
one key is used to create a signature (the private signing key) and the other to check the
signature (the public verification key). A digital signature enables the recipient to verify the
source (e.g., the signer) of a message or document and confirm its integrity.
Elliptic Curve Cryptography: A cryptographic design whereby the strength of the system is
predicated on the demonstrated difficulty of determining points on a plane curve when defined
over large finite groups. This known property of large finite fields is also referred to as the
discrete logarithm problem.
Encryption: The transformation of data via cryptography into a form unreadable by anyone not
in possession of the required key. It can provide for data confidentiality by keeping the
information hidden from any individual or entity for which it was not intended.
FIPS: (Federal Information Processing Standards): A set of standards developed by the
National Institute of Standards and Technology (NIST) for use by the United States
Government. FIPS deals with a wide range of computer system components, including those
relating to security and assurance.
Hash function: A function that maps a bit string of arbitrary length to a fixed length bit string.
Common names for the output of a hash function include hash value, hash, message digest and
digital fingerprint. Approved hash functions satisfy the following properties:
• One-way: it is computationally infeasible to find any input that maps to any pre-specified
output, and
• Collision resistant: it is computationally infeasible to find any two distinct inputs that map
to the same output.
Identifier: A bit string that is associated with a person, device or organization. It may be an
identifying name, or may be something more abstract (for example, a string consisting of an IP
address and timestamp), depending on the application.
Identity authentication: A process that uses a credential(s) to verify the identity of a user who
is attempting to access resources and/or services.
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 property that information has not been modified or deleted in an unauthorized
and undetected manner.
Key escrow: an arrangement in which keys needed to decrypt encrypted data are held in
escrow by a third party, such that authorized individuals may obtain them if required.
Key management: The activities involving the handling of cryptographic keys and other related
security parameters during the entire life cycle of the keys, including their generation, storage,
establishment, entry and output, and destruction.
UNCLASSIFIED
25
GO-ITS 25.12 Status: Approved Version 1.1
Key recovery: A function in the lifecycle of keying material that uses mechanisms and
processes that enable authorized entities to retrieve keying material from key backup or archive.
Key revocation: A function in the lifecycle of keying material; a process whereby a notice is
made available to affected entities that keying material should be removed from operational use
prior to the established expiry date for that keying material.
Managed perimeter boundary: The portion of the Government of Ontario network connected
to the internal Corporate Firewall cluster interface points.
Message authentication code (MAC): A cryptographic checksum on data to detect both
accidental and intentional modifications of data.
Network attached storage (NAS): A server specifically designed for handling files (rather than
block data). Network-attached storage is accessible directly on the local area network (LAN)
through LAN protocols such as TCP/IP. This is as opposed to storage that is internal to or
directly connected to a server (e.g., via parallel SCSI cables) and only accessible from that
server.
Non-repudiation: A service that enables the integrity and origin of information to be verified by
a third party. This service prevents the originating entity from successfully denying involvement.
Non-repudiation is supported cryptographically though the use of a digital signature created
using a private key known only by the signer (the originating entity).
Password: A string of characters (letters, numbers and other symbols) that are used to
authenticate an identity or to verify access authorization.
Pass phrase: A lengthy string of characters intended to provide for significantly increased
complexity compared to traditional passwords, in a format users can readily recall from memory.
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 authority is required to collect and use the personal
information needed for the delivery of a specific program or service.
Private key: A cryptographic key, used with a public key cryptographic algorithm that is
uniquely associated with an entity and is not made public. In an asymmetric (public)
cryptosystem, the private key is associated with a public key.
Program manager: The person responsible for the continued development, operational control,
implementation, monitoring, etc. of a specific program or service within a Ministry.
Public key: A cryptographic key that is used with a public key cryptographic algorithm. The
public key is uniquely associated with an entity and may be made public. In an asymmetric
(public key) cryptosystem, the public key is associated with a private key. The public key may
be known by anyone and, depending on the algorithm, may be used to:

• Verify a digital signature that is signed by the corresponding private key (public
verification key); and/or
• Encrypt data that can be decrypted by the corresponding private key (public encryption
key).
UNCLASSIFIED
26
GO-ITS 25.12 Status: Approved Version 1.1
Public key certificate: A public key that has been digitally signed by the issuing organization
(Certification Authority). The integrity of the public key can be confirmed by verifying the digital
signature associated with it.
Responsibility: The obligation to perform a given task or tasks associated with a specific role.
Risk: An estimation of the likelihood and impact of potential events on an organization’s ability
to meet its business objectives.
Safeguard: A protective and precautionary measure intended to prevent a threat agent from
reducing security or causing harm.
Secret key: See symmetric key.
Secure sockets layer (SSL): A protocol that protects the confidentiality of data exchange
between applications and users on the Internet. Early versions of SSL should be avoided (e.g.,
prior to SSL 3.0).
Security: The effort to create managed environments within which agents can only perform
authorized actions and gain prescribed access, once appropriately authenticated.
Storage area network (SAN): A specialized network that provides access to high performance
and highly available storage subsystems using block storage protocols. The main characteristic
of a SAN is that the storage subsystems are generally available to multiple hosts at the same
time, which makes them scalable and flexible.
Stream cipher: A cryptographic algorithm that processes a large series of bits (or pieces of
information) by combining plaintext data of variable length with a key stream (e.g., RC4).
Symmetric key: A single cryptographic key (used with a symmetric key cryptographic
algorithm) uniquely associated with one or more entities that must be protected from disclosure.
Symmetric key algorithm: A cryptographic algorithm that uses the same secret key
(symmetric key) for all operations (e.g., encryption and decryption).

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.
Transport layer security (TLS): A protocol that ensures privacy between communicating
applications and their users on the Internet. TLS (e.g., SSL 3.1) evolved from earlier Secure
Sockets Layer (SSL) protocols.
User: A person authorized to access and use Information and Information Technology
resources.
UNCLASSIFIED
27
GO-ITS 25.12 Status: Approved Version 1.1
Zone: A controlled, managed environment with defined interface points that employs technical
safeguards and access controls in accordance with a defined scheme. Network components
and systems must be housed within an appropriate Zone, and in cases, separated from other
parts of the Government of Ontario network by approved policy enforcement and access
controls.


UNCLASSIFIED
28
GO-ITS 25.12 Status: Approved Version 1.1
8. APPENDIX C: ACRONYMS

The following abbreviations and acronyms are used in this standard:

3DES: Triple Data Encryption Standard
AES: Advanced Encryption Standard (specified in FIPS 197)
ANSI: American National Standards Institute
CMAC: Cipher-based MAC
CAVP: Cryptographic Algorithm Validation Program (NIST/CSEC effort)
CMVP: Cryptographic Module Validation Program (NIST/CSEC effort)
CSEC: Communications Security Establishment Canada
CSB: Corporate Security Branch (MGS)
DES: Data Encryption Standard (deprecated; do not implement)
DSA: Digital Signature Algorithm (specified in FIPS 186-3)
ECB: Electronic Codebook (a mode of operation)
EDE2: A 3DES mode of operation using two unique keys
EDE3: A 3DES mode of operation using three unique keys (more secure than EDE2)
FIPS: Federal Information Processing Standard
GO-PKI: Government of Ontario Public Key Infrastructure
HMAC: Keyed-Hash Message Authentication Code (specified in FIPS 198)
IEC: International Electrotechnical Commission
IPsec: Internet Protocol Security
ISO: International Organization for Standardization
ISPC: Government of Ontario Information Security and Privacy Classification Policy
ITS: Infrastructure Technology Services
MAC: Message Authentication Code
MGS: Ministry of Government Services
NIST: National Institute of Standards and Technology
OPS: Ontario Public Service (the employees of the Government of Ontario)
PDA: Personal Digital Assistant (e.g., Palm, RIM Blackberry)
UNCLASSIFIED
29
GO-ITS 25.12 Status: Approved Version 1.1
PIA: Privacy Impact Assessment
PKI: Public Key Infrastructure
RSA: Rivest, Shamir, Adelman (an algorithm)
SHA: Secure Hash Algorithm
SNA: Systems Network Architecture (an IBM networking protocol for mainframes)
SSH: Secure Shell
SSL: Secure Socket Layer
STE: Security Testing and Evaluation
TLS: Transport Layer Security
TRA:

Threat Risk Assessment
VPN: Virtual Private Network
UNCLASSIFIED
30
GO-ITS 25.12 Status: Approved Version 1.1
9. APPENDIX D: ADDITIONAL INFORMATION

Type of standard

Check
One
Type of Standard



Implementation or Process Standards – requirements or specifications, which may
include best practices and guidance, for the implementation of a technology or the
performance of an activity related to the use of technology, applicable throughout the
provincial government (e.g., mandatory O/S configuration requirements, security
procedures, change management procedures, web page design requirements).


Information Standard – specifications for a data format (e.g. XML schema, metadata,
and/or related data models)


Technical Standard - networking and communications specifications, protocols,
interfaces (API’s) (e.g., standards adopted from recognized standards development
organizations such as W3C, OASIS or IETF such as TCP/IP, XML, SOAP, etc.)

Architecture Standard – application patterns, architecture and standards principles
governing the design and technology decisions for the development of major enterprise
applications


Product Standard – an enterprise-wide product which is mandatory for use such as a
single corporate-wide application, which all ministries and agencies use to record and
access their HR information.


Publication

Please indicate if this standard should be restricted to publishing on the Internal (Intranet) IT
Standards web site or whether it is intended for publishing on the public (Internet) Government
of Ontario IT Standards web site.

Check
One
Publish as Internal or External

Internal Standard

External Standard
UNCLASSIFIED
31
GO-ITS 25.12 Status: Approved Version 1.1
Consultation

Check
Area
Date:
(month/year)

Technical Standards, Technology Adoption Branch, OCCTO


Corporate Architecture Branch (CAB Architects), OCCTO


Corporate Security Branch


Cluster Security Officers


Access and Privacy Office / OCIPO


Archives of Ontario


Strategy, Policy, Planning and Management Branch (SPPM,
OCCS)


Corporate ACT and Domain Working Groups


- Information Architecture Domain (IADWG)


- Technology Architecture Domain (TADWG)


- Application Architecture Domain (AADWG)


- Security Architecture Working Group (SAWG)


Infrastructure Consolidation projects:
- Enterprise Email Services
- Servers and Data Centres
- Desktop Management
- Service Management


IT Standards Council (ITSC)
Sept. 17, 2008

UNCLASSIFIED
32
GO-ITS 25.12 Status: Approved Version 1.1
Impacts to standards
List any existing GO-ITS that may be impacted or associated with this standard.

GO-ITS #
Describe Impact
Recommended Action (or page
number where details can be
found)
GO-ITS 25.0
Other GO-ITS 25 documents
supplement this document.





Impacts to existing environment
List any significant impacts this standard may have on the existing I&IT environment.
Application(s)
or
Infrastructure
Impacted
Describe Impact
Recommended Action (or page
number where details can be found)
All
Adherence to these security
requirements will reduce the risks to
Government I&IT resources.
Compliance with these requirements.
All
Implementation of these security
requirements will produce some
impact due to additional complexity
and/or some increase in
computational overhead.
Compliance with these requirements.




UNCLASSIFIED
33
GO-ITS 25.12 Status: Approved Version 1.1

References
Information and Information Technology Security Directive:
http://intra.pmed.mbs.gov.on.ca/mbc/pdf/Management_of_IT-Dir.pdf
Information Security & Privacy Classification Policy
http://intra.pmed.mbs.gov.on.ca/mbc/pdf/InformationSecurity&PrivacyClassificationPolicy-Aug05.pdf
Threat Risk Assessment Guideline:
http://intra.pmed.mbs.gov.on.ca/mbc/docs/T-Threat.htm
ISO/IEC Standards:
http://www.iso.org
FIPS standards:
http://csrc.nist.gov/publications/fips/index.html
NIST/CSEC CAVP:
http://csrc.nist.gov/groups/STM/cavp
NIST/CSEC CMVP:
http://csrc.nist.gov/groups/STM/cmvp/index.html
NIST Cryptographic Toolkit - Current Modes of Operation:
http://csrc.nist.gov/groups/ST/toolkit/BCM/current_modes.html
NIST Cryptographic Toolkit - Modes of Operation in Development:
http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_development.html
NIST Special Publications:
http://csrc.nist.gov/publications/PubsSPs.html
800-38A Recommendation for Block Cipher Modes of Operation – Methods and Techniques
800-38B Recommendation for Block Cipher Modes of Operation: the CMAC Mode of
Authentication
800-38C Recommendation for Block Cipher Modes of Operation: the CCM Mode for
Authentication and Confidentiality
800-57 Recommendation for Key Management – Part 1
800-57 Recommendation for Key Management – Part 2
800-63
Electronic Authentication Guideline




UNCLASSIFIED
34
GO-ITS 25.12 Status: Approved Version 1.1

Copyright
© Queen's Printer for Ontario 2008
UNCLASSIFIED

35