B AND MOBILE ACCESS
PhixFlow 7.0
16 September 2016

1 Introduction
2 PhixFlow security design features
2.1 Secure coding
2.2 Secure authentication
2.3 Authorisation
2.4 Access to other data
2.5 Separation of test data
2.6 Logging & audits
3 Deploying PhixFlow for web access
3.1 Introduction
3.2 Risk Assessments
3.3 Deployment Options
3.4 Deploying via VPN
3.5 Deploying using a DMZ or Screened Subnet
3.5.1 Hardening
3.5.2 Install an X509 Certificate to provide encryption
3.5.3 Configure firewall to allow access to the internal network
3.5.4 Configure firewall to allow access to the internet
3.5.5 General recommendations for using PhixFlow securely
3.6 Intrusion Detection & Prevention (ID/IP)
3.6.1 Patching and Monitoring
4 Deploying PhixFlow for Mobile Access
4.1.1 Centrally managed mobile devices
4.1.2 Auto-lock / PIN unlock
4.1.3 Restrict use in public places
4.1.4 Review read only access

Introduction

This document provides information for IT and business managers at customer organisations who are involved in deploying PhixFlow applications for web and mobile access by remote users. The document provides technical information on how PhixFlow helps reduce the risks of remote access, through a secure design approach and through specific features that increase the level of security. It also provides advice on deploying and using PhixFlow in the two most common remote access scenarios:

• • traditional browser-based access on laptops at user's homes
  • field-based access by users using mobile phones and tablets

This document contains the following sections:

PhixFlow security design features

Secure coding

PhixFlow is designed to be a secure business system that can be used via browsers and mobile devices, rather than being designed primarily as web based system. It uses technologies specifically selected to solve complex processing problems, address both the needs of an agile mobile workforce and the security issues that increased levels of remote access brings.
PhixFlow software is built using our own proprietary secure coding standards and processes adapted from the Open Web Application Security Project (OWASP).
Using these approaches means that should your application be targeted by unauthorised users, the vulnerabilities common in many other web applications either do not exist, or have already been addressed, and it will therefore be extremely difficult to circumvent the security controls.
Examples include:

• • Data containment: All input entered and viewed by users is sanitised to prevent common types of 'injection', and 'cross site scripting' attacks.
  • No page caching: Many browser-based applications allow users to use the back buttons to navigate previous screens and in-process forms which can cause data corruption.
  • No URL modification: Many browser-based applications expose the user IDs in the address bar that allow and encourage direct access circumventing the navigation and security policies.

Secure authentication

Within PhixFlow, authentication can be delegated to an external authentication service provider e.g. your company's Microsoft Active Directory or authentication can use user accounts managed directly by PhixFlow.
If you use an external authentication service provider, then all policies including password length and complexity, maximum number of attempts and password history will be adhered to.
If you choose to use PhixFlow for authentication, secure password policies can be created and enforced to ensure that passwords are strong, changed regularly and not re-used.

Authorisation

PhixFlow uses user-defined access groups and roles, to provide a highly configurable and highly granular level of access control, encouraging the principle of least-privilege access. Using the tools in PhixFlow, access to specific screens and buttons can be limited to just those users, or groups of users, who require access.
In addition, PhixFlow consultants will configure record-level security if this is required, to ensure that users can only see or update those specific customers or records which they have been given access to.

Access to other data

Most applications configured in PhixFlow involve accessing data from company databases, web APIs or other third party systems. PhixFlow manages security for this in two ways:

• • Through system level security i.e. remote system access is authorised with a "phixflow" system level user account (or multiple accounts to provide each "application" just the access needed in line with the principle of least privilege). This is the preferred security model.
  • Using the logged on user's credentials so that no further accounts are needed.

When PhixFlow solutions are exported for deployment between test and live systems, all database and web services authentication details are removed to ensure that live data access is not accidentally shared with a test system.

Separation of test data

As a policy PhixFlow Ltd does not use or store live customer data in any PhixFlow owned development or test infrastructure. Data used on any of these systems for testing is either randomly generated or anonymised using algorithms agreed with the customer.
PhixFlow provides a mechanism which supports replication of applications without copying any data. This allows for easy creation of test and staging instances without exposing confidential records.

Logging & audits

PhixFlow logs all access and access attempts to support forensic data analysis. In addition, all changes to configuration objects in PhixFlow are audited.
During a project, PhixFlow consultants follow a methodology that captures additional security requirements, which for example may include auditing changes to data records.

Deploying PhixFlow for web access

Introduction

This section provides input into your risk assessment process and deployment decisions.
As with any application, deploying PhixFlow for remote access presents security risks. The most common risks for browser based business systems include attempted unauthorised access to the server resources, the data and the users' computers. Whenever a server is available via the world wide web, there is increased exposure to various security vulnerabilities in the underlying web server operating system. For this reason, many customers choose to access PhixFlow via a VPN.

Risk Assessments

We recommend your risk assessment process includes the following:

