Document history

Date

Summary

2007-03-27

Endorsed: IT Standards Council endorsement

2007-04-03

Approved: Architecture Review Board approval

  • Approved version number set  to 1.0

2007-10-19

Revised:

  • Publication Details section changed and marked for external posting as directed by Corporate Security Branch
  • Contact information updated. Version number set to 1.1

2010-08-20

  • Structure changed, developer appendix added, aligned with other security standards (i.e. GO-ITS 25.x series)

2010-11-24

  • Developer guidance updated with .NET COE input

2010-12-01

  • Some content removed due to GO-ITS 25.x overlap, ITSC template 2.0, responsibilities, OWASP 2010 update

2011-02-04

  • Updated according to SADWG, IPA, and ITSC input

2011-02-16

Endorsed:  IT Standards Council endorsement

2011-03-29

  • Java COE updates (as per ITSC action items)

2011-04-06

Approved:  Architecture Review Board approval

Approved version number set  to 1.2

2015-01-19

Administrative updates and ISO/IEC alignment, document version changed to 1.3

2015-03-09

Minor update as per received  ARB feedback

2015-03-18

Endorsed by Architecture Review Board

2015-04-16

Approved by Information Technology Executive Leadership Council

2015-11-12

Revision to scope to ensure standard is applicable to internal and external Web Applications.

  • Changed title to Web Applications, document version changed to 1.4
2016-02-03Endorsed by Architecture Review Board

Foreword

Government of Ontario Information Technology Standards (GO-ITS) are the official publications on the guidelines, preferred practices, standards and technical reports adopted under delegated authority of the Management Board of Cabinet (MBC). These publications support the responsibilities of the Treasury Board Secretariat (TBS) for coordinating standardization of Information & Information Technology (I&IT) in the Government of Ontario. 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.

1. Introduction

1.1. Background and purpose

This document describes security requirements, software development rules, and principles for engineering/implementing Web Applications for the Government of Ontario and is intended to ensure that the use of Web Applications will not result in undue or unmitigated risk that jeopardizes the electronic delivery of Government services.

The primary audience for this document includes application developers, implementers, application architects, production management staff, and Program Managers. It is intended to influence the design, development, and deployment of applications operated on behalf of the Government of Ontario.

This document also includes detailed recommendations for secure development techniques in section 4.

1.2. Scope

1.2.1. In Scope

The GO-ITS 25.13 Security Requirements for Web Applications apply to:

  • All ministries of the Ontario Government and any organization that uses a ministry’s or I&IT Cluster’s information technology infrastructure;
  • Any organization that uses ministry or I&IT Cluster information technology infrastructure;
  • Any third party organizations (and their staff) that connect to the Government of Ontario integrated network for business purposes, unless exempted in a Memorandum of Understanding; and
  • All components of Web Applications that support the processing of transactions involving Government information. In the case of backend databases, it only includes requirements relating to access to the database services.

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

The Strategy, Policy and Enterprise Architecture Branch (SPEAB) of the I&IT Strategy and Cyber Security Division (SCS), or a successor division/branch, maintains this standard, and should be contacted if the requirements in this document require clarification, or if it is not clear whether this standard applies to a given situation.

1.2.2. Out of Scope

This standard does not apply to:

  • Internet web sites that only present static information to the public, or Intranet services; and
  • Internet sites that do not connect to additional services or servers within the Government of Ontario integrated network, or similar services or servers operated elsewhere on behalf of the Government of Ontario.

1.3. Applicability statements

1.3.1. Organization

Government of Ontario IT Standards and Enterprise Solutions and Services apply (are mandatory) for use by all ministries/clusters and to all former Schedule I and IV provincial government agencies under their present classification (Advisory, Regulatory, Adjudicative, Operational Service, Operational Enterprise, Trust or Crown Foundation) according to the current agency classification system.

Additionally, this applies to any other new or existing agencies designated by Management Board of Cabinet as being subject to such publications, i.e., the GO-ITS publications and enterprise solutions and services – and particularly applies to Advisory, Regulatory and Adjudicative Agencies (see also procurement link, OPS paragraph). Further included is any agency which, under the terms of its Memorandum of Understanding with its responsible Minister, is required to satisfy the mandatory requirements set out in any of the Management Board of Cabinet Directives (cf. Operational Service, Operational Enterprise, Trust, or Crown Foundation Agencies).

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

When implementing or adopting any Government of Ontario IT standards or IT standards updates, ministries and I&IT Cluster must follow their organization’s pre-approved policies and practices for ensuring that adequate change control, change management, risk mitigation, and control selection mechanisms are in place and employed.

For the purposes of this document, any reference to ministries or the Government includes applicable agencies.

1.4. Requirements levels

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

Must – This word, or the terms "REQUIRED" or "SHALL", means that the statement is an absolute requirement.

Should – This word, or the adjective "RECOMMENDED", means that there may exist valid reasons in particular circumstances to ignore the recommendation, but the full implications (e.g., business functionality, security, cost) must be understood and carefully weighed before.

1.5. Contact information

1.5.1. Roles and responsibilities

Accountable role definition

The individual ultimately accountable for the process of developing this standard. There must be exactly one accountable role identified. The accountable person also signs off as the initial approver of the proposed standard before it is submitted for formal approval to ARB. (Note: in the OPS this role is at a CIO/Chief or other senior executive level, e.g. Head, Director or higher).

Accountable role:

Title: Manager, Security Policy and Standards Unit
Ministry/Cluster: Ministry of Government and Consumer Services
Division: Cyber Security Division
Branch: Cyber Security Strategy, Risk Management & Architecture Branch
Section: Security Policy and Standards Unit
Phone: 647-982-5216
Email: Alex.Fanourgiakis@ontario.ca

Responsible role definition

The organization responsible for the development of this standard. There may be more than one responsible organization identified if it is a partnership/joint effort. (Note: the responsible organization provides the resource(s) to develop the standard).

Responsible organization:

Ministry/Cluster: Ministry of Government and Consumer Services
Division: Cyber Security Division
Branch: Cyber Security Strategy, Risk Management & Architecture Branch

Support role definition

The support role is the resource(s) to whom the responsibility for actually completing the work and developing the standard has been assigned. There may be more than one support role identified. If there is more than one support role identified, the following contact information must be provided for each of them. If there is more than one support role, the first role identified should be that of the editor – the resource responsible for coordinating the overall effort.

Support role (editor):

Ministry/Cluster: Ministry of Government and Consumer Services
Division: Cyber Security Division
Branch: Cyber Security Strategy, Risk Management & Architecture Branch
Section: Security Policy and Standards Unit
Job Title: Senior Security Policy Advisor
Name: Tim Dafoe
Phone: 416-327-1260
Email: Tim.Dafoe@ontario.ca

Consulted

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

Organization consulted (Ministry/Cluster)DivisionBranchDate

MGS

OCCIO

CSB Security Design

Dec. 1st, 2010

Committee/working group consultedDate

.NET COE

Nov. 17th 2010

SDLC

Jan. 7th, 2011

Java COE

Mar. 14th, 2011

ARB

Dec. 10th, 2014

Informed

Please indicate who was informed during the development of this standard. Include individuals (by role and organization) and committees, councils and/or working groups. (Note: informed means those who are kept up-to-date on progress, generally characterized by one-way communication such as presentations):

Committee/working group informed

Date

Security Architecture Working Group

Nov. 19th, 2010

Security Architecture Working Group

Dec. 8th, 2010

Application Architecture Domain Working Group

Nov. 19th, 2010

Technology Architecture Domain Working Group

Jan. 26th, 2011

1.6. Recommended versioning and/or change management

Changes (i.e. all revisions, updates, versioning) to the standard require authorization from the “responsible” organization. Once a determination has been made by the responsible organization to proceed with changes, the Strategy, Policy and Enterprise Architecture Branch, OCCS, will coordinate and provide assistance with respect to the approvals process. The approval process for changes to standards will be determined based on the degree and impact of the change. The degree and impact of changes fall into one of two categories:

Minor changes – requiring communication to stakeholders, ARB endorsement required. Changes are noted in the “Document History” section of the standard.

Major changes – requiring a presentation to ARB and ITELC for endorsement.

Below are guidelines for differentiating between minor and major changes:

Minor:

  • represents incremental version changes to one or more specifications
  • does not impact procurement (other than informational)
  • does not require configuration changes to current solutions
  • does not impact other standards
  • is not related to legislative, policy, or procurement changes

Major:

  • represents a major version change to one or more specifications
  • impacts procurement
  • requires configuration changes to current solutions
  • impacts other standards
  • responds to legislative, policy or procurement changes

1.7. Publication details

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

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

1.8. Compliance requirements

This document is intended to guide the design, development, deployment and operation of all new Web Applications. Compliance with this document is mandatory due to the high degree of vulnerability and impact associated with applications that are deployed and operated without careful security planning and appropriate safeguards.

2. Technical specification

Web Applications are a source of significant security exposure and technical vulnerability; effective management of these services requires careful development and adherence to security requirements.

Ministries and agencies must be assured that Web Applications are secure and that Government I&IT resources are not jeopardized by their use. This assurance is expressed in terms of accountability, confidentiality, integrity, availability, reliability and the opportunity for audit.

The implementation of security measures for Web Applications does not diminish the need for Program Managers to ensure that formal, documented risk assessments (e.g. TRAs) are conducted, developers are appropriately qualified and trained, new technology is assessed for risk, and physical/logical access controls are implemented to protect Government assets.

2.1. Security and privacy assessments

Privacy Impact Assessment (PIA) pre-screening and a Threat/Risk Assessment (TRA) must be undertaken for any Government of Ontario project involving Web Applications. Peer-review of project development and design efforts should also occur, to validate practices prior to the completion of a TRA.

