Enterprise Architecture Guildlines and Best Practices for ... and Best Practices... · Guidelines...

Guidelines and Best Practices for Government Information Technology Solutions

of 90

Updated 2018-04-06

Guidelines and Best Practices for

Government Information Technology Solutions

Enterprise Architecture Division

Office of the Chief Information Officer (OCIO)

Government of Newfoundland & Labrador

VERSION 8.2.1

2018-04-06

Government of Newfoundland and Labrador

Office of the Chief Information Officer

Corporate Service and Projects: Enterprise

Architecture


of 90

Updated 2018-04-06

Version Date Author Description

5.9 2012-09-22 EA Group In-depth document review & update

5.10 2012-10-31 Todd Pinksen Version updated.

6.0

2013-01-22 Curtis Snelgrove Document updates and QA.

6.1 2013-03-21 Todd Pinksen Added Browser Compatibility Guidelines and

.NET as primary stack

6.2 2013-07-21 Andre Besso Draft Under Review

6.21 2013-09-12 Andre Besso Consolidated Individual Review

6.22 2014-01-10 Steve Burton Added How to Mitigate TLS Vulnerabilities

6.23 2014-05-21 Andre Besso Updated Server Standard to Win 2012

7.0 2015-06-05 EA Group Updated Major Version Release

7.1 2016-02-12 Andre Besso Technology Version Updates

8.0 2016-03-16 Andre Besso Technology & Security Updates

8.1 2017-12-13 Cory Slaney Supportability Principle, Intranet Standard

and Minor Technology and Version Updates

8.2 2018-02-19 Cory Slaney Technology Version Updates

8.2.1 2018-04-06 Michael Pelley Minor updates including new Branch names;

update Windows Server to version 2016




Architecture


of 90

Updated 2018-04-06

TABLE OF CONTENTS

Contents

1. Purpose ........................................................................................................................... 6

2. Guiding Principles .......................................................................................................... 6

2.1 PRINCIPLE OF SOLUTION ACQUISITION ............................................................................ 6

2.2 PRINCIPLE OF REUSE ..................................................................................................... 6

2.3 PRINCIPLE OF SUPPORTABILITY ...................................................................................... 6

2.4 PRINCIPLE OF USER INTERFACE (UI) CONSISTENCY ........................................................ 6

2.5 PRINCIPLE OF MULTITIER OR N-TIER ARCHITECTURE ....................................................... 7

2.6 PRINCIPLE OF ABSTRACTION .......................................................................................... 7

2.7 PRINCIPLE OF VIRTUALIZATION ....................................................................................... 7

2.8 PRINCIPLE OF DEVIATION ............................................................................................... 7

3. Systems Architecture ..................................................................................................... 8

3.1 CORE SUPPORTED TECHNOLOGIES ................................................................................ 8

3.2 ADDITIONAL SUPPORTED TECHNOLOGIES ....................................................................... 9

3.3 VIRTUALIZATION OF INFORMATION SYSTEMS ..................................................................10

3.4 USER AUTHENTICATION PROCESS .................................................................................11

3.5 ARCHITECTURE PATTERNS FOR INFORMATION SYSTEMS .................................................11

4. Application Architecture .............................................................................................. 24

4.1 MOBILE CONTENT .........................................................................................................24

4.2 SUPPORTED FRAMEWORKS & LIBRARIES .......................................................................24

4.3 WEB APPLICATION DESIGN GUIDELINES .........................................................................26

4.4 APPLICATION DESIGN PATTERNS ...................................................................................31

4.5 APPLICATION DEVELOPMENT GUIDELINES ......................................................................35

4.6 APPLICATION LOGGING .................................................................................................40

5. Database Architecture ................................................................................................. 41




Architecture


of 90

Updated 2018-04-06

5.1 SUPPORTED DATABASES ..............................................................................................41

5.2 SQL STATEMENTS ........................................................................................................41

5.3 DATABASE SECURITY ....................................................................................................42

5.4 NAMING CONVENTIONS .................................................................................................46

5.5 NORMALIZATION ...........................................................................................................49

5.6 CASE INSENSITIVE SORTING AND COMPARISON WITH ORACLE DBMS..............................49

6. Information Protection and Security Architecture ..................................................... 51

6.1 INFORMATION SECURITY CLASSIFICATION ......................................................................52

6.2 SECURITY FUNCTIONAL CONTROLS ...............................................................................52

6.3 SECURITY PHYSICAL ARCHITECTURE .............................................................................53

6.4 USE OF CRYPTOGRAPHY ...............................................................................................62

6.5 APPLICATION LEVEL SECURITY REQUIREMENTS .............................................................67

7. Deviations and Exemptions ......................................................................................... 73

7.1 DEVIATION & EXEMPTION PROCESS ...............................................................................73

8. Glossary ........................................................................................................................ 74

Appendix A: Application Security .......................................................................................... 77

Appendix B: Backup and Recovery ....................................................................................... 82

PURPOSE OF DATA BACKUPS ...................................................................................................82

DATA BACKUP TYPES ..............................................................................................................82

DATA BACKUP PROCESS ..........................................................................................................82

DATA INCLUDED IN THE BACKUP PROCESS ................................................................................82

REMOTE DATA BACKUPS .........................................................................................................82

DATA BACKUP SCHEDULES ......................................................................................................83

DATA ACCESS DURING BACKUPS ..............................................................................................83

DELETED AND OVERWRITTEN DATA ..........................................................................................83

BACKUP TAPE RETENTION CONSIDERATIONS ............................................................................83

BACKUP DATA RETENTION PERIODS .........................................................................................83

BACKUP DATA OLDER THAN 30 DAYS .......................................................................................83

EXEMPTIONS TO DATA RETENTION PERIODS .............................................................................84

Appendix C: OCIO Network Architecture .............................................................................. 85

NETWORK BEST PRACTICES.....................................................................................................85

ARCHITECTURE COMPONENTS .................................................................................................86




Architecture


of 90

Updated 2018-04-06

Appendix D: Supportability Matrix ......................................................................................... 88

SDLC DELIVERABLES ..............................................................................................................88

SUPPORTABILITY MATRIX: ........................................................................................................89

TABLE OF TABLES

Table 1- Responsibilities and Restrictions for Each Tier of Two-Tier Architecture .....................14

Table 2 - Responsibilities and Restrictions for Each Tier of Three-Tier Architecture .................16

Table 3 - Information Security Classification .............................................................................44

Table 4 - Minimal Security Physical Control Requirements for the OCIO ..................................62

Table 5 - Cryptographic Requirements for the OCIO .................................................................67

Table 6 – N-Tier Application Security Requirements .................................................................72

Table 7 – EA Technology Binder Definitions and Acronyms ......................................................76

Table 8 - Supportability Matrix ...................................................................................................89

TABLE OF FIGURES

Figure 1 - Technology Stacks ..................................................................................................... 9

Figure 2 - High-Level Two-Tier System Architecture .................................................................13

Figure 3 - High-Level Three-Tier System Architecture ...............................................................15

Figure 4 – High-Level System Architecture with Separate Internal and External Interfaces .......17

Figure 5 - High-Level Decoupled External System Interface .....................................................18

Figure 6 – Pattern #4 Scenario 1 ..............................................................................................19

Figure 7 - Pattern #4 Scenario 2 ...............................................................................................20

Figure 8 - High-Level Decoupled External System Interface with Service Queue ......................22

Figure 9 - High-Level Service Queue Depicted On the Internal Data Tier..................................23

Figure 10: Layered Application Architecture ..............................................................................28

Figure 11 - Four Architecture Pillars and Layers .......................................................................51

Figure 12 - One Architectural Approach to Establishing Physical Controls ................................53



Solution Delivery: Enterprise Architecture


of 90

Updated 2018-04-06

1. Purpose

The purpose of this document is to outline the guiding principles and best practices for all Government of Newfoundland and Labrador solutions. The concepts presented in this document reflect the views of the OCIO and standards that are actively reviewed as part of the solution architecture.

Compliance to these guiding principles and best practices is managed through the Project Architecture Review Board (PARB) process and is evaluated on a per-project basis.

For more information about the Guidelines and Best Practices for Government Technology Solution, contact [email protected].

2. Guiding Principles

The OCIO seeks to have solutions acquired and implemented according to the following principles.

2.1 Principle of Solution Acquisition

Solutions shall be acquired based on business value, cost, and adequate management of risk in consultation with Enterprise Architecture and Information Management & Protection.

The following deployment methods are considered acceptable:

Commercial-off-the-Shelf (COTS)

Cloud Services

Custom-Built Applications

2.2 Principle of Reuse

The OCIO prefers to reuse existing solutions and solutions shall be acquired that will allow for maximum reuse.

Shared infrastructure will be used to provide resources to projects whenever possible.

2.3 Principle of Supportability

A solution shall use technologies that will be in mainstream supporti for a minimum of 24 months

following go-live. Project supportability matrices will ensure that a solution is sustainable throughout the

project and following transition to support.

2.4 Principle of User Interface (UI) Consistency

The default deployment mechanism shall be World Wide Web Consortium (W3C) standards for Hypertext Mark-up Language (HTML) 5, Extensible Hypertext Mark-up Language (XHTML) 1.0, or higher.

mailto:[email protected]





of 90

Updated 2018-04-06

2.5 Principle of Multitier or N-Tier Architecture

Multitier or N-tier solution architecture1 is preferred. Architectures and systems must be designed, developed, enhanced or acquired such that solutions and processes can be adopted, shared and integrated across the enterprise.

2.6 Principle of Abstraction

Application design should avoid the duplication of code. This is best accomplished through a Separation of Concerns (SoC)2 within the application. Administrative and user interfaces should also be logically separated within the application.

2.7 Principle of Virtualization

2.7.1 Virtual

The OCIO has a “Virtual First” policy. Virtualization is used to increase the amount of resource utilization while decreasing the physical footprint. All systems will use virtualization for the operating system, CPU, memory, and storage.

2.7.2 Exceptions

Exceptions to the “Virtual First Policy” can be requested but must be justified before new physical resources are procured.

2.8 Principle of Deviation

If the best solution deviates from the OCIO’s guidelines, Enterprise Architecture (EA) approval is required. The process outlined in the Deviations and Exemptions section of this document must be followed.

1 http://en.wikipedia.org/wiki/Multitier_architecture 2 http://en.wikipedia.org/wiki/Separation_of_Concerns





of 90

Updated 2018-04-06

2.8.1 Project-by-Project

Deviations from the OCIO’s guidelines and best practices are approved on a project-by-project basis.

2.8.2 Approval

Any deviation(s) from the OCIO’s guidelines and best practices previously approved by EA does not constitute a new guideline or best practice.

2.8.3 Vendors Supported

In the case of COTS solutions, vendors’ supported and preferred technology platforms will take precedence over the OCIO’s solution stacks where the support and sustainability is assured.

3. Systems Architecture

3.1 Core Supported Technologies

This section identifies the combinations of technologies to be used within the OCIO. Each solution stack is a combination of operating systems (OS) including all associated hardware, database, and application technologies.

Figure 1 identifies combinations which represent the OCIO’s preferred stacks. When choosing a technology stack, the decision should be based on a combination of the specific needs of the solution and on the skill sets of the support resources in Application and Information Management Services (AIMS) Branch and Operations and Security (O&S) Branch.





of 90

Updated 2018-04-06

Standard Technology Stacks

Java Stack

(Secondary)

.Net Stack

(Primary)

PHP Stack

(Secondary)D

eve

lop

men

t

La

ng

uag

e

Op

era

tin

g

Sys

tem

Deliv

ery

Serv

er

Microsoft SQL Server

2014

Microsoft Internet

Information Server 8.5

ASP.NET 4.5

---------------------

C#.NET

Visual Basic.NET

Microsoft Windows

Server 2016

Oracle Database 12c

Apache Tomcat Server,

version 7

---------------------

Oracle WebLogic

Server, version 12c

Java Enterprise Edition

version 7

IBM AIX 7.1

PHP, version 7.x

Apache Web Server,

version 2.x

Oracle Database 12c

Red Hat Enterprise

Linux, version 7

Vir

tua

lizati

on

Pla

tfo

rm

VMWare vSphere VMWare vSphereIBM PowerVM

Data

bas

e

Figure 1 - Technology Stacks

3.2 Additional Supported Technologies

The list below outlines the additional technologies being used at the OCIO and their preferred method of use:

WordPress 4.x

Web Content Management and Delivery Platform for Intranet and Public facing websites.

SharePoint 2010

Content and Collaboration Platform.





of 90

Updated 2018-04-06

New Intranet development for SharePoint platform is currently phased out in favour of WordPress Content Management and Delivery Platform.

Skype for Business 2016

Audio/Video Conferencing and Collaboration.

Exchange 2010

Mail System.

SFTP

Secure FTP transfer method for internal environments.

Active Directory 2012 R2.

Directory Services with Domain and Forest Functional Level of 2008 R2.

HP Records Manager (formerly TRIM) 8.2

Document Management.

Pulse Secure vADC

Application Delivery Controller.

Accellion MFT

File Transfers with external parties.

3.3 Virtualization of Information Systems

Virtualization has increased system consolidation, improved system efficiencies, increased availability, and simplified manageability.

The OCIO has deployed two standard virtualization technologies, VMWare ESX and IBM Power VM. Both technologies aid in the deployment of virtual Windows, Linux, and AIX operating systems in a shared resource pool. See the “Standard Technology Stacks Version 2.0” diagram above for virtualization standards and supported operating systems.





of 90

Updated 2018-04-06

3.4 User Authentication Process

Active Directory is to be used as the primary authentication source for internal solutions with the alternate solution to be user authentication in the database. For external solutions, user authentication in the database is the preferred method.

3.5 Architecture Patterns for Information Systems

This section provides a number of high-level system architecture patterns approved by the OCIO. The OCIO provides these system architecture patterns to project teams with a view to increasing the quality and consistency of systems within the OCIO’s operating environment. By implementing systems which adhere to these patterns, a project team can be sure that a system will conform to architectural norms prevalent within the information systems industry at large and the OCIO in particular.

The following sample system architectures are documented at a very high-level and are largely independent of specific technologies (i.e. operating systems, application servers, programming languages). The OCIO defines “technology stacks” which should be used to implement these sample architectures where possible.

Information Classification