• • User types – staff, contractors, associates.
  • Dialogue with end-users as well as technology staff, to identify and understand the risks and existing counter-measures.
  • Device types and who owns and manages them.
  • Locations where the system will be accessed from e.g. homes, offices, public areas.
  • Treatment of any high priority risks identified by applying good or best practices in network and firewall configuration, intrusion detection and prevention strategies, server hardening, configuration, deployment, application monitoring and usage guidelines.

Deployment Options

During business requirements and risk assessment, decisions will be made about whether to deploy a using a VPN, Virtualisation (e.g. Citrix), DMZ, Screen subnet etc. VPN or Citrix type technology may be applicable if you have existing architecture in use for other similar applications and/or have low numbers of trusted users needing access e.g. Employees.
For higher numbers of users and/or if a VPN architecture is not appropriate or feasible then a DMZ or screened subnet is usually the method chosen for web, email and ftp applications that require access by remote users but some access to internal resources such as file and database servers. This ensures that the internal network is not exposed to additional threats from the Internet.

Deploying via VPN

Choose a VPN technology that ensures that all data and authentication details are encrypted such as L2TP/IPsec, SSL VPN or Citrix. If possible use a VPN technology that includes a quarantine area, so that you can ensure that users accessing PhixFlow that have up-to-date Anti-Virus and any required Operating System security updates applied. PhixFlow would recommend customers do not use PPTP or L2TP (without IPsec) VPN protocols as these do not encrypt authentication details.

Deploying using a DMZ or Screened Subnet

The following architectures are commonly used by operators of remote access business applications when a VPN is not appropriate:

DMZ using two firewalls
This is most secure and often uses firewalls from 2 different vendors

Screened sub-net using a tri-homed firewall

Hardening

The following table lists the areas that require hardening and recommendations

Install an X509 Certificate to provide encryption

When users access PhixFlow over the internet without a VPN, all traffic should be encrypted so that the information sent and viewed by users is private and cannot be accessed by unauthorised users.
When using PhixFlow without a VPN, we recommend the use of Secure Socket Layer (SSL) and X509 Certificates.

Configure firewall to allow access to the internal network

After hardening, the firewall (or internal interface) should be configured to allow access between PhixFlow and the internal network. The following connections can then be tested internally:

• • Databases
  • Internally hosted web services
  • Authentication
  • File directories
  • Email

Configure firewall to allow access to the internet

Lastly, the firewall (or external interface) should be configured to allow access from the Internet to PhixFlow.

General recommendations for using PhixFlow securely

• • Do not use users' actual names or variants in usernames, use unique ID's
  • Implement least privilege access by:
    • Only placing users in groups appropriate for the tasks they need to do.
    • Review accounts used by PhixFlow solutions for access to databases and email accounts ensuring they only have the level of access needed.
    • Limit the number of administrators or accounts with full access.
  • Do not use the system for testing or development as it is common for additional user accounts to be required, and authorisation to be relaxed to enable testing.

Intrusion Detection & Prevention (ID/IP)

If your company currently uses intrusion detection monitoring tools, the following information may be helpful.

Patching and Monitoring

To protect PhixFlow from security vulnerabilities we recommend a best practice approach is used to identify assess and apply operating system and web application server security updates as soon as possible.
You should also ensure clients operating systems and browsers also deploy security updates as soon as possible, if possible using automatic updates for high priority security vulnerabilities.
Audit PhixFlow user accounts regularly, checking for accounts that are no longer needed or not being used and disable or remove them.

Deploying PhixFlow for Mobile Access

PhixFlow mobile uses the same web application as for web access, which employs responsive design and HTML5 to deliver user interfaces that are compatible with a large number of mobile phones, tablets and netbooks. This approach ensures that no confidential data is stored by PhixFlow on the device itself, and the security policies with regard to user accounts and access are centrally managed exactly as for web access.
Deploying any application for mobile access does present some additional risks. These include loss, theft or shared use of mobile devices and tablets. Other risks include incorrect data input as users can sometimes make mistakes performing data input on very small interfaces.
Because of this, a further risk assessment should be carried out prior to deploying PhixFlow involving users and technology staff, and then risk treatment agreed to reduce the likelihood or impact of any significant risks. This process is something PhixFlow consultants can facilitate or assist with if required, especially if screens and processes need to be reviewed and optimised for mobile devices.
We recommend that in addition to following the guidelines on web access, that all mobile devices used to access PhixFlow applications containing confidential data be protected from unauthorised access by applying the following controls:

Centrally managed mobile devices

We recommend that all mobile devices should be centrally managed to ensure updates are applied and security vulneraries are patched in accordance with the customer's security policy.
We recommend that the remote management allows lost or stolen devices to remotely wiped of all data and settings.

Auto-lock / PIN unlock

We recommend all devices have an auto-lock feature that requires a PIN or passcode to unlock it.

Restrict use in public places

We recommend that customers have a policy in place that limits the viewing of large amounts of confidential data on tablets and laptops in busy areas such as trains, hotel bars and cafes.

Review read only access

When data does need to be entered or viewed in public places, we recommend that customers review screens, process and access controls to reduce the volume of data.