A TRA (in conjunction with the Government of Ontario’s information sensitivity classification Policy and associated guidelines) must be used to determine the degree of risk associated with the project. TRA and PIA work products must be revisited as additional information becomes available or when the project is significantly changed prior to deployment. Any new unacceptable risk or other exposure must be mitigated prior to deployment in a production environment.

When recommended by a TRA, when time-critical services are deployed or changed, or when a Web Application will process or present sensitive information, Security Testing and Evaluation (STE) must be conducted (typically in the form of Vulnerability Assessment and Penetration Testing). Web Applications with time-critical status, that process or present High Sensitivity information, or have been identified as code review candidates via a TRA, must be subject to source code security review (where technically possible) by the Cyber Security Branch (CSB), or a vendor endorsed by CSB.

Remedial action resulting from STE findings during development must be completed prior to production use of the web application. STE must also be performed if the application is significantly changed. Testing should also be performed within the production environment.

2.2. Deployment of Web Applications

Government of Ontario Web Applications must be deployed in accordance with GO-ITS 25.11 Security Design Requirements. Typical locations for web application components include:

  • Access Zone DMZ or Presentation Zone (presentation of UI, web pages, portals);
  • Logic Zone (business rules, processing, parsing of input and queries); and
  • Data Zone (database query handling, organized information storage).

Non-standard deployment may be accommodated according to GO-ITS 25.11 (subject to TRA recommendations).

2.3. Management of production Web Applications

The management of production Web Applications must include:

  • Ensuring that such applications are deployed in accordance with the requirements in this document, Government policies and standards, and applicable industry best practices;
  • Arranging for Security Testing and Evaluation every two years (e.g., vulnerability assessments, penetration testing, application testing), unless major/ongoing changes or TRA recommendations mandate more frequent or immediate assessment (as per section 3.1);
  • Ensuring that IT infrastructure services (e.g., network, servers, desktops, data communications, directories, etc.) are kept current and that recommended security patches are promptly applied;
  • Running applications and supporting services with the least privilege principle enforced as per GO-ITS 25.11, to control access to infrastructure and networked resources;
  • Ensuring that changes to network security (e.g., changes to firewall deployment or rules) do not jeopardize the security of Government applications and services;
  • Monitoring for unauthorized changes to production software and services;
  • Ensuring that backup and restore functions are implemented and tested for Web Applications;
  • Ensuring that time-critical Web Applications have business continuity and disaster recovery plans, and that these plans are kept current;
  • Establishing procedures to monitor for attacks when applications are deemed time-critical or when sensitive information is involved; and
  • Establishing and reviewing audit logs, with prompt reporting and remediation of suspected security breaches, non-compliance with security requirements, or other incidents, in accordance with the GO-ITS 37.0 Enterprise Incident Management standard.

2.4. Administration of production Web Applications

The administration of production Web Applications must include:

  • Access to administrator footnote 2(e.g., privileged operating system access) accounts must be provided on a least privilege basis, and restricted to individuals who have been authorized by the Cluster Chief Information Officer (or his/her delegate);
  • Assigned privileged accounts must be monitored and audited to detect misuse and/or security violations;
  • Each administrator must have his or her own account with a specific administrative role and limited privileges. The number of administrative roles may vary due to the complexity and sensitivity of the information processed, or a documented requirement for separation of duties;
  • Administrator accounts must be promptly terminatedfootnote 3 (e.g., by next business day) when the authorized account holder no longer requires access, or locked when it is suspected that the account has been compromised. In the case of administrators responsible for High Sensitivity applications, these actions must be immediate (e.g., performed upon initial notification without delay);
  • All administrators must sign an agreement that sets out their responsibilities including the protection of Government information, and the use and protection of their identity credential;
  • Administrators responsible for applications processing High Sensitivity transactions must have an OPS Personnel Screening Clearance or equivalent;
  • Administrator accounts must never be accessed using an insecure computerfootnote 4 ;
  • Appropriate operational and/or physical security measures must be in place to protect administrative consoles and/or management networks, as required by the applicable Government standards and policies. In high-risk situations, consideration should be given to organizational and/or physical separation of administrators from other staff;
  • Direct operating system access to application components (e.g., web servers, business logic) and management interfaces must be provided via VPN and/or a management segment of the network;
  • Application development staff should not be granted administrative/privileged access to production systems; and
  • Auditors should be provisioned with unique accounts, with access restricted to the minimum needed to conduct audits.

2.5. Development environment

Development and test environments must be managed in a manner consistent with GO-ITS 25.0 General Security Requirements. Application development must be managed in a manner consistent with the GO-ITS 54.0 Application Development Standard.

Information stored and/or processed within a development environment must be appropriately classified according to the Government of Ontario’s information sensitivity classification Policy and associated guidelines.

Must avoid the use of sensitive information in accordance with Government of Ontario’s information sensitivity classification Policy and associated guidelines for test and development instances; where this is not technically feasible, determine exposure via risk assessment, and deploy an appropriate mitigation technique (e.g., additional safeguards, data masking, strong industry de-identification techniques, etc.).

Privileged accessfootnote 5 to the development environment for a given application must be restricted to authorized individuals (developers) as assigned by the Cluster Chief Information Officer (or his/her delegate).

Access to the development environment must be terminated when no longer needed (e.g., by next business day). Termination of access must be immediate and without delay in instances involving sensitive information (e.g., dismissal of an employee developing a High Sensitivity application).

The development team must be aware of and adhere to the I&IT Security Directive, the Freedom of Information and Privacy Directive, Government of Ontario information sensitivity classification Policy and associated guidelines, the security requirements set out in this standard, other Government policies and standards, and applicable industry best practices (see References in this document).

Development staff must understand the development environment (e.g., software development tools) and the development process (e.g., system and software development life cycles, change control, testing, secure software design and coding best practices). For more information on secure development practices, see sections 5.1 and 5.2 in the Appendix of this document.

The software supporting the development environment should be kept current. In particular, updates to address serious security issues must be promptly tested and applied.

If a Threat/Risk Assessment (TRA) determines that the development environment presents unacceptable risk, consideration should be given to additional security measures, such as:

  • OPS Personnel Screening Clearancefootnote 6for development staff;
  • Physical separation of development staff from other staff (e.g., additional physical access controls);
  • Increased use of approved cryptography to protect sensitive material;
  • Separation of duties within the development team and more restrictive access controls; and/or
  • Independent security audit/review and testing of application code.

2.6. Authentication requirements

Minimum requirements

Web Applications providing access to sensitive information (as determined by the Government of Ontario information sensitivity classification Policy or a TRA) must authenticate individuals (e.g., clients, users,  or authorized administrators).

The authentication mechanism for a Web Application that provides access to sensitive information must at a minimum:

  • Enforce GO-ITS 25.0 access control and password requirements, and other requirements from applicable Government standards and best practices;
  • Protect identity credentials as High Sensitivity information as per applicable Government standards and policies;
  • Ensure the identity credentials for the authentication process are not stored by the browser (e.g., client cache);
  • Never confirm valid usernames, responding to incorrect username and/or password input with the same error message;
  • Lock out accounts temporarilyfootnote 7 (e.g., for 30 minutes) after a maximum of five consecutive incorrect password attempts;
  • Capture failed authentication attempts in security logs (the attempted password must not be logged, with logged usernames protected as they may contain password information);
  • Create a session key to authenticate subsequent data transmissions in the session;
  • Reject credentials that have expired or have been revoked by the issuing organization; and
  • Support a secure method to recover identity credentials.

The authentication mechanism should also:

  • Generate an alert for immediate follow up if more than one account is locked out within a short time; and
  • Include protection against automated brute force attacksfootnote 8.

Authentication mechanisms controlling access to Medium or High Sensitivity information must be of a strength and assurance level commensurate with the confidentiality and integrity of the information presented (or the transactions enabled) by the application. Additional safeguards beyond these requirements should be used if needed by a program to address unacceptable risk identified by a relevant TRA. These requirements also apply to system and device authentication, where deployed.

OPS and service partner user roles

Web Applications must authenticate usersfootnote 9. OPS users dealing with High Sensitivity information, and all non-OPS users dealing with sensitive information, must sign an agreement that sets out their responsibilities including the protection of Government information, and the use and protection of their identity credential.

For OPS users dealing with High Sensitivity information, a process or technology should be in place to verify that a secure computer is being used (e.g., a Government-provided computer that is properly maintained, has an approved system image and build, and has approved security safeguards in place).

Administrator roles

Before gaining access to his/her account, the identity of an administratorfootnote 10 must be authenticated using a unique electronic credential issued in accordance with applicable Government standards and policies.

Administrators must use secure computers when managing applications to limit exposure to attacks against local clients, or second-order injection attacks. A process or technology should be in place to verify that a secure computer is being used for management activity.

2.7. Session management

Session management is a key component of secure Web Applications. The following requirements apply to session management implementations:

  • A unique session identifier must be securely created after the individual is successfully authenticated;
  • The session identifier (e.g., session token, key, or string) must be strongly and reliably associated with the session in a way that resists attacks against the session management function;
  • Session identifiers must not contain sensitive information;
  • Session identifiers must not be predictable, readily reverse-engineered, or susceptible to a brute-forcefootnote 11 attack;
  • The integrity and authenticity of a session identifier received via the Internet must be securely verified (i.e., through the use of an approved cryptographic hash algorithm that includes the session identifier and a secret session key value);
  • The application must not leave behind sensitive and/or personal information on the user/client’s computer (e.g., in a cache or cookie) upon termination of a sessionfootnote 12 . The user/client’s browser should be forced to discard web pages from the cache (i.e., by setting an aggressive expiry date);
  • A logout facility must be provided to deactivate the session. A reminder should be displayed to remind users of the importance of promptly logging out when access is no longer required;
  • Sessions must be subject to an inactivity timeout (recommended to be no longer than 20 minutes) to reduce the chance of an abandoned active session being exploited by an attacker. Shorter inactivity timeouts should be used depending on the risks involved and the sensitivity of the information related to the transactions;
  • Input supplied by the client (e.g., via a browser) can never be assumed valid or correct, and must be validated;
  • The session identifier should be passed to and from the user/client computer in a manner that will not result in inadvertent disclosure of the value(s) in use (i.e., the identifier should not appear in the URL itself);
  • Session information saved on the user/client’s computer should be kept to a minimum (i.e., ideally only the session identifier); and
  • Session state information should be retained within business logic when possible (i.e., information retained on the web server should be kept to the absolute minimum), and deleted upon termination of the session.

