Security OverviewDocument Version 1.5

HR.net Security Overview

To learn more about HR.net go to www.vizual.co.uk

1 Introduction 1

2 Architecture 1

3 HR.net Role Based Security 2

Password Rules 3

4 Authentication 4

Internal Authentication in the HR.net Web Application 4

Windows Domain Authentication in the HR.net Web Application 5

Authentication in the HR.net Web Service Applications 5

5 Authorisation 6

6 Client Certificates and Secure Sockets Layer 6

7 Data Security 6

Table and Column Security 6

Row Level Data Security 6

Secure Sockets Layer Encryption of Network Data 7

Auditing of Data Changes 7

8 Web Service Security 8

9 Physical Infrastructure 8

Securing the Network 8

Harden Firewalls 8

Harden Routers and Switches 8

Encrypt Sensitive Communications 8

Securing the Servers 9

HR.net Implementation 9

10 Prevention of Common Security Issues 10

SQL Injection 10

Cross Site Scripting (XSS) / HTML & Script Injection 10

ViewState Modification 11

Disclosure of Sensitive Information 11

Hashing of Passwords 11

Encryption of Sensitive Application Settings 11

All Application Errors are Handled 11

Theft of Authentication Cookies 11

Contentspage

To learn more about HR.net go to www.vizual.co.uk

Page 1

This document provides a technical overview of the HR.net architecturefrom a security aspect. The document also lists considerations when securing the network on which HR.net will be installed.

The intended audience for this document is internal OneClickHR plc technical staff and potential HR.net customers. This document is a technical document and assumes the reader has knowledge of network administration (Firewalls, routers,TCP/IP and .Secure Sockets Layer) andWeb server technology. This document forms one part of a series of documents detailing HR.net. Other documents in this series are:

HR.net Architecture – an overview of the design and architecture ofHR.net.

HR.net Functionality – an overview of the functionality of HR.net

In order to understand the security aspects of HR.net it is useful to understand the architecture of the application. For a full description of the HR.net application architectureplease refer to the document entitled “HR.net Architecture”.

HR.net has been developed using the Microsoft .NET framework.An understanding of theMicrosoft .NET framework will help the reader appreciate the inherent security features andscalability of the .NET framework. Details can be found on the Microsoft web site athttp://msdn.microsoft.com/netframework

Figure 1 – HR.net Architecture

Introduction

Architecture

HR.net Security Overview

HR.net has been designed as an n-tier application; this is depicted in Figure 1.

End users use the HR.net Web Application,Administrator Console or Document ExplorerWindows Forms client applications. Clients using the HR.net Web Application communicatewith the ASP.NET HR.net Web Applications.These are hosted on a web server runningMicrosoft Internet Information Services (IIS). Clients can either be authenticated against aWindows Domain or against HR.net’s internal authentication mechanism. Clients authenticating against a Windows Domain access the HR.net Windows AuthenticationApplication and once authenticated are seamlessly logged into HR.net. Clients using HR.net’sinternal authentication method must first log into HR.net using a user name and passwordprovided by their HR.net administrator.

Clients using the Administrator Console or Document Explorer Windows Forms Applicationscommunicate with the Administrator Console Web Service running on the same web serveras the ASP.NET HR.net Web Application.

The HR.net web application and web services communicate with the Business Facades,Business Rules and Data Access Objects Class Libraries.A Class Library is a Microsoft .NETapplication and has the file extension .dll.The Data Access Objects retrieve data from theMicrosoft SQL Server database.

To enable a high level of scalability Queued Windows Service Applications perform tasks suchas the running of reports, sending of mail and the creation of mail merge documents.Thesetasks are performed asynchronously without the need for the client to wait for a task to complete.

HR.net uses its own internal role based security model to control user access to the application.

A role has the following properties and privileges assigned to it: (see fig 2 on next page)

A user is assigned one Primary Role and optionally any number of Secondary Roles.

The Primary Role is used to determine the users Authentication Method,ApplicationSecurity, Function Security, Module Security and Data Security (table, row and field access).

Secondary Roles are used to determine privileges when accessing document, reports andcommunities within the HR.net Web Application.

HR.net RoleBased Security

Page 3

Internal Authentication supports the following password rules:Password Rules

Property Description

Authentication Method Determines how users of the role are authenticated.

User can be authenticated using a list of user names and passwords stored in the HR.net database (Internal Authentication), against a Windows Domain,Active Directory or a server using LDAP.