The information security classification scheme for the Government of Newfoundland and Labrador categorizes information assets by the requirements for confidentiality, integrity, and availability. As described below, the classification scheme aids in the selection of appropriate high-level system architecture for a particular project.

Selection of an Appropriate High-Level System Architecture

In order to determine the appropriate sample system architecture, it is necessary to obtain the information classification for the proposed system. System implementers should then use the sample system architecture(s) appropriate for the proposed system`s information classification. Architectural requirements which correspond to a given information classification and level of exposure (i.e. Intranet, extranet, or Internet) are detailed in the OCIO`s security guidelines (see section 7.0). It is possible to combine two or more sample architectures to produce a merged system architecture.

The selection of a sample system architecture also takes into account the exposure of the system to security threats (i.e. deployment to internal networks, extranets or the Internet). Physical tiering of an application provides a type of architectural control which helps protect the confidentiality of a system’s information.

3.5.1 Pattern #1: Two-Tier System Architecture

Two tier systems are recommended by the OCIO when an internal system requires a medium level of security or lower to protect the information contained within it. The primary consideration in this architecture is the use of two separate servers to host the system. The removal of the databaseii (or data store) to a separate server, from that which hosts the application, ensures that the end-user is





of 90

Updated 2018-04-06

never able to directly interact with the database (or data store). The first tier is able to help ensure that no request coming from the end-user will be passed to the second tier (the data tier) if it is malformed, inappropriate or malicious. A simplified diagram of a two-tier system is below.





of 90

Updated 2018-04-06

Figure 2 - High-Level Two-Tier System Architecture

3.5.1.1 Infrastructure

The infrastructure model adopted by the OCIO for two-tier systems consists of two servers. The tiers are:

The Presentation / Application Tier contains the services directly accessed by users and the bulk of the application and security code; and

The Data Tier contains the database (or other data store).

In a two-tier design, only the first tier can be accessed by the user community. Direct access to the data tiers should not be permitted by the user community.

The Presentation / Application tier hosts the bulk of the application logic, validates the end-user, processes requests from the end-user, and interacts with the database.

Note: both tiers are located on separate network segments and these segments are isolated by network firewalls.

Administrative and system management functionality should always be separate from the services being delivered. Furthermore, administrative access to the system should not be available to the user community.

High-level Sample of a

Two-Tier System Architecture

User Community

Network Zone

Tier One

Network Zone

Tier Two

Network Zone

Firewall Firewall

Presentation,

Application Tier



May 2010

Data TierUser’s Workstation

or Device

Minimum required

database privileges





of 90

Updated 2018-04-06

3.5.1.2 Responsibilities and Restrictions for Each Tier

Table 1 describes the responsibilities and restrictions for each tier of two-tier architecture.

The Presentation, Application Tier Must Perform: The Data Tier Must Perform:

Session management;

Fine-grained authorization (access control); and

Input validation.iii

Secure storage of data; and

Appropriate management of database privileges (or other data store access control).

The Presentation, Application Tier Must Not: The Data Tier Must Not:

Accept any input received without validating it;

Pass any data to any other services without re-validating it; and

Store sensitive data including user credentials.

Grant unnecessary database access to any user.

Table 1- Responsibilities and Restrictions for Each Tier of Two-Tier Architecture

3.5.2 Pattern #2: Three-Tier System Architecture

Three-tier systems are recommended for systems when the OCIO has defined a requirement to implement the maximum industry best practices for security. The primary consideration in this architecture is the use of three separate servers used to host the system.

As in the two-tier model, the database is removed from the application to a dedicated server, but in addition, the application itself is split across two separate servers. The overall effect is that there is a server in the “middle” between the first tier of the system (which is most susceptible to malicious end-user attacks) and the database tier. The middle tier is able to provide an additional level of security to ensure that no request coming from the first tier will be passed to the third tier (the database tier) if it is malformed, inappropriate or malicious.

Three-Tier systems are used when the security classification for internal facing systems is high, or an external facing system has a security classification of medium.

A simplified diagram of a three-tier system is provided in Figure 3 below.





of 90

Updated 2018-04-06


Three-Tier System Architecture

User Community

Network Zone

Tier One

Network Zone

Tier Two

Network Zone

Tier Three

Network Zone

Firewall Firewall Firewall

Presentation Tier Application Tier Data Tier



May 2010

User’s Workstation

or Device

Minimum required

database privileges

Figure 3 - High-Level Three-Tier System Architecture

3.5.2.1 Infrastructure

The infrastructure model adopted by the OCIO for three-tier systems consists of three server tiers.

The Presentation Tier contains the services directly accessed by users;

The Application Tier contains the bulk of the application and security code; and

The Data Tier contains the database (or other data store).

In a three-tier design, only the Presentation Tier can be accessed by the user community. Direct access to the application or data tiers should not be permitted by the user community. In addition, the database should not be directly accessible from the Presentation Tier. As the tier most vulnerable to a user-based attack is the Presentation tier, even if it were compromised, this tier is not able to interact directly with the database.

The Application Tier, which hosts the bulk of the application logic, processes requests from the Presentation Tier only after validating them and interacts with the database as necessary. Note that all three tiers are located on separate network segments and these segments are isolated by network firewalls.






of 90

Updated 2018-04-06

3.5.2.2 Responsibilities and Restrictions for Each Tier

The following table describes the responsibilities and restrictions for three-tier architecture.

The Presentation Tier Must Perform:

The Application Tier Must Perform:

The Data Tier Must Perform:

Coarse-grained authorization; and

Input validation.iv

Session management;

Fine-grained authorization (access control); and

Input validation.v

Secure storage of data; and

Appropriate management of database privileges (or other data store access control).

The Presentation Tier Must Not:

The Application Tier Must Not:

The Data Tier Must Not:

Store system or user credentials;

Pass any input or data to any other first- or second-tier service without validating it;

Communicate directly with any third-tier service; and

Store sensitive data.

Accept any input received without validating it; and

Pass any data to any other second- or third-tier services without re-validating it.

Pass any data directly back to the first tier; and

Grant unnecessary database access to any user.

Table 2 - Responsibilities and Restrictions for Each Tier of Three-Tier Architecture

3.5.3 Pattern #3: Separate Internal and External Interfaces

Separate internal and external interfaces are recommended for systems when the OCIO has defined a requirement to implement a system for distinct user communities with very different security and functional requirements. This is often the case when an internal government system, used by internal government staff, has a requirement to accommodate citizen access via the Internet. This pattern helps to mitigate the risk of any exposure to the Internet of any information or system features which are solely intended to be used by internal system users. The primary consideration in this architecture is the use of separate servers for both user communities with only the back-end databasevi tier shared in common. A simplified diagram of a System Architecture with Separate Internal and External Interfaces is provided in Figure 4 below.





of 90

Updated 2018-04-06


System Architecture with Separate

Internal and External Interfaces

External User Community

Network Zone

External Tier One

Network Zone

Shared Database

Network Zone

Firewall

Firewall

External Application Tier



May 2010

Limited database

privileges

Internal User’s Workstation

or Device

Internal User Community

Network Zone

External User’s Workstation

or Device

Internal Tier One

Network Zone

Firewall

Firewall

Internal Presentation, and

Application Tier

External Presentation

Tier

Firewall

External Tier Two

Network Zone

Greater

(but not excessive)

database privileges

Figure 4 – High-Level System Architecture with Separate Internal and External Interfaces

In the example depicted in Figure 4, each user community accesses an n-tier system architecture appropriate for the security requirements for that user community and the zone from which users connect. In particular, government staff connects from the more trusted internal network zone so they use two-tier architecture, while citizens connect via the less trusted Internet zone so they use the more secure three-tier architecture. The pattern may be used with other combinations of system architectures substituted for the n-tier systems shown above (e.g. the internal system might be legacy client-server or mainframe architecture). The important point is that the two interfaces are essentially distinct but share the same database server. Each n-tier system connects to the shared data tier, but uses a different database account with system privileges appropriate for the minimum needs of each user community. Use of advanced security features to restrict the permissions granted to the external system’s database privileges is strongly advisable (e.g. use of stored procedures and views are preferred over any direct access to manipulate database objects such as tables, etc.). In many cases, an external system may only require read-only database access, which can greatly limit the risk of the external system introducing vulnerabilities that would impact the integrity of the database.

Note: there is no communication between any of the two system interfaces except at the database level. All tiers are located on separate network segments and these segments are isolated by network firewalls.





of 90

Updated 2018-04-06


3.5.4 Pattern #4: Decoupled External System Interface

A decoupled external system interface is recommended for systems for which the OCIO has defined a requirement to publish information to external (less trusted) parties while providing maximum protection of the internal information from external threats. This pattern is characterized by the use of a second databasevii used to support the external interface. In this pattern, a copy of information contained within an internal database is deployed to a separate external database, and only the external database is made accessible via an external interface. As there is no access from the external system interface to the internal database, the risk of a security breach to the internal system is strongly mitigated. Figure 5 depicts this pattern. A solid dark line and a one-way arrow are used to represent the fact that no access from any component of the external system interface is granted to the internal data source.

Note: While the pattern is illustrated in Figure 5 using a two-tier external system interface, and only a single tier of the internal system is depicted, the architecture of both systems may vary; the essential part vital to the pattern is the one-way publishing from an internal system to an external data store.



User Community

Network Zone

Tier One

Network Zone

Tier Two

Network Zone

Internal Data Source

Network Zone

Firewall Firewall

External Presentation, and

Application Tier

External (“Copy”)

Data TierInternal Data Source



May 2010

External User’s

Workstation or Device

Outbound “Push”

access only

Firewall

Minimum required

database privileges

Figure 5 - High-Level Decoupled External System Interface

A decoupled external interface is frequently used to safely expose a portion of the data stored in a confidential internal system, or in situations where the integrity of information in an internal system is very important. Examine the scenarios described below.





of 90

Updated 2018-04-06

Scenario 1

A subset of less-confidential information is to be published to the Internet from an internal system which contains other confidential information which should not be published to the Internet, please see Figure 6 below.

External Data Tier

Network Zone


Network Zone

External (“Partial Copy”)


Larger sensitive database

contains some non-sensitive

data for publishing

Non-Sensitive

Data

Larger Sensitive

Database

Non-Sensitive

Data

Firewall

Figure 6 – Pattern #4 Scenario 1

Scenario 2

Information is to be published to the Internet from an internal system which contains the authoritative copy (i.e. it constitutes the “record of authority”) of information with a high integrity requirement, please see Figure 7 below.





of 90

Updated 2018-04-06

External Data Tier

Network Zone


Network Zone

External (“Copy”)


Integrity of internal “record of

authority” is protected from

external threats

Non-Sensitive

Data

Non-Sensitive

Data

Firewall

Figure 7 - Pattern #4 Scenario 2

In both of these scenarios, the use of the decoupled external system interface pattern ensures that no access is allowed to the internal system for external users. Any vulnerability in the external interface which may be exploited by an external user will result in the compromise of the external “copy” of the database only, and not the internal system.

Limitations

While the use of Pattern # 4 (Decoupled External System Interface) contributes greatly to the security of the internal system, there is a limitation on the “freshness” of the copied data available through the external interface. The frequency with which the external interface may be updated from the internal system will be impacted by the limitations involved in creating a “fresh” export of the data for the external interface – most notably the performance impact on the internal system and the amount of time required to export / transport / import the data. Generally, external interfaces such as this are updated during a nightly process, but they may be updated more frequently, or even triggered by an internal user’s action. For many business processes, this limitation is not problematic, but there are situations in which the latest copy of information is required. Pattern #5 is a variation on the Decoupled External System Interface which introduces a Service Queue to improve the capabilities of the overall solution while maintaining the security of the decoupled model.

Where the business requirements are met by Pattern # 4 (Decoupled External System Interface), it should be viewed as preferable to either Pattern #3 (Separate Internal and External Interfaces) or Pattern #5 (Decoupled External System Interface with Service Queue), due to the security benefits and the relatively low complexity.

Acceptable Export Mechanisms

The mechanism by which the information is extracted, transported and imported from the internal data source to the external system interface may vary. The key is that in order to maintain the effectiveness





of 90

Updated 2018-04-06

of the pattern, the external interface must not be allowed to access the internal system. This means that some “internal” server or process must control the extraction and transportation (though not necessarily the import process). Database links, scheduled jobs with secure file transfers, middle tier servers, Extract, Transform and Load (ETL) servers, or internal application server processes may all be considered for implementation of the export mechanism. The EA Group should be consulted early in the design phase to approve the project team’s proposed mechanism.

3.5.5 Pattern #5: Decoupled External System Interface with Service Queue

Decoupled External System Interface with Service Queue

This pattern is a variation on pattern #4 which adds a service queue to the architecture, helping resolve certain limitations in the Decoupled External System Interface model. This pattern applies to scenarios for which the OCIO has defined a requirement to expose internal system functionality to external (less trusted) parties while providing maximum protection of the internal information from external threats. Like Pattern #4, this pattern is characterized by the use of a second databaseviii used to support the external interface with the addition of a Service Queue. In this pattern, a service queue is created to:

Allow information to be collected from the external interface into the internal system for storage and processing;

Provide near real-time interaction between the external interface and the internal system; and

Improve the level of synchronization between the external interface and the internal system.

The addition of the service queue allows these benefits without changing the fundamental nature of the decoupling of the external interface and the internal system. As there is no access from the external system interface to the internal database, the risk of a security breach to the internal system is strongly mitigated. Figure 8 below depicts this pattern. A solid dark line and a one-way arrow is used to represent the fact that no access from any component of the external system interface is granted to the internal data source; however, data can flow back to the internal system from the external portal – but the connection is initiated and controlled by the internal system.





of 90

Updated 2018-04-06



User Community

Network Zone

Tier One

Network Zone

Tier Two

Network Zone


Network Zone

Firewall Firewall

External Presentation, and

Application Tier

External




May 2010

External User’s

Workstation or Device

Service Queue Manager handles

any waiting requests

Firewall

Service Queue Holds requests

waiting to be processed

Bindery Queue

Figure 8 - High-Level Decoupled External System Interface with Service Queue

Note: while the pattern is illustrated in Figure 8 using a two-tier external system interface, and only a single tier of the internal system is depicted, the architecture of both systems may vary; the essential part vital to the pattern is the one-way initiated connection from an internal system to an external system.

Service Queue Depicted On the Internal Data Tier

In Figure 9 below, the Service Queue is depicted as a component on the External Data Tier while the Service Queue Manager is depicted on the Internal Data Tier. The servers are configured in separate network segments separated by a firewall. It is critical that the firewall is configured to allow connections initiated by the Internal Data Tier to the External Data Tier, but not vice-versa. This helps isolate the internal system from exposure to the external interface and any vulnerabilities it may introduce. Periodically, the Service Queue Manager connects to the service queue (Step 1, in the diagram) and retrieves any service requests (marking them as “retrieved”) and any information submitted along with the service requests (Step 2). Each request is processed by the Internal Data Tier, and may involve pushing results back to the database in the external data tier (Step 3). Many types of requests may not require additional data to be pushed to the External Data Tier, so this step is optional. For example, the request may simply be to accept some information submitted through the external interface which would not require pushing of fresh data to the external interface in response. Many other requests, such as retrieving an up-to-date account transaction report, would require a response. The final step in the pattern (Step 4) involves updating the status of the request in the service queue (e.g. “complete”, “failed with errors”, etc.). The service queue is cleared of completed / failed requests periodically.





of 90

Updated 2018-04-06

Figure 9 - High-Level Service Queue Depicted On the Internal Data Tier





of 90

Updated 2018-04-06

4. Application Architecture

4.1 Mobile Content

Given the growing ubiquity of mobile devices, which include hybrid PCs, tablets, and smart phones, there is an increasing need to make content available to multiple form factors. Responsive web design provides an optimal viewing experience (i.e. easy reading and navigation with a minimum of resizing, panning, and scrolling) across a wide range of devices.

All new applications and web content should be delivered using an architecture which supports and includes responsive web design. Mobile-friendly applications should employ a service oriented architecture which includes WEB APIs. This will maximize modularity and enable continuous development.

The following Frameworks are recommended for mobile web content:

JQuery Mobile; and

Bootstrap CSS.

Additional frameworks may be considered to augment the ones listed above, on a case-by-case basis, and with consultation with OCIO Enterprise Architecture

4.2 Supported Frameworks & Libraries

In order to promote consistency, it is recommended that project teams make use of frameworks and libraries listed in the following sections. These guidelines are intended primarily for custom applications, but can be used as a guide for selecting COTS solutions as well.

4.2.1 Selecting A Development Platform

When selecting an appropriate technology for a custom solution, the decision should be based on technical considerations specific to the solution, as well as on the skill sets of the project team and Application and Information Management Services support team.

In cases where the above criteria are neutral regarding the suitability of the supported frameworks and/or libraries, the .NET Framework should be considered the preferred technology.

4.2.2 Microsoft.NET

4.2.2.1 Version

New applications should be developed using ASP.NET version 4.5, with C#.NET or Visual Basic.NET as the coding language.





of 90

Updated 2018-04-06

4.2.2.2 Libraries

Wherever possible, Microsoft libraries, frameworks, and components should be leveraged. Third-party libraries, frameworks, and components may be used when there is no equivalent Microsoft technology available or appropriate. The use of third-party libraries, frameworks, or components is subject to approval by EA.

4.2.3 Java

4.2.3.1 Version

New applications should be developed using Java Enterprise Edition version 7.

4.2.3.2 Libraries

Wherever possible, Java Enterprise 7 libraries should be leveraged. Third-party libraries should only be used when there is no equivalent Java Enterprise solution available. Available libraries include, but are not limited to:

Java Server Faces (JSF) Version 2.2;

JavaServer Pages (JSP) Version 2.3;

JavaServer Pages Standard Tag Library (JSTL) 1.2;

Servlets 3.1;

Java Persistence API (JPA) Version 2.1;

Given its current use, and supportability within Application and Information Management Services, Hibernate version 3.6.3, is considered an acceptable provider for JPA;

Java Data Objects (JDO) Version 3.0; and

JAX-WS Version 2.2.

4.2.4 PHP

4.2.4.1 Version

New applications should be developed using PHP version 7.x.





of 90

Updated 2018-04-06

4.2.5 AJAX

The use of AJAX is recommended to improve user experience. AJAX may be implemented using either

AJAX support native to the selected development platform or by JQuery version 1.10.2. As stated in

previous sections, it is recommended that core libraries be used for each of the approved technology

stacks, when possible. It is recognized however that sometimes the best solution is provided by a third-

party library. Use of such libraries is approved on a case-by-case basis. In such cases, only stable

versions will be accepted. Beta versions are not acceptable. Version 1.0, are generally not considered

desirable.

4.3 Web Application Design Guidelines

4.3.1 Separation of Concerns

This section discusses the overall structure for applications in terms of the logical grouping of

components into separate layers that communicate with each other and with other clients and

applications, and how to represent these layers in a diagram. These guidelines are intended primarily

for custom solutions.

4.3.1.1 Layers

Layers are concerned with the logical division of components and functionality, and do not take into

account the physical location of components. They can be located on different tiers, or they may reside

on the same tier. Layers help to differentiate between the different kinds of tasks performed by the

components, making it easier to create a design that supports reusability of components. Each logical

layer contains a number of discrete component types grouped into sub layers, with each sub layer

performing a specific type of task.

Dividing an application into separate layers that have distinct roles and functions helps to maximize

maintainability of the code, optimize the way that the application works when deployed in different ways,





of 90

Updated 2018-04-06

and provide a clear delineation between locations where certain technology or design decisions must

be made.

Note that “layers” should not be considered synonymous with “tiers”, which represent physical

separation at the infrastructure level, as described in section 3.5 Architecture Patterns for Information

Systems

4.3.2 Application Architecture Diagram

The application architecture diagram should provide a high-level representation of the logical

architecture of an application. It shows a simplified view of the layers and their relationships with:

Users;

Other layers within the application;

Other applications that call services implemented within the application’s business layer;

Data sources such as relational databases or web services that provide access to data; and

External or remote services that are consumed by the application.





of 90

Updated 2018-04-06

The following shows OCIO’s recommended format for application architecture diagrams.

USERS

SER

VIC

ELA

YER Service Interfaces Message Types

EXTERNAL SYSTEMS

Service Consumers

PR

ESEN

TATI

ON

LAY

ER

UI Components

Presentation Logic Components

BU

SIN

ESS

LAY

ER

Business Workflow

Business Components

Business Entities

Application Facade CR

OSS

- CU

TTIN

G

Co

mm

un

icat

ion

Op

erat

ion

al M

anag

emen

t

Secu

rity

DA

TALA

YER Data Access

ComponentsData Helpers/

UtilitiesService Agents

ServicesData

Sources

Figure 10: Layered Application Architecture





of 90

Updated 2018-04-06

4.3.3 Application Layers

4.3.3.1 Presentation Layer

The Presentation Layer will usually include the following:

User Interface Components: These are the application's visual elements used to display information to the user and accept user input; and

Presentation Logic Components: Presentation logic is the application code that defines the logical behaviour and structure of the application in a way that is independent of any specific user interface implementation.

4.3.3.2 Services Layer

The services layer will usually include the following:

Service Interfaces: Services expose a service interface to which all inbound messages are sent. This façade exposes the business logic implemented in the application (typically, logic in the business layer) to potential consumers. Service interfaces include technologies such as Web Services, WCF, et cetera; and

Message Types: When exchanging data across the service layer, data structures are wrapped by message structures, such as XML and JSON that support different types of operations. The services layer will also usually include data types and contracts that define the data types used in messages.

4.3.3.3 Business Logic Layer

The business layer will usually include the following:

Application Façade: This optional component typically provides a simplified interface to the business logic components, often by combining multiple business operations into a single operation that makes it easier to use the business logic. It reduces dependencies because external callers do not need to know details of the business components and the relationships between them. For example, when updating changes to an object, the caller need not be aware of, or have access to all the underlying operations required to persist those changes to a data source. The caller should only need to execute a public Object.Update command. This update method would encapsulate the inner workings of the update process and hide it from the caller;

Business Logic Components: Business logic is defined as any application logic that is concerned with the retrieval, processing, transformation, and management of application data; application of business rules and policies; and ensuring data consistency and validity. To maximize reuse opportunities, business logic components should not contain any behavior or application logic that is specific to a particular use case;





of 90

Updated 2018-04-06

Business Workflow Components: After the UI components collect the required data from the user and pass it to the business layer, the application can use this data to perform a business process. Many business processes involve multiple steps that must be performed in the correct order. Business workflow components define and coordinate long running, multistep business processes, and can be implemented using business process management tools. They work with business process components that instantiate and perform operations on workflow components; and

Business Entity Components: Business entities encapsulate the business logic and data necessary to represent real world elements, such as customers or orders, within an application. They store data values and expose them through properties; contain and manage business data used by the application; and provide stateful programmatic access to the business data and related functionality. Business entities also validate the data contained within the entity and encapsulate business entity specific logic to ensure consistency.

4.3.3.4 Data Access Layer

The data layer may include the following:

Data Access Components: These components abstract the logic required to access the underlying data stores. Also, they centralize common data access functionality in order to make the application easier to configure and maintain;

Data Helpers and Utilities: Some data access frameworks may require the developer to identify and implement common data access logic in separate reusable helper or utility data access components. Other data access frameworks, including many Object Relational Mapping (ORM) frameworks, implement such components automatically, reducing the amount of data-access code that the developer must write; and

Service Agents: Service agents implement data access components for calling services from your application, and may provide additional services such as caching, offline support, and basic mapping between the format of the data exposed by the service and the format your application requires.

4.3.3.5 Cross Cutting Concerns

The majority of applications will contain common functionality that spans layers and tiers. This

functionality typically supports operations such as authentication, authorization, caching,

communication, exception management, logging and instrumentation, and validation. Such functionality

is generally described as crosscutting concerns because it affects the entire application, and should be

centralized in one location in the code where possible. For example, if code that generates log entries

and writes to the application logs is scattered throughout layers and tiers, and the requirements related

to these concerns change (such as logging to a different location), the relevant code may have to





of 90

Updated 2018-04-06

updated throughout the entire system. Instead, if the logging code is centralized, the change can be

made in just one location.

4.4 Application Design Patterns

In order to promote consistency across applications, it is recommended that application designers employ recognized application design patterns. The choice of an appropriate design pattern will be determined by the specific needs and architecture of the solution. The following section describes some common application design patterns and provides some general guidelines for their use in designing custom applications for deployment in the OCIO network.

A design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

At the highest level are application archetypes. Custom applications built for use in government consist of four acceptable types:

Web Applications: Applications of this type, typically support connected scenarios and can support different browsers running on a range of operating systems and platforms. The core of a web application is its server-side logic. This logic may be comprised of many distinct layers. A typical example is a three-layered architecture comprised of presentation, business, and data layers. A web application will normally access data stored on a remote database server. It may also consume services exposed by other applications, including S+S hosted services and web services.

Web Services: Web services expose shared business functionality and allow clients to access them from a local or a remote system. Service operations are called using messages, based on XML schemas, passed over a transport channel. The goal of this type of application is to achieve loose coupling between the client and the server. Services literally provide some programmatic service to the caller that consumes the service. A service application that exposes such services will normally be structured as a multilayered application consisting of service, business, and data layers.

Web API: Web APIs are interfaces involving request-response messaging exposed over the web. These request-responses generally use REST and JSON, but can be accomplished through different message types as well. Web 2.0 applications are increasingly utilizing Web APIs over the more traditional Web Service model, due to performance and flexibility.

Daemons/Services: This type of application runs as a background process, rather than being under the direct control of an interactive user. Daemons/Services are usually installed as part of a solution to provide functions such as overnight batch processing or other events which are triggered on a timer.

http://en.wikipedia.org/wiki/Software_design

http://en.wikipedia.org/wiki/Object-oriented

http://en.wikipedia.org/wiki/Interaction

http://en.wikipedia.org/wiki/Class_(computer_science)

http://en.wikipedia.org/wiki/Object_(computer_science)

http://en.wikipedia.org/wiki/Background_(computer_software)

http://en.wikipedia.org/wiki/Process_(computing)





of 90

Updated 2018-04-06

4.4.1 Domain Logic Patterns

4.4.1.1 Domain Model

A Domain Model creates a web of interconnected objects, where each object represents some meaningful individual. These objects incorporate data and behaviour. As these objects are often different from the relational data in a database, mapping is required. This pattern is recommended in all Object Oriented Applications where complex manipulation of domain objects is required by the business logic layer.

4.4.1.2 Table Module

A Table Module organizes domain logic to closely match the table structure in the database. This type of application may be object oriented, but this is not required to justify the use of the pattern. The key feature of Table Module is the use of recordsets (Data Readers, Data Tables, etc.) to represent the business entities. This pattern is recommended for solutions where data is tabular and the primary purpose is to read and display data. This pattern works well where record sets are bound directly to data-aware controls, such as Grids, and where business objects are not required (e.g. content management systems).

4.4.1.3 Service Layer

A service layer defines an applications boundary and its set of available operations from the perspective of interfacing client layers. This layer can be implemented either as a domain façade, or as an operation script. A Domain Façade implements the minimum logic to create a boundary between the requester and the business logic. A Domain Façade is often used to establish a common entry point for communication between the presentation and business logic layers. An Operation Script service encapsulates the application’s workflow logic (as opposed to domain logic), controlling transactions and coordinating responses in the implementation of its operations. An Operation Script would commonly exist in the form of a separate service tier.

4.4.2 Data Access Patterns

4.4.2.1 Data Mapper

A data mapper is a layer which separates domain objects from the database. Its responsibility is to transfer data between the domain objects and database objects and to isolate the two from each other. This pattern is most appropriate when domain-model objects are subject to complex business logic or parts of the object, such as collections and inheritance, are not present in the relational database.





of 90

Updated 2018-04-06

4.4.2.2 Table Data Gateway

A Table Data Gateway holds all of the SQL for accessing a single table or view, including: selects, inserts, updates, and deletes. Other code calls its methods for all interaction with the database. This pattern is recommended for use with a Table Module.

4.4.2.3 Active Record

An Active Record is an object which holds both data and behavior. Each Active Record is responsible for saving and loading to the database, as well as any domain logic that acts on the data. This pattern is recommended when using a Domain Model where there is a close match between the business objects and the database objects; and the domain logic is limited to CRUD, minor derivations, and validations of data.

4.4.3 Object Relational Behaviour Patterns

4.4.3.1 Unit of Work

A Unit of Work keeps track of everything a user does during a business transaction that can affect the database. When the user is finished, it figures out everything that needs to be done to alter the database as a result. This pattern should be employed whenever object manipulation could result in multiple calls to the data source.

4.4.3.2 Identity Map

An Identity Map is an in-memory storage device which ensures that each domain object gets loaded only once from a data store. This helps avoid conflicts within a session. Identity maps are often stored in the Unit of Work, but can also be stored in a registry tied to a session. As an Identity Map records all objects which have been read from a data store during a session, the Identity Map should always be checked first, before making a trip to the data store.

4.4.3.3 Lazy Loading

Lazy Loading involves the use of placeholders for data which is only loaded into the object when needed. This is useful for loading large objects with related sub objects. For example, loading a customer’s purchase history upon initialization of the Customer object could have a noticeable performance penalty. Initializing a PurchaseHistory child object would only be beneficial when referencing the PurchaseHistory property (i.e. Customer.PurchaseHistory).





of 90

Updated 2018-04-06

4.4.4 Presentation Patterns

4.4.4.1 Model-View-Controller

Model View Controller (MVC) pattern isolates the domain model from the presentation, permitting independent development, testing and maintenance of each concern, while providing a loose coupling between these elements. This separation is important in any application where the model has some behavior (i.e. business logic).

Another separation provided by MVC is the separation of view and controller. This separation is less important than the first, but should be considered when there is a benefit derived from the separation, such as when tight control over presentation is required (e.g. different views are required for different devices.

4.4.4.2 Model-View-Presenter

Model View Presenter (MVP) pattern is primarily concerned with separating the responsibilities for visual display and event handling in an application. The view (the Web page) manages the controls on the page and forwards user events to a presenter. The presenter contains the logic to respond to the events, update the model (business logic and data of the application) and, in turn, manipulate the state of the view.

This pattern promotes automated testing of presentation logic, allows for the sharing of code between pages that require the same behavior, and provides a clear separation of business logic from UI logic.

4.4.4.3 Template View

This pattern renders information into HTML by embedding markers in an HTML page. Use of this pattern is acceptable as a sub pattern of MVC and Page Controller, but should not be considered the primary design pattern.

4.4.5 Distribution Patterns

4.4.5.1 Remote Façade

Any object that is intended to be used as a remote object needs a coarse-grained interface that minimizes the number of calls needed to get some-thing done. A Remote Façade provides such an interface. None of the fine-grained objects have a remote interface, and the Remote Façade contains no domain logic. The Remote Façade translates coarse-grained methods onto the underlying fine-grained objects. For example, when sending a request to the business layer to update an object, the presentation need not have access to all of the underlying code to achieve the database write. It simply calls an Update method via the interface to which it has access, and relies on the method itself to handle the details of creating a unit of work, starting a transaction, creating a command, etc.





of 90

Updated 2018-04-06

4.4.5.2 Data Transfer Objects (DTO)

When working with a remote interface, such as Remote Façade, each call to it is expensive. As a result, the number of calls needs to be reduced and more data should be transferred with each call. A Data Transfer Object is a serializable object that can hold all the data and carry it across the connection. The receiving end then uses an assembler to transfer data between the DTO and any domain objects.

4.4.6 Abstraction Patterns

Abstraction aims to reduce duplication of code as well as dependencies between components. This decoupling provides for greater reuse of code, and greatly simplified unit testing.

4.4.6.1 Dependency Injection

Dependency Injection (DI) is a pattern whereby external dependencies are “injected” into components rather than baked in. A component’s dependencies are defined through contracts. The dependent consumer then injects the appropriate class into the provider. DI can be achieved through Interfaces, setter injection, or constructor injection.

DI is all about flexibility. When hard-coded dependencies are removed from components, the components can be reused without having to be changed. This way multiple implementations of the same component can be created at runtime and injected into the same code.

DI also makes unit testing easier because you can inject “mock objects” into the component, thereby testing the component itself, independent of its dependencies.

A more complete discussion on DI can be found at: http://martinfowler.com/articles/injection.html.

4.4.6.2 Factory Pattern

A factory is a specialized object used solely for the creation of other objects. In the Factory pattern a client uses a factory to create a product (object). The factory completely abstracts the creation and initialization of the product away from the client. This way the product can change over time without the need to change the client. Furthermore, the factory itself can change independently of the client. This form of decoupling allows individual components to be altered, or swapped out completely, with little or no impact on the user of the factory or the factory’s products.

4.5 Application Development Guidelines

4.5.1 Writing Consistent Readable Code

The purpose of this section is to provide guidelines by which application design and development teams can build solutions which are consistent and readable to any support staff that needs to work with an application’s code throughout the application life cycle.

http://martinfowler.com/articles/injection.html





of 90

Updated 2018-04-06

4.5.1.1 Naming Conventions

Some of the potential benefits that can be obtained by adopting a naming convention include the following:

To provide additional information (e.g. metadata) about the use of an identifier;

To help formalize expectations and promote consistency within a development or support team;

To enable the use of automated refactoring or search, and replace tools with minimal potential for error;

To enhance clarity in cases of potential ambiguity;

To enhance the aesthetic and professional appearance of work product (i.e. by disallowing overly long names, comical or "cute" names, or abbreviations);

To help avoid "naming collisions" that might occur when the work product of different organizations are combined;

To provide meaningful data to be used in project handovers which require submission of program source code and all relevant documentation; and

To provide better understanding in case of code reuse after a long interval of time.

4.5.1.2 Coding Conventions

The fine details of a coding convention are largely subjective and the intention of this section is not to enforce a single coding style in every situation. However, several common elements that influence most, if not all, coding conventions are listed below.

Use meaningful names - Choose easily readable identifier names, which are descriptive of the purpose of the thing being named;

Avoid abbreviations – Use descriptive, full words (e.g. FirstName is preferable to fnam). The languages in the OCIO’s technology stack do not have restrictive variable-length requirements, and all recommended GUI’s have code-completion, which eliminate the need to type long names;

Begin function and method names with a verb - Use action identifiers which clearly indicate what the procedure is doing (e.g. GetVendorList, ProcessPayment, UpdateRecord);

Use nouns to describe the purpose of namespaces (DataAccessManagers), classes (BusinessManager), and web services (FinancialLookupService);

http://en.wikipedia.org/wiki/Metadata

http://en.wikipedia.org/wiki/Refactoring





of 90

Updated 2018-04-06

Object names should be written as singular nouns (e.g. Vendor, Product). Collections of objects should be identified with the suffix “List” (e.g. VendorList, ProductList);

Begin property names with a noun - Attribute names should begin with either a noun (e.g. Name, Address, Phone), or if the property is boolean, prefixed with “Is” or “Has” (e.g. IsActive, HasWarranty). In this case, an adjective may be more appropriate;

Avoid the use of underscores - Avoid the use of underscores to delineate words (FirstName is preferable to First_Name) unless it is a requirement of the official naming convention (e.g. CONSTANT_VALUE). Instead, use PascalCase or camelCase, depending on the programming language;

Avoid the use of hyphens - Avoid the use of hyphens as they can sometimes be mistaken for the arithmetic operator “minus;”

Avoid the use of special characters - Non-alphanumeric characters should be avoided;

Avoid the use of Hungarian notation - This involves prefixing entity names with an abbreviated type identifier (e.g. intCount, strFirstName). All recommended GUI’s make it easy to determine an entity’s type by simply mousing over the entity name. Therefore, prefixing serves no purpose;

Avoid the use of keywords as variable names - Each language has a list of predefined keywords, whose names are reserved for specific purpose. Avoiding their use will eliminate conflict as well as confusion; and

Use comments and white space - Use comment sections for procedures, which can be used by the development environment (IDE) to build documentation. These comments should be high level, and identify the code author. Use comments to explain why a block of code does not seem to fit conventions or best practices (such as when performing bug fixes). Comments meant to explain specific pieces of code should be done at a block level (i.e. explain the entire code block, not each individual line). White space enhances readability, especially for those who are not the original coders.

For a more detailed set of coding standards within a particular technology it is recommended that developers follow the coding best practices set out by the respective organizations which own the technology:

For Microsoft .NET, the following MSDN source is recommended: http://msdn.microsoft.com/en-us/library/sxe8hcf2.aspx

For Java and PHP, the SUN Microsystems (now Oracle) coding standard is recommended: http://www.oracle.com/technetwork/java/codeconvtoc-136057.html

http://msdn.microsoft.com/en-us/library/sxe8hcf2.aspx

http://msdn.microsoft.com/en-us/library/sxe8hcf2.aspx

http://www.oracle.com/technetwork/java/codeconvtoc-136057.html





of 90

Updated 2018-04-06

4.5.2 Coding for Performance

Applications that perform poorly in production can cost an enterprise in terms of lost business opportunities, poor customer service, and unscheduled downtime. The earlier a performance issue is fixed, the less time and resources it costs to do so. The need to find and fix performance issues early means that it is up to developers to ensure that applications meet performance requirements.

The following are some general guidelines to follow which will help prevent avoidable performance problems with applications. These are common to all programming languages in the standard technology stacks.

4.5.2.1 Working with Strings

Assign values directly (String sentence = “Hello World”) and do not use the String() constructor.

Perform complex string concatenation using StringBuilder() rather than joining with “&” or “+”.

Throw fewer exceptions. This does not mean reduce the use of Try/Catch blocks. Rather, use performance monitoring tools to determine areas where exceptions are being frequently thrown, and work to reduce this number. Also, do not use exception handling to control logic flow in an application.

4.5.2.2 Other Performance Guidelines

The following list provides some further direction on building performance into an application:

Use caching;

Avoid creating temporary objects in frequently used methods, or inside loops;

Close or dispose of all objects and connections when they are no longer required;

Minimize remote calls;

Use connection pooling;

Turn off auto commit when establishing database connections; and

Use lazy loading.

4.5.3 Web Standards

Web applications, particularly those accessible to the general public, should adhere to the OCIO’s Web Development Standards (DOC10867 2009 Enterprise Architecture Web Development Standards.PDF http://www.ocio.gov.nl.ca/ocio/itresources/OCIOWebStandardsforGNLWebsites.pdf), whenever technically feasible.

The following are guidelines which should be followed for all web applications:

http://www.ocio.gov.nl.ca/ocio/itresources/OCIOWebStandardsforGNLWebsites.pdf





of 90

Updated 2018-04-06

Accessible - webpages should be accessible to the widest range of people and devices possible;

User Centered - when developing the information architecture for a site, consider a structure that makes sense to the primary users;

Consistent - where feasible, web applications should have a consistent look and feel with the Government of Newfoundland and Labrador website; and

Supports the Brand - web applications should support the Government of Newfoundland and Labrador brand.

4.5.3.1 Supported Web Browsers

Where not specified by business requirements, internal web applications as well as Internet-facing applications not made available to the general public, should be capable of running in Internet Explorer version 11 (Microsoft has ended support for all previous versions as of January 2016). Applications should be compliant with CSS3, and HTML 5.

Web applications for use by the general public should be useable in major browsers which include:

Microsoft Internet Explorer;

Microsoft Edge

Mozilla Firefox;

Google Chrome; and

Apple Safari.

Supported versions of recommended browsers should be the current version (at the beginning of the Implementation Phase of the SDLC) and the most-recent previous major release.

4.5.3.2 Web Browser Compatibility

When designing new web applications it is important to build in compliance. While it is impossible to anticipate and prevent all issues over the life of an application, good planning and design will minimize potential compatibility issues with future browser version upgrades.

Microsoft

A considerable portion of compatibility issues are related to Internet Explorer, yet Internet Explorer continues to enjoy a leadership position in the browser marketplace. Therefore it is crucial to maintain a priority on minimizing potential issues with Internet Explorer version compatibility throughout the entire life of web applications.





of 90

Updated 2018-04-06

The Microsoft Developer Network (MSDN) contains guidelines for managing version compatibility for Internet Explorer on Internet Explorer Developer Center (http://msdn.microsoft.com/en-us/library/ie/aa740473.aspx). The Developer Center contains documentation on new browser features for HTML5, CSS, and JavaScript, as well as recommendations on how to design adaptive multi-platform websites, upgrade existing sites to web standards, code and debug for performance, and use tools such as feature and behavior detection.

JQuery

JQuery is the recommended ECMA Script (JavaScript) framework in OCIO’s Guidelines and Best Practices. www.jquery.com contains information on browser compatibility for the framework.

Community Resources

There are also many user communities dedicated to sharing tips and tricks on designing, testing and fixing browser compatibility. Some community sources for best practices include:

Stack Overflow (http://stackoverflow.com/questions/1064594/what-are-the-best-practices-for-cross-browser-web-sites)

About.com (http://webdesign.about.com/)

Quirks Mode (http://www.quirksmode.org)

W3C Schools (http://www.w3schools.com/cssref/css3_browsersupport.asp)

Web Resources Depot (http://www.webresourcesdepot.com/html5-and-css3-browser-compatibility-chart/)

4.5.4 Web Security

The Internet is considered the least secure deployment environment for an application. Therefore, care must be given to mitigating the risks involved in providing applications over the Internet. A detailed discussion of the risks and mitigation strategies can be found in the Web Application Security section.

4.6 Application Logging

Custom applications should maintain logs of activities internal to the application. This type of logging includes information such as:

Program Flow:

User Inputs;

Procedure Calls;

Procedure Parameters; and

Procedure Return Types/Values.

http://msdn.microsoft.com/en-us/library/ie/aa740473.aspx

http://msdn.microsoft.com/en-us/library/ie/aa740473.aspx

http://www.jquery.com/

http://stackoverflow.com/questions/1064594/what-are-the-best-practices-for-cross-browser-web-sites

http://stackoverflow.com/questions/1064594/what-are-the-best-practices-for-cross-browser-web-sites

http://webdesign.about.com/

http://www.quirksmode.org/

http://www.w3schools.com/cssref/css3_browsersupport.asp

http://www.webresourcesdepot.com/html5-and-css3-browser-compatibility-chart/

http://www.webresourcesdepot.com/html5-and-css3-browser-compatibility-chart/





of 90

Updated 2018-04-06

Program Exceptions:

Error Messages; and

Stack Traces.

These logs are maintained for the purpose of enabling support resources to more easily troubleshoot issues within the system. Logs can be enabled at various levels: INFO, DEBUG, ERROR, etc. These logging levels should be configurable to be enabled and disabled as needed. Logs should be written to files located on the application servers where the logged events occur, and should include timestamps.

Logs should be written to a secure file share on the server which contains the application being logged.

5. Database Architecture

5.1 Supported Databases

The OCIO supports the following databases (The latest vendor supported version should be used unless there is a specific requirement that dictates an earlier version):

Oracle Database Management System (DBMS) hereinafter referred to as Oracle. The preferred version is 12c;

Microsoft SQL Server hereinafter referred to as SQL Server. The preferred version is SQL Server 2014; and

and

Exceptions may be permitted with sufficient justification.

5.2 SQL Statements

5.2.1 Transactions

Transactions must be used wherever practical. They are essential for the integrity of the data in the database. They are supported in all editions of Oracle DBMS and MS SQL Server but MySQL requires that the InnoDB storage engine be used in order to support transactions.

5.2.2 Avoid Use of the Select * from Clause

It is common for programmers to code “Select * from …” type of statements to select all of the columns from a table. The OCIO considers this approach undesirable. Programmers should specify each field by name in the SQL statement to avoid potential performance or security issues.





of 90

Updated 2018-04-06

5.2.3 SQL Version

All SQL statements should be coded to conform to the American National Standards Institute (ANSI) SQL-99 standard. MySQL supports a subset of this standard and both Oracle DBMS and MS SQL Server support this standard as well. One area that is impacted by this standard is SQL join statement syntax. Older syntax (where all join criteria is mixed with all of the filtering criteria in the where clause) is typically of the form.

Select t1.field1, t2.field2, t3.field3

from table1 t1, table2 t2, table3 t3

where t1.field1 = t2.field2

and t1.field1 = t3.field3

and t1.field4 = …

With ANSI SQL-99 syntax this can be more clearly written as:

Select t1.field1, t2.field2, t3.field3

from table1 t1

join table2 t2 on t1.field1 = t2.field2

join table3 t3 on t1.field1 = t3.field3

where t1.field4 = …

Note the clear separation of the join criteria from the filtering criteria in the where clause. This syntax also supports inner, left outer and right outer joins as well. There are various other improvements in the syntax, but this is probably the one change that might have the greatest impact on programmers.

This is not intended to cost the programmer time and effort, but to make it easier for support to handle SQL for various databases and make the SQL more understandable. However, if there is a specific non-ANSI function available in a database that is convenient to use, then programmers should use it.

5.3 Database Security

5.3.1 Roles

Databases ship with predefined roles to support administration, backup, support, etc. These roles may be assigned to logins to specify the authorization within the database. The database system administrator role should not be assigned to the application login(s) used for normal business processing. This will help to prevent a perpetrator from obtaining administrative access to the database if the login is compromised. The administrator login should be restricted to the database administrators (DBA).

Application roles may be defined and assigned access and privileges appropriate to the needs of the particular role. These roles are then assigned to logins instead of granting access and privileges to the





of 90

Updated 2018-04-06

specific objects in the database. This simplifies the assignment of privileges and is consequently more secure than assigning privileges individually.

Roles should be assigned only the privileges necessary to perform the functions of that role.

5.3.1.1 System Administrator

This login should not be used for normal access to the database. It should be restricted to system administration only and must have a strong password as per the OCIO Password Directive, Standard and Guideline.

5.3.1.2 Business Logins

Logins should be created for normal business data processing with the appropriate roles assigned to these logins. In the case of operating system (OS) authentication, these could be the normal network user IDs or they may be logins created specifically for access to the database using database authentication.

5.3.1.3 Logging and Auditing

The following is a list of the minimal set of events that should be logged and audited in any database:

Logins to the database including failed attempts;

Privilege changes;

Role changes;

Execution of any Data Definition Language (DDL);

Any Create, Drop or Alter of tables, database links, directories, indexes, stored procedures, profiles, roles, tablespaces, triggers, users, or views (may be a normal part of processing in some applications so may be ignored on a case-by-case basis);

Any commands that require DBA authority;

Any changes to database configuration if possible;

Start / Stop of the database; and

Database backup and restore.

Additional logging should be enabled depending on the Information Security Classification of the specific data in the database, see Table 3 below:





of 90

Updated 2018-04-06

Information Security Classification Logging Actions

High Sensitivity All select, insert, update and delete of data should be logged.

Medium Sensitivity All select, insert, update and delete of data should be logged.

Low Sensitivity Data may be logged at project / data owner discretion or where there is organizational risk to a data breach.

Unclassified Data should be logged only in exceptional circumstances such as suspicion of a data breach or where there is organizational risk to a data breach.

Table 3 - Information Security Classification

Application tables created for the purposes of auditing must permit insertion and deletion only. Deletion should be prohibited except in the case where there is an approved purge of stale data or for archival purposes. Any attempt to modify the log table should be treated as a security breach.





of 90

Updated 2018-04-06

5.3.1.4 Use of Link Encryption

The following matrix can be used as a guideline to decide when to enable encryption between the application tier, and the database tier.

Integrity Confidentiality Encryption in Transit App to DB

Comments

Low Low No Low Risk

Low Medium Yes/No Internal=No External=Yes

Low High Yes

Medium Low No Low Risk

Medium Medium Yes/No Internal=No External=Yes

Medium High Yes

High Low No Low Risk

High Medium Yes

High High Yes





of 90

Updated 2018-04-06

5.3.2 Parameterized Queries (SQL Injection)

Parameterized queries should be used at all times. This helps to prevent SQL injection. SQL injection is a method that can be used to gain unauthorized access to data in a database. For example, if dynamic SQL is used instead of parameterized SQL and the application creates a query like the one below:

String query = “Select username, password from users where username =

‘” + UserName + “’ and password = ‘” + Password = “’”;

Where UserName is an input field and Password is an input field. If the user enters the following values into these fields, then they may gain access to unauthorized data.

UserName “’ or 1 = 1 –“;

Password “”

If this query is executed against the database, all rows will be returned from the database.

If this query is changed to use a parameterized query, then it will look like:

String query = “select username, password from users where username =

@Username and password = @Password”

with parameter values being passed for @Username and @Password.

If this query is executed against the database, no rows will be returned because the Username value will be treated as a query search value instead of text that is used to create the dynamic query. SQL injection can be much more sophisticated than this and parameterized queries will protect against it all. It is recommended to use parameterized queries at all times.

5.4 Naming Conventions

The main goal of adopting a naming convention is to permit easy identification of the purpose and meaning of the object being named. Many naming conventions may be in use, but the difficulty arises with inconsistent naming, so developers cannot rely on the name to give them any information about the object. The primary objects of interest to developers are:

Tables;

Columns;

Views;

Stored Procedures; and

Triggers.





of 90

Updated 2018-04-06

Database Administrators may also be interested in Indexes and Constraints.

5.4.1 Common Rules

Limit the names to 30 characters, unless that results in a meaningless name (Oracle names are limited to 30 characters);

Use only letters or underscores and use underscores as little as possible and only in specific cases. Do not use any special characters even if they are permitted by the database engine;

Capitalize the first letter of each word in a name (this is called Pascal casing);

The first character in a name should be a letter;

Avoid abbreviations unless they are unambiguous across the entire organization;

Avoid acronyms as most have multiple meanings unless they are unambiguous across the entire organization;

Make names readable. They should not sound strange when read aloud;

Do not use embedded spaces in names; and

Do not use a database reserved name.

5.4.2 Tables

Use plurals instead of singular names. If the table contains customer data, for instance, call it Customers instead of Customer.

Do not use prefixes such as tblCustomers as it is obvious from the context of the SQL statement, that it is a table.

If a database has tables containing data for various business groups such as Health Care and Payroll, it is acceptable to use prefixes such as HcAddresses for a table containing Health Care address and Pay… for tables containing Payroll information although it is not good practice to have data from different functional entities in the same database. However, this might be acceptable in a database used for interfacing or integration. This has the benefit of grouping all the tables together in listings of tables.

Junction tables handle many to many or one to many relationships and as such should be named by concatenating the names of the tables involved in the many to many relationships or one to many relationships. For example, a junction table defining a many to many relationship between Doctors and Patients should be called DoctorsPatients.





of 90

Updated 2018-04-06

5.4.3 Views

Views follow the same naming conventions as tables.

5.4.4 Stored Procedures

Stored Procedures follow the same naming conventions as tables.

5.4.5 Columns

Do not use prefixes to indicate a column name such as col_field1 or fld_field1 etc. Do not include the table name in the column name; it will be obvious from the context in the SQL statement, which table it belongs to. For instance, the customer’s first and last names should be called FirstName and LastName instead of CustomerFirstName and CustomerLastName in the Customers table.

Primary Key fields should be named ID in the table (as it is recommended that the primary key not contain meaningful business data but be a sequence or identity field). Each table should have an ID field.

Foreign Key fields should be named with the name of the primary key table (in singular form) with an ID suffix. For instance, a foreign key to the Addresses table residing in the Customers table should be called AddressID. If the Customers table contains multiple foreign keys to the Addresses table such as a home address and a work address, then they should have a suffix indicating the meaning such as AddressIDHome and AddressIDWork.

Use meaningful names that make the intent of the column as obvious as possible. For instance, a column name ‘printed’ could be a Boolean meaning that something was printed or it could be a datetime specifying the date and time something was printed. If the field is a Boolean, it should be something like ‘IsPrinted’ and if it is a datetime it should be something like ‘DateTimePrinted’.

5.4.6 Indexes

Since indexes are always related to a table or view, they should be named with their table or view and the field that is being indexed along with a suffix that indicates unique / not unique and clustered or not clustered. The pattern is {TableName}{ColumnName}{U|N}{C|N} where the TableName follows the Pascal casing name for the table and ColumnName is the Pascal casing name of the column and U|N indicates if the index is unique or non-unique and C|N indicates if the index is clustered or non-clustered. Do not use prefixes or suffixes such as idx or ind.

5.4.7 Constraints

Constraints are applied to the columns, of a table, so the name should indicate the type of constraint and the column to which it applies and the table that owns that column. It should be named with the pattern {ConstraintType}{TableName}_{ColumnName} where ConstraintType is one of:

Pk – for a primary key constraint;





of 90

Updated 2018-04-06

Fk – for a foreign key constraint;

Ck – for a check constraint; and

Un – for a unique constraint.

The underscore is just used to provide a clean separation between the table name and the column name.

5.5 Normalization

Normalize a database to Third Normal Form or above. Seek approval from EA for using anything less than Third Normal Form. In some cases, it may even be necessary to denormalize a table for performance reasons.

5.6 Case Insensitive Sorting and Comparison with Oracle DBMS

With the introduction of Oracle 10gR2, Oracle expanded the functionality for case insensitive queries. Oracle 10gR2 introduced a new value for NLS_COMP parameter (LINGUISTIC) that extend the NLS_SORT sort order parameter to cover all SQL sorts and comparisons. See section 5.6.1 below for a description of these parameters.

5.6.1 NLS_COMP and NLS_SORT

The NLS_COMP parameter determines how the database does comparisons. The LINGUISTIC value forces the comparison to be done using the value of the NLS_SORT parameter.

The NLS_SORT parameter determines how the database does sorting.

When the value is set to BINARY, sorts will be done using the ascii numeric value of the character in the character set. All uppercase characters have a lower ascii value than lowercase characters, so this would cause the following data to be sorted as:

Gordon;

Sandy;

gordon; and

sandy.

When the value is set to BINARY_CI (making it case insensitive) then that same data would be sorted as:

Gordon;





of 90

Updated 2018-04-06

gordon;

Sandy;

sandy.

5.6.2 How Indexing is Impacted by these Settings

When a character field is indexed using a normal index, the index is created using the ascii numeric values of the characters and would produce an order similar to that shown above for NLS_SORT=BINARY. The database engine is aware of this and when a query is executed with NLS_SORT=BINARY_CI (making the query case insensitive), the index would be of no value and is ignored, thus causing a sequential scan of the entire table. This can have a significant performance impact if the table is large.

This issue is resolved by using a function-based index similar to the following that would serve for doing case insensitive queries:

create index name_ci

on person (nlssort(first_name, ‘NLS_SORT=BINARY_CI’))

Note: that the use of the nlssort function will make the index case insensitive and it will now be used for case insensitive queries. One of the restrictions on function-based indexes is that it will not be used if the query might return NULL values. Consequently, the query should be modified to exclude NULLS if there are NULL values in the table.





of 90

Updated 2018-04-06

6. Information Protection and Security Architecture

The OCIO Information Protection and Security Architecture provides a holistic, enterprise-wide, consistent approach and level of risk – with respect to protecting and securing information. The Information Protection and Security Architecture provides the “glue” between information security governance, the components that can be implemented and the overall guidance for managing IT risk across the organization.

This Architecture is represented by four “pillars” (Access Management, Trust and Assurance, Network and Infrastructure, and Security Management) that span across three layers:

Conceptual Architecture – owned by the Operations and Security Branch (Information Protection Division); a description of the business organization and relationships necessary for stakeholders to agree on information security principles and functions;

Functional Architecture – owned by the Operations and Security Branch (Information Protection Division); a description of the information security building blocks or “functions” required to implement information security; and

Physical Architecture – owned by EA; applies technical standards, specifications and solutions to the functional requirements identified in the functional architecture. This level of architecture identifies how to implement security functionality that is specified by the components of the functional architecture.

Figure 11 - Four Architecture Pillars and Layers





of 90

Updated 2018-04-06

6.1 Information Security Classification

An Information Security Classification ranks the sensitivity and criticality of government information, and guides the process to place appropriate levels of security and protection around information assets. Classification supports the risk assessment model in its selection of suitable safeguards.

While the Information Security Classification is not a ‘risk assessment’ per se, it drives a risk assessment process by identifying and ranking asset(s) that must be protected from threats, vulnerabilities, and risk. The sensitivity and criticality of government information is ranked High, Medium, Low or Unclassified (for Confidentiality only), based on the following criteria; also called the ‘CIA Triad’:

Confidentiality (C) – upholding required restrictions against unauthorized access or disclosure of information (e.g., personal information, cabinet confidences, trade secrets);

Integrity (I) – maintaining the authenticity and preventing unauthorized modification or destruction of information (e.g., food or water testing, health care, law enforcement); and

Availability (A) – ensuring timely and reliable access to and use of information (e.g., emergency communications or health services, financial systems, benefits systems).

Based on the classification rankings, “Functional Control Requirements” are provided that state the minimum level of information protection and security “functions” to be implemented in order to adequately protect the information asset. For more information on the Information Security Classification process, please contact the Operations and Security Branch (IP Division) at [email protected].

6.2 Security Functional Controls

As noted in the previous section, the Functional Architecture (FA3) identifies the ‘functions’ (i.e. functional controls) that must be in place to adequately protect an information asset. Functional control requirements will increase as the sensitivity of the information asset increases. The extent to which an information asset is protected, from a functional perspective, is relative to the sensitivity of that asset, as stated in the Information Security Classification.

The Operations and Security Branch (IP Division), as the owner of the Functional Architecture, is responsible for identifying the functions that must be in place to protect information; EA, as owners of the Physical Architecture, are responsible for taking the functional control requirements and identifying “how” those functions must be implemented. For example, as stated in the Functional Control Requirements, the functional control ‘2nd Factor Authentication’ is mandatory to access High Confidentiality information from outside the government network. Identification of specific technologies, tools, architectures or designs considered acceptable to perform the function of ‘2nd Factor Authentication’ would be the responsibility of EA.

For a copy of the Security Functional Controls Requirements as stated by the Operations and Security Branch (IP Division), please contact the Branch.





of 90

Updated 2018-04-06

6.3 Security Physical Architecture

The diagram, depicted in Figure 12, illustrates one architectural approachix to establishing physical controls by partitioning an information system into three logical stacks and layering physical security controls on each of these stacks.

Application

Stack

Administration

Stack

Management

Stack

2 nd

Factor

Authentication

Authorization &

Access Control

Credential

Management

Entity Store

User Management

Identification &

Authentication

Audit

,

,

Confidentiality

Business Continuity

Non repudiation

Secure Storage

Disaster RecoveryIntegrity

Logging

Backup &

Recovery

Figure 12 - One Architectural Approach to Establishing Physical Controls

In order to allow mapping and traceability of functional requirements to physical requirements, the starting point is to import all functional control requirements and then apply appropriate baseline physical control mechanismsx to each physical control family, as detailed below in Table 4:





of 90

Updated 2018-04-06

Functional Control

Code Level Technical Control Implementation

Authentication IA-1 H, M, Users are uniquely identified by identifiers.

IA-2 H, M, L OCIO Active Directory is used for authentication of internal users.

IA-3 H, M, L Personally identifiable data (e.g. MCP or driver license numbers) are not used as user identifiers.

IA-4 H, M, L Password length and complexity requirements set in the OCIO Password Management Standard are followed and enforced for user authentication.

IA-5 H, M, L OCIO Active Directory user Identifiers or passwords are not used in external facing interfaces (e.g., the Internet).

IA-6 H User last logon date and time is displayed upon successful logon.

IA-7 H, M, L Security challenge question and answer style is not used for user authentication without consultation with EA.

IA-8 H, M, L ReCAPTCHA technology may be considered as a factor of authentication without consultation with EA.

IA-9 H, M, L Remember/cache user password features are not enabled on client machines.

IA-10 H, M, L Maximum number of consecutive unsuccessful authentication attempts is limited by locking the account temporarily or permanently requiring administrative release.

IA-11 H, M, L Exponential delays between consecutive unsuccessful authentication attempts are implemented.

IA-12 H, M, L User authentication logic is performed on the application tier in an n-tier system.

IA-13 H, M, L Authentication tokens are managed securely on the server and not client side.





of 90

Updated 2018-04-06

IA-14 H, M, L Communicating peers are authenticated on all tiers in an n-tier system.

IA-15 H, M, L External systems are authenticated before exchanging any sensitive information.

Additional Authentication

SA-1 H OCIO approved token technology (if required) is supported for normal users.

SA-2 H OCIO approved token technology (if required) is supported for privileged users.

SA-3 H, M, L, U

OCIO approved token technology is deployed for vendor access with the physical token escrowed by Government employees.

SA-4 H, M, L, U

OCIO approved token technology may include synchronous or asynchronous one-time password technology displayed on proprietary or mobile devices such as RIM Blackberry.

SA-5 Optional The use of biometric method is not recommended without consultation with EA.

SA-6 Optional Cryptographic-based authentication using FIPS 140-2 approved hardware devices (e.g., using X.509 digital certificates securely stored in a smartcard device) is supported.

Authorization

AC-1 H, M, L OCIO approved login banner is displayed to users.

AC-2 H User access control is granted based on individual user’s permissions and privileges at a granular level.

AC-3 H, M, L Role-based access control according to different types of user roles and group memberships (e.g., administrators, helpdesk, users, guests, etc.) is supported.

AC-4 H, M, L Assignment of users with least privileges is supported.

AC-5 H, M, L Propagation of user access rights is restricted.





of 90

Updated 2018-04-06

AC-6 H, M, L Any user actions that can be performed without authentication are identified and documented.

AC-7 H, M, L Storage of user access permissions in locations that could be corrupted by the user (e.g. cookies or form data) is avoided.

AC-8 H, M, L Maximum number of concurrent sessions per user account is limited (1 for high and medium security classification).

AC-9 H, M, L, U

Least privileges and actions are performed by vendor support personnel via remote access.

AC-10 H, M, L Automatic locking or termination of user sessions is implemented.

AC-11 H, M Segregation of duties (e.g., different accounts for different roles) is supported.

AC-12 H Dual authorization of critical operations is supported.

AC-13 H, M User authorization logic and access control decision is enforced on the application tier of an n-tier system.

AC-14 H, M, L Authorization tokens are managed securely on server and not client side.

AC-15 H, M, L, U

Peer entity authorization and access control is enforced at every level of an n-tier system.

AC-16 H, M, L Information flow between entities in an n-tier system is restricted by security gateways according to the OCIO network security zone policies (e.g., to enforce content inspection and filtering).

User Management UM-1 H, M, L User lifecycle management from creating, modifying, disabling to removing user accounts (e.g., using built in workflow engine) is supported.

UM-2 H User activity reports (e.g., for auditing or compliance purposes) are available on demand.

UM-3 H, M, L Expired user accounts are automatically disabled.





of 90

Updated 2018-04-06

UM-4 H, M, L Inactive user accounts are automatically disabled.

UM-5 H User account change (i.e. modifications or updates) notifications are communicated to the individual users using out-of-band channel outside of the application user interface (e.g., by email).

UM-6 H, M, L, U

Privileged user accounts are separate from normal user accounts.

UM-7 H Automatic notifications of any changes of status in user accounts (e.g., new user account is created or changes of user privileges) are generated.

Credential Management

CM-1 H, M, L When passwords are generated/regenerated through an automated process, these passwords are required to change upon first login by the user.

CM-2 H, M, L Password complexity, expiry and reuse policies are enforced as required by the OCIO Password Management Standard.

CM-3 H, M, L Default passwords are changed upon successful installation.

CM-4 H, M, L Passwords entered by users are not echoed on the screen without masking.

CM-5 H, M, L Passwords are securely encrypted or hashed in transmission and storage.

CM-6 Optional For PKI-based authentication, certificate validity must be verified before granting authorization.

CM-7 Optional For PKI-based authentication, access to the private keys is restricted.

CM-8 Optional For PKI-based authentication, binding of authenticated identity to the user account is implemented.

Entity Store ES-1 H, M, L Storage of user identifiers, credentials and access authorization is securely protected from unauthorized disclosure and modification.





of 90

Updated 2018-04-06

ES-2 H, M, L Entity (user ids, passwords and authorization data) lifecycle management processes such as user registration, issuance, modification, revocation, expiry and termination are supported.

ES-3 H, M, L Use of the OCIO Active Directory as entity store for internal users is recommended.

ES-4 H, M Separate and controlled management access from normal traffic to entity store (e.g., by deploying on different servers) is supported.

ES-5 H, M, L Credentials are stored in encrypted or one-way hash formats only.

Confidentiality CF-1 H, M, L FIPS 140-2 compliant cryptographic algorithms are supported.

CF-2 H, M, L Credentials or authentication tokens are not sent in clear-text over the network.

CF-3 H, M, L TLS transport security with asymmetric key length of at least 2048 bits is used for communicating sensitive information in transit.

CF-4 H, M, L Public SSL certificates issued by a verified / trusted signing authority (e.g. VeriSign) are used for all secure public-facing web applications.

CF-5 H, M, L Private SSL certificates issued by the OCIO internal CA are used in any communication for internal web application or between tiers in an n-tier system when there is no human interaction required.

CF-6 H, M, L Sensitive information is kept inside the data tier in an n-tier system except for minimum processing requirements.

CF-7 H Sensitive information (e.g., files) is encrypted while in storage outside of database.

CF-8 H Column or table encryption technology is enabled.

CF-9 H, M, L Credentials imbedded in the application code, configuration files, connection strings and scripts, etc., are protected from unauthorized disclosure (e.g., by encryption or hashing).

CF-10 H Endpoint encryption on mobile client devices is deployed.





of 90

Updated 2018-04-06

CF-11 H, M, L Production data is not used in non-production environments without sanitization or masking of sensitive fields.

Integrity IT-1 H, M, L, U

The integrity of configuration files is protected from unauthorized modification and corruption.

IT-2 H, M, L, U

The integrity of data is protected from unauthorized modification and corruption.

IT-3 H, M, L, U

Application frameworks are leveraged to provide transaction management.

IT-4 H, M, L, U

Referential integrity check is enforced when updating database tables.

IT-5 H Cryptographic checksum (e.g., SHA-2) is used to protect the integrity of data.

IT-6 H Cryptographic checksum (e.g., SHA-2) is used to protect the integrity

of executable and configuration files.

IT-7 Optional X.509 digital signature is used to protect the integrity of data.

IT-8 Optional X.509 digital signature is used to protect the integrity of executable files.

IT-9 Optional X.509 digital signature is used to protect the integrity of mobile codes (e.g., ActiveX or Java Applet).

Logging LG-1 H, M, L The following standard logging is supported:

Changes to user accounts, user names, password and role changes or resets;

Login and logout/time out stamps for users;

Activity that may indicate a threat to the system; and

Failed access attempts.





of 90

Updated 2018-04-06

LG-2 H, M, L The following valid information is collected within each audit log event:

- User IDs;

- Dates, times and details of key events (e.g. log-on and log-off);

- Terminal identity or location, if possible;

- Records of successful and rejected system access attempts;

- Records of successful and rejected data and other resource access attempts;

- Changes to system configuration;

- Use of privileges;

- Use of system utilities and applications;

- Files accessed and the kind of access;

- Network addresses and protocols;

- Alarms raised by access control system; and

- Activation and deactivation of protection systems (e.g. anti-virus systems and intrusion detection systems).

LG-3 H, M, L Normal and privileged user activities are logged in accordance with

security and compliance requirements.

LG-4 H, M, L Sensitive information is not captured in the logs while meeting the security and compliance requirements.

LG-5 H, M, L, U

Sufficient log storage capacity is allocated.

LG-6 H, M, L, U

Log administrators are alerted in real time in the event of log processing failure (e.g., hardware failure or when the storage capacity is full).





of 90

Updated 2018-04-06

LG-7 H, M, L, U

Appropriate and secure actions are taken in the event of log processing failure.

LG-8 H, M, L, U

Synchronized network timeservers are used to generate timestamps.

LG-9 H Cryptographic mechanisms (e.g. encryption or hashing) are used to protect the confidentiality and integrity of log files.

LG-10 H, M, L, U

Access to log files is restricted to a subset of privileged administrators.

LG-11 H, M, L Logging of individual components or devices in a system is centralized (e.g., to management or reporting console).

LG-12 H, M, L Log records are compiled (or converted) in standardized format.

LG-13 H, M, L, U

Logging tools or frameworks that support multiple log levels are implemented.

LG-14 H, M, L, U

Logging level is controlled by configuration file or database entry, not by code changes.

LG-15 H

Logging of individual user access to sensitive data fields (e.g., read,

write or delete operations) is implemented and enabled at all tiers of

systems.

LG-16 H Security log events are sent to specified external log systems (e.g., SIEM product).

Auditing AU-1 H, M, L, U

Auditable records that contain sufficient information to establish type of event, timestamp, source, outcome (success or failure) of the event, and the identity of any user/subject associated with the event are produced.

AU-2 H An auditing feature is implemented to support investigation of security incidents including normal and privileged user actions.

AU-3 H, M, L, U

The integrity and confidentiality of the audit trail is protected online and offline.





of 90

Updated 2018-04-06

AU-4 H, M, L, U

Audit trail is retained and disposed to meet security and compliance requirements (e.g., writing to a write-once only CD).

AU-5 H Automated audit log analysis is performed natively to detect abnormal activities and alert security administrators.

Non-Repudiation NR - Consult with the OCIO.

Backup and Recovery

BR - Consult with the OCIO.

Disaster Recovery DR - Consult with the OCIO.

Business Continuity

BC - Consult with the OCIO.

Table 4 - Minimal Security Physical Control Requirements for the OCIO

6.4 Use of Cryptography

Proper use of cryptography in algorithms or protocols is crucial in information security and any improper use may actually foster a false sense of security. Consequently, it is important to set the baseline in using cryptography.

Table 5 provides information on the OCIO’s Cryptographic Requirements.





of 90

Updated 2018-04-06

Cryptographic Control Algorithm / Protocol

Strength (bits) Comments

Symmetric Key Cryptosystems

AES 256 AES is the primary choice.

Triple DES 168 DES is used for existing applications and backward compatibility only and not allowed for “high” sensitivity information.

Public Key Cryptosystems RSA 2048 RSA is the primary choice.

DH 2048 RSA should be used wherever possible.

ECC 256 ECC may be considered for a constrained environment such as smartcards. RSA should be used wherever possible.

Block Cipher Modes CBC, CTR, RC4

Algorithm Dependent

ECB is not allowed.

RC4 for Beast Mitigation Only

Digital Signature RSA 2048 RSA is the primary choice.

DSA 2048 RSA should be used wherever possible.

ECDSA 256 ECC may be considered for constrained environment such as smartcards. RSA should be used wherever possible.

Pseudorandom Bit (number) Generator

Hash_DRBG, HMAC_DRBG, CTR_DRBG, Dual EC DRBG

Algorithm Dependent

See detail in NIST SP800-90.

Should be seeded with adequate entropy such as keyboard, mouse, disk, and processes activities. Time of day alone is not acceptable as seed.





of 90

Updated 2018-04-06

Hashing SHA2 256, 384, 512 SHA2 is the primary choice.

MD5 is not allowed for cryptographic operations.

SHA1 160 Non-digital signature generation applications. SHA2 should be used wherever possible.

SHA3 Whenever it is officially approved by NIST.

Message Authentication Codes (MACs)

HMAC, CMAC, CCM, GCM, GMAC

Algorithm Dependent

The shared keys must be kept secret.

Applications TLS Web Client-Server Communications

Algorithm Dependent

TLS (public SSL certificates for Internet facing web applications).

SSL hardware accelerators may be required for better SSL performance.

TLS Inter-Tier Communications

Algorithm Dependent

One-way or two-way TLS (private SSL certificates issued by an OCIO CA).

TLS Web Services Algorithm Dependent

TLS with password or SSL mutual (2-way) authentication.

FTPS, SFTP Algorithm Dependent

SFTP or FTPS or OCIO approved Managed File Transfer solution.

SMTPS Algorithm Dependent

SMTP over SSL.

LDAPS Algorithm Dependent

LDAP over SSL.

Kerberos Algorithm Dependent

Kerberos for Windows domain communications.





of 90

Updated 2018-04-06

Secure Email Algorithm Dependent

S/MIME, PGP.

Transport TLS v1.1,1.2 Algorithm Dependent

SSH v 2 Algorithm Dependent

SSH v 1 is not permitted. SSH Key is preferred to password authentication.

Network IPSEC Algorithm Dependent

TLS is preferred. Network encryption via IPSec is not a preferred mechanism for securing communications due to the fact that in some cases, it has the ability to tunnel everything depending on which IPSec stack is used. The effect is that it bypasses the firewall security mechanisms and can allow open access between hosts. The project team should consult with EA before considering the use of IPSec.

DataLink MACSEC Algorithm Dependent

TLS is preferred.

WLAN WPA2

802.1X EAP-TLS, TTLS, PEAP (or EAP-MSCHAPv2)

Algorithm Dependent

WPA is acceptable for legacy systems for backward compatibility only.

Database TLS for link communication

Algorithm Dependent

Oracle databases will require additional Advanced Security Option (ASO).





of 90

Updated 2018-04-06

Column, or table encryption

Algorithm Dependent

Oracle databases will require additional Advanced Security Option (ASO) for Column Encryption. SQL Server Enterprise Edition is required to get Data Encryption for SQL Server.

FIPS 140-2 Hardware Security Module (HSM) is preferred.

Web Services OASIS WS-Security Suite

Algorithm Dependent

In cases where end-to-end security cannot be achieved by securing the network transport layer (e.g. if TLS is terminated at some intermediary points and propagated unencrypted between the source and destination).

Backup Data Source and Target Algorithm Dependent

High and Medium Confidentiality Classification.

Not required Algorithm Dependent

Low Confidentiality Classification.

Crypto API MS CAPI + CNG (Windows platforms),

openssl (C/C++ Unix platforms) , and

certified JCE providers (Java platform).

Algorithm Dependent

Use the latest version only.

Endpoint devices Approved disk or USB drive encryption products

Algorithm Dependent

Consult with the OCIO.

Hardware Security Modules (HSM)

FIPS 140-2 Level 2 or 3 Certified

Algorithm Dependent

SSL accelerators, smartcards, etc.





of 90

Updated 2018-04-06

Cryptographic Key Management

Encryption keys (Symmetric or asymmetric)

Algorithm Dependent

Key escrow or recovery is required.

Signature keys Algorithm Dependent

No key escrow or recovery is required.

Authentication keys Algorithm Dependent

No key escrow or recovery is required.

X.509 digital certificates

Algorithm Dependent

All certificates should be either signed or public CA or OCIO approved private CA. Self-signed certificates are not allowed.

All certificates should be checked for validity using CRL or OCSP protocols

Table 5 - Cryptographic Requirements for the OCIO

6.5 Application Level Security Requirements

6.5.1 N-tier Application Security Requirements

Table 8 depicts the OCIO’s N-tier Application Security Requirements.





of 90

Updated 2018-04-06

Application Security Code Description

System Architecture AR-1 Use three-tier architecture consisting of a web / application server front-end, a separate application server hosting the business logic as the middle tier and third server hosting the database as the data-tier. Note that reverse proxy is not considered as a replacement for presentation tier.

Three-tier architecture is required for:

high sensitivity internal systems (Internet access is not permitted for high sensitivity systems);

medium sensitivity systems with internet-facing components

Two-tier architecture is required for:

medium sensitivity internal systems;

Low sensitivity or unclassified systems of all types.

AR-2 Presentation layer contains only presentation logic and initial validations.

AR-3 Apply input validation between each tier. Validate on received inputs and when invoking services in other tiers.

AR-4 Use input validation to ensure:

Inputs are expected;

Inputs conform to expected size, type and format;

Input does not contain malicious code; and

Untrusted data is encoded in the target destination’s encoding scheme.

AR-5 IP’s must not be hard-coded in applications or systems for production purposes.

Session Management SM-1 Authorization logic is conducted on the business logic tier of an n-tier system.





of 90

Updated 2018-04-06

SM-2 Store session data in the database (medium and high sensitivity information).

SM-3 Initialize session management upon successful login. Any session credentials issued prior to login are destroyed or ignored upon successful login.

SM-4 Use encrypted links (TLS) for all authenticated activity.

SM-5 Timeout on inactivity is set to:

No more than one half hour (high sensitivity information);

No more than 3 hours (medium sensitivity information); and

No more than 24 hours (low sensitivity information).

Error Handling

EH-1 Incorrect username or password is not indicated in a login error message.

EH-2 Stack traces do not include information about application variables, paths and other configuration / infrastructure components in an error message.

EH-3 Server errors do not provide version and patch information about the Web / Application server in an error message.

EH-4 Generic error messages are returned to the user for any failures that are unexpected or do not need specific handling.

Administrative Interfaces AI-1 Deploy administrative components to separate infrastructure from the application (high sensitivity information).

AI-2 Restrict access to administrative components to administrators only.

Web Application Security





of 90

Updated 2018-04-06

Input Validation

WS-1 For string form variables, the set of characters does not contain escape characters, or other string information that may be used for SQL injection, buffer overflows and Cross Site Scripting (XSS) code.

Select a set of characters that are valid for the field in question. For example, names should only contain characters A-Z, a-z, space, “-“and “’”.

WS-2 If the file uploaded is in a well-known format, such as a text or comma delimited document, to be read directly into the application, the application performs character field validation (see above).

WS-4 As soon as an input validation process identifies that the attached file is not following the expected input rules, it shall be removed from the system.

WS-5 Encode all user input to prevent XSS (XSS is a situation whereby adding JavaScript into a textbox / textarea allows a malicious user to execute a script on the client that could send information to a third party site).

WS-6 Encode all HTML output and data returned to the user to prevent XSS (“>” changed to > etc.).

WS-7 When combo or drop down boxes are submitted by a web browser, type check the values are integers or in an expected range based on the HTML form.

WS-8 Validate every form field value (e.g., character and maximum length).

WS-9 Use parameterized SQL (or stored procedures) to access database tables and views. Any SQL, particularly dynamic SQL, references the database method parameters and not the form field values.

WS-10 The information is validated by the receiving server and do not rely on JavaScript to validate form values.

Sensitive Data WS-11 Form and session values such as cookies and session variables are encrypted on the server end and validated on each page submission.

WS-12 Any files that contain sensitive information such as the web.config file in .Net are encrypted.





of 90

Updated 2018-04-06

WS-13 No Personally Identifiable Information (PII) is stored in cookies Store the information on a protected database and store a hashed or encrypted ID in the cookie. Alternatively, store sensitive information on a persistent session object, provided the information is encrypted and the information is never sent to the browser.

Page Authentication WS-14 Authenticate every HTML form submission by the receiving method using the user and the form name. The user name is taken from the database and not from a form variable. Database or application roles and permissions are used. Enforce authentication on a form-by-form basis.

POST instead of GET Method

WS-15 When submitting an HTML form, POSTs instead of GETs are used. GETs are easier for hackers to target. GETs may also store the form variables in the URL and that information is stored in bookmarks, history, log files, etc.

Form Variables and Values WS-16 Variables are not passed via the form (hidden or regular form variables).

System Calls WS-17 The use of “exec” and “eval” type procedures that make system function calls or have the potential to allow malicious code to be executed on the server are avoided. If calls to those functions are necessary, use hard coded values and do not supply parameters directly from the user. Restrict the parameter values to a known range of values.

Public Methods WS-18 Each public method that is accessible from the Internet contains or employs authentication tokens and/or programming that checks the user permission and the session information, including session timeout, etc.

Debugging Code WS-19 Any debugging code, including HTML comments from production code is removed.

Backdoor Access WS-20 Development accounts or methods that circumvent a valid login are not in any production environment. Circumventing logins in Testing and Development environments is also discouraged.

Administration Operations WS-21 Administration operations such as account creation, account unlocking is limited to specific IPs on private network and not generally accessible.





of 90

Updated 2018-04-06

Use of AUTOCOMPLETE WS-22 .Disable AUTOCOMPLETE on forms capturing sensitive information. Consult EA on acceptable use cases.

Table 6 – N-Tier Application Security Requirements





of 90

Updated 2018-04-06

7. Deviations and Exemptions

Project teams should make every effort to implement solutions that are compliant with the OCIO’s principles and practices defined in this document. However, there may be compelling business reasons to request either a deviation or an exemption. A deviation is defined as non-compliance with OCIO Guidelines and Best Practices where an acceptable alternative, or compensating control, is being employed. An exemption is defined as non-compliance with OCIO guidelines and Best Practices where NO alternative, or compensating control, is being employed. If the best solution deviates, or is exempted, from the OCIO’s guidelines, EA approval is required. The EA Deviation/Exemption Process outlined below must be followed.

7.1 Deviation & Exemption Process

EA employs a process for any Deviations/Exemptions to be presented to EA for review and subsequent approval or rejection.

The steps required for a Deviation or Exemption includes:

1. Contacting your EA assigned Prime to clarify whether a Deviation or Exemption is necessary;

2. Submitting a formal request to [email protected] for a Deviation or Exemption approval. The request must document the justifications for the Exemption or Deviation and the impact(s);

3. The EA assigned Prime will assess the request and forward any recommendations to the Manager of EA for review;

4. If a Deviation or Exemption approval is granted, the approval must be in writing and state clearly the business reasons for granting the exception. The approval must be submitted to [email protected]; and

5. The approval, along with the approver’s contact information must be included in Section 3.3 of the DAD.





of 90

Updated 2018-04-06

8. Glossary

Word / Acronym Definition

AES Advanced Encryption Standard

ANSI American National Standards Institute

ASCII American Standard Code for Information Interchange

ASO Advanced Security Option (Oracle)

CIS Center for Internet Security

COTS Commercial-off-the-Shelf

DBA Database Administrator

DBMS Database Management System

DES Data Encryption Standard

DMZ Demilitarized Zone

EA Enterprise Architecture

FIPS Federal Information Processing Standards

FTP File Transfer Protocol

FTPS File Transfer Protocol Secure

Government Government of Newfoundland and Labrador

HTML Hypertext Mark-up Language





of 90

Updated 2018-04-06


IP Internet Protocol

IPSec Internet Protocol Security

LDAP Lightweight Directory Access Protocol

MD5 Message-Digest Algorithm 5

MFT Managed File Transfer

NIST National Institute of Standards and Technology

OASIS Organization for the Advancement of Structured Information Standards

OCIO Office of the Chief Information Officer

OWASP Open Web Application Security Project

OS Operating System

PARB Project Architecture Review Board

PGP Pretty Good Privacy

RSA Rivest, Shamir and Adleman

SaaS Software as a Service

SDLC Systems Development Life Cycle

SFTP Secure File Transfer Protocol

SHA Secure Hash Algorithm





of 90

Updated 2018-04-06


SMTP Simple Mail Transfer Protocol

SoC Separation of Concerns

SSH Secure Shell

SSL Secure Sockets Layer

TLS Transport Layer Security

UI User Interface

VPN Virtual Private Network

W3C World Wide Web Consortium

WS-S Web Services Security

XHTML Extensible Hypertext Mark-up Language

XSS Cross Site Scripting

Table 7 – EA Technology Binder Definitions and Acronyms





of 90

Updated 2018-04-06

Appendix A: Application Security

Secure Systems Development Lifecycle

Custom and COTS applications should consider security and privacy concerns early in the SDLC processes and adopt secure application development best practices including threat modeling, secure coding, code review and testing methodologies to ensure programmatic and logic vulnerabilities are detected and eliminated. Develop a set of related security requirements for each functional requirement. Attack Use Cases are a useful means of identifying all the ways in which a system can be attacked and in designing and implementing multiple controls protecting against the identified attacks. The source code of custom applications should be protected from unauthorized access or modification. The OCIO may request vendors of COTS or custom application solutions to provide sufficient evidence such as third party certification or perform independent review activities such as static and/or dynamic scanning of delivered applications to validate the security quality of the supplied software in meeting with the OCIO security standards.

Web Application Security

Limit User Feedback on Login Pages

On failed login attempts by the user, do not return the password or username back to the form. It is reasonable to force the user to retype both their username and password for login pages.

Limit Inputs and Interfaces

Limit interfaces to components at all levels. The more inputs there are to an interface, the more opportunity there is for a malicious user to provide a well-crafted attack. Input and interfaces should be minimal.

Critical Web Application Security Project (OWASP)

Refer to the Open Web Application Security Project (OWASP) Top 10 Web Application Security Risks (http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project)xi. This should be considered part of the best practices to be consulted.

Leverage Existing Secure Code Libraries and Resources

OWASP has initiated a project called the Enterprise Security Application Programming Interface (ESAPI). ESAPI is a free, open source web application security control library that makes it easier for programmers to write lower-risk applications. The ESAPI libraries are designed to make it easier for

http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project





of 90

Updated 2018-04-06

programmers to retrofit security into existing applications as well as serve as a solid foundation for new development.

Integration of these libraries within existing and new development should assist developers in both fixing old apps and ensuring new ones stay secure.

https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

In addition, OWASP has developed a series of Cheat Sheets to provide a concise collection of high value information on specific web application security topics. These Cheat Sheets were created by application security professionals who have expertise in specific topics. The Cheat Sheets cover a wide range of topics that can be useful for assisting developers fix potentially vulnerable code as well as ensuring developers write more secure code.

The following is a list of OWASP Developer Cheat Sheets that are currently available:

Authentication Cheat Sheet

Choosing and Using Security Questions Cheat Sheet

Clickjacking Defense Cheat Sheet

C-Based Toolchain Hardening Cheat Sheet

Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

Cryptographic Storage Cheat Sheet

DOM based XSS Prevention Cheat Sheet

Forgot Password Cheat Sheet

HTML5 Security Cheat Sheet

Input Validation Cheat Sheet

JAAS Cheat Sheet

Logging Cheat Sheet

.NET Security Cheat Sheet

https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API





of 90

Updated 2018-04-06

Password Storage Cheat Sheet

Pinning Cheat Sheet

Query Parameterization Cheat Sheet

Ruby on Rails Cheat Sheet

REST Security Cheat Sheet

Session Management Cheat Sheet

SQL Injection Prevention Cheat Sheet

Transport Layer Protection Cheat Sheet

Unvalidated Redirects and Forwards Cheat Sheet

User Privacy Protection Cheat Sheet

Web Service Security Cheat Sheet

XSS (Cross Site Scripting) Prevention Cheat Sheet

Cloud Computing

Cloud computing is an attractive business model that allows organizations the ability to rapidly provision and release computing resources elastically without significant initial capital investment. However, in case of public clouds, service providers must address specific security and privacy requirements particularly with regard to the OCIO data residing inside the providers’ IT environments. Cloud providers should demonstrate that their security standards follow the cloud security best practices recommended by NISTxii, Cloud Security Alliancexiii or Jericho Forumxiv.

Mitigating TLS Vulnerabilities

The Problem

Security protocols SSL 3.0 and TLS 1.0 are subject to an attack against CBC cipher suites (CVE-2011-3389). Attacks against SSL have been around as far back as 2001 however it was considered not practical to carry out these attacks at the time. Recently new attacks have been developed that have demonstrated that the attack is practical to be carried out. BEAST (Browser Exploit Against SSL/TLS) is one of these attacks.





of 90

Updated 2018-04-06

The BEAST attack does nothing to harm back end servers; the vulnerability is against the client browsers in that it has the ability to allow an intruder to steel authentication cookies and other credentials and pose as the legitimate user of the credentials.

The Mitigation

Beast can be mitigated by increasing the priority of the RC4-based cipher suites over block-based cipher suites as RC4 does not use CBC. RC4 is not considered as cryptographically strong as AES, but is considered stronger than AES using a CBC cipher when considering mitigation for BEAST

Keep in mind that the mitigation is only required for servers and sites that only support SSL 3.0 and TLS 1.0. Sites and browsers that support TLS 1.1 and 1.2 do not require this mitigation as the issue has been addressed in these versions.

Adoption of TLS 1.1 and 1.2 protocols has been slow; therefore disabling TLS 1.0 is not a good mitigation strategy as it will break a large number of clients connecting to sites because of compatibility issues. Latest stats from Wikipedia puts support for TLS 1.1 and 1.2 at 14.5% and 17.0% consecutively.

The best approach to mitigate is a two pronged approach where we prioritize ciphers belonging to TLS 1.1 and 1.2 first and then have the RC4 ciphers follow as fallback for clients that do not support the newer protocols. This gives the best of both worlds where the clients that are capable of supporting the secure protocols can use them and the ones that can’t fall back to RC4 ciphers that will also mitigate the BEAST attack. As client browsers and servers move to TLS 1.1 and 1.2, this approach automatically allows for client progression to happen without any intervention.

Currently the SDI group have created a Windows GPO to be installed on all new web servers and any new web servers on Linux will also have the cipher prioritization enabled.

Windows Mitigation: (Registry changes to prioritize Cipher Suites)





of 90

Updated 2018-04-06

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256

TLS_RSA_WITH_RC4_128_SHA

TLS_RSA_WITH_AES_128_CBC_SHA256

TLS_RSA_WITH_AES_256_CBC_SHA256

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384

Linux Mitigation: (Apache Config)

SSLHonorCipherOrder On

SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-

SHA256:RC4:HIGH:!MD5:!aNULL:!EDH

The idea is that you put a few TLS 1.2 cipher suites first so that they can be picked up by TLS 1.1 and

1.2 clients, which are not vulnerable, followed by RC4 for TLS 1.0 clients.





of 90

Updated 2018-04-06

Appendix B: Backup and Recovery

Purpose of Data Backups

Data Backups are created to enable the recovery of electronic data in the event of a disaster or other event that disrupts normal business operations.

Data Backup Types

The type of information that is backed up includes:

E-mail;

Files stored on the network in shared drives and personal drives;

Databases;

Applications; and

Operating system data.

Data Backup Process

The OCIO manages backups on more than 1000 servers within the Government of Newfoundland and Labrador. All servers are scanned for changes to the file system (additions, modifications, deletions and movement of data) and those changes are recorded in a database. All additions and modifications are sent over the network to the backup system, where they are written to a virtual tape library. When written, all changes to the tapes are copied to a second tape library in a different building/location.

Data Included in the Backup Process

Files on local hard drives are not backed up by the OCIO. It is recommended that employees save Government of Newfoundland and Labrador information on network drives (shared drives and personal drives) and not on desktop/laptop (s) or other local computer hard drives.

Remote Data Backups

In cases where a network drive is not available and data must be stored to a local hard drive, the OCIO recommends making a secure copy of the data for local backup purposes. This can be done using a number of methods including: secure USB drive, encrypted CD/DVD, etc. Users should review the Information Protection information on the OCIO’s website http://www.ocio.gov.nl.ca/protection/faqs.htm.





of 90

Updated 2018-04-06

Data Backup Schedules

Backups run seven days a week, 365 days a year. All backups run within the defined “backup window” of 10:00 PM to 6:00 AM daily.

Data Access during Backups

Files and applications are available during backups. Currently, some databases still require to be taken off line, also known as Cold Backups, during the backup processes. However, the OCIO is in the process of moving these databases to regular online Hot Backups instead of the traditional Cold backups.

Deleted and Overwritten Data

Deleted or overwritten files can be recovered as long as users are aware of the action and contact the OCIO Service Desk via phone or email within 30 days of the action.

Backup Tape Retention Considerations

Backup tapes remain in use until they reach the end of the manufactures recommended lifespan or show evidence of errors. At that point, data contained on the tape is copied to new media and the old media is destroyed using secure shredding.

Backup Data Retention Periods

The OCIO has a 30 day retention period, which is an industry best practice for the purpose of maintaining business continuity and recovering from disaster. Information that is greater than 30 days old and exists on the system will continue to be backed up.

Backup Data Older Than 30 Days

Any information that exists on the system being backed up will continue to be backed up on a regular basis. The data will exist for 30 Days after it has been deleted or modified.

The examples below illustrate how older data is managed:

Data addition – A client creates and saves a file to a network drive. That file will be copied to tape the next night and remain on tape as long as that file exists and remains unmodified and unmoved in its original location;

Data modification – A client modifies and saves over an existing document. The new version of that file will be written to tape the next night and treated as a data addition. The old version, or overwritten file, will remain on backup tape for 30 days before being erased;





of 90

Updated 2018-04-06

Data deletion – A client deletes a file from a network drive. When the backup runs the next night, the backup system will note the absence or removal of the file and flag its removal from tape in 60 days; and

Data move – A client drags/drops or cut/pastes a file from a network drive. When the backup runs the next night, the backup system will note the absence of the file from its original location and treat it as a data deletion. The file in its new location will be treated as a data addition.

Exemptions to Data Retention Periods

Departments requiring exceptions to the 30 day retention policy must identify their needs to the OCIO and obtain the appropriate approvals for exemption. Exceptions will be considered when a department can demonstrate a legislative, legal or operational requirement for a longer retention period.





of 90

Updated 2018-04-06

Appendix C: OCIO Network Architecture

Network Best Practices

Components and principles adopted from the International Organization for Standardization (ISO) network management model, the TOGAF and ITIL frameworks, industry vendors and Security Blueprints for Enterprise Networks form part of our enterprise network best practices from industry vendors. . These areas provide practical reference architectures on the different functional areas for network infrastructure and data communications.

Network and security applies to:

All equipment connected to the government networks;

Any IP network to which the Government of Newfoundland and Labrador network equipment is connected;

Project teams requiring new equipment to be connected to the network;

Any IP networks across government;

Data in transit, across government managed networks;

All users connected to the network; and

Network administrators managing the network infrastructure and related equipment.

Security

Managed security gateways provide connectivity and access control between the internal government network and other networks such as the Internet. Security gateways and technologies currently available and supported by the OCIO include:

Network Firewalls;

Application Delivery Controllers;

Web Application Firewalls; and

Secure Web Gateways providing filtering and packet inspection technologies to ensure integrity and availability of services.





of 90

Updated 2018-04-06

Architecture Components

This section details the roles of network and security components, its primary function and how it integrates into the overall enterprise architecture. For additional information, please consult with EA.

Component Primary Role Security Function

Border Routers Provide upstream connectivity to Internet Service providers and screen traffic coming into the network perimeter.

Ingress and Egress network filtering as per IANA bad source addresses.

Flood defense.

Address leak prevention or propagation.

Prevention of spoofed RFC 1918 source address space.

Perimeter / Border Switches

Provide LAN connectivity for public facing services and systems.

Physical and logical isolation from internal networks.

Perimeter Firewall w/IDP

Gatekeeper for access control to external networks to permit or deny traffic based on a series of rules or policies. Also serves to monitor overall traffic for suspicious events and correlation.

Segregate DMZ traffic.

Segregates extranet traffic from Intranet traffic.

Block all inbound and outbound traffic not specifically authorized.

Main choke point for all inbound traffic from the Internet.

Corporate / Internal Firewall w/IDP

Gatekeeper for access control to internal networks, to permit or deny traffic based on a series of rules or policies.

Serve to monitor overall traffic for suspicious events and correlation

Segregate perimeter traffic from Intranet traffic.

Block all inbound and outbound traffic not specifically authorized.

Main choke point for all inbound traffic through the perimeter firewall and outbound traffic from the corporate networks.

SSL VPN Leverage the Internet in connecting to government resources in a secure manner.

Segregate access through user groups and networks to infrastructure or applications.

Encrypt traffic between client and government networks.

Access control to external and internal networks or applications.

Function as two factor authentication remote access.





of 90

Updated 2018-04-06

Component Primary Role Security Function

FortiWeb (Proposed)

High-Performance Web Application Security

To be updated following full implementation of the proposed solution.





of 90

Updated 2018-04-06

Appendix D: Supportability Matrix

SDLC Deliverables

During acquisition activities, an Initial Supportability Matrix will be completed by the procurement or tender respondent or a solution architect for custom-built solutions.

A Final/Confirmed Supportability Matrix requires completion or amendment by the project team during the Execute Phase and will be attached to the SDLC Transition Agreement to ensure that the minimum 24 months support requirement following transition is achieved or exceeded.

Transition Agreement Sign-off involving the Project Delivery team and Application Support representatives, occurring between the Execution and Implementation Phases, will review the Transition Agreement with attached Supportability Matrix to determine if the solution still meets or exceeds the minimum 24 month support lifecycle following transition.

The supportability matrix below is a SDLC deliverable for each project and will be completed at various phases to ensure that a solution is fully supported by a vendor for a period of 24 months following project transition.





of 90

Updated 2018-04-06

Supportability Matrix:

Technology Name Version Support Provider End Date of Vendor Support

Operating System(s):

1

2

3

Application(s):

1

2

3

Development Languages/Frameworks/Compilers (non-COTS solutions, if applicable):

1

2

3

Database Management System(s) (if applicable):

1

2

3

Infrastructure (Servers, Storage, Network Switches, Firewalls, etc.) (if applicable):

1

2

3

Supporting Software (e.g., Middleware, etc.):

1

2

3

Other(s):

1

2

3

Table 8 - Supportability Matrix





of 90

Updated 2018-04-06

i The internal definition of mainstream support is support by a vendor whether included in a traditional support contract or as an added cost. ii Note that the term database used in this pattern may be interpreted more generally as any type of data store. Though the OCIO’s information systems most frequently use relational databases, these patterns are meant to extrapolate well to other types of data stores. iii Submitted inputs must be (a) expected, (b) of an expected size, type and format and (c) scanned for malicious code and viruses, where appropriate. iv Submitted inputs must be (a) expected, (b) of an expected size, type and format and (c) scanned for malicious code and viruses, where appropriate. v Submitted inputs must be (a) expected, (b) of an expected size, type and format and (c) scanned for malicious code and viruses, where appropriate. vi Note that the term database used in this pattern may be interpreted more generally as any type of data store. Though the OCIO’s information systems most frequently use relational databases, these patterns are meant to extrapolate well to other types of data stores. vii Note that the term database used in this pattern may be interpreted more generally as any type of data store. Though the OCIO’s information systems most frequently use relational databases, these patterns are meant to extrapolate well to other types of data stores. viii Note that the term database used in this pattern may be interpreted more generally as any type of data store. Though the OCIO’s information systems most frequently use relational databases, these patterns are meant to extrapolate well to other types of data stores. ix This approach is similar to the one used by ISO/IEC 18028-2:2006 – Information Technology – Security Techniques – IT Network Security – Part 2: Network Security Architecture x Some of the physical controls are based on NIST Special Publication 800-53 Recommended Security Controls for Federal Information Systems and Organizations

xi http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

xii http://csrc.nist.gov/publications/drafts/800-144/Draft-SP-800-144_cloud-computing.pdf xiii https://cloudsecurityalliance.org/ xiv http://www.opengroup.org/jericho/

http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

http://csrc.nist.gov/publications/drafts/800-144/Draft-SP-800-144_cloud-computing.pdf

https://cloudsecurityalliance.org/

http://www.opengroup.org/jericho/

Enterprise Architecture Guildlines and Best Practices for ... and Best Practices... · Guidelines...

Documents

Transcript of Enterprise Architecture Guildlines and Best Practices for ... and Best Practices... · Guidelines...