Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

B AND MOBILE ACCESS
PhixFlow 7.0
16 September 2016

Anchor
_Toc505754055
_Toc505754055
Anchor
_Toc508076427
_Toc508076427
Anchor
_Ref509122098
_Ref509122098
Anchor
_Ref509122107
_Ref509122107
Anchor
_Ref509122113
_Ref509122113
Anchor
_Ref509122119
_Ref509122119
Anchor
_Ref509123051
_Ref509123051
Anchor
_Ref509123401
_Ref509123401

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
Change History

Version

Date

Author/Approver

Description

1

12-Sep-16

Craig Strangwick

Initial public version.

2

16-Sep-16

Andy Humphries

Approved version










References
Other PhixFlow sources which may be referenced are:

  1. PhixFlow online help


Anchor
_Toc145416157
_Toc145416157
Anchor
_Toc229386997
_Toc229386997
Anchor
_Toc461783722
_Toc461783722
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

This section describes the approaches and features within PhixFlow that address common security vulnerabilities and ensure PhixFlow is as secure as possible.

  • Deploying PhixFlow for web access

This section provides input into your risk assessments and web deployment decisions.

  • Deploying PhixFlow for mobile access

This section describes additional deployment decisions for mobile access.

Anchor
_Toc461783723
_Toc461783723
PhixFlow security design features

Anchor
_Toc461783724
_Toc461783724
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.

Anchor
_Toc461783725
_Toc461783725
Secure authentication
Anchor
_GoBack
_GoBack

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.

Anchor
_Toc461783726
_Toc461783726
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.

Anchor
_Toc461783727
_Toc461783727
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.

Anchor
_Toc461783728
_Toc461783728
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.

Anchor
_Toc461783729
_Toc461783729
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.

Anchor
_Toc461783730
_Toc461783730
Deploying PhixFlow for web access

Anchor
_Toc461783731
_Toc461783731
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.

Anchor
_Toc461783732
_Toc461783732
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.

Anchor
_Toc461783733
_Toc461783733
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.

Anchor
_Toc461783734
_Toc461783734
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.

Anchor
_Toc461558689
_Toc461558689
Anchor
_Toc461783735
_Toc461783735
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

Anchor
_Toc461558690
_Toc461558690
Anchor
_Toc461783736
_Toc461783736
Hardening

The following table lists the areas that require hardening and recommendations

Area to Harden

Recommendations

Operating Systems

Refer to the PhixFlow system planning guide and Vendor recommendations

Apache Tomcat application server

Refer to the PhixFlow system planning guide and vendor recommendations

PhixFlow Database server

Refer to the PhixFlow system planning guide and database vendor recommendations

PhixFlow Application

Refer to the PhixFlow Installation guide for installation with least-privilege access and removal of installation files and users.

PhixFlow Solutions Configuration

Review the permissions implemented on any applications.
Audit users and remove any that no longer require access.
Ensure a strong password policy used.


Anchor
_Toc461558692
_Toc461558692
Anchor
_Toc461783737
_Toc461783737
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.

Anchor
_Toc461783738
_Toc461783738
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

Anchor
_Toc461783739
_Toc461783739
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.

Anchor
_Toc461783740
_Toc461783740
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.

Anchor
_Toc461558691
_Toc461558691
Anchor
_Toc461783741
_Toc461783741
Intrusion Detection & Prevention (ID/IP)

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

Whitelist/Blacklist

Pattern

Description

Blacklist

.php, .exe, .asp, .aspx,

PhixFlow does not use any of these file extensions

Blacklist

..\ – <! </script>

Requests with these character combinations are not required

Whitelist

? & :

PhixFlow uses these characters in the URL

Anchor
_Toc461558694
_Toc461558694
Anchor
_Toc461783742
_Toc461783742
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.

Anchor
_Toc461783743
_Toc461783743
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:

Anchor
_Toc461783744
_Toc461783744
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.

Anchor
_Toc461783745
_Toc461783745
Auto-lock / PIN unlock

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

Anchor
_Toc461783746
_Toc461783746
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.

Anchor
_Toc461783747
_Toc461783747
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.