ITPROSEC General Security Requirements

This document defines the general security requirements for the protection of the integrity, confidentiality and availability of the IT Professional Security’s (ITPROSEC) networks, computer systems and information. This document is one in a series that defines security requirements that are applicable to people, processes and technology at the ITPROSEC.

This documented is aligned with four sections of ISO/IEC 27013 “Information technology – Security techniques – Code of practice for information security controls”:

Section 9 – Access Control
- Section 12 – Operations Security
- Section 13 – Communications Security
- Section 18 – Compliance

1.2 Target audience. 6

1.3 Terms. 6

2 Technical specification. 6

3 Access control 7

3.1 Business requirements for access control 7

3.1.1 Access control procedures. 7

3.1.2 Access to networks and network services. 8

3.2 User Management 8

3.2.1 Password management 9

3.2.2 Password requirements. 9

3.2.3 Password use, change and maintenance. 10

3.3 System and application access control 10

3.3.1 Information access restriction. 10

3.3.2 Secure log-on procedures. 11

3.3.3 Access control systems. 12

3.3.4 Use of privileged utility programs. 12

3.3.5 Access to program source code. 13

4 Operational security. 13

4.1 Operational procedures and responsibilities 13

4.1.1 Use of privileged utility programs. 13

4.1.2 Operational change management 14

4.1.3 Capacity management 14

4.1.4 Separation of development, testing and operational environments. 15

4.2 Protection against malware. 15

4.2.1 Controls against malware. 16

4.3 Backup. 16

4.3.1 Information backup. 17

4.4 Logging and monitoring. 17

4.4.1 Event logging. 17

4.4.2 Protection of log information. 18

4.4.3 Administrator and operator logs. 18

4.4.4 Clock synchronization. 18

4.5 Control of operational software. 19

4.5.1 Installation of software on operational systems. 19

4.6 Information systems audit considerations 19

4.6.1 Information systems audit considerations 19

4.7 Technical vulnerability management 20

4.7.1 Management of technical vulnerabilities 20

4.7.2 Restrictions on software installation. 21

5 Communications. 21

5.1 Network security. 21

5.1.1 Network security management 21

5.1.2 Security of network services. 22

5.1.3 Segregation in networks. 22

5.2 Information transfer 23

5.2.1 Information exchange policies and procedures. 23

5.2.2 Agreements on information transfer 23

5.2.3 Security of media in transit 24

5.2.4 Electronic messaging. 24

5.2.5 Confidentiality or non-disclosure agreements. 25

6 Compliance. 26

6.1 Internal compliance. 26

6.2 External compliance. 26

6.2.1 Compliance with legal requirements. 26

6.2.2 Intellectual property and copyright 26

6.2.3 Organizational records. 27

6.2.4 Data protection and privacy of personal information. 27

6.2.5 Cryptography. 27

6.3 Information security reviews. 28

6.3.1 Independent review of information security. 28

6.3.2 Internal compliance. 28

6.3.3 Technical compliance with policies and standards. 29

Appendix A – Terms and definitions. 30

Appendix B – References. 32

This documented is aligned with four sections of ISO/IEC 27013 “Information technology – Security techniques – Code of practice for information security controls”:

Section 9 – Access Control
- Section 12 – Operations Security
- Section 13 – Communications Security
- Section 18 – Compliance

This document is also aligned with the Government of Galaxy IT Standards (GO-ITS). The requirements outlined in this document must be implemented unless business or functional requirements preclude doing so. In cases where the requirements can’t be met, security exemptions must be raised and approved.

1.1 Purpose

This security requirements document is intended to outline the security controls that should be in place to protect the integrity, confidentiality and availability of ITPROSEC networks, computer systems and information.

All security requirements documents will be reviewed on an ongoing basis to account for the changing threat landscape and the evolution of security and other related technologies and processes.

The requirements outlined in this document must be followed and other additional requirements may arise from any or all of the following:

Security assessments;
- Security testing and evaluations (e.g. vulnerability assessments, penetration testing, static code analysis, etc.); and
- Provincial and federal privacy laws.
- Galaxy Government Directives
- ITPROSEC policy and/or process changes

1.2 Target audience

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

Information security personnel
- Internal auditors
- Developers
- Systems administrators
- Help desk staff
- User account management staff
- Procurement staff
- Project managers
- Records staff

1.3 Terms

This document follows specific wording conventions. The following terms have specific obligations associated with them:

Must: this word, or the terms “required”, or “shall”, means that the statement is a mandatory requirement.

Should: this word “should”, or the adjective “recommended”, indicates there may be a valid reason, in particular circumstances, to ignore the recommendation. However, the full implications (e.g., business functionality, security, and cost) must be understood and carefully considered before deciding not to follow the recommendation.

The following technical requirements apply to all information and information technology (I&IT) assets that store or process ITPROSEC information. The technical specification is comprised of four separate domains that map to ISO 27002:2013:

Section 3: Access Control (maps to Section 9 of ISO 27002:2013)
- Section 4: Operations Security (maps to section 12 of ISO 27002:2013)
- Section 5: Communications Security (maps to section 13 of ISO 27002:2013)
- Section 6: Compliance (maps to section 18 of ISO 27002:2013)

3.1 Business requirements for access control

Objective: To limit access to information and information processing facilities.

3.1.1 Access control procedures

User access and privilege management procedures must be conducted in a comprehensive manner. Information and/or systems owners (or their approved delegate) should formally approve requests for access.

The following requirements must be addressed with access control procedures:

The principles of segregation of duties and least privilege must be implemented to reduce the risk of an external intrusion or unintentional or deliberate misuse of systems or information within the ITPROSEC;
The need-to-know principle must be applied and only users who require access to sensitive or confidential information as part of their job duties should be granted access;
Access must only be provided after formal authorization is granted, via unique authentication credentials with a formal record documenting the provision of access;
The use of generic or shared accounts must be avoided wherever possible;
Where there is a business requirement for the use of a generic or shared account, these accounts must be documented, tracked, and removed when no longer required;
Generic or shared accounts must be subject to the same password expiration and change requirements as individually assigned accounts issued to regular users;
Elevated privilege accounts (e.g., administrator/root) should not be used for normal business tasks which includes, but is not limited to, web browsing, accessing e-mail and other documents;
Requirements for the expiry of privileged access rights should be defined; and
Comprehensive user access and privilege reviews must be conducted on a regular basis to ensure that end users and IT personnel have formally approved and appropriate access to ITPROSEC data and services.

3.1.2 Access to networks and network services

Users should only be provided with access to the networks and network services they have been specifically authorized to use.

Unauthorized and insecure connections to network services can affect the whole organization. Users should only be granted access to services they require and are authorized to use.

All remote access by ITPROSEC staff into the ITPROSEC network must be through a secure channel such as a VPN. The following security controls must be in place for VPN connections or for wireless access:

Two-factor authentication is required for all remote access to the ITPROSEC network. The authentication should be comprised of something you know (e.g. username and password) and something you have (e.g. a hardware or software token or a smart card);
Session information should be protected using the Advanced Encryption Standard (AES) with a minimum key size of 128-bits (256 bit or greater should be used when possible);
Any communication between a remote access server (RAS) device and an authentication server needs to be made via a secure channel; and
The use of network services such as wireless or remote access should be monitored.

Unauthorized and insecure connections to network services can put the ITPROSEC at risk. This control is particularly important for network connections to applications housing sensitive information and for users in high-risk locations (e.g. public or external locations outside of the ITPROSEC’s control).

Objective: To ensure authorized user access and to prevent unauthorized access to systems and services.

Passwords are the most common type of credentials deployed within the ITPROSEC’s access control systems. The following password management requirements must be addressed by access control systems intended to protect ITPROSEC I&IT assets:

Passwords are highly sensitive and must be protected appropriately (i.e. encrypted/hashed in both in storage and transmission);
Users are required to maintain their own passwords. Any secure temporary passwords must be randomly generated and changed at first login;
Managers must assist in efforts to revoke user credentials when they are no longer required;
Passwords should never be stored on computer systems in an unprotected form (e.g. stored in a text, word or excel file or in memory);
A mechanism must be in place to ensure that password values are not reused by the same user with a span of twelve consecutive months;
Accounts must be locked out after the fifth consecutive incorrect password entry and users must contact the help desk to enable further attempts or to reset the account password after validating the user/requestor;
Administrators with access to IT&T assets and infrastructure must not share the job function of user password maintenance;
Controls must be in place to ensure that emergency passwords are changed after use, with details regarding use of emergency accounts/passwords reviewed by appropriate personnel;
Passwords must not be hard coded into applications, automated login processes, scripts, macros, or function keys; and
Access control systems that cannot meet the defined “password management” controls defined in this section of the standard should be as a security exception and reviewed and approved by the business owner of the system or application and Information Security.

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

System and user passwords must be a minimum of eight (8) characters in length;
Mobile device passwords must be a minimum of six (8) characters in length;
Passwords for service accounts must be a minimum of twenty (20) characters in length;
Passwords must be complex and contain three of the four the following categories:
1. Uppercase characters
1. Lowercase characters
1. Base 10 digits (0 through 9)
1. Non-alphanumeric characters: ~!@#$%^&*_-+=’|\()[]:;”’<>,.>/
Users must change their passwords at least once every 45 days;
Passwords must be unique for twelve (12) iterations to prevent risks associated with password re-use;
Users must change their password whenever there is any indication of possible compromise;
Apple devices must lock after 5 minutes of inactivity, with 10 consecutive password failures causing the device to be disabled and wiped of information
Default vendor passwords should be altered following installation of systems or software;
User passwords must not be constructed of information that is easily deduced (e.g. names of pets, birthdays, addresses, hobbies, etc.);
Users must not use the same password for business and non-business purposes and unique passwords must be selected for remote access and for access to different platforms; and
Where possible passphrases should be used instead of shorter password values.
Access control systems that cannot meet the defined “password requirement” controls defined in this section of the standard should be as a security exception and reviewed and approved by the business owner of the application or system and Information Security.

Users must adhere to the following password use requirements:

Users must not divulge their passwords to anyone, including IT support staff or other people in authoritative roles;
User must contact the ITPROSEC help desk or user account manager for assistance with their password, and should report any suspected or confirmed breach/leakage or disclosure of a password to the Chief Information Officer (CIO) and General Counsel Office (GCO); and
Users must promptly change any password they suspect has been shared or disclosed to an unauthorized party.

Objective: To prevent unauthorized access to systems and applications.

Access to information and application system functions by end users and support personnel should be restricted in accordance with the defined access control policy.

Information owners (or in some cases system owners) of applications and the information held within the application should manage access rights and rules for applications, in accordance with the business requirements and the established access control policy/procedure. (refer to 3.1.1)

The following capabilities should be considered to support access restriction requirements:

Menus to control access to application system functions should be provided;
The access rights of users should be granted as per business requirements and approvals;
If a user changes roles and/or departments their existing access should be removed and new access should be provisioned as required;
Access rights should be removed immediately on all platforms when a user separates, retires or otherwise terminates employment;
Access rights should also be removed immediately if access is no longer required or if an account has been inactive for 90 days.

Access to operating systems and applications should be controlled by a secure log-on procedure.

A log-on process should disclose a minimal amount of information about the operating system, service or application the user is trying to access, in order to prevent an unauthorized user with unnecessary information. Log-on procedures should comply with the following requirements:

Display a warning banner that indicates the system should only be accessed by authorized users;
Not transmit password in clear text;
Suppress displaying the password being entered or hide the password with characters or symbols;
The number of log on attempts should be limited to a reasonable number (e.g. 5) and the following controls should be in place:
1. Recording both successful and un-successful log-on attempts;
1. Sending an alarm to a log consolidation console when the maximum number of logon attempts is reached.
Where possible the following information should be displayed upon successful logon:
1. Date and time of previous successful log-on; and
1. Details of any unsuccessful log-on attempts since the last successful log-on.

The strength of user authentication should be appropriate for the classification of the information to be accessed.

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

Access control systems must be centrally deployed and managed;
The design and operation of centralized access control systems must include resiliency and redundancy;
Access rights of users who have left the ITPROSEC or have changed job roles must be blocked or removed in a timely manner unless a valid business reason exists;
Elevated privileges must be assigned on an “as needed” basis, such that these privileges are not provided for an unnecessary duration;
The use of elevated privilege accounts must be logged, and monitored on a frequent basis to assist in detecting unauthorized access or misuse;
Where possible, privileged access accounts should use two-factor authentication;
Prior to being granted access to any systems, users should sign an acceptable use agreement; and
Systems that house confidential or sensitive information should terminate a user session after 20 minutes of inactivity.

The use of utility programs that might be capable of overriding system and application controls should be restricted and tightly controlled.

System utilities that provide administrative capabilities for systems should be tightly controlled as the misuse of these tools could present a threat to the security controls of an operating system or application.

In order to manage risk associated with system utilities, the following controls should be in place:

Where possible these utilities should use identification, authentication and authorization procedures;
System utilities should be segregated from application software;
The use of system utilities should be restricted to a limited number of administrators who require access to these tools for systems management;
Logging should be in place to track the usage of system utilities; and
Unnecessary software based utilities and system software must be removed or disabled.

Access to program source code should be restricted.

Access to program source code and associated technical documents (such as designs, specifications, verification plans and validation plans) should be tightly controlled to prevent the introduction of unauthorized functionality, to avoid unintentional changes as well as to maintain the confidentiality of intellectual property. Source code, specifically should be stored in a central source code library. The following elements should be considered to protect program source libraries:

Where possible, program source libraries should not be held in production systems;
Program source code and program source code libraries should be managed according to established procedures;
Granular access control policies should be put in place to manage access to source code repositories;
An audit log should be maintained of all access to program source libraries;
Maintenance and copying of program source libraries should follow change control procedures. (refer to 4.1.2)

4.1 Operational procedures and responsibilities

Objective: To ensure correct and secure operations of information processing facilities.

System operating procedures should be documented, maintained and made available to all users who need them.

Operating procedures should be treated as formal documents that must be reviewed and approved by management. The procedures should include system operations instructions for the following:

Processing and handling of information;
System backup procedures;
Scheduling requirements, including, interdependencies with other systems, mandatory start/stop times for system work, maintenance windows, or changes, if applicable;
Instructions for handling errors or other exception conditions, which might arise during job execution, including restrictions on the use of system utilities;
Support and escalation contacts in the event of unexpected operational or technical difficulties;
System contingency, restart and recovery procedures for use in the event of a system failure; and
Special output and media handling instructions, such as the management of confidential output, including procedures for secure disposal of equipment and/or data.

Changes to business processes, information processing facilities, systems and applications must be controlled. Unauthorized or uncontrolled changes to systems can cause major disruptions to the availability of information systems, business processes or security controls. Formal management responsibilities, policies, and procedures should be in place to ensure satisfactory control of all changes to systems, applications or procedures.

The following change related controls must be in place:

A change control record must be submitted for significant changes to the production computing environment;
Change control records must be reviewed and approved by the appropriate ITPROSEC personnel prior to changes being implemented;
Changes must be planned and tested, where possible, prior to being implemented in production;
The potential impacts of changes must be considered, including security impacts, prior to the implementation of the change;
Details of planned or proposed changes must be communicated to all relevant persons prior to the implementation of the change;
Change procedures must tested to confirm that the change was successful, and that the security posture of the environment has not been weakened; and
Roll back procedures must exist for reversing unsuccessful changes.

As the demand for data centre processing continues to increase, the ITPROSEC needs to maintain the ability to meet this demand from a facilities, personnel and technology perspective. The risks associated with capacity management can be reduced by taking the following measures:

System tuning;
Monitoring the use of resources (e.g. storage, CPU, memory, etc.)
Input from the user base; and
Projecting future requirements.

For each new system, capacity requirements should be identified. Where possible detective controls should be implemented to automatically notify ITPROSEC or third party vendor personnel of capacity related issues.

Development and testing facilities must be physically and/or logically separated to reduce the risk associated with unauthorized access or changes to production systems. Operational (production) systems require the highest level of availability and integrity. Using the same equipment and software to develop and test new systems makes production systems vulnerable to potential failures of integrity and loss of availability.

If development or test personnel have access to production systems they may be able to introduce unauthorized and untested code or alter production data. Depending on the nature of the systems, this capability could be used to commit fraud, introduce untested code, or malware.

The following controls should be implemented:

Development, test and production software should be run in physically or logically separated environments;
Rules for the promotion of code or transfer of software from develop to production should be defined and formally documented;
Development and testing activities should be separated from production operations and physical or logical segregation must be employed;
Users should use different user profiles for production and testing systems; and
Sensitive data should not be copied into the testing environment unless equivalent security controls are provided for the testing system.

Objective: To ensure that information and processing facilities are protected against malware.

Controls are required to prevent the introduction of malware to the ITPROSEC environment.

Software and information processing facilities are vulnerable to the introduction of malware. Users should be made aware of the dangers of unauthorized software or malware.

Detective and preventative controls to protect against malware and appropriate user awareness training must be implemented.

All systems must employ controls to protect against malware.

The following controls should be considered to help protect against malware:

Establishing a formal policy prohibiting the use of unauthorized software;
Implementing controls to prevent or detect the use of unauthorized software (e.g. application whitelisting);
Implementing controls that prevent users from accessing suspected or known malicious websites (e.g. blacklisting);
Formal procedures to protect against risks associated with obtaining files and software either from or via external networks;
Installation and regular update of anti-virus software to scan computers for malware;
Scanning any files on electronic media or uncertain or unauthorized origin, or files received over unknown networks, for malware prior to use;
Scanning any electronic mail attachments for malware prior to use; and
Appropriate business continuity plans for recovering from malware related incidents, including all necessary data and software backup and recovery arrangements.

Malware could potentially be present as executable or interpretable scripts, shell code, or program commands in files, e-mail or web content and as such these files should be scanned. Vendor updates to malware signature files should be monitored and updated on a daily basis. In addition:

Anti-malware software must be installed, operated, and updated regularly for both clients and servers;
Malware signature updates must only be downloaded from trusted sites; and
Perimeter firewall devices must manage and limit incoming and outgoing network connections to a pre-defined spectrum of approved connections, services and applications.

Objective: To protect against loss of data.

Backup copies of essential business information and software must be taken regularly. Comprehensive backup capabilities should be provided to ensure that all essential business information and software can be recovered following a disaster, system or media failure. The following controls should be considered:

The extent and frequency of backups should reflect the business requirements of the ITPROSEC;
Backups should be stored in a remote location, far enough away to escape any damage from a disaster at the main site;
Backup information should be given an appropriate level of physical and environmental protection consistent with the standards applied at the main site. The controls applied to media at the main site should be extended to cover the backup site;
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;
A retention period for backup media should be determined;
Information from systems storing highly sensitive information (as determined by a security assessment) must be encrypted using approved methods; and
Backups must be managed in accordance with records retention schedules.

The frequency of backups must be based upon availability requirements, as defined by a business impact assessment and/or the initial requirements established during the business case for the system. Backups must be stored in a secure off-site facility and system restoration processes must be tested at a minimum annually.

Objective: To record events and generate evidence.

Events on systems must be logged and archived for the purpose of system monitoring and audit. Operator, system, and audit/event logs must be stored on a centralized log server. These logs must include at a minimum, where relevant, the following:

User IDs;
System start and halt times;
Dates, times and details of key events, e.g. log-on and log-off;
System activities, error and any corrective action taken in response;
Records of successful and failed system access attempts;
Records of successful and unsuccessful data and other resource access attempts;
Changes to system configuration;
Use of privileges;
Files access and the kind of access (e.g. read, write);
Activation and de-activation of protection systems, such as anti-virus systems; and
A timestamp indicating when the log entry was generated by the system, with system time synchronized to a redundant and validated reference time source.

As event logs can contain sensitive data such as personally identifiable data, appropriate privacy protection measures should be taken.

Logging facilities and log information should be protected against unauthorized access and tampering.

Log information can only be relied upon if its integrity has not been altered. Controls related to protecting log information should provide the following capabilities:

Prevent log files being edited or deleted;
Modifications to the type of information being recorded in logs; and
Adequate storage capacity to ensure 90 days of logs can be maintained.

It is essential that controls to protect log files are in place and functioning as log files are required to support the ITPROSEC’s established incident response program, troubleshooting technical issues and may be required as evidence should an investigation be initiated.

The activities of administrators and operators should be logged and the logs protected and reviewed regularly.

All administrative activities should have a clear audit trail. These logs are important for providing assurance of the integrity of computer operations. The logs should be retained for 90 days and should be reviewed regularly.

The clocks of information processing systems within the ITPROSEC should be synchronized with an agreed upon, accurate time source.

Proper time synchronization is important to ensure that system logs are time and date stamped accurately. These time and date stamps serve as an audit trail for transactions between end users. Many clocks tend to drift with time, an automated procedure to check for and correct time should be implemented. An atomic time source should be used to ensure that time is kept synchronized.

Objective: To ensure the integrity of operational (production) systems.

Procedures should be in place to control the installation of software on operational systems.

Operating systems can be vulnerable to the installation of unauthorized software and unauthorized changes to operating system software can result in the loss of data integrity. To minimize risk to operational systems the following controls should be in place:

Operating systems and applications should only be updated by trained administrators and upon change management approval;
Production systems should only hold approved executable code and not development software;
Extensive testing should be conducted prior to implementing operational software (e.g. security testing, usability testing, and performance testing);
Where possible a configuration management solution should be adopted to help control implemented software as well as system documentation;
Previous versions of application software should be retained as a contingency measure; and
Old versions of software should be archived, together with all required information and parameters, procedures, configuration details and supporting software for as long as the data are retained in archive.
Vendor provided production software used in operational systems should be maintained at a level supported by the vendor.

Objective: To minimize the impact of audit activities on operational systems.

Audit requirements and activities involving checks on operational (production) systems should be carefully planned and agreed upon to minimize disruptions to business processes.

The following principles should be followed:

Prior to any audit activity commencing, the proposed scope must be reviewed and agreed to by appropriate ITPROSEC management personnel;
The scope of technical audit tests should be agreed and controlled;
Audit checks should be limited to read-only access to software and data;
Any tools used in an audit must be thoroughly tested in a development environment before they are used in a production environment;
All access during the audit should be monitored and logged to produce a reference trail; and
The person(s) conducting the audit should be independent of the systems or activities being audited.

Objective: To reduce risks resulting from exploitation of published technical vulnerabilities.

Information about technical vulnerabilities of information systems being used at the ITPROSEC should be obtained in a timely manner. The ITPROSEC’s exposure to such vulnerabilities should be evaluated and appropriate measures taken to address risk.

Many attacks against organizations’ information systems are based on the exploitation of published technical vulnerabilities. The time between a vulnerability being discovered and an exploit being published continues to be shortened. The ITPROSEC needs to maintain procedures to identify and address technical vulnerabilities in a timely manner. The following capabilities should be in place:

Roles and responsibilities associated with technical vulnerability management should be defined, including functions such as monitoring, vulnerability scanning, risk assessment and patching;
A timeline should be established for reacting to notifications about potentially relevant vulnerabilities;
Once a potential technical vulnerability has been identified, the ITPROSEC should identify associated risks and actions to be taken. Actions could involve patching of a vulnerable system or applying other compensating controls;
Depending on how urgently a technical vulnerability needs to be addressed, the action should be carried out according to the controls related to change management (refer to 4.1.2) or by following established incident response procedures;
If a patch is available, the risks associated with installing the patch should be assessed (the risk of not applying the patch should also be assessed);
Patches should be tested in a development or testing environment before they are installed to ensure they are effective and do not result in side effects that cannot be tolerated;
If no patch or workaround is available, actions such as turning off services related to the vulnerability, modifying or adding access controls (e.g. firewalls or filtering on routers), and raising awareness about the vulnerability should be considered;
Vulnerabilities on systems that are considered high risk should be addressed first; and
The technical vulnerability management program should be monitored and regularly evaluated to ensure it is operating effectively.

The ITPROSEC must establish, implement and maintain rules governing the installation of software by users.

The principle of least privilege should be applied. The ITPROSEC should identify what types of software installation are permitted (if any) by end users and what types of installations are prohibited.

Objective: To ensure the protection of information in networks and supporting information processing facilities.

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

Responsibilities and procedures for the management of networking equipment should be established;
Encryption should be used to safeguard the confidentiality and integrity of data passing over public networks or over wireless networks to protection the connected systems and applications;
Logging and monitoring capabilities should be applied to enable recording and detection of actions that may affect, or are relevant to information security; and
Management activities should be closely coordinated both to optimize the service to the business and ensure that controls are consistently applied across the infrastructure.

Security features, service levels, and management requirements of all network services should be identified and included in any network services agreements, whether these services are provided in-house or outsourced.

The use of third parties to supply network services to the ITPROSEC could potentially expose the ITPROSEC to unauthorized access attempts by other parties. This could in turn lead to a breach of confidentiality and loss of integrity if the third-party services are not sufficiently secure. Availability is another key attribute that should be reviewed when assessing a third party’s capabilities. It is important to review the resilience of a supplier’s operations, including their facilities, geographic dispersion of personnel and their fallback plans to address network or equipment failures.

Security features, service levels, and management requirements should be identified for particular services. The ITPROSEC must ensure that network service providers implement these measures and a right to audit clause should be included in contracts where appropriate.

Network services include the managed security solutions such as firewalls or intrusion detection systems as well as the provision of network links and network management services.

Groups of information services, users, and information systems shall be segregated on networks.

Networks are vulnerable to unauthorized access attempts and this can potentially result in breaches of confidentiality and loss of integrity or availability for the network or systems attached to the network. The following capabilities should be in place:

Production, staging/test, and development zones should be established and logically separated by firewalls;
Network zones must be implemented and managed in a manner that respects this separation of environments. For example, development hosts should never be used in a zone created for production systems;
Development staff should not be provided with access to the production zone with the exception of temporary access that is granted in case of emergency;
Privileged access granted to developers is to be revoked by the Technical Services team as soon as the emergency is over; and
Applications should not go live in the production environment until they have been approved through established change management procedures (refer to 4.1.2).

Objective: To maintain the security of information transferred within the ITPROSEC and with any external entity.

The exchange of information using electronic communication facilities, such as networks, cloud services, cell phones, and email carry a risk for to ITPROSEC information. The following security controls should be implemented:

Sensitive or confidential information should be encrypted to protect the confidentiality, integrity and authenticity of the information;
Sensitive or confidential information transferred out of the ITPROSEC must be encrypted. This includes information transferred via FTP and email;
Established data retention and disposal guidelines should be followed for all business correspondence, including email, in accordance with provincial and federal laws;
Sensitive or confidential information should not be left on printers or copiers as they may be accessed by unauthorized personnel;
ITPROSEC employees should use caution when communicating with others in public places to ensure they do not disclose sensitive or confidential information; and
ITPROSEC employees need to be mindful when entering personal or demographic information on the Internet to avoid collection for unauthorized use.

Agreements should address the secure transfer of business information between the ITPROSEC and external parties.

When the ITPROSEC provides information to another organization there is always a risk that it may not be looked after with the level of care we desire. This could potentially lead to unauthorized exposure of the information resulting in a breach of confidentiality.

The following controls, where practical, should be included in exchange agreements:

Procedures for notifying sender, transmission, dispatch and receipt;
Minimum technical standards for packing and transmission;
Procedures to ensure a proper audit trail is generated;
Responsibilities should be identified in regards to handling security incidents such a loss of data;
Where practical an agreed upon labeling system for sensitive or critical information should be agreed upon; and
Any special controls that may be required to protect sensitive items, such as cryptographic measures.

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

Media containing information should be protected against unauthorized access, misuse or corruption during transportation beyond the ITPROSEC’s physical boundaries.

Potential vulnerabilities to the transportation of information include loss, unauthorized access and misuse. These vulnerabilities present risk to the confidentiality, integrity and availability of the information or software on the media that is transferred. Where applicable, the following steps should be taken when transporting media:

Reliable transport or couriers should be used;
Procedures need to be in place to check the identification of couriers when shipping or receiving items to the ITPROSEC data centre;
Where appropriate, controls should be adopted to protect sensitive information from unauthorized disclosure such as:
1. Lockable containers
1. Tamper proof packaging
1. Hand delivery

All shipments should be recorded and where appropriate authorized.

Information involved in electronic messaging should be appropriately protected.

Email poses a number of risks to the ITPROSEC such as being used inappropriately by a user or being a vector for viruses or other malicious software. Security measures must be taken to minimize the risks associated with the use of email.

The following technical controls should be implemented to help mitigate the risks associated with email:

All email clients (desktops and laptops) and email servers must run anti-virus software and virus signatures must be updated regularly;
Mail gateways must inspect all inbound and outbound email for viruses, spam and other malicious software;
Mail gateways must provide a proper audit trail (e.g. complete SMTP header information, time & date) of inbound and outbound email messages;
Protection against abuse such as the unauthorized use of a SMTP relay or user enumeration; and
Access to ITPROSEC email from publicly accessible networks requires two-factor authentication.

All electronic communications using the ITPROSEC’s equipment are considered to be in the possession, custody and control of the Commission.

The communication of confidential information with third parties should not take place in the absence of some form of confidentiality or non-disclosure agreement. Requirements for confidentiality or non-disclosure agreements reflecting the ITPROSEC’s needs for the protection of information should be identified, regularly reviewed and documented.

Confidentiality or non-disclosure agreements must address the requirement to protect confidential information using legally enforceable terms and conditions. The following elements should be considered for inclusion in confidentiality agreements:

A definition of the information to be protected (e.g. sensitive or confidential information);
Expected duration of the agreement, including cases where confidentiality might need to be maintained indefinitely;
Actions required when an agreement is terminated;
Responsibilities and actions of signatories to avoid unauthorized information disclosure, including encryption requirements and requirements relating to the location and storage of data (e.g. data storage in Canada);
A right to audit clause should be included to allow the monitoring of activities that involve confidential information;
A process for notification and reporting of unauthorized disclosure or confidential information leakage;
Expected actions to be taken in case of a breach of the agreement; and
Terms for information to be returned or destroyed at the end of an agreement.

Based on the nature of the agreement, the ITPROSEC may have other elements that need to be included in a confidentiality or non-disclosure agreement. In considering whether a confidentiality or non-disclosure agreement is required, staff should consult with the ITPROSEC’s General Counsel’s Office (GCO). All confidentiality and non-disclosure agreements should be drafted by GCO or, if prepared by a third party, reviewed by GCO.

Objective: To avoid breaches of legal and contractual requirements.

Managers must ensure that all security operations within their area of responsibility are carried out properly and in a manner that meets identified security requirements.

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

Objective: To avoid breaches of legal and contractual requirements.

Several areas of external compliance requirements exist. ITPROSEC I&IT assets must be managed in compliance with these 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).

Procedures should be implemented to ensure compliance with restrictions on the use of software and copyrighted materials. Failure to comply with requirements can lead to fines or legal action.

In particular, the following safeguards should be implemented:

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 that fixed seat licenses are not inadvertently exceeded;
Monitor the installation of acquired software packages and control inappropriate installation;
Ensure all contracts are reviewed by the ITPROSEC’s General Counsel Office (GCO)

ITPROSEC records must be protected from loss, unauthorized release, falsification and destruction. Some Commission records may need to be securely retained to meet legal and regulatory requirements, as well as to support essential business activities.

Records should be classified, with storage requirements and retention periods clearly defined for each record type used within the ITPROSEC. Archival procedures should be considered for various types of records to ensure they are protected. Refer to the ITPROSEC Records Retention Schedules for addition details. Technological changes and integrity protection should be considered when choosing a medium for electronic records to ensure they can be accessed but not modified. The ITPROSEC’s Information and Records Management Policy should be referred to for specific details.

The ITPROSEC is bound by legislative requirements at both the provincial and federal level regarding the protection of personal privacy. Security techniques and methods must comply with all relevant provincial and federal privacy legislation.

If personal information is subject to disclosure due to a security breach, Government of Galaxy privacy breach procedures, or those outlined within any relevant legislation or ITPROSEC policy/process must be undertaken. Privacy breaches should be reported immediately to both the ITPROSEC’s General Counsel’s Office (GCO) and Chief Information Officer (CIO).

Controls must be in place to ensure compliance with national and international agreements, laws, regulations related to the use, import, and export of cryptographic software and devices. Required review may include:

Determination of import/export status for cryptographic hardware and software;
Determination of import/export status for items to which cryptography is to be added; and
Determination of use of any cryptography in any jurisdiction where not sanctioned.

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 details in the ITPROSEC policy “Security Requirements for the use of Cryptography”.

Objective: To ensure that information security is implemented and operated in accordance with the ITPROSEC’s policies and procedures.

The ITPROSEC’s approach to managing information security and its implementation (i.e. control objectives, controls, policies, processes, and procedures for information security) should be reviewed independently at planned intervals or when significant changes to the security implementation occur.

The ITPROSEC’s approach to information security and its implementation should be reviewed periodically (e.g. at a minimum every two years) to ensure that controls in place are suitable and operating properly. The results of the independent review should be reported to management.

Reviews should be carried out by individuals independent of the area under review. Results of independent reviews should be recorded and corrective actions taken.

If an external party is engaged to conduct an independent review, no information should be provided until a contract or agreement is in place that outlines terms and conditions for the review.

Managers should regularly review the compliance of information processing and procedures within their area of responsibility with the appropriate security policies, standards, and any other security requirements.

Managers should review the security requirements in defined ITPROSEC policies and standards to ensure they are met. Where feasible, automatic measurement and reporting tools should be used to provide efficient and regular review capabilities.

If any non-compliance is found as a result of the review, managers should:

Identify the causes of non-compliance;
Evaluate the need for actions to achieve compliance;
Implement appropriate corrective action; and
Review corrective action taken to verify its effectiveness and identify any deficiencies or weaknesses.
Report the non-compliance to the CIO, GCO and Information Security Manager.

Results of reviews and corrective actions taken by managers should be recorded and records should be maintained.

Information systems should be regularly reviewed for compliance with the ITPROSEC’s information security policies and standards.

Technical compliance, where possible, should be assessed with the assistance of automated tools with the output reviewed by a technical specialist. Alternatively, manual reviews should be conducted by an experienced technical specialist should be performed.

Any technical compliance reviews should be conducted by competent, authorized personnel and should be supervised by the appropriate personnel from the ITPROSEC.

Appendix A – Terms and definitions

Term	Definition
Access	Entry to an electronic network provided by the ITPROSEC to employees and other authorized individuals on our outside of the ITPROSEC premises.
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 control)
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 the information and legislative requirements (e.g. FIPPA)
Cryptography	The art of protecting information by transforming it (encrypting it) into an unreadable format, called cipher text. Only those who possess a secret key can decipher (or decrypt) the message into plain text.
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 specific I&IT resource or group of resources.
Information	The meaning derived from or assigned to facts or data, within a specific context.
Integrity	The authenticity, accuracy and completeness of data that can be affected by unauthorized or accidental additions, changes and/or deletions.
Non-repudiation	A method of guaranteeing message transmission between parties via digital signature and/or encryption.
Risk	A potential opportunity or threat that may have an impact on the ITPROSEC’s ability to meet its business objectives.
Risk assessment	Process of risk analysis and risk evaluation including a study of vulnerabilities, threats, likelihood, loss and impact.
Safeguard	A protective and precautionary measure to prevent a security threat from happening.
Service account	An account which is generally used for application-to-application authentication or web service authentication.
Two-factor authentication	Requires the user to physically possess something (i.e. smartcard or token) in addition to something the user knows (i.e. a password or a PIN). The physical component (i.e. smartcard, token) is independently separate from the desktop or laptop used to conduct the authentication process.