progeny security architecture · 2013-08-07 · progeny security architecture 5 database security...

Progeny Security Architecture Ensuring Secure Access to Your Data

Rev 1.0

Contents

Overview ............................................................................................................................... 4

Database Security .................................................................................................................. 5

Data Transport Security ............................................................................................................................................ 5

Data Store Security .................................................................................................................................................... 5

Network Security ....................................................................................................................................................... 5

Securing the Operating System ................................................................................................................................. 6

Database Access Security .......................................................................................................................................... 6

Enable Database Auditing ......................................................................................................................................... 7

Application Security .............................................................................................................. 8

Progeny Desktop ....................................................................................................................................................... 8

Authentication ...................................................................................................................................................... 9

Creating Progeny Users ........................................................................................................................................... 10

Application Level Security ................................................................................................................................... 10

User Classes .................................................................................................................................................... 10

Modules or Functions ..................................................................................................................................... 10

Folders ............................................................................................................................................................ 10

Fields ............................................................................................................................................................... 10

Progeny Objects/Entity Security ..................................................................................................................... 10

Other Security Aspects of Progeny Desktop ................................................................................................... 11

User Identification and Authentication ...................................................................................................... 11

Application Level Auditing.......................................................................................................................... 11

Transport-Layer Security (TLS) ................................................................................................................... 11

Database Level Security ............................................................................................................................. 11

External Access Protection ......................................................................................................................... 11

Login Auditing ............................................................................................................................................ 11

Customizable Validations Module.............................................................................................................. 11

Progeny Web Server ................................................................................................................................................ 12

Trust boundaries ................................................................................................................................................. 12

Applying the OWASP TOP 10 Model to Progeny Web Server ............................................................................. 13

A1 Injection..................................................................................................................................................... 13

A2 Broken Authentication and Session Management .................................................................................... 13

A3 Cross Site Scripting .................................................................................................................................... 14

A4 Insecure Direct Object Reference ............................................................................................................. 14

A5 Security Misconfiguration ......................................................................................................................... 14

A6 Sensitive Data Exposure ............................................................................................................................ 15

A7 Missing Functional Level Access ................................................................................................................ 15

A8 Cross Site Request Forgery ........................................................................................................................ 15

A9 Unknown Vulnerable Components (UVC) ................................................................................................. 16

A10 Unvalidated Redirects and Forwards (URF) ............................................................................................ 16

Other Common Security Threats to Web Applications ....................................................................................... 16

Authentication Attack..................................................................................................................................... 17

Buffer Overruns .............................................................................................................................................. 17

Denial of Service Attack .................................................................................................................................. 17

HTML Injection Attack .................................................................................................................................... 18

Input Manipulation Attack & Trusting the Client’s Authorization .................................................................. 18

LDAP Injection Attack ..................................................................................................................................... 18

Incoming Data Validation ........................................................................................................................... 19

Outgoing Data Validation ........................................................................................................................... 19

Repudiation .................................................................................................................................................... 19

SQL Injection Attack ....................................................................................................................................... 19

General Security Measures Employed In Progeny Web Server .......................................................................... 20

Server Generated User Tokens Have Expiry Time .......................................................................................... 20

Treat All Requests from Internet as Untrusted .............................................................................................. 20

Strong Public Cryptographic Algorithms ......................................................................................................... 21

Measures against Session Stealing ................................................................................................................. 21

Error Reporting ............................................................................................................................................... 21

Patient Signup in FHQ ..................................................................................................................................... 21

Regulatory Compliance ........................................................................................................ 22

What is HIPAA ......................................................................................................................................................... 22

Technical Safeguards ............................................................................................................................................... 22

Access Control ..................................................................................................................................................... 22

Audit Controls ..................................................................................................................................................... 23

Integrity Controls ................................................................................................................................................ 23

Transmission Security ......................................................................................................................................... 23

Progeny Security Architecture 4

Overview

Progeny is the leading software used by genetic researchers currently installed at more than 2000 sites in 78

countries. Used by customers in the heavily regulated health care and health insurance industry; it is imperative

that it not only is an efficient and effective tool for managing health data but that it does so in an environment

where our customers can feel secure about the data they generate and store while at the same time being able to

comply with even the most onerous regulations that govern their industry. Our North American customers have to

comply with HIPAA while customers elsewhere in the world have to comply with regulations in those countries or

regions. At Progeny Software we pride ourselves in creating robust software tools that make it easy for our

customers to become more efficient. We also are constantly looking for ways to make the software more secure

and to help our customers comply with existing and future regulations and/or security needs. This whitepaper will

look at Progeny in terms of how its design meets the security needs of our customers. It also takes into account the

environment in which Progeny typically runs and addresses the security impact of those environments and how

our customers can use that knowledge to enhance their IT and application security. In that vein, the paper will

examine the following main areas in some detail:

Database Security

Application Level Security

Regulatory Issues

In describing the application security we will break down the applications into client server or desktop application,

web server or web application including the customer facing family history tool, integration platform that enables

Progeny to integrate with other external systems. Where appropriate we will apply the Open Web Application

Security Project (OWASP) security model to highlight how Progeny addresses the issues enumerated in this very

well respected security benchmark. All Progeny products depend on and use a common Sybase SQL Anywhere

(SQLA) database engine on the back end. That means that some of the security concerns and approaches are

common as they depend on this database engine. We will address security issues and defense measures that