Application Security Data and screens within the system are divided into user defined Applications.

Application Security defines which of these Applications a role can access.

Function Security Controls access to functions within the system such as viewingthe Audit Trailing or creating a new Community portal.

Module Security Controls access to the Web Application,Administrator Console and Document Explorer applications.

Table Security Defines table, row and field level security for data.

Object Security Documents, Reports, Communities and Add-ins are security onan object by object basis. Each object has read, write anddelete access defined for it.

Figure 2 – Role Privileges

Password Rule Description

Letters-Only Passwords Determines if a user’s password must contain numbers as well Not Allowed as letters.

Minimum Password Length Determines the minimum number of characters a password can contain.

Maximum Failed Logon Defines the maximum number of invalid logon attemptsAttempts allowed before a user’s account is frozen.

Password Never Expires/ Determines how many days a password is valid for and if the password expires.When a password has expired, the user account is suspended and the user can no longer log on to the application.The user is warned ten days before password expiration and prompted to change their password.

Figure 3 – Password Rules

HR.net Security Overview

Authentication is the process of checking a user’s credentials in order to confirm they arewho they say they are.This is performed when the user logs into HR.net.

HR.net supports two methods of authenticating a user:

Internal Authentication

The user name and password is matched against a list of user names and passwords stored inthe HR.net database.The passwords are stored in an encrypted format.The user name andpassword entered in the logon screen is passed from Internet Explorer to the HR.net WebApplication in plain text. Secure Sockets Layer (SSL) should be used to encrypt this data.

Windows NT Account

The user is authenticated by a Windows Domain.The user must have an account on thespecified Windows Domain.The authentication is performed by the ASP.NET web applicationand therefore the web server must be part of the domain on which the users are to beauthenticated. IIS Directory Security settings are used to specify Basic, Digest or IntegratedWindows Domain authentication.

The method used to authenticate a user is determined by the Primary Role assigned to theiruser account in HR.net.The System Administrator defines the authentication method to beused for each role in the system.

Internal Authentication is performed using ASP.NET Forms Authentication. If a user attemptsto access the HR.net Web application without first authenticating then they are automaticallyredirected to the logon page.

ASP.NET Forms Authentication transmits the user name and password from InternetExplorer to the HR.net Web application in clear text, therefore SSL should be used toencrypt this traffic.

Once a user has successfully authenticated they are issued with a security key which is storedin a cookie on the user’s machine.This key is passed with all subsequent requests and is usedby ASP.NET to determine if the user has been authenticated.The cookie used to store thesecurity key on the user’s PC is non-persistent and is present only as long as their browser isopen.Also, once the user logs out, or has been inactive for a period of time, this security keybecomes invalidated on the web server.

Authentication

InternalAuthentication inthe HR.net Web

Application

Page 5

Users with Windows Domain accounts can be authenticated against the domain when logginginto HR.net. If the user has authenticated at the time of login to Windows, then they will be seamlessly logged into HR.net and will not be prompted to re-enter their network credentials.

If the user has not pre-authenticated then they will be prompted for their network credentials using a logon dialog native to Internet Explorer and the Windows operating system.

HR.net supports the mapping of an internal HR.net account (to which security privileges are attached) to one or more Windows Domain accounts.This enables the authentication to be performed by a Windows Domain and authorisation to be controlled byHR.net’s security system.

The authentication is performed by a dedicated ASP.NET authentication application writtenfor HR.net.The authentication is controlled by modifying the IIS Directory Security properties for the HR.net authentication ASP.NET application.The following DirectorySecurity settings can be set:

Basic authentication

Basic authentication results in the transmission of passwords across the network in an unencrypted form.This method is not recommended unless SSL is used.

Digest authentication

This method is new in IIS 5.1 and sends a hash value over the network rather than thepassword.This method works across proxy servers and other firewalls.

Integrated Windows authentication

Integrated Windows authentication uses a cryptographic exchange with the user’sInternet Explorer Web browser to confirm the identity of the user

The user’s credentials are verified in the same manner as the HR.net Web Application.

If the user’s credentials are successfully verified then a security token, in the form of a 128 bitGlobally Unique ID (GUID), is issued to the client application.

This security token must be passed when making a method call to the Web Service application.This security token is stored in memory only, and is never written to the user’shard drive.

Windows DomainAuthentication inthe HR.net Web

Application

Authentication inthe HR.net Web

ServiceApplications

HR.net Security Overview

Authorisation is the process of checking if a user has security access to a particular resourceor function within HR.net.

HR.net uses its own custom authorisation based upon roles assigned to a user. Each role hasa set of privileges assigned to it.

Before a user’s request is processed a test is performed to see if any of the roles assigned tothe user have the required privileges to perform the requested action.

If the user does not have the required privileges then an application exception is thrown.This exception is handled in the HR.net Web Application and Administrator ConsoleApplication and an error message is display to the user informing them that they do not have the required privileges..

All the HR.net applications including the Web Application, Document Explorer andAdministrator Console Web Services can optionally be secured using Client Certificates.Client Certificates ensure that the clients accessing the HR.net applications are who they saythey are.

Certificates can be issued by an organisation themselves using Microsoft Certification Server(an optional component of Windows Server) or by a 3rd party such as VeriSign or Thawte.

To use Client Certificates on a web server Secure Sockets Layer (SSL) must be installed.SSL is supported by all the HR.net ASP.NET and Web Services applications.

Microsoft SQL Server is used to store the HR.net data. Microsoft SQL Server is a well established and secure database management system.

Table and Column Security

Users can be prevented from reading, writing or deleting records from specified tables.Security can be controlled down to column level within a table.This has been implementedusing SQL Server Views.

Row Level Data Security

Row-level security has been implemented in HR.net as Microsoft SQL Server does notsupport row security at a granular level as required in HR.net.This allows control, at a finelevel, of the records that a user can view, modify and delete. Row level security is defined forHR.net roles and roles are then assigned to users. For example, a view that enables a linemanager to only see their own personal details and the details of the employees that directlyreport to them may be defined.This level of control enables system administrators toprecisely define the data that may be viewed, modified and deleted by users.

Client Certificatesand Secure

Sockets Layer

Data Security

Authorisation

Page 7

Secure Sockets Layer Encryption of Network Data

HR.net supports the use of Secure Sockets Layer to provide 128 bit encryption of the datatransferred between the client, Microsoft Internet Explorer or the Administrator Consoleapplication, and the HR.net server applications.

Auditing of Data Changes

HR.net enables the optional auditing of changes made to the data contained in HR.netdatabase tables.Auditing is controlled at table level and can be switched on or off forindividual table.When a change is made to a row within the table the original and new rowis stored in the audit table.The audit table, which has the following structure:

The audit trail for a table is viewed by clicking the ‘Audit’ button on a screen that uses the table asits main source of data.

Column Name Description

TABLENAME The table in which the record

RECORDID The primary key of the record which was modified

SEQNO Incrementing integer value storing the sequence of the change.Forms the primary key of this table together with TABLENAME and RECORDID columns

PARENTRECORD_ID The primary key of the records parent record if data in a child table was modified

CHANGETYPE Indicates if the record was modified, inserted or deleted

OLDRECORD Delimited list of column values for the original row

NEWRECORD Delimited list of column values for the new row

FIELDNAMES Delimited list of column names

IDENTIFIERTEXT The identifier text for the record.This consists of acombination or column values from the table.This is used when displaying the audit trail to the user.

USERNAME The user name of the user that made the change.

AUDITDATETIME The date and time on which the change was made.

Figure 4 – Audit Table Structure

HR.net Security Overview

Securing the Network

HR.net can only be as secure as the network on which it is installed.The following issuesmust be addressed in order to ensure a secure network infrastructure.

These items are not the responsibility of OneClickHR and must be addressed by the client sNetwork Administrator.

For further details of items discussed in this section please refer to the following Microsoftweb site: http://msdn.microsoft.com/library/en-us/dnnetsec/html/THCMCh15.asp

Harden Firewalls

• Firewalls must be kept current withpatches and updates.

• Unused ports and protocols mustbe blocked.

Harden Routers and Switches

• Stay current with patches andupdates

• Use ingress/egress filtering to rejectspoofed packets

• Screen ICMP traffic from the internal network

Encrypt Sensitive Communications

• Use SSL to encrypt sensitive communications.

PhysicalInfrastructure

• Use filtering to reject illicit requests

• Screen directed broadcast requestsfrom the internal network

• Reject trace routing requests

The HR.net Web Services allow method calls to be made across any network that supportsthe HTTP protocol including the Internet.

Every public method expects a security token, in the form of a Globally Unique Identifier(GUID), to be passed as the first parameter of the method.The security token is issued tothe client upon successful authentication.A copy of the security token is kept in the HR.netdatabase so that it can be matched with security tokens passed from the client.Therequested method is only executed if the security token is validated.

As an additional security measure the traffic to and from the HR.net Web Services can beencrypted using Secure Sockets Layer (SSL) 128 bit encryption.

Web ServiceSecurity

Securing the Servers

Some issues that should be addressed when securing the servers on which HR.net will run are:

• Ensure that all software (MS SQL Server, Operating Systems and IIS) have currentService Packs and Updates installed.

• Harden IIS with IISLockdown and URLScan.

• Harden the Web Server s TCP/IP Stack — http://msdn.microsoft.com/library/en-us/dnnetsec/html/HTHardTCP.asp

• Run ASP.NET using Principle of Least Privilege

• Use ACL Resources to prevent unauthorized access

• Disable unused shares and services

• Move Web Root to drive other than C:

For further details on these items see the following Microsoft web site:http://msdn.microsoft.com/library/en-us/dnnetsec/html/THCMCh15.asp

HR.net Implementation

To ensure a secure implementation of HR.net it is important that a secure infrastructure ismaintained.There are many possible ways to implement HR.net, however Microsoft recommends the following infrastructure for a distributed .NET application.

(please see over)

Page 9

HR.net Security Overview

SQL Injection

HR.net uses parameterized SQL statements and stored procedures to eliminate the possibility of SQL Injection attacks.

In addition to this HR.net executes SQL statements and stored procedures that receiveparameter value input from the user under dedicated SQL Server user accounts that do nothave access to view system tables or perform Data Definition Language (DDL) statements.

Cross Site Scripting (XSS) / HTML & Script Injection

On some sites, it is possible for a user to type HTML tags and/or script into an input field.For example, the site may ask the user to enter a review of a book on sale on the site.Theuser can enter HTML / script in the input field, and this will be saved in the database on theweb site.When the web site then displays this data back to other users, their browsersinterprets this HTML / script as part of the page, thereby altering the page layout, runningscript in the users browsers, etc.

ASP.NET (used by HR.net) prevents HTML and script character combinations being enteredin input fields, in the query string, etc; thereby preventing the above form of attack.

Prevention ofCommon Security

Issues

Figure 5 – Microsoft Recommended Infrastructure for Distributed .NET Applications

In this infrastructure there are two sets of clustered Windows servers (two tiers). Each tier is isolated from the otherusing dedicated network interface cards (NIC) and firewalls.The SQL Server database managements system is configured only to accept traffic from the IP address 10.2.7.xx.

ViewState Modification

ViewState is a hidden field stored in a number of pages on the site.This field stores temporary information about the controls displayed on the current page.When the usersubmits this page back to the server, our application makes use of some of the values stored in the ViewState, in order to correctly display controls on the next response page.

To prevent the user from altering any value in the ViewState, we enable ViewStateMac inASP.NET. If the user manually modifies with any value in the ViewState, or tries to manuallycreate their own ViewState, the server will detect a change has occurred, and it will rejectthe request.

Applications can inadvertently disclose information that can potentially help a hackercompromise the security of a web site. HR.net protects against this using several methods.

Hashing of Passwords

Passwords stored in the database are not stored as plain text but are encrypted using SaltedPassword Hashes. Hashing is a one way process where the passwords are encrypted. It ismathematically unfeasible to decrypt them.Therefore, if a user inadvertently gains access tothe table in which passwords are stored then they will not be able to read the passwords.

Encryption of Sensitive Application Settings

Application settings such as database connection strings are stored in configuration files in asecure encrypted format using Microsoft Data Protection Application Programming Interface(DPAPI). Full details of DPAPI can be found on the Microsoft web site:http://msdn.microsoft.com/library/en-us/dnsecure/html/windataprotection-dpapi.asp

1 All Application Errors are Handled

Configuration settings in ASP.NET applications make it possible for unhandled applicationerrors to be displayed to the user along with the source code where the error occurred.

HR.net disables this option and additionally handles all un-trapped errors messages anddisplays a user friendly error dialog. In addition to this, all un-trapped errors are logged to theHR.net database and optionally the Windows Event Log.

Theft of Authentication Cookies

Once a user has been authenticated a Cookie is issued to the user. If another uses steals thisCookie then they can access the system as if they were the original authenticated user.HR.net authentication Cookies are restricted to use SSL only.This provides a very strongdefence against Cookie theft.

Page 11

Disclosure ofSensitive

Information