2.8. Access control and authorization

Web Applications must employ access control techniques in a manner consistent with GO-ITS 25.0 access control requirements.

Access to applications

  • Centrally managed access controls must be in place to ensure that administrators, users and clients only have access to application functions and program information that are authorized for their specific duties and privileges.
  • If a common mechanism is used to control access to applications from different ministries/program areas, the management of administrator, user and client accounts must be securely segmented such that a given ministry/program area manages the access controls for their own application(s).
  • The access control process must be subject to a vulnerability assessment and penetration test prior to implementation and when there is a change with security implications.
  • Internet users must not be allowed to browse directory listings for file content directlyfootnote 13, and should be prevented from viewing server-side scripts and active content.
  • Programs should establish a policy to govern administrator, user and client access to program information and application functions based on the sensitivity of these resources.
  • A role/rules based authorization model should be used. The roles, associated access rights and privileges, and the process for their administration should be formally documented and approved by the Program Manager.
  • Prior to defining access controls for a new application, Programs should adjust the assignment of duties and privileges to address processing requirements and any unacceptable security and privacy risks relating to insufficient separation of dutiesfootnote 14.
  • Consideration should be given to re-authenticating individuals prior to providing access to more sensitive content/functions or completing a transaction.
  • The resources allocated to individual sessions should be limited to guard against denial of service attacks. Higher resource limits should apply for authenticated and authorized individuals.

Access to databases and back-end systems

  • There must be no direct traffic from a web server to a data server (e.g., only the application server should communicate directly with the data server), unless the configuration is described as permissible according to GO-ITS 25.11 Security Design Requirements.
  • Users and clients must never have direct access to a database (e.g., all user/client access must be via the appropriate application), unless the configuration is described as permissible according to GO-ITS 25.11 Security Design Requirements. Administrator sessions must be restricted to the minimum access needed to fulfill their responsibilities.
  • An application’s access privileges for back-end systems or databases must be restricted to the minimum required for the application’s successful operation.
  • An application’s credentials and its authentication and access commands must be protected in accordance with the Government of Ontario’s information sensitivity classification Policy.
  • All privileged access to databases and back-end systems must be subject to monitoring and audit.

2.9. Logging

Logging capabilities and practices for Web Application components must be consistent with those described in GO-ITS 25.0 General Security Requirements. In addition to those requirements, the following are specific to applications:

  • Servers must be configured to send all logs to centralized logging servers located on secure management network;
  • Logs must be available for on-line review for a minimum of 6 months;
  • Server logs must be classified as per the Government of Ontario’s information sensitivity classification Policy;
  • Archived logs must be maintained for 2 years and safeguarded based on the Government of Ontario’s information sensitivity classification Policy and associated guidelines;
  • Archived logs must be made available for on-line review within 7 days;
  • Three or more invalid access attempts within 60 seconds must generate an alarm;
  • Logs must be reviewed daily for intrusion and attack attempts; and
  • Privileged account activity must be captured in secure audit logs.

2.10. Time synchronization

All servers associated with Web Applications must obtain or synchronize system time with a redundant and validated reference time source in accordance with GO-ITS 25.0 General Security Requirements.

2.11. Cryptography

Cryptography must be used to protect sensitive information as required by applicable Government standards and policies, or as described in TRA recommendations. This includes transport security for information in transit.

Cryptography deployed for the purpose of protecting Web Applications or Government of Ontario information must comply with the requirements described in GO-ITS 25.12 Use of Cryptography.

The technology used to protect web sessions from interception must be enforced by the application, such that clients cannot negotiate or request unapproved methods of cryptography (e.g., transport encryption that does not comply with published requirements).

A managed certificate issued by an approved Certificate Authority must be used for secure Web Application sessions operated on behalf of the Government of Ontario.

2.12. Data validation

Data received by the application from all potential sources of input (e.g., all input/text fields, hidden fields, URL contents, client-submitted values such as HTTP_REFERER, cookies, etc.) must be validated to protect against a broad range of attacks (e.g., insertion of HTML, XML, Javascript, SQL queries, system commands, buffer overflows, cross-site scripting, directory traversal attempts, etc.).

Input data must be validated at the earliest opportunity on the server sidefootnote 15 before being processed elsewhere within a Web Application.

The validation should take place against a positive specificationfootnote 16 of what is allowed (e.g., data encoding methods, data type, allowed character set, syntax, minimum and maximum length, numeric ranges, specific values or patterns allowed, etc.).

Bound, parameterized views and parameterized statements should be used wherever possible, and client-submitted information must not be directly passed to command execution or SQL queries. For more information, refer to section 5.1 and 5.2 in the Appendix of this document.

2.13. Error handling

A structured error handling approach must be used to minimize information disclosure in production environments. When these applications encounter processing errors, they must respond to the user/client with a generic, sanitized message with no information that might be useful to an attacker.footnote 17  Developers must test the production error handling prior to deploying the application.

3. Related standards

3.1. Impacts to existing standards

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

GO-IT StandardImpactRecommended action
---

3.2. Impacts to existing environment

Impacted infrastructureImpactRecommended action

Web application/business logic environments and systems supporting Internet transactions

Mandatory alignment with the requirements of this document will increase the degree of rigour, risk management, and review associated with developing and deploying related software

Compliance with the standard is recommended due to the current level  risk and impact associated with compromise of Web Applications

4. Appendices

4.1. Developer guidance

Web Application security requires that applications be protected using safeguards and security services (e.g., authentication). Such protected applications then must be free of flaws and vulnerabilities in related source code. The guidance presented in this section addresses these requirements.

The guidance presented in this appendix is intended to assist in addressing both the security vulnerabilities most often observed during Government of Ontario audits and those typically documented in ongoing projects such as the Open Web Application Security Project (OWASP) initiative.

The technical guidance provided will address insecure programming techniques (e.g., security flaws or vulnerabilities) which make Web Application source code vulnerable to subversion or attack. In particular, the guidance is intended to assist developers in protecting applications from the following documented types or classes of known attack:

  • Logic weaknesses;
  • SQL and command injection;
  • Cross-site scripting (XSS);
  • Cross-site request forgery (CSRF);
  • Application integrity corruption;
  • Information leakage;
  • Insecure communication;
  • Insecure use of cryptography; and
  • Runtime resource depletion.

Existing GO-ITS 25 series documentation will provide developers and Program Managers with additional guidance for functional, policy, compliance and system design requirements.

4.2. Application design guidance

The following guidance is provided to assist developers with the secure design of Web Applications.

4.2.1. Secure login / authentication

Article Code: WAS-08

Related Standards: WAS-07
References: OWASP 2007 Top Ten: A7; OWASP 2010 Top Ten: A3; OWASP 2013 Top Ten: A2

Article statementAuditable criteriaComments

A secure authentication mechanism will be implemented.

  • Use central, managed authentication mechanisms where possible.
  • Always start the login process from an encrypted page.
  • Create a new session for the login process, either after a successful authentication or a privilege-level change.
  • Create a logout link on every page, and use a timeout period to force session expiry.
  • Invalidate the session upon logout or forced expiry. For applications that handle sensitive information, consider invalidating the session if logins from multiple clients are detected.
  • Apply a one-way hash for answers to security questions.
  • Do not store session identifiers or passwords in the logs.
  • Validate the existing password when the user attempts to set a new one.
  • Do not use IP addresses, HTTP_Referer headers, or similar items as a sole form of authentication.
  • At a minimum, enforce GO-ITS 25.12 compliant transport security for the authentication process.

This standard addresses insecure login issues by defining a secure login scenario.

.NET specific recommendations:

  • Use Forms Authentication mechanisms.
  • Encrypt and sign the forms authentication tickets.
  • Enforce absolute ticket expiration.
Article (Standard) Code: WAS-05

Related Standards: WAS-07
References: OWASP 2007 Top Ten: A5, A7; OWASP 2010 Top Ten: A3, A5; OWASP 2013 Top Ten: A6, A8

Article statementAuditable criteriaComments
Runtime user authentication and session validation will be performed within applications dealing with sensitive information, or where a TRA has documented enhanced integrity requirements.
  • Confirm user credentials and re-validate sessions during runtime, particularly prior to performing a transaction or executing actions.
  • Use transaction signing to validate a user’s identity.
  • Use additional authentication mechanisms, other than the initially supplied ID and password, in order to validate a user’s identity.
User authentication and validation at the beginning of the session is not sufficient. An attacker can implement different kinds of impersonation attacks and gain access to the system in the guise of a legitimate user.

.NET specific recommendations:

  • Use wildcard mapping mechanisms to integrate ASP.NET security with classical ASP pages.

Java specific recommendations:

  • Use Container-managed Security in conjunction with programmatic security.
Article (Standard) Code: WAS-06

Related Standards: WAS-07
References: OWASP 2007 Top Ten: A5, A7; OWASP 2010 Top Ten: A3, A5; OWASP 2013 Top Ten: A6, A8

Article statementAuditable criteriaComments
A user will be re-validated with data not automatically supplied by the user’s browser.
  • Insert a custom random token into any form and URL that will not be automatically submitted by a browser (e.g., in a field or parameter that is not visible).
  • Use only POST methods to process sensitive data.
  • Data supplied by a browser cannot be considered as a reliable proof of a user’s identity. A user’s computer can be compromised, and previously proved credentials become vulnerable to abuse.

.NET specific recommendations

  • Set a ViewStateUserKey to emulate a random token associated with the current page.

Java specific recommendations

  • Use the Java Packages Random API or UUID to create random session tokens or IDs.

4.2.2. Secure Session Management

Article Code: WAS-07

Related Standards: N/A
References: OWASP 2007 Top Ten: A5, A7, OWASP 2010 Top Ten: A3, A5, OWASP 2013 Top Ten: A6, A8

Article statementAuditable criteriaComments
Strong session management mechanisms will be implemented.
  • Use the built-in session management mechanism.
  • Do not accept a new, preset, or invalid session identifier.
  • Session IDs are to be unique and unpredictable.
  • Secure session cookies are temporarily stored in the browser’s temporary memory, and not on the hard disk.
  • Secure session cookies contain an attribute indicating that the cookies can be sent over a secure/encrypted (HTTPS) connection.
  • Define the scope of the cookie to be as narrow as possible.
  • Set the HttpOnly flag.
  • Session IDs are valid only for the length of the session.
  • Session timeouts are enforced for inactive sessions.
  • Persistent cookies are not used.
  • Where platforms permit, avoid including session identifiers directly in URLs.

.NET specific recommendations

  • Do not store sensitive data in a session state object.
  • Start using session state only after a user’s logon.
  • Keep session cookies in memory, if possible. If not, give each application its own session state database.

4.2.3. Input Validation

Article Code: GS-06 Data Input Validation

Related Standards: SQL-02, GS-03
References: OWASP 2007 Top Ten: A1, A2, A5; OWASP 2010 Top Ten: A1, A2, A5; OWASP 2013 Top Ten: A1, A3, A8

Article statementAuditable criteriaComments

A secure input validation mechanism will be implemented.

  • The input validation mechanism cannot be bypassed.
  • The input validation mechanism covers all channels of data input.
  • Responses to errors will not disclose sensitive data or technical details.

.NET specific recommendations:

  • For data placed into a hidden “Viewstate” field, make sure that data integrity has been verified through all hierarchical sets of .NET framework.
  • Avoid placing sensitive information in a Viewstate field. If this is not possible, use encryption to protect any sensitive data placed into Viewstate field.

Java specific recommendations:

  • Add validation logic to HttpServletRequest.

4.2.4. Secure Error Handling

Article Code: GS-02 Error handling

Related Standards: IL-02, IL-06
References: OWASP 2007 Top Ten: A6; OWASP 2010 Top Ten: A6; OWASP 2013 Top Ten: A6

Article statementAuditable criteriaComments

A secure application-error-handling mechanism will be implemented that will:

  • Capture application and system errors;
  • Communicate an error to users without revealing details about the system and technology;
  • Restore the system to its default secure state;
  • Record non-sensitive error-related data in the error log; and
  • Shutdown the application securely.
  • Design and implement a strategy to address system failure.
  • Design and implement two sets of error messages: one for end users, and another for technicians.
  • Ensure that messages sent to users do not contain technical details.
  • Ensure that error messages are consistent across the system.
  • Ensure that all resources are released before system shutdown.
  • Avoid caching sensitive information. Ensure that any sensitive information has been erased from all temporary media (e.g., cache memory, temporary files) before shutdown.
  • Ensure that system error and exception related data is sent to and stored in the error log, and that sensitive information is not included.
  • An error-handling mechanism is required to manage and document failures caused by the software or system errors.
  • An inadequate mechanism may facilitate attacks, or may be exploited by an attacker as a means to compromise system security.
Article Code: GS-03

Related Standards: IL-06
References: OWASP 2007 Top Ten: A6; OWASP 2010 Top Ten: A6; OWASP 2013 Top Ten: A6

Article statementAuditable criteriaComments

A secure user-error-handling mechanism will be implemented that will:

  • Capture user errors in data input or the functions menu;
  • Respond to a user error without revealing details about the system and technology; and
  • Record error-related data in an audit log.
  • Deny all invalid user-input values, and prompt users to try again.
  • Commit only valid inputs to storage.
  • Ensure that error messages do not contain technical details.
  • Incorrect data can be crafted purposely in order to break into the application, or to collect technical details about the system.
  • Therefore, an inadequate error-handling mechanism may facilitate an attack, or may be exploited by an attacker to compromise system security.
  • Sensitive information may be disclosed as a part of the error messages presented to the end user.

4.2.5 Strong Authorization/Access Control

Article Code: PCI-13

Related Standards: GS-01
References: OWASP 2007 Top Ten: A3; OWASP 2010 Top Ten: A3; OWASP 2013 Top Ten: A2

Article statementAuditable criteriaComments

All system components will be covered by access control.

Access control is established for:

  • Application;
  • Databases;
  • Middleware;
  • Communication and connectivity objects; and
  • Any other objects that compose the application architecture.

.NET specific recommendations:

  • Use the Membership, SQL Membership Provider and Active Directory Membership Provider features if access control is not managed by another service.
Article Code: GS-01

Related Standards: GS-04
References: N/A

Article statementAuditable criteriaComments

Access control mechanisms will be:

  • Granular enough to be relevant to data sensitivity;
  • Policy-based;
  • Centralized at a single point;
  • Invoked on every access request;
  • Mandatory, so it cannot be avoided;
  • Reliable in that its operation cannot be subverted by hostile parties; and
  • Auditable.

Deploy access control mechanisms that:

  • Protect each asset with a mechanism that is relevant to business and security requirements;
  • Control all possible channels of internal and external communications with applications;
  • Validate entity identities and access privileges as early as possible (e.g., at the first call);
  • Re-validate entity identities and access privileges periodically during runtime, or in a continuous/ongoing fashion if possible;
  • Use the least privilege concept when invoking an application or a local service (e.g., start services using a service account with carefully chosen rights);
  • Use organizational controls, such as segregation of duties;
  • Use default deny as the default setting; and
  • Access control policy will cover not only application users but also application data/objects.

The access-control mechanism will be strong enough to provide sufficient protection of data and application functionality. Inadequate access controls open the door to a number of attacks.

.NET specific recommendations:

  • Use Role Manager features.
  • Connect to the database server by using an assigned least privilege account, not the sysadmin account.
  • Use SQL Client Permission Attribute to ensure that a client has a required security level.
  • Use Registry PermissionAttribute to limit access to registry keys.
  • Use Zones to isolate applications.

4.2.6. Secure Audit/Event Logging

Article Code: GS-04

Related Standards: GS-01
References: N/A

Article statementAuditable criteriaComments

Implement a secure user-event auditing mechanism that will:

  • Capture auditable events;
  • Collect related data and store it in the logs;
  • Ensure log integrity;
  • Ensure the confidentiality of sensitive data recorded in the logs; and
  • Provide analytical and reporting functions.
  • User event audit logs capture events of the:
  • Introduction of objects;
  • Deletion of objects;
  • Distribution or revocation of access rights or capabilities;
  • Changes to subject or object security attributes;
  • Policy checks performed by the security software;
  • Use of access rights to bypass a policy check;
  • Use of identification and authentication functions;
  • Security-related actions taken by an operator/user; and
  • Import/export of data from/to removable media.
  • Audit logs are stored on a system intended to receive and protect logs.
  • Protect the integrity, confidentiality and availability of audit logs.
  • Do not store sensitive data in the audit logs unless absolutely necessary, and document/justify the need to store sensitive data in the audit logs (e.g., in a TRA and/or a PIA).
  • Encrypt sensitive data if storing this information in logs cannot be avoided.
  • Ensure implemented logging is adequate to support forensic activities.
  • Ensure backup and restore procedures are in place for log information.
  • Audit logs contain valuable information that can be exploited by an attacker. Therefore, the protection, integrity and confidentiality of the logs is of great importance.
  • Log detail and integrity will be sufficient to support forensic activities in the event of security incidents.
  • Separate application and system logs from audit logs.

4.3. Application development guidance

The following guidance is provided to assist developers in writing secure Web Applications:

4.3.1. Enforce application logic

Application logic that resists subversion and maintains strong internal rules will be more resilient when attacked. Application logic that provides attackers with a way to induce errors or unanticipated results may be vulnerable. Such attacks include:

  • Bypassing access control mechanisms;
  • Bypassing data validation mechanisms;
  • Obtaining unauthorized access to information and/or I&IT assets;
  • Unauthorized elevation of system privileges;
  • Redirection of legitimate users to illegitimate and/or malicious sites; and
  • Resource depletion/Denial of Service.

Logic errors can occur when decision making routines have been incorrectly implemented (or are not complete). They may also be the result of poor presentation of data to the decision-making routine. Such weaknesses can be controlled by careful development of decision making blocks and data presentation to such routines.

Article Code: COR-01

Related Standards: GC-01, GC-06
References: N/A

Article statementAuditable criteriaComments

Test for a positive result / success when verifying error conditions.

A decision-making block that is constructed to test for successful completion (where the conditions for success are known and all other cases are treated as failures) can help resist attacks against logic components.

Proceed with data processing if, and only if, the required condition of proceeding is true and validated. Avoid using exceptions as a flow control technique.

Article Code: COR-02

Related Standards: GC-01, GC-06
References: N/A

Article statementAuditable criteriaComments

When the conditions are specified as a logical combination of atomic terms connected by AND/OR operators, ensure that combinations are presented as the logical conjunctions.

  • Define a matrix that contains the combinations that will lead to data processing, and determine the system behaviour for each particular combination.
  • Each line of the matrix should combine items joint with AND only; each OR should produce separate line of the matrix.
  • To deter attack against decision-making routines, write the control block that verifies each combination for success, and direct all negative results to an appropriate error handling mechanism.

Java specific recommendations:

  • Verify security context for the business helper classes when they are called by more than one Enterprise Java Bean.
Article Code: COR-03

Related Standards: GC-01
References: N/A

Article statementAuditable criteriaComments

Check returning state when calling a subroutine.

  • Check returning state for success.
  • Do not return references to internal objects unless necessary. For applications handling sensitive information, return a duplicate copy of mutable objects so the caller cannot change the object state.

N/A

Article Code: COR-04

Related Standards: GC-02
References: N/A

Article StatementAuditable criteriaComments

Implement loop control

  • Define loop boundaries clearly, and do not set infinite loops.
  • Define system behaviour for a loop control variable being inside, outside, or on a boundary.
  • Avoid modifying outer loop indices from inner loop update expressions.

N/A

4.3.2. Ensure correct presentation of data

Article (Standard) Code: COR-05

Related standards: SQL-02
References: N/A

Article statementAuditable criteriaComments

Resolve canonicalization issues when verifying resource names.

  • Input should be canonicalized by the first component that accepts the input, and make canonical representation before any action is taken.
  • Avoid making decisions based on file names. When required (and where possible), have an operating system make the decision and do not handle files directly.
  • Define file names and conventions, and use a regular expression to restrict what is allowed in such names. Always validate the entire filename, and ensure it is valid from the beginning to the end of the request.
  • Do not rely on a PATH environment variable to locate files; always use full path names to data and executables. Attackers may be able to manipulate such variables.
  • Do not use the PATH environment variable to find files. Always use the full path names to your data and executable files.
  • Canonicalize names in order to get as close as possible to the file system’s representation of the file. Verify that the filename refers to the file itself, and not to a device or a link.
  • Define the canonical versions of server/host names and validate all names against this list.
  • Use the canonical username to validate user accounts; for the Windows platform, this will be the SAM (Security Account Manager) name.
  • Avoid double decoding of data.
  • Canonical representation issue relates to the ability of presenting resource names in various equivalent forms. The problem occurs when an application makes wrong decisions based on a non-canonical representation of a name. Variances not always are captured by the software.
  • On Windows platforms, do not generate 8.3 filenames (this requires a host configuration change) and avoid auto-generated 8.3 filenames.

.NET specific recommendations:

  • Use .NET Framework for regular expression support.
  • Use encoding statement controls.
  • Do not assign form fields data directly from the Request object: username.Text = Request.QueryString(“username”).
  • Understand which .NET controls automatically encode output data.

Java specific recommendations:

  • Use the chroot option to confine valid files on platforms that support it.
Article Code: COR-06

Related standards: SQL-02
References: N/A

Article statementAuditable criteriaComments

Resolve internationalization issues when verifying resource names.

  • Use Unicode and do not convert between Unicode and other code sets.
  • Use standard libraries to handle Unicode regular expressions.
  • Use a Character Map to determine which characters are valid.
  • Multi-language applications use non-ASCII fonts that may be misused to construct invalid names.
  • Use Create File to validate filenames.
  • Use IsNLS Defined String function to validate Unicode strings.

.NET specific recommendations:

  • Use .NET Framework for globalization support.

4.3.3. Prevent malicious injection

Malicious injection is one of the leading causes of preventable information breaches and system compromises. Protection from this attack vector is critical for all Web Applications. Control over malicious injection will be addressed, including the following widely-documented injection types:

  • SQL injection;
  • Shell (e.g., session and command execution) injections; and
  • Directory services (e.g., LDAP) injections

Detailed standards: SQL-01, SQL-02, SQL-03, SQL-04, SQL-05, SQL-06.

Article Code: SQL-01

Related Standards: N/A
References: OWASP 2007 Top Ten: A1, A2, A5; OWASP 2010 Top Ten: A1, A2, A5; OWASP 2013 Top Ten: A1, A3, A8.

Article statementAuditable criteriaComments

All channels of data input will be guarded with data-validation mechanisms.

  • Perform data validation for all channels of data input, such as:
  • The user interface;
  • HTTP parameters; and
  • Flat files sent by e-mail or FTP.
  • User-supplied data may contain malicious content that can be passed, interpreted, and executed by the system.
  • There cannot be any available data input channel that does not enforce data validation.
Article Code: SQL-02

Related Standards: N/A
References: OWASP 2007 Top Ten: A1, A2, A5; OWASP 2010 Top Ten: A1, A2, A5; OWASP 2013 Top Ten: A1, A3, A8.

Article statementAuditable criteriaComments

Strong data input validation will be performed.

  • Always perform data input validation on the server, even if it was already performed on the client side (e.g., within the browser).
  • Design specific data input validation procedures that match the business rules.
  • Disallow unlimited data strings.
  • Validate the data type and format, and verify data completeness and consistency. All special characters will be validated.
  • Block any invalid or incomplete pieces of data, and never attempt to interpret them. They will be returned to the user or discarded.
  • Use a white-list policy (e.g., permit valid characters only) to validate data and never rely on a black-list policy (e.g., attempting to block invalid characters).
  • Validate XML documents and objects against an XML Schema.
  • Validate input data at least twice; once as close to the origin as possible and again immediately before parsing or taking action.
  • Data input validation should be specific in order to secure the system from injection attempts.
  • Failure to include data validation mechanisms are trivial for attackers to discover and exploit.
Article Code: SQL-03

Related Standards: N/A
References: OWASP 2007 Top Ten: A1, A2, A5; OWASP 2010 Top Ten: A1, A2, A5; OWASP 2013 Top Ten: A1, A3, A8.

Article statementAuditable criteriaComments

Do not pass dynamically crafted statements to an interpreter, and avoid creating them.

  • Never insert user-provided input or data into or as an SQL query.
  • All submitted strings are escaped and any submitted parameters are bound to SQL using bind variables.
  • Bound, static or parameterized statements for code-level crafted queries should only be used if absolutely necessary. Enforce strict syntax and suppress/quell special characters at a minimum.
  • For SQL statements, use bound, parameterized views whenever possible.
  • Statements that are crafted with the use of data input in real time are an easy target of injection attacks. Both command injection and SQL injection attacks can be constructed with the use of parameterized statements. An interpreter is unable to recognize malicious parts of input data.
  • Consider the use of stored procedures or other methods to maintain data-binding (e.g., ADO.NET Entity Framework).

.NET specific recommendations:

  • Use strongly-typed parameterized queries, such as SqlCommand with SqlParameter.

Java specific recommendations:

  • Use Object-relational mappings (ORMs).
  • Ensure all native queries are correctly escaped, and do not contain user input.
  • Ensure ORM calls which translate to dynamic queries are re-written as bound parameters.
Article Code: SQL-04

Related Standards: N/A
References: OWASP 2007 Top Ten: A1, A2, A5; OWASP 2010 Top Ten: A1, A2, A5; OWASP 2013 Top Ten: A1, A3, A8.

Article statementAuditable criteriaComments

The use of special characters in input obtained from or submitted by a user will be minimized.

  • Developers should be aware of potential dangers regarding special characters, and employ techniques to avoid them.
  • Create a complete inventory of allowed special characters together with the business rules that direct their usage. Use filtering functions to strip all disallowed characters from input.
  • Develop specific data input validation procedures.
  • Favour using API calls instead of calling commands via the shell, avoiding interpreters.
  • Customize the white list of allowed meta-characters to make it language and technology specific. Do not use generic lists.
  • Do not rely on a language’s generic meta-character filter.

Malicious content injected into data input always starts with a special character that is required by an interpreter in order to initiate interpretation (and subsequent attack, e.g., execution or exfiltration).

Article Code: SQL-05

Related Standards: N/A
References: OWASP 2007 Top Ten: A1, A2, A5; OWASP 2010 Top Ten: A1, A2, A5; OWASP 2013 Top Ten: A1, A3, A8.

Article statementAuditable criteriaComments

User-data input will not be copied into application-generated data (such as audit logs or reports) without being pre-processed.

  • Perform data-output validation the same way as with data-input validation, if possible. Consider “second order” attack techniques.
  • Encode special characters. Neutralize and escape user data.

When malicious content is planted in data input and stored into a file, there is a chance that it will be interpreted and executed at a later time. Process input to avoid these attacks.

Article Code: SQL-06

Related Standards: N/A
References: OWASP 2007 Top Ten: A1, A2, A5; OWASP 2010 Top Ten: A1, A2, A5; OWASP 2013 Top Ten: A1, A3, A8.

Article statementAuditable criteriaComments

Inputs will be decoded and canonicalized before they are validated.

  • Decode data and canonicalize its location just before applying the data-validation mechanism.

Having no precautions about the data-input’s original location may result in duplicated encoding, and in bypassing the validation.

4.3.4. Prevent cross-site scripting

Controls should prevent the ability to construct cross-site scripting attacks against an application.

This weakness is well-understood, widely/easily exploited and is listed in the OWASP 2007, OWASP 2010 and OWASP 2013 Top Ten.

Detailed standards: XSS-01, XSS-02, XSS-03, XSS-04.

Article Code: XSS-01

Related Standards: GS-03, SQL-01, SQL-02
References: OWASP 2007 Top Ten: A1, A5; OWASP 2010 Top Ten: A1, A5 ; OWASP 2013 Top Ten: A1, A8.

Article statementAuditable criteriaComments

Strong data-input validation will be enforced.

See related standards.

-
Article Code: XSS-02

Related Standards: GS-03, SQL-01, SQL-02, SQL-03, SQL-04, SQL-05, SQL-06
References: OWASP 2007 Top Ten: A1, A5; OWASP 2010 Top Ten: A1, A5; OWASP 2013 Top Ten: A1, A8.

Article statementAuditable criteriaComments

SQL and command-injection protection will be enforced.

See related standards.

-
Article Code: XSS-03

Related Standards: N/A
References: OWASP 2007 Top Ten: A1, A5; OWASP 2010 Top Ten: A1, A5; OWASP 2013 Top Ten: A1, A8.

Article statementAuditable criteriaComments

Special characters will be encoded in the application output.

  • Replace special characters with their HTML equivalents.
  • Convert dangerous symbols, including HTML tags, to their HTML representation. For example, < becomes &lt.
  • Force the codepage, and set it explicitly by specifying the allowable charset.
  • Add double quotes around all tag properties.
  • If a server-application attack is successful, then data output containing special characters can also be misused.
  • Malicious code can be injected into the output and interpreted on a client’s machine, thus infecting the machine.

.NET specific recommendations:

  • Use Microsoft Anti-XSS Library.
  • Understand which .NET controls automatically encode output data.

Java specific recommendations:

  • Use Struts output mechanism such as <bean:write. . .>, or use the default JSTL escapeXML=”true” attribute in <c:out…>.
  • Do not use <%=….%> unnested (that is, outside of a properly encoded output mechanism.

4.3.5 Prevent cross-site sequest forgery

Controls should prevent the ability to construct cross-site request forgery attacks against an application.

This weakness is listed in the OWASP 2007, OWASP, 2010 and OWASP 2013 Top Ten.

Detailed standards: CSRF-01, CSRF-02

Article Code: CSRF-01

Related Standards: XSS-01, XSS-02, XSS-03
References: OWASP 2007 Top Ten: A5; OWASP 2010 Top Ten: A5; OWASP 2013 Top Ten: A8.

Article statementAuditable criteriaComments

Cross-Site Scripting protection will be enforced.

See related standards.

-
Article Code: CSRF-02

Related Standards: WAS-06
References: OWASP 2007 Top Ten: A5; OWASP 2010 Top Ten: A5; OWASP 2013 Top Ten: A8.

Article statementAuditable criteriaComments

A transaction request will be re-validated with the data that are not automatically supplied by a user browser.

  • Insert a custom random token into any form and URL that will not be automatically submitted by a browser.
  • Use only POST methods to process sensitive data.
  • Use transaction signing for sensitive data transactions.
  • Data supplied by a browser cannot be considered as a reliable proof of a user’s identity. A user’s computer can be compromised, and previously proved credentials become invalid.

.NET specific recommendations:

  • Build .NET CSRF Guard [1]

J2EE specific recommendations:

  • Build J2EE CSRF Guard [2]

4.3.6. Prevent Sensitive Information Leaks

Information leakage can provide attackers with valuable information or aid in the planning of attacks. Controls should prevent the leak of sensitive information via an application. All potential channels of information leakage should be addressed, including:

  • Application memory;
  • Application code; and
  • Application-generated output.
  • Detailed standards: IL-01, IL-02, IL-03, IL-04, IL-05
Article Code: IL-01

Related Standards: IL-02
References: N/A

Article statementAuditable criteriaComments

Sensitive data will not be hard-coded.

  • Do not hard-code sensitive data; all values should be populated only during runtime.
  • Immediately after usage, sensitive data values will be erased from all temporary media.
  • Avoid any caching of sensitive information. Encrypt any sensitive information that will be cached.
  • A developer may include sensitive information in source code. This happens most often with passwords or encryption keys. Source-code viewers or even a text editor will reveal the data.
  • Sensitive data may also be seen within binary code when using a hexadecimal viewer.
Article Code: IL-02

Related Standards: N/A
References: N/A

Article statementAuditable criteriaComments

All sensitive data traces will be erased from all media used in real time.

  • Before the memory is released, and where supported, overwrite cache memory segments. Provide a one-by-one overrun for each byte and overwrite each segment at least five times. This cannot be performed on all platform types.
  • Make sure that data is wiped regardless of exit status or exceptions (e.g., positive exit or error exit).
  • Where platform support exists, overwrite application data in temporary files or in page files (particularly for applications handling sensitive information).

Data can remain in cache memory, in temporary files stored on hard disk, or in page files stored on hard disks. Do not assume that transactional or transient data has been removed from the system.

Article Code: IL-03

Related Standards: N/A
References: N/A

Article statementAuditable criteriaComments

Control serialization.

  • If serialization is required, attempt to limit the reach to non-sensitive data.
  • Should the application require the serialization of sensitive data, be aware of the risks of exposure to any code with permission to serialize that data (malicious or otherwise), and possible session state loss for applications upon redundant failover.
  • Unless required, avoid cloning (or make the cloning method “final”).

Prevent data leaks through illegally instantiated objects. Object instantiation should be taken under application control. This control can be lost when a developer applies cloning or serialization techniques without explicitly defined conditions of terminating object instantiation.

Article Code: IL-04

Related Standards: N/A
References: N/A

Article statementAuditable criteriaComments

The visibility of sensitive data objects in memory will be minimized.

  • Avoid packaging sensitive data objects with other types of objects. If this cannot be done, protect all data objects commensurate with the highest level of information sensitivity being processed.
  • Do not give direct access to the sensitive data objects from other classes. Access can be implemented only by using accessor methods owned by sensitive data classes.
  • Avoid placing sensitive data into static or global variables.
  • Make as many elements as possible “private,” and use accessor methods that employ access control where appropriate.
  • Access to objects depends heavily on the pre-defined object properties.
  • Minimize the ability to access the object by secure design and by assigning secure characteristics to objects.
Article Code: IL-05

Related Standards: GS-03
References: N/A

Article statementAuditable criteriaComments

Sensitive information will be excluded from the application-generated data, such as error messages or audit logs.

  • Design and implement two sets of consistent error messages, one for end users and another for technicians.
  • Ensure that messages sent to end users do not contain technical details.
  • Routine communication should not be too verbose, and should not provide details of treating sensitive data.
  • Do not store sensitive data in audit logs without valid and documented reasons. If storage of sensitive data cannot be avoided, encrypt it first.
  • This can occur with application error messages sent to end users, containing technical details intended for technicians. This information is of value when constructing an attack.
  • Common communication with end users also can be vulnerable when it contains information about the system, or provides a clue to the sensitive data type or format, such as the ID and password.
  • Audit-log records often contain sensitive data, such as user passwords or cryptographic keys, thus exposing highly sensitive data to a reader.

4.3.7. Preserve Application Integrity

Controls should ensure that the application code has not been deliberately modified during runtime. Therefore, controls will be applied to an application in terms of the managing application variables (e.g., buffers, arrays, cycles and iterations).

This weakness is listed in OWASP 2007, OWASP  2010 and OWASP 2013 Top Ten.

  • Detailed standards: GC-01, GC-02, GC-06
Article Code: GC-01

Related Standards: N/A
References: OWASP 2007 Top Ten: A2, A3; OWASP 2010 Top Ten: A1, OWASP 2013 Top Ten: A1.

Article statementAuditable criteriaComments

Prevent application memory overrun.

  • The application code should check the method returns.
  • Where platforms permit:
  • Control the size of data to be put into the stack buffer;
  • Control the size of data to be put into the heap buffer; and
  • Control array indexing.
  • Application-memory integrity may be corrupted in many ways. Consider the most common and most exploitable methods, such as:
    • Buffer overflows;
    • Heap overrun;
    • Integer overflow; and
    • Mismatching the Unicode and ANSI buffer sizes.
  • Use the Visual C++ .NET/GS option.
  • Implement safe string handling.
  • Ban unsafe function calls.
  • Use the StackGuard feature or similar functionality.
  • Avoid dynamically crafted values of the “format string” parameter for the printf function.
Article Code: GC-02

Related Standards: N/A
References: OWASP 2007 Top Ten: A2, A3; OWASP 2010 Top Ten: A1; OWASP 2013 Top Ten: A1.

Article statementAuditable criteriaComments

All iterations or any conditional constructs of the code will be restricted by verifiable conditions.

  • Ensure that all iterations are ended.
  • Limit the number of instantiated objects and queued items.
  • Apply resource-request timeouts.
  • The following may be exploited by an attacker to crash an application:
    • Unlimited iterations;
    • Incorrectly defined conditions when stopping an iteration; and
    • Incorrectly defined conditions when exiting a piece of code.
Article Code: GC-06

Related Standards: N/A
References: OWASP 2007 Top Ten: A2, A3; OWASP 2010 Top Ten: A1; OWASP 2013 Top Ten: A1.

Article statementAuditable criteriaComments

An inclusion policy will be followed instead of an exclusion policy.

  • Create a list of acceptable values to be used to check the correctness of values.
  • Do not attempt to predict and suppress/quell undesirable values.
  • Use the if….then….else construct to test for a successful completion, where; the conditions for success are known, and where all other cases are treated as failures and managed accordingly.
  • An inclusion policy verifies the correctness of articles or conditions against known, positive, values. An exclusion policy verifies the incorrectness of items.
  • A list of undesirable characters is difficult to complete and maintain as the number of input items to reject will always increase faster than the number of things to accept.
  • Uncertainty will remain in regards to verified items or conditions.

4.3.8. Ensure correct object access

Controls should ensure that the application resources have been properly managed. That is:

  • Legitimate paths to an application objects are not misplaced;
  • Legitimate object names are not misplaced; and
  • All paths to the objects are controlled and/or mutually authenticated/validated.

This weakness is listed in OWASP 2007, , OWASP 2010 and OWASP 2013 Top Ten.

Detailed standards: GC-04, GC-07, GC-08, GC-09, GC-10

Article Code: GC-04

Related Standards: N/A
References: OWASP 2007 Top Ten: A3, A4; OWASP 2010 Top Ten: A4, A8, A10; OWASP 2013 Top Ten: A4, A7, A10.

Article statementAuditable criteriaComments

Correct file access will be ensured during directory traversal.

  • Store temporary files in the application-specific directory.
  • Run an application under a purposely created account with least privilege rights.
  • Never use a filename for more than one operation. Instead, pass a handle or file descriptor from the first operation to successive function calls.
  • Resolve the path to the file, following symbolic links and any backwards traversals before performing validation on the path.
  • Validate the path and do not rely on environment variables.
  • Lock files when appropriate.
  • Check whether a file is a real file and not a pipe, device, or symlink.

Multiple representation capabilities may be exploited when traversing the directory hierarchy in order to gain unauthorized access to data folders, or to misplace a correct file with a modified or malicious version.

Article Code: GC-07

Related Standards: N/A
References: OWASP 2007 Top Ten: A3, A4; OWASP 2010 Top Ten: A4; OWASP 2013 Top Ten: A4.

Article statementAuditable criteriaComments

Unpredictable (e.g., not from a dictionary) names for named objects will be used.

  • Create and apply a naming convention policy.
  • An attacker can gain access by guessing names – and predictable names are easier to guess. This is especially dangerous when used against connectivity objects.
Article Code: GC-08

Related Standards: N/A
References: OWASP 2007 Top Ten: A3, A4; OWASP 2010 Top Ten: A4, A8; OWASP 2013 Top Ten: A4, A7.

Article statementAuditable criteriaComments

Processes will be created securely.

  • Define explicitly and correctly parameters of the “Create Process” instruction.
  • Do not pass Null for the application name to be called.
  • Control the path to the executable.

Errors or an incomplete definition of the executable path may initiate malicious commands or software instead of a legitimate application.

Article Code: GC-09

Related Standards: N/A
References: OWASP 2007 Top Ten: A3, A4; OWASP 2010 Top Ten: A4, A8; OWASP 2013 Top Ten: A4, A7.

Article statementAuditable criteriaComments

System directories will only be used for originally defined purposes.

  • Do not write user files to the \Program Files folder.
  • Do not write user data to metadata directories.

By putting user data into system data folders facilitates the planting of malicious code and executing attacks.

Article Code: GC-10

Related Standards: N/A
References: OWASP 2007 Top Ten: A3, A4; OWASP 2010 Top Ten: A4, A8; OWASP 2013 Top Ten: A4, A7.

Article statementAuditable criteriaComments

Files will be created securely.

  • Verify the source and file type before opening a file, or calling the “Create File” action.
  • A file name obtained from unknown or unreliable resources could facilitate an attack.
  • Precautions should be taken, particularly when creating temporary files.

4.3.9. Prevent manipulation of objects

Controls should prevent the misplacement of legitimate objects with illegitimate ones crafted to construct an attack. This includes controlling:

  • Access to application objects; and
  • The execution of application modules.
  • This weakness is listed in the OWASP 2007, OWASP, 2010 and OWASP 2013 Top Ten.
  • Detailed standards: WAS-03, WAS-04, WAS-08
Article Code: WAS-03

Related Standards: WAS-04
References: OWASP 2007 Top Ten: A3, A4; OWASP 2010 Top Ten: A4, A8; OWASP 2013 Top Ten: A4, A7.

Article statementAuditable criteriaComments

Malicious file execution will be prevented.

  • Do not use user-supplied inputs in any filename for any server-based resources without validation.
  • The application will only use indirect object references.
  • An attacker can discover lack of validation and/or names of the files.
  • The attacker may attempt to replace legitimate files or pages with malicious ones.
Article Code: WAS-04

Related Standards: N/A
References: OWASP 2007 Top Ten: A3, A4; OWASP 2010 Top Ten: A4, A8; OWASP 2013 Top Ten: A4, A7.

Article statementAuditable criteriaComments

Direct references to internal objects will not be exposed.

  • References to private objects are hidden, such as by indexing, indirect object maps, or any other possible method.
  • Authorize a caller rights to obtain the object.
  • Validate any private object references.
  • Use an inclusion policy for validation.

Direct references provide an easy way to access objects and manipulate them.

Article Code: WAS-08

Related Standards: WAS-04
References: OWASP 2007 Top Ten: A10; OWASP 2010 Top Ten: A8; OWASP 2013 Top Ten: A7.

Article statementAuditable criteriaComments

Access control to all URLs in the application will be enforced.

  • Access control is to be enforced:
  • For all pages designed to provide business functionality;
  • For hidden pages designed to provide administrative or supporting functionality;
  • To block access to all file types that are not served by the application; and
  • To keep executable extensions outside of the root directory

URLs that are not protected by access controls can be discovered and accessed by an attacker.

4.3.10. Secure Use of Cryptography

Controls will be used to ensure the secure use of cryptographic materials and rely on approved/endorsed cryptography. Primarily, encryption keys will be protected by an application to assure:

  • Confidentiality;
  • Integrity; and
  • Validity.
  • This weakness is listed in the OWASP 2007, OWASP, 2010 and OWASP 2013 Top Ten.
  • Detailed standards: DE-01, DE-02, DE-03, DE-04, DE-05, DE-06, DE-07, DE-08, DE-09, DE-10, DE-11, DE-12, DE-13, DE-14.
Article Code: DE-01

Related Standards: N/A
References: OWASP 2007 Top Ten: A8, A9; OWASP 2010 Top Ten: A7, A9; OWASP 2013 Top Ten: A6.

Article statementAuditable criteriaComments

Sensitive data will be encrypted in accordance with approved standards.

  • Cryptographic algorithms and operating modes will comply with Appendix A requirements described in GO-ITS 25.12 Use of Cryptography.
  • All published and/or appropriate encryption key management policy processes and procedures will be followed.

Contact the I&IT Strategy, Policy & Enterprise Architecture Branch (SPEAB) for assistance with GO-ITS 25.12 compliance.

Article Code: DE-02

Related Standards: N/A
References: OWASP 2007 Top Ten: A8; OWASP 2010 Top Ten: A7; OWASP 2013 Top Ten: A6.

Article statementAuditable criteriaComments

Data in rest will be encrypted with the highest possible granularity, relevant to the data’s sensitivity classification.

  • Encryption will be implemented for sensitive data.
  • Data files, folders, or whole-disk encryption can be used to protect data as a batch function. However, if the data includes sensitive items, then field encryption or transparent data encryption (TDE) should be implemented.

Field and transparent data encryption provides reliable protection of sensitive information. File/folder and whole-disk encryption is easier to break.

Article Code: DE-03

Related Standards: N/A
References: OWASP 2007 Top Ten: A8; OWASP 2010 Top Ten: A7; OWASP 2013 Top Ten: A6.

Article statementAuditable criteriaComments

An encryption key will be used for one purpose only.

  • Use different keys for field encryption and bulk/TDE encryption.
  • Use different keys for data encryption and key encryption.
  • Use different keys for data encryption and message encryption.

Use of different keys reduces the impact of a single key compromise, and can reduce an attacker’s chances of compromising sensitive keys.

Article Code: DE-04

Related Standards: N/A
References: OWASP 2007 Top Ten: A8; OWASP 2010 Top Ten: A7; OWASP 2013 Top Ten: A6.

Article statementAuditable criteriaComments

Encryption keys will be protected at the same level or higher as the data.

  • The encryption key storage will be separated from the data storage.
  • Encryption keys will be stored in encrypted form. A key-wrapping key should be used to encrypt keys.
  • Access to the encryption-key storage must be protected with a strong access control mechanism.
  • Access to encryption keys will be managed separately from the operating system’s access control.

Encryption keys are to be classified as and safeguarded according the same Government of Ontario information sensitivity classification Policy and sensitivity designation as the information they are intended to protect.

Article Code: DE-05

Related Standards: N/A
References: OWASP 2007 Top Ten: A8; OWASP 2010 Top Ten: A7; OWASP 2013 Top Ten: A6.

Article statementAuditable criteriaComments

Encryption keys should be labelled.

  • A label should be used to identify attributes, parameters, or the intended use of a key.
  • At a minimum, the label should include:
  • The key type (e.g., data encryption, key encryption, message encryption, master key);
  • The key-usage period, including an originator usage period and a separate recipient usage period;
  • Associations with those applications that are allowed to operate with a key;
  • A key-encrypting key identifier;
  • An integrity protection mechanism; and
  • A key state: (e.g., pre-activation, active, deactivated, destroyed, compromised, expired).

Key labelling helps to verify the correctness, integrity, and validity of encryption keys.

Article Code: DE-06

Related Standards: N/A
References: OWASP 2007 Top Ten: A8; OWASP 2010 Top Ten: A7; OWASP 2013 Top Ten: A6.

Article statementAuditable criteriaComments

Encryption-key validity will be verified by an application before use.

A secure application will verify the attributes and parameters of a key before it is used.

-
Article Code: DE-07

Related Standards: N/A
References: OWASP 2007 Top Ten: A8; OWASP 2010 Top Ten: A7; OWASP 2013 Top Ten: A6.

Article statementAuditable criteriaComments

Encryption-key integrity will be verified by an application before use.

  • The status and integrity of encryption keys will be verified before use. Examples include:
  • Digital signatures;
  • Message authentication codes; and
  • Certificate Revocation Lists (CRLs).
-
Article Code: DE-08

Related Standards: N/A
References: OWASP 2007 Top Ten: A8; OWASP 2010 Top Ten: A7; OWASP 2013 Top Ten: A6.

Article statementAuditable criteriaComments

The integrity of encryption-key associations will be verified by an application before use.

  • Proof of valid encryption-key associations should be verified before use. Examples include:
    • Digital signatures; and
    • Message authentication codes.
-
Article Code: DE-09

Related Standards: N/A
References: OWASP 2007 Top Ten: A8; OWASP 2010 Top Ten: A7; OWASP 2013 Top Ten: A6.

Article statementAuditable criteriaComments

An encryption key will be generated offline.

Key-generation processes should not be present in the application source code.

-
Article Code: DE-10

Related Standards: IL-02
References: OWASP 2007 Top Ten: A8; OWASP 2010 Top Ten: A7; OWASP 2013 Top Ten: A6.

Article statementAuditable criteriaComments

All temporary/transient key material will be destroyed immediately after use.

Key material will be erased from all temporary media used by an application immediately after use. Keys should not be cached or written to media.

Includes all temporary/transient application media, including RAM.

Article Code: DE-11

Related Standards: IL-01
References: OWASP 2007 Top Ten: A8; OWASP 2010 Top Ten: A7; OWASP 2013 Top Ten: A6.

Article statementAuditable criteriaComments

Encryption keys will not be hard-coded.

No encryption key will be found in the source code.

Do not rely on trivial obfuscation.

Article Code: DE-12

Related Standards: IL-06
References: OWASP 2007 Top Ten: A6, A8; OWASP 2010 Top Ten: A7; OWASP 2013 Top Ten: A6.

Article statementAuditable criteriaComments

Encryption keys will not be stored in audit logs.

No encryption keys are to be recorded in audit logs.

Audit logs are often examined by attackers in order to locate sensitive data.

Article Code: DE-13

Related Standards: N/A
References: OWASP 2007 Top Ten: A8; OWASP 2010 Top Ten: A7; OWASP 2013 Top Ten: A6.

Article statementAuditable criteriaComments

Encryption-key storage with an application should implement the split-knowledge concept.

  • The encryption key should be split into two or more parts when it is to be stored if stronger methods are not available.
  • Each part will be encrypted.
  • The key-recovery mechanism should be more complex than simple concatenation.

Key recovery will only be possible when authorized, and should resist unauthorized activities.

Article Code: DE-14

Related Standards: N/A
References: OWASP 2007 Top Ten: A8; OWASP 2010 Top Ten: A7; OWASP 2013 Top Ten: A6.

Article statementAuditable criteriaComments

The memory used for encrypting sensitive data will be protected.

  • Where possible, and where platforms permit, allocate different buffers for plaintext and encrypted information. Erase data traces from the buffers immediately after use, where platforms permit. Be aware that plaintext information may still persist in the heap, to be managed by functions such as garbage collection cycles.

If both types of data are located in the same buffer, then there is a chance that unencrypted data may be leaked due to unforeseen race conditions, inter-process communication, or core dumps.

4.3.11. Control resource consumption

Controls should ensure that the application resources have been properly managed. This requires that:

  • Resources are allocated and released by an application;
  • Resources are managed during all states of an application, including failure states; and
  • All resources are controlled.
  • This weakness can enable other classes of security vulnerability.
Article Code: GC-03

Related Standards: N/A
References: N/A

Article statementAuditable criteriaComments

Resource consumption will be controlled during runtime.

  • Release unused resources once available.
  • Error-handling mechanisms should include such a resource-release feature.
  • Release all types of resources such as memory, data files, communication channels and connectivity objects.

An attacker may use uncontrolled resource consumption to construct a Denial of Service attack, or attempt to broaden an otherwise brief window to more easily exploit a race condition.

4.4. Normative references

GO-ITS 20.1 Platform Software Standard

GO-ITS 24.0 Omnibus Web Services Standard

GO-ITS 25.0 General Security Requirements

GO-ITS 25.11 Security Design Requirements

GO-ITS 25.12 Use of Cryptography

GO-ITS 37.0 Enterprise Incident Management Standard

GO-ITS 54.0 Application Development Standard

GO-ITS 56.0 OPS Enterprise Architecture Standard

Corporate Operating Policy on Internet Tracking Technologies

Corporate Policy on I&IT Security (MGS Intranet)

ISPC Policy (MGS Intranet)

ISPC Procedures (MGS Intranet)

Freedom of Information & Privacy Directive (MGS Intranet) (PDF)

4.5 Informative references

OWASP

OWASP “Top Ten” Project:

PCI-DSS (PDF)

PA-DSS (PDF)

5. Responsibilities

5.1. Users

Users are responsible for:

  • Complying with Government directives, policies and agreements when using Government applications and services;
  • Safeguarding credentials for Web Applications and using only those services they are authorized to access; and
  • Reporting any suspected security breaches to the OPS Service Desk.

5.2. Program Managers

Program Managers are responsible for:

  • Endorsing secure development techniques for their projects;
  • Completing Government of Ontario information sensitivity classification and Threat/Risk Assessments for Web Applications;
  • Arrange Personnel Screening for staff and contractors as appropriate; and
  • Ensure Business Continuity and Disaster Recovery Plans are developed, and kept current, for programs under their control.

5.3. Cluster Chief Information Officers:

The Cluster CIOs are responsible for:

  • Authorizing appropriate individuals to be granted privileged administrative access or development access to Web Applications, or delegating this authority to an appropriate individual or area (e.g., Program Managers).

5.4. Infrastructure Technology Services (ITS)

ITS is responsible for:

  • Developing, implementing and managing any Web Applications which fall outside of vendor network support contracts in accordance with this standard;
  • Using secure development techniques when building and deploying new Web Applications;
  • Ensuring that logs are securely maintained, available when needed for investigations and retained in accordance with this standard;
  • Managing central backup and restore capabilities; and
  • Ensuring infrastructure/hosting systems are hardened and patched appropriately.

5.5. Network Service Provider

The Network Service Provider is responsible for:

  • Developing, implementing and managing Web Applications operated on behalf of the Government of Ontario in accordance with this standard; and
  • Ensuring that logs are securely maintained, available when needed for investigations and retained in accordance with this standard.

5.6. I&IT Strategy, Policy and Enterprise Architecture Branch (SPEAB)

SPEAB, or a successor division/branch, is responsible for:

  • Maintaining this standard and all other applicable IT security standards, policies, procedures and related guidance on behalf of the Government of Ontario;
  • Supporting developer education efforts; and
  • Monitoring the evolution of application security attack techniques.

5.7. Cyber Security Branch (CSB)

CSB is responsible for:

  • Co-ordinating responses to enterprise-wide security incidents; and
  • Conducting Security Testing and Evaluation (STE) (typically in the form of TRAs, Vulnerability Assessments and Penetration Testing) services for Web Applications.

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

Glossary

Access: 
Entry to an electronic network provided by the government to its employees and other authorized individuals on or outside government premises, including telework situations.
Access Controls:
Procedures/devices designed to restrict entry to a physical area (physical access controls) or to limit use of a computer/communications system or computer stored data (logical access controls).
Application:
Software code and components that function to provide a service or process transactions.
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.
Confidentiality:
The result of safeguards enforcing access to information consistent with the sensitivity of information, competitive position, and legislative requirements (e.g., FIPPA, PIPEDA, PHIPA).
Cryptography:
The transformation of data into a form unreadable by anyone (encryption) without the correct decryption key, ensuring confidentiality by keeping the information hidden from anyone for whom it was not intended, including those who can see the encrypted data.
Data:
Any formalized representation of facts, concepts or instructions suitable for communication, interpretation or processing by a person or by automatic means.
Denial of Service (DoS):
An attempt to make a computer resource unavailable to its intended users. Although the means to, motives for, and targets of a DoS attack may vary, it generally consists of the concerted, malicious efforts of a person or persons to prevent an Internet site or service from functioning efficiently or at all, temporarily or indefinitely.
Electronic Network:
Computers and computer systems that can communicate with each other and, without restricting the generality of the foregoing, includes the internet, networks internal to an institution, as well as closed networks external to an institution.
Firewall:
 Software or a hardware device that acts as a barrier between two networks and mediates access between those two networks according to an approved set of rules.
Information:
The meaning derived from or assigned to facts or data, within a specified context.
Information Technology Resources:
Those resources (hardware, software, data, etc.) associated with the creation, storage, processing and communication of information in the form of data, text, image and voice.
Integrity:
The authenticity, accuracy and completeness of data that can be affected by unauthorized or accidental additions, changes and/or deletions.
Mutual Authentication:
Also referred to as two-way authentication refers to two parties authenticating each other suitably. In technology terms, it refers to a client or user authenticating themselves to a server and that server authenticating itself to the user in such a way that both parties are assured of the others' identity.
Network:
IT systems that can be made of one or both of the following components:
  • Local Area Network (LAN) - Network of Information technology systems wholly situated at one geographical address;
  • Wide Area Network (WAN) - located over more than one geographical site.
Program:
A specific program or service within a Ministry.
Program Manager:
The person responsible for the continued development, operational control, implementation, monitoring, etc. of a specific program or service within a Ministry.
Responsibility:
The obligation to perform a given task or tasks associated with a specific role.
Risk:
  A potential opportunity or threat that may impact on an organization’s ability to meet its business objectives.
Safeguard:
  A protective and precautionary measure to prevent a security event from happening.
Sensitive Information:
Information that has been classified as Medium Sensitivity or High Sensitivity as per the Government of Ontario’s information sensitivity classification Policy and associated guidelines.
User:
A person authorized to access and use Information and Information Technology resources.
Virtual Private Network (VPN):
A logical communications “tunnel” through another network. One common VPN use case is secure communications through the public Internet, but a VPN need not have explicit security features, such as authentication or content encryption. VPNs, for example, can be used to separate the traffic of different user communities over an underlying network with strong security features.