leverage the Sybase security architecture in the section on database security below. The way in which application

security is approached depends on the technology environment in which these products exist.


Database Security

Sybase SQL Anywhere (SQLA) provides robust and extensive security architecture. In this section we are going to

describe those security aspects of SQLA that are available to us directly as creators of Progeny software products;

as well as describe the SQLA security aspects that our customers can take advantage of depending on how their IT

environment is set up.

Data Transport Security While we are not directly in control of the customer’s database environment we always strongly encourage our

customers to set up the database servers so that the communication between client application (or web server)

and the database server uses the most optimal security setup possible. SQLA provides the ability to secure all

communications between the server and client computers by using the Transport Layer Security (TLS)

communication protocol. The database by default encrypts the login packet. The customer can choose to enable

TLS enabled communication when such communication is expected to occur via public channels such as

unprotected WANs or the wider internet. In most LAN settings the client and the server are inside the same

network perimeter so that the need for TLS enabled communications is not as strong. When TLS is required, any

one of the following methods can be used to accomplish that secure communication.

Digital certificates

Public key infrastructures (PKI) using global commercial certificate authorities

Only server certificates for server authentication

Server certificates in combination with client certificates to enable client authentication

Always encrypt login packets or authentication information

Data Store Security While this aspect of database security is mainly the responsibility of our customers, we at Progeny Software always

advise our customers to place databases in the most secure location. In a client-server configuration, database

servers are to be placed inside the LAN and are secured by tightening both network security and operating system

controls.

Network Security We highly recommend that clients ensure the database server is not directly exposed to the internet. When used

with Progeny web server, the only access to the databases server must be from the web server through a port

through which only local applications running inside the DMZ can pass to reach the database.


Securing the Operating System We advise that the server on which the database services are running is secured by disabling all unnecessary

services and daemons (FTP, Telnet, shared folders and so on) to eliminate the possibility of unauthorized access to

the database because of a security flaw in another piece of software. Finally, all relevant security updates for the

operating system need to be downloaded and installed on a regular basis. Also, care should be taken with respect

to operating system user accounts. Only users with administrator privileges should be allowed to have access to

the database executables and data files. Permissions to start and stop processes should also be tightly controlled

to prevent users from intentionally or accidentally stopping the database server.

Database Access Security

This covers the management of user accounts, permission structures and authentication mechanisms to get access

to the data inside the database. SQLA provides the following ready-made features to help with enhancing the

security of data in databases. Progeny takes advantage of a lot these features, but it is important that customers

take advantage of those features that may not be implemented in the Progeny applications but are available to

database administrators.

Minimum password lengths

Enforce password management policies

Enforce user password expiration by applying the most optimal expiry times

Change the default database administrative user (DBA) password

Do not include passwords in insecure properties files or other ODBC data sources

Limit the number of failed login attempts

Provide administrators with the ability to setup custom login procedure to enforce certain login policies

Administrators have the ability to restrict access to the following key SQLA commands typically accessible from the operating system prompt

o Dbbackup

o dbinfo

o dbinit

o space

o dbstop

o dbstart

o dbunload

o dbconsole

o Dbisql


Backup encryption allows administrators to apply single or even double encryption on the backed up data. Since backed up data are rarely retrieved it is possible to do double encryption without adversely effecting database performance

Data encryption allows administrators to set the database up so that data inside the database can be protected from unauthorized use in the event that someone successfully gains access to the database. It is possible to encrypt:

o The whole database albeit at a high cost in performance

o Only certain tables containing key sensitive personally identifying data where required. This is better in terms of performance

o Only certain columns/fields values in certain tables. This is the best in terms of performance as only the fields/columns that are thusly encrypted will incur extra cost of updates and retrieval

o Store data encryption keys away from the database and use algorithm and possibly web service to retrieve them at runtime

o Apply simple to strong encryption depending on balance with performance

Enable Database Auditing SQLA by default keeps a transaction log which records all activities that modify the database which helps with

ensuring data integrity and also to recover corrupted databases. Administrators are strongly encouraged to set up

SQLA with auditing on to add security-related information to the transaction log, which can be examined at any

time. Auditing information can help identify malicious behavior by logging information about when a user

attempted unauthorized access to the database. The following additional data is stored in the transaction log:

All login attempts whether successful or failed, including their IP addresses of the device of computer from which the request originated.

Accurate timestamps of all events (to a resolution of milliseconds).

All successful and failed permissions checks, including the object on which the permission was checked

All actions that ordinarily require DBA authority to perform

Extra care must be taken to secure database transaction logs as an authorized attacker can reconstruct the whole

database by translating log file transactions. It is therefore advisable to encrypt backup copies of transaction logs

to ensure that a malicious user could not use them to generate all the SQL statements needed to create a

complete copy of the database.


Application Security

In this section we discuss the different ways in which the different Progeny products handle security. This includes

a discussion of the software components that are shared between all the three products and how security is

handled. We will start with Progeny Desktop (FAT Client), then discuss the Progeny Web Server.

Progeny Desktop Progeny Desktop is a client server application written in VC++ and runs only on Windows operating systems. It uses

the Sybase SQL Anywhere client embedded SQL to communicate with a SQL Anywhere database backend. The

diagram below shows the Progeny Desktop architecture.

PROGENY DESKTOP CLIENT (CLIENT SERVER MODEL)

Table 1 - Typical Progeny Desktop client server architecture with the database server and windows based desktop client located inside the same

local area network.

Communication between the client and database server uses the proprietary Sybase CMDQS protocol. By default,

this communication channel between the application (through embedded SQL) and the database server is neither

secured nor encrypted. The login packet consisting of user name and password, however, is secured and encrypted

by default. Progeny provides a way for the customers to choose a level of security they wish to have for their

database including whether or not the database should be encrypted and at what level of encryption.

Some of the core components of Progeny Desktop are packaged into a windows dynamic library that is used by the

other two primarily Java based products. Any installation of the Progeny Web Server, for instance, requires at

least one Progeny Desktop client install that is used for administrative purposes, like setting up application security


and creating and managing users. While LAN based client server applications in general (and Progeny Desktop in

particular) are not as vulnerable to attack as web applications, we recognize that all applications are vulnerable to

some attacks. Below are some of the common security issues that pertain to Progeny Desktop. We also include a

discussion of the full application level security inside Progeny.

AUTHENTICATION

User accounts in Progeny are actually Sybase database user accounts – authentication is accomplished on the

server backend. When deployed in Enterprise environments, Progeny user accounts can optionally authenticate

against Active Directory using an LDAP connector built into the Progeny Web Server. In addition to leveraging the

defense mechanisms provided by SQLA, Progeny incorporates the following techniques to mitigate the risks from

authentication-based attacks:

Strong passwords are encouraged including giving the Progeny administrator the ability to determine what a strong password actually entails. Progeny checks for some minimum levels of strength in the case where customers do not exercise the required vigilance

Administrators can choose the length of time between the creation of new password and when it expires

Expired passwords are archived in encrypted form to avoid password rotation. Administrators can define how many unique passwords are stored before a password can be reused (if setting is 3, then the first password entered cannot be reused until the 4

th password reset)

Users are locked after five consecutive failed login attempts.

The administrator can lock specific user accounts manually whenever he needs to.

Users can be locked after a certain period of inactivity and are not allowed back in the system without further administrator action. Administrators can configure the database so that user accounts that have been inactive for a set amount of time will be automatically locked. This inactivity period is configurable to fit security and infrastructure requirements.

While Progeny user names are available in the database and retrievable by users with administrative privileges, the passwords are secured using a two-layer encryption method which uses (1) the standard Sybase encryption algorithm and (2) a proprietary hashing algorithm with a site-specific salt

All login attempts (successful as well as failed) are logged in the Progeny database. This provides the administrators with the ability to use heuristics to determine those login attempts that are coming from sustained attackers

Progeny provides two entry points into the Sybase database. The primary entry point through which all users are allowed is Progeny user interface. The second is the Sybase Interactive SQL through which users with Sybase administrative privileges are allowed. All non- administrative users are limited to the Progeny user interface for access to the database

In addition to the ability to leverage Sybase’s auditing capabilities, Progeny also provides the ability to log every user connection and disconnect activity including details such as when and where the user logged on from. This can be used to track suspicious activity if and when it arises.


Creating Progeny Users Only the Progeny super users with administrative privileges have the ability to create other users. When users are

created or have their password reset, the password should be communicated to them using a communication

channel that can be trusted. Initial passwords for new user accounts are one-time passwords that expire upon first

login.

APPLICATION LEVEL SECURITY

Progeny application level security is built around folders, Progeny objects or entities such as pedigrees, samples or

individuals, and functional areas of the software called modules. Access to these folders, objects, and modules can

be controlled through user classes (groups).

USER CLASSES Progeny allows administrators to create user classes to help decide which user will have access to what objects,

modules or functional area within the system. An unlimited number of security classes can be created. Folders,

modules and Progeny objects can be assigned to these security classes. The security classes assigned to a user will

determine which of the folders, modules and objects that user will have access to. The type of access afforded by

that user class also determines whether the user will have ability to view, add, modify and/or delete objects from

the system.

MODULES OR FUNCTIONS Progeny is divided into various modules or functional areas. Each module/functional area can be independently

activated or deactivated for each user class. Only users assigned to the same user class as the module or functional

area will have access to that module. It is also possible to grant a user access to specific modules using the user ID.

FOLDERS Each of the modules or functional areas can organize Progeny objects or entities into a hierarchical folder structure.

Users with the right privileges can create these folders and assign them to users classes. Users assigned to the

same user classes are granted granular access to the objects in these folders based on their user class settings. This

structure allows the researchers to organize study subjects in such a way that only certain classes of users are

granted read/write/delete access while other groups may be granted more limited read only access

FIELDS In addition to the system-level fields that are natively integrated into every Progeny database, users are given the

ability to create any number of additional database fields including more complex entities such as tables and

lookup tables. The user class to which the field is assigned will determine what level of access users will have to it.

PROGENY OBJECTS/ENTITY SECURITY Progeny’s primary application modules create and maintain the logical objects that that represent the information

that is the focus of that module. The pedigrees module creates and maintains pedigrees while the samples tracking

module creates and maintains samples. Individuals are created and maintained in the individuals module. We call

these objects Progeny objects or entities. When the objects are created they are assigned to user classes and also

placed in folders that pertain to their specific module or functional area. The user class assigned to the entity


determines the level of access that each user will have to these entities. When more global access control is

required, access to Progeny objects can be granted indirectly through folders so that the level of access to the

object will be determined by the user class of the folder and not that of the object in question.

OTHER SECURITY ASPECTS OF PROGENY DESKTOP User Identification and Authentication

Access to Progeny is ordinarily controlled through database user name and password. In enterprise

settings the database access is controlled through more sophisticated authentication system such as

Lightweight Directory Access Protocol (LDAP).

Application Level Auditing

With two forms of auditing available, the Chain of Custody audit maintains a record of transactions

performed on samples in the database, while the Field audit records the values that are updated,

displaying old and new values for every modification. Both audits time stamp each event with a date, time

and User ID. In addition to these features, which are both available through the user interface, the

database engine has extensive auditing available in the form of log file operations.

Transport-Layer Security (TLS)

You can use transport-layer security to authenticate communications between client applications and the

database server. Transport-layer security uses simple, elliptic curve, or RSA encryption technology.

Separately licensable components are required for RSA and elliptic curve encryption.

Database Level Security

The user can set the level of security on the database by restricting functions such as the ability to add,

delete, or modify a pedigree or individual folder as well as the ability to add, delete, or modify a data

folder.

External Access Protection

SQLA provides a way for administrators to create custom login procedures. Progeny builds on that

capability and provides a login procedure that denies all users but the most privileged administrative

users access to the Progeny database from outside the Progeny application interface. This allows Progeny

to enforce its application level security measures when it comes to viewing and modifying data in the

database.

Login Auditing

Each login to the database is audited. The User ID, operating system, application, host name, login date,

and logout date are recorded for every successful and unsuccessful login.

Customizable Validations Module

System administrators can create database fields that have validation enforced. A validation module acts

like a choke point through which all requests to save data to the database have to pass through to ensure

that only data that matches certain validation criteria are allowed. This helps with data integrity directly.

It also indirectly helps combat SQL injection attacks as only valid data of the right length and containing

only valid characters are let through to the database.


Progeny Web Server Progeny Web Server is a two tier application with a Java servlet based server side and a JavaScript based client

written using Google Web Toolkit (GWT) language. As such it also leverages the state of the art security

architecture provided by GWT including out of the box defenses against cross site scripting (XSS), cross site request

forgery (CSRF) and a host of other common web application attacks. As previously mentioned the Progeny web

server leverages both the core Progeny application security model as well as the database security measures

provided by SQLA. Every aspect of application security and database security described for Progeny Desktop

equally applies to the web server. We will focus here on the security issues and/or measures that are unique to

web applications.

All web applications by nature require a lot more care to ensure proper security because their architecture is such

that the database server and the web server are located in disparate areas of a wider network. While it is possible

to have a setup where a user’s client computer is run inside the same local area network as the web server and

database server, in the most common architectures the web server will run in the public internet while the

database server is in a more secure local area network behind the firewall. This opens more doors for attackers to

gain access to organizational data by using the web server as the vehicle. We will discuss the most common

security threats faced by web applications in general. We then focus on how the Progeny Web Server is designed

and deployed in ways that directly address those security threats.

PROGENY WEB SERVER (INCLUDING FHQ):

Table 2 - Typical Progeny Web Server architecture that includes patients connecting remotely through the family history questionnaire (FHQ).

The database server is located inside the local area network behind the internal firewall.

Access to the database from the web application running inside the web server occurs through a database port

opened in the internal firewall. The web server is accessed through the standard web server port 80 (443 when

using secure sockets layer to secure communication between browser and web server).

TRUST BOUNDARIES

As can be seen from the diagram above there are three boundaries that any packet has to cross from the web

browser running on a personal computer or table until it reaches the database. First the packets have to cross the

external firewall to get to the web server. Once the request reaches the web server, services running behind the

web server are called to complete the request for data in the database. It is a general rule in web applications that

anything coming from the browser is not to be trusted so vigilance has to be exercised to ensure that bad requests

are cleaned up and sanitized before they reach the database.


APPLYING THE OWASP TOP 10 MODEL TO PROGENY WEB SERVER

Every year OWASP publishes what they call the OWASP TOP 10 which is a list of what is widely accepted as the

most common and most impactful security issues facing web applications. It is widely accepted that addressing the

OWASP TOP 10 issues goes a long way in making web applications more secure. The 2013 list is shown in the table

below. We will discuss each of the items on the list in some detail, focusing on how the Progeny web server has

been built and/or is deployed to address each one. We will also highlight the items on the list that have not yet

been addressed and give timeframes and/or versions of Progeny web server that will address those issues.

OWASP TOP 10 and Progeny Web Server

Rank Item Progeny Compliance

Responsibility

A1 Injection Yes Vendor

A2 Broken Authentication and Session Management

Yes Vendor

A3 Cross Site Scripting (XSS) Yes Vendor

A4 Insecure Object Reference Yes Vendor

A5 Security Misconfiguration Yes Vendor

A6 Sensitive Data Exposure Yes Customer

A7 Missing Functional Level Access Control

Yes Vendor

A8 Using Known Vulnerable Components

Yes Vendor

A9 Cross Site Request Forgery Yes Vendor

A10 Unvalidated Redirects and Forwards

Yes Vendor

A1 INJECTION OWASP Injection attacks also entail both SQL Injection and LDAP Injection attacks. To summarize how Progeny

Web (and indeed all Progeny applications) addresses SQL and LDAP Injection: here are the best practices that

Progeny follows in our coding practices to protect our customers against potential SQL and LDAP Injection attacks.

All SQL parameters in Progeny are escaped

Use value place holders in SQL and LDAP statements

Use stored procedures for a lot of the core functions for storing and retrieving data

Sanitize all data to remove any special characters that may give extra meaning to the data when interpreted in a SQL or LDAP query or statement

A2 BROKEN AUTHENTICATION AND SESSION MANAGEMENT Application functions related to authentication and session management are often not implemented correctly,

allowing attackers to compromise passwords, keys, session tokens, or exploit other implementation flaws to


assume other users’ identities. Progeny enables administrators to implement strong password policies. Progeny

web server is built using GWT and therefore easily leverages the extensive security architecture provided by this

platform. GWT has an inbuilt ability to prevent attacks that are based on stolen, forged or broken sessions

employing cross site request forgery.

A3 CROSS SITE SCRIPTING Cross-Site Scripting (also known as XSS) is one of the more common web application attacks. XSS attacks are

possible because of the internet security weaknesses of client-side scripting languages such as HTML and

JavaScript. The concept of XSS is to manipulate client-side scripts of a web application to execute in the manner

desired by the attacker. The attacker embeds scripts into the web pages being loaded by the victim and those

scripts will execute inside the user’s session, all the while as the attacker’s script communicates with the attacker’s

web site. At the minimum XSS attacks can be annoying to the user being attacked as the attacker can control the

browser and make it do what they want and not what the user wants. More serious attacks will use the XSS code

being executed in the victim’s session to expose sensitive information by transferring such information to the

attacker’s computer or web site, causing potential disclosure of sensitive data.

Progeny employs the following security best practices to guard against XSS attacks.

All client bound data destined for HTML elements are escaped to disarm HTML and JavaScript enabled portions of the data

Very little if any dependency on JSON and JSONP for data transmission. Where used care is taken to ensure that data contained in JSON objects is disarmed before use

Gradual migration to GWT’s SafeHTML for widgets that display user entered data

Making sure that no sensitive data or intellectual property is stored / executed on the client side inside the browser. User names and passwords are transmitted only once from the client browser to the server at user logon. All subsequent requests are tied to the session token for validation purposes on the web server.

A4 INSECURE DIRECT OBJECT REFERENCE A direct object reference occurs when a developer exposes a reference to an internal implementation object, such

as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate

these references to access unauthorized data. Progeny does not expose system handles to file system objects

directly. When encryption is used for databases, the keys are stored in hashed form so that they are not available

to hackers.

A5 SECURITY MISCONFIGURATION OWASP defines the problem as one that arises when application of web server and/or other application server

configuration is not done properly, hence leaving room for attackers to exploit the holes exposed by such

configuration. Good security requires having a secure configuration defined and deployed for the application,

frameworks, application server, web server, database server, and platform. Progeny does the following to help

combat this type of attack:

System configuration is done through a screen that requires extra unpublicized user names and passwords to access

http://www.veracode.com/


Configuration screens can only be executed in a browser running on the web server unless that requirement is excepted by the administrator

Configuration settings are stored securely on the web server encrypted using strong encryption

Configuration settings that define database connection strings are not transported to the browser. Only aliases of database servers are provided to the user inside the browser. The rest of the data required to construct a connection string to an actual database are stored securely in encrypted form on the web server

A6 SENSITIVE DATA EXPOSURE This issue arises when sensitive data is either stored in sections of the software or transmitted between multiple

tiers of the software; in an insecure manner so that attackers can easily get hold of the data stored or in transit.

While this issue does not seem to affect Progeny directly, the few things that could tangentially be construed to be

related to this issue in the Progeny context are user names and passwords as well as electronic personal health

history (ePHI) data. Progeny avoids sensitive data exposure by:

Maintaining a strong password and strong authentication policies

Giving ability (through both Progeny and the SQLA database engine) for Administrators to encrypt certain data.

No protected/personal/deciding information is stored in cookie

A7 MISSING FUNCTIONAL LEVEL ACCESS This issue affects web applications that fail to hide modules or functional areas of the software appropriately.

Progeny uses its fine grained application security model based on user classes to determine who has got access to

what module or functional area. The server side strictly enforces this access control for each request that is made

to the services that run behind the web server.

A8 CROSS SITE REQUEST FORGERY Cross-Site Request Forgery (CSRF) is an attack whereby a malicious website will send a request to a web

application that a user is already authenticated against from a different website. This way an attacker can access

functionality in a target web application through the attacked user's session. The key difference between CSRF and

XSS is that XSS attacks are executed in the user’s browser whereas the CSRF attacks are executed on the server

because of their ability to hijack the user’s session. In that sense CSRF attacks are more dangerous. The key

remedies implemented in Progeny for CSRF attacks are:

Transport layer encryption using SSL. This avoids man in the middle attackers from gaining access to sensitive information such as username and passwords. Progeny has no direct control over this but we always strongly encourage our customers to make sure that Progeny web servers are only accessible via the SSL port.

Progeny leverages GWT’s CSRF protection mechanisms that appends unpredictable challenge tokens to each request and associate them with the user’s session. By including a challenge token with each request, the Progeny web server can examine and be sure request is valid and not coming from another source other than the user who initiated the session

Upwards of 99% of all requests from the Progeny web client (browser) to the server are executed using the POST HTTP method. This in itself makes it very difficult to come up with ways to generate CSRF attacks.


When you combine this with GWT’s ability to combat CSRF attacks by design; the result is a system that is pretty much inoculated from those attacks

A9 UNKNOWN VULNERABLE COMPONENTS (UVC) According to the OWASP TOP 10 list website UVC arises when vulnerable components, such as libraries,

frameworks, and other software modules almost always run with full privilege. So, if exploited, they can cause

serious data loss or server takeover. Applications using these vulnerable components may undermine their

defenses and enable a range of possible attacks and impacts.

Progeny web server does the following to protect against this class of attacks:

Tomcat user runs as a user with administrative privilege instead of the operating system administrative user

Sybase services are executed by a designated user with admin privileges

Certain high privilege functions in Sybase are disabled or allowed to run in sandboxed mode

While Progeny Web server can be configured to allow storing documents and images uploaded by users in remote location (shared folder), remote repository can be placed inside trusted internal network and exposed to DMZ through firewall.

A10 UNVALIDATED REDIRECTS AND FORWARDS (URF) OWASP defines URF as a problem that arises when web applications redirect and forward users to other pages and

websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can

redirect victims to phishing or malware sites, or use forwards to access unauthorized pages. Progeny only allows a

few redirects that themselves are not determined by incoming query strings or user data. Static values are used to

determine which pages the users must land on. In that way Progeny is not susceptible to these types of attacks.

OTHER COMMON SECURITY THREATS TO WEB APPLICATIONS

The OWASP TOP 10 list provides a very good model for assessing how applications fare against the class of attacks

considered important by OWASP. It is helpful in highlighting the most common issues that affect web applications.

But it is not the be-it-end-all for security issues. Here we discuss some of the more common application threats

that have not been enumerated in the OWASP TOP 10. If the issue was addressed under OWASP in a more general

sense then it might be repeated here with the object of providing more details.

Authentication Attacks

Buffer Overruns

Denial of Service

HTML Injection

Input Manipulation Attacks

LDAP Injection

Repudiation


SQL Injection

Some of the attacks or threats apply across application type boundaries in that they affect client server

applications as much as they affect web applications. Below is a brief description of each and a summary of the

types of defenses that Progeny has in place to prevent and/or minimize risks associated with them.

AUTHENTICATION ATTACK This type of attack affects all types of applications that use one form or another to authenticate users.

Authentication attacks can be further classified into the following attacks

Brute force attacks – also called dictionary attacks

Session hijacking

Credential theft

The table below summarizes what Progeny does to guard against these types of attacks.

Authentication Attacks and Progeny

Attack Type Remedies Responsibility Addressed

Session Hijacking

SSL secured web server Customer Yes

Session Timeouts Customer Yes

XSRF aware software using GWT libraries Vendor Yes

Credential Theft

Two Factor Authentication Vendor No

Strong passwords Vendor Yes

Hashing and salting passwords Vendor Yes

Brute Force Attacks

Strong passwords Vendor Yes

Hashing and salting passwords with one way hashing algorithms

Vendor Yes

Lock users out Vendor Yes

Multi-factor authentication Vendor No

Logs of login attempts Vendor Yes

BUFFER OVERRUNS This type of attack applies to applications that are written in languages like C++ and other languages where the

memory management is the responsibility of the programmer and not the language framework. Progeny web is

written in both C++ and Java so the C++ portion is a potential target for buffer overflow attacks. The only way to

mitigate against this attack in a Progeny context where C++ is the language is to make sure that a robust QA

process is put in place to reduce the amount of bugs that could open the system up for exploitation in this manner.

DENIAL OF SERVICE ATTACK A denial-of-service attack (DoS attack) or distributed denial-of-service attack (DDoS attack) is meant to flood the

target machine or server with requests up to the point where that server is unable to respond to legitimate


requests. DoS attacks for the most part affect whole infrastructures. The Progeny web server does have some

legitimate content and functions within it that if left unprotected can be taken advantage of to launch DoS attacks.

Because DoS attacks are mainly launched against network and server infrastructures, most of the remedies are in

the control of the customer. Depending on environment, we strongly recommend that security administrators

implement some of these DoS attack prevention techniques where possible.

Setup firewalls to allow/deny only certain ports, protocols and even IP Addresses

Setup switches and routers with ability to limit the rate of traffic allowed through to the internal systems. This helps slow down and block packets that are considered to be coming from a bad source

Install intelligent fronting hardware to inspect traffic before it reaches the servers

Use the concept of cleaning centers that when setup allows all traffic to be scrubbed or sanitized before it is allowed to proceed to the internal network where servers are running. This can be done in various way including the use of tunnels, proxy servers and direct circuits

The following techniques are employed by Progeny Web Server to make sure that DoS attack risk is reduced.

Allow Progeny server administrators to limit the size of files that can be uploaded using Progeny’s document management module.

All uploaded files go through a central chokepoint on the server side that runs some algorithm to limit the rate at which files can be loaded

HTML INJECTION ATTACK HTML attacks are done with the express intent of site defacement. In Progeny all user entered data and URL query

parameters are HTML encoded before being allowed to be displayed in HTML pages. It is worth noting that this

attack is none too dissimilar to cross site scripting attacks in its manifestation, as well as ways to prevent it. So the

security measures enumerated above for XSS apply here as well.

INPUT MANIPULATION ATTACK & TRUSTING THE CLIENT’S AUTHORIZATION This attack arises when data is passed from browser to web server/services in clear text and when the web server

and its services accept the data without some form of input validation. Progeny deals with this kind of attack by

validating all input that comes from the browser to the server and rejecting any data that is not valid. Also see the

section on how we deal with SQL Injection for more details on how data entering the database through SQL

statements is sanitized or at the minimum disarmed from morphing into SQL Injection attacks.

LDAP INJECTION ATTACK Lightweight Directory Access Protocol (LDAP) Injection is an attack that exploits applications that accept user input

to the LDAP server without first making sure that the input is properly inspected for unauthorized LDAP statements.

This could result in the execution of arbitrary commands such as granting permissions to unauthorized queries.

LDAP Injection is very similar to SQL Injection so the defense mechanisms tend to track each other.

While most of the responsibility to prevent against LDAP attacks lies with the LDAP administrator, Progeny is

designed to add some basic protections against these attacks.


Incoming Data Validation

Progeny tries to clean up all client supplied data that is destined for LDAP (e.g. user names and passwords)

by stripping out any characters or strings that could possibly be used maliciously. Single and double

quotes in the data are stripped or escaped so that any attempt to inject new statements is prevented. If a

statement is added to the end of or in the middle of a user name, then by properly inspecting and

sanitizing the username the inserted malicious statement will not be executed but instead will be treated

as the part of the user name.

Regular expressions are used inside the software to allow only certain characters in user names. All

symbols or punctuation characters that have meaning in HTML are HTML encoded on the server side

before being passed on to the LDAP server for processing.

Outgoing Data Validation

Progeny further checks all user bound data by making sure that the amount of data returned by the

queries should be restricted to certain known numbers or are within a certain specified range. If one row

is expected to be returned then only one row should be allowed for that particular query.

LDAP Configuration

LDAP Injection attack would be almost impossible if the LDAP server is properly configured with the

correct permissions granted to the right users and user classes. While Progeny does not have control over

the setting up of LDAP server, it is something we strongly encourage our users to take seriously. In

addition, the LDAP server should not be directly accessible on the Internet, thereby eliminating direct

attacks to the server.

REPUDIATION Repudiation means that a user who otherwise has no authorization to carry out certain activity in the system or

gain access to certain data does so and is able to successfully challenge or refute evidence pointing to them having

carried out those activities. In the Progeny context this may be a user gaining access to view data on individuals in

a study that they are not authorized to view and/or modify. Without applying and using digital signatures for all

messages exchanged between the web server and the client, it is almost impossible to fight against repudiation.

Progeny does not yet make use of digital signatures but does apply the following measures to fight against

repudiation:

Enforcing strong authentication using strong passwords to avoid credential theft in the first place

Logs of user login attempts including when and where the user logged on from. Also monitoring those logs to discover incongruous patterns

Progeny audit system ensures that all data changes can be traced back to the user that performed them

Message digital signatures planned for future versions

SQL INJECTION ATTACK SQL Injection attacks arise when user input is used verbatim in constructing of dynamic SQL statements. When that

happens, a statement that may be intended to pull data out of a table in a database can be easily modified by a

clever hacker to do data inserts and/or updates. It could also be manipulated to expose data that the attacker

must not have access to.


To guard against SQL injection attacks Progeny applies the following well known techniques when handling user

input in SQL statements

Employing the principal of least privilege to database server access. Progeny users can only do what they are explicitly allowed and nothing more. A non-administrative Progeny user cannot execute DDL statements for instance. So if a query included an attack potion that executes a DDL statement then that query will fail due to lack of privilege.

Using stored procedures. Stored procedures are orders of magnitude more secure than statements constructed outside the database on the fly. They also enforce data type and field sizes more strictly for input parameters. This greatly reduces the chances of bad data making into the actual executable queries.

Using parameterized queries and/or updates statements is SQL. Most SQL databases (and certainly Sybase SQL Anywhere) provide the ability to escape data that is inserted into SQL statements as parameters so that the user input cannot be manipulated to create compound statements that the programmer did not intend.

Escape user input used in dynamic queries

GENERAL SECURITY MEASURES EMPLOYED IN PROGENY WEB SERVER

Progeny Web Server does the following things to further enhance the possibility of circumventing attacks.

SERVER GENERATED USER TOKENS HAVE EXPIRY TIME Once the user is logged on; user credentials are kept in a user session object on the server and are not to be

transported across the wire with every request. Instead, leased user tokens are used to identify the user each time

a request is transmitted between client and server. The tokens have the following properties:

a. They expire after a set period of time, at which point the user will be leased another secure token. Any attempts to logon using an expired token will be rejected even if all the other credentials are correct.

b. They are mapped to the actual user credentials on the server before accessing the database.

c. They are generated in a random and secure manner to ensure that they cannot be guessed easily.

TREAT ALL REQUESTS FROM INTERNET AS UNTRUSTED Progeny Web Server treats each request received from the Internet as one that cannot be trusted. In that vein,

each request is checked to ensure that the user has the correct authorization to the resources that they say they

are requesting before granting them access. For instance, if an attacker intercepts a request from a real user

requesting pedigrees from a certain folder and decides to change the request so that it returns a list of pedigrees

from another folder that the user would normally not have access to, the Progeny Web Server security layer will

reject such a request on the basis that user making the request does not have correct authorization to view objects

that reside in that folder.


STRONG PUBLIC CRYPTOGRAPHIC ALGORITHMS Only publicly available cryptographic algorithms are used to encrypt data. Published algorithms tend to be strong

because they are well tested and hence most if not all vulnerabilities would have been discovered and addressed.

All the internally encrypted data use strong 256 bit keys combined with salts.

MEASURES AGAINST SESSION STEALING Progeny employs the following measures to ensure that stolen sessions cannot be used to attack and possibly steal

and/or decimate the application data.

Make user sessions expire after set period of inactivity

Users are provided with links that allow them to log out of the system, a process that invalidates the user’s session so that it is no longer recognized by the web server. Any attempts to steal and use such session will therefore rejected by the server.

Use servlet filters to inspect each request for validity of source. This is done by associating session with IP Address of remote device/PC. All requests on this session must emanate from the same source.

Require that every request to the server be SSL encrypted. This is something that Progeny cannot enforce, but we do strongly advise our clients to setup SSL on their web servers before they are deployed in production.

ERROR REPORTING Progeny server failure is reported using very discreet messages. No extra information that may expose the type of

web server, operating system or database server is transmitted to the user. We also make sure that error

messages constructed from exception stack traces are stripped of the extra details that would otherwise provide

inside information about the technology environment to the attacker.

PATIENT SIGNUP IN FHQ When patients are invited to participate in a study using Progeny’s FHQ application, the following measures are

taken to ensure that the data remains secure:

FHQ patients to use the email to which the invite was sent as the user name

FHQ patients passwords are properly salted and hashed with each user/patient’s password being hashed with a different salt

When resetting forgotten passwords we do not send forgotten passwords to users because we don't know them (because they're hashed); so instead, we offer a password reset feature, which sends a unique link to the email address for that user


Regulatory Compliance Most of our customers are in the health care industry space. That means that they use our software to handle and

transmit personal health information. For that reason they are required to comply with HIPAA and other

regulations governing actors in this industry. As part of HIPAA compliance, all these institutions have to make sure

that the technologies they use to handle and/or transfer data is also HIPAA compliant. Progeny takes that

requirement for our customers to be HIPAA compliant very seriously.

What is HIPAA Health Insurance Portability and Accountability Act of 1996 requires the establishment of national standards for

electronic health care transactions and national identifiers for providers, health insurance plans, and employers

among other things. The administrative simplification provisions also address the security and privacy of health

data.

Progeny (as do all vendors supplying information technology to companies in the health industry) have to make

sure that their technology or tools comply with the Technology Safeguards of the Security Rule of the HIPAA

regulations. The section below discusses the specific technology safeguards and how Progeny complies with those

safeguards.

According to the Health and Human Services (HHS) guidelines, the Security Rule requires covered entities to

maintain reasonable and appropriate administrative, technical, and physical safeguards for protecting electronic

personal health information (e-PHI).

Technical Safeguards The Technical Safeguards in particular mandate that the institution controls access to computer systems and

enabling covered entities to protect communications containing PHI transmitted electronically over open networks

from being intercepted by anyone other than the intended recipient. There are four technical safeguards under

the HIPAA Security Rule. These are Access Control, Audit Controls, Integrity Controls and Transmission Controls.

ACCESS CONTROL

Under the access control safeguard a covered entity must implement technical policies and procedures that allow

only authorized persons to access electronic protected health information (e-PHI). Progeny provides a

comprehensive system of application level security controls. It also leverages database security provided by the

underlying database to make sure that only authorized persons are allowed to view and/or modify data. The

section on Application Security describes in detail how Progeny groups data entities/objects and users into groups

and then uses a fine grained system to enable different levels of access to the smallest data point on an entity; as

well as providing access to whole modules and entities. The Progeny document management module allows

administrators to store documents and/or images on a remote server that runs in a trusted environment away

from the web server. Web servers are usually set up to run inside the DMZ so this ability provides some nice

protection for this potentially sensitive data.

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

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


AUDIT CONTROLS

Under the audit controls safeguard a covered entity must implement hardware, software, and/or procedural

mechanisms to record and examine access and other activity in information systems that contain or use e-PHI.

Progeny keeps track of all users that log on to the database. This includes which data was viewed, changed, or

deleted by a user. We even keep a history of the original value and what it was changed to by the user.

INTEGRITY CONTROLS

Under the integrity controls a covered entity must implement policies and procedures to ensure that e-PHI is not

improperly altered or destroyed. Electronic measures must be put in place to confirm that e-PHI has not been

improperly altered or destroyed. By giving only authorized users the ability to delete certain objects or entities

Progeny ensures that no one without the right level of access can delete these entities anonymously. The audit

sub-system in Progeny also allows the integrity of data to be maintained.

TRANSMISSION SECURITY

Under the transmission control, a covered entity must implement technical security measures that guard against

unauthorized access to e-PHI that is being transmitted over an electronic network. Progeny enables our clients to

set their systems in such a way that data transmitted from one part of the system to another is properly secured

using strong encryption. The web server must always be set up with SSL so that data from the user’s client PC to

the web server is transmitted in encrypted form. Where required, communications between the web server and

the database server can also be secured using SSL or TLS. While not enforced, customers are also encouraged to

setup their databases to use TLS for data communication between the desktop client and the database server.

progeny security architecture · 2013-08-07 · progeny security architecture 5 database security...

Documents