Security Questions

Frequently asked questions around Keyfax security.

How does Omfax Systems mitigate against supply chain style attacks

All Keyfax product source code is held within a secure cloud-based source code repository.

Access to both our source code repository and build systems is only granted to senior Omfax Systems employees and access is monitored and protected by MFA.

As part of general on-going Keyfax development senior product engineers continually monitor the source code repository commit history on a daily basis to ensure all product changes are genuine, beneficial, and not from unknown actors.

We also work to minimise 3rd party dependencies within Keyfax. Where a dependency is necessary, we ensure these dependencies are kept up to date and often work with the dependency vendor to ensure we are confident they are not susceptible to a supply chain attack.

With each public Keyfax release a release is created within our source control repository which generates a unique cryptographic hash for that release. Upon request Omfax Systems can provide this hash with each release allowing you to recreate the hash locally using the downloaded Keyfax files and compare with the hash we provided to verify the files are original and have not been modified since download.

Does Keyfax support encryption at the application and / or database level?

Is data encrypted in transit?

Omfax Systems would always recommend using a TLS certificate to secure communication in transit between the Keyfax web server and client devices. The Keyfax web server will always communicate with the Keyfax database over an encrypted connection.

Is data encrypted at rest?

By default, Keyfax does not encrypt any data at rest however IT staff can enable encryption at the OS or disk level using technologies such as BitLocker or full disk encryption provided with Windows based server operating systems. Certain sensitive Keyfax configuration settings (such as database usernames and passwords) can be optionally encrypted at rest independent of BitLocker or full disk encryption.

Can Keyfax configuration settings be encrypted at rest?

With Keyfax 4.4.0 and above sensitive configuration settings stored within the Keyfax configuration files can be optionally encrypted. It's important to note that these configuration settings are not encrypted by default and these would need to be ecrypted manually using an encryption utility provided within the Keyfax installation files.

How is communication between the Keyfax web & database server secured?

SQL Server connections & traffic are not encrypted by default. SQL Server can use TLS 1.2 to encrypt traffic however this requires set-up by enabling encrypted connections within SQL Server Management Studio and setting up a certificate within SQL Server Configuration Manager. Each client connecting to the instance of SQL Server would also need a copy of this certificate installed. Further details can be found here.

Database connections are established with SQL Server logins with an appropriately strong password and appropriate firewall / networking rules in place.

What security measures are built into Keyfax to protect against SQL injection, XSS, etc?

The following methods are used:

• ASP.NET request validation is enabled throughout the Keyfax web application to help protect against cross site scripting style attacks

• All internal Keyfax database communication is performed via parameterized stored procedures to protect against SQL injector style attacks.

• Customers should be aware of the potential issues regarding the use of custom SQL Databoxes within Keyfax and should ensure any such SQL is created and/or reviewed by appropriate technical staff with both performance and security in mind.

• Detailed error messages are disabled and sensitive error information is never disclosed to regular end users. Users will always see a generic friendly error message that does not reveal any sensitive information.

• All potentially unsafe text output reflected to web pages is correctly encoded via HttpUtility.HtmlEncode

• Keyfax access secured by a unique session GUID

• Creating a new Keyfax session is only available through the portal or HMS. From Keyfax v4.4, the REST API provides enhanced authentication to better secure launching Keyfax from any external process. Hosts will have this option for any new integrations

• Keyfax relies on the portal to authenticate users before launching a new Keyfax session

• Vulnerabilities can be exposed by both system and application-level components. We rely on local IT staff to ensure the overall system security on any installations we do not host ourselves

• Keyfax already benefits from security enhancements resulting from previous penetration tests. Customers are encouraged to arrange their own Penetration testing. We are happy to investigate and mitigate any new vulnerabilities identified within the Keyfax application

• IT staff should consider a Web Application Firewall (WAF) as an additional layer of protection. Omfax Systems don't have any specific recommendations and it would be up to your IT staff to identify and evaluate solutions.

Have our developers undertaken any training in secure coding: specifically aimed at Internet facing .NET applications? How do we incorporate application security into our software development lifecycle?

No SDL training within SDLC per se, but solid awareness of foundational concepts/considerations e.g. XSS, SQL injection, risk assessment, approved tools, familiarisation with 3rd party Penetration requirements.

How does Omfax Systems consider the OWASP Top 10?

Clearly, other Clients using Keyfax Online have varying levels of security expectations and historically (for Keyfax Self-Service) these have generally been met by working with the Client. The perspective has always been that as a repairs request system it could be deemed lower risk so long as key security measures (as outlined above) are met. However, If further weaknesses are exposed, wherever practicable, we would be more than happy to address these to meet acceptable levels.

What Pen Tests have been undertaken by other customers?

The Keyfax web application has undergone several independent penetration tests by 3rd party security firms and has continued to be hardened over the years. We are familiar with 3rd party penetration testing requirements. Keyfax developers use only vetted tools & libraries from trusted 3rd party vendors. Source control is managed via Git and commits are often peer reviewed with a focus on clear, concise, secure code.

What are the associated front-end / back-end technologies? For example, node.js, ASP etc?

• NET Full Framework 4.8

• ASP.NET Web Forms

• SQL Server

• Bootstrap CSS framework

• jQuery JavaScript framework

• DevExpress 10.2.8 WinForm Controls

• log4net 2.0.8.

Approximately how many unique dynamic and static pages are there?

The large majority of Keyfax application pages are dynamic .ASPX pages, of which there are around 20. There are 8 static html pages such as help pages or error pages. Note that Keyfax also communicates via web services or .ASMX files.

Approximately how many Form Fields are there across the application?

Due to the dynamic nature of Keyfax this is difficult to answer. This largely depends on the customers configuration and underlying scripts. There could be anything from a few dozen fields to hundreds of fields depending on the customers available scripts.

Keyfax allows customers to create scripts that could contain any number of questions. Each of these questions typically use form fields to capture user input. Keyfax supports several different question types.

• Address (displays several fields to capture address information)

• Check List (displays a multiple choice check list)

• DateTime (displays a HTML 5 date input)

• ExternalForm (links to an external HTML page displayed via an iframe)

• File Upload (allows users to upload specific file types)

• List (a list of single choice options)

• Numeric (a number input type)

• Text (a single line free text box)

• Dynamic List (a single choice list populated via a server side data source)

The above question types can be combined in any order to build up Keyfax scripts. A script could contain one or dozens of questions of the above types.

If at any point PEN testing logically runs through any scripts to test the various form fields, we recommend setting up custom PEN test scripts to readily surface the different types of page types and input fields within Keyfax Online for testing.

Does the application have any functionality to change back-end data? For example, an admin page that can add/edit/delete database information?

The Keyfax administration functionality is provided by a .NET Full Framework 4.8 WinForms application.

This application runs natively on Windows based operating systems. This .NET WinForms application is referred to as the Keyfax Administrator Tools.

Keyfax Administrator Tools communicates with the Keyfax web application via SOAP based web services for initial authentication.

Once authenticated the Keyfax Admin Tools then talk directly to the SQL Server database used to power Keyfax to add, edit or delete records. No administration functionality is provided via the Keyfax web application.

Do you have a configuration and change management approach?

Keyfax product changes follow secure software development best practices, including regular security risk assessments and on-going rigorous automated & manual testing.

Changes within our cloud environment that could impact customers are scheduled and clearly communicated with customers. Changes internally require a formal request for change (RFC) document. This document describes the details of the change, steps required to execute the change, possible impact & risks of the change and a backout plan for the change. All production environment RFCs are reviewed and only approved by senior management after first being thoroughly tested separately within a test environment. Developer access to production environments is limited via explicit access requests, subject to senior management review and authorization.

I'm aware of the Heartbleed vulnerability; does this affect Keyfax?

The Heartbleed bug is a vulnerability in the OpenSSL cryptographic software library as defined here by GlobalSign (our SSL certificate provider).

As such Keyfax Self-Service is not affected by the Heartbleed bug as our hosted platform uses Microsoft ISA server and Microsoft IIS7 server.

Microsoft state "We also want to assure our customers that default configurations of Windows do not include OpenSSL, and are not impacted by this vulnerability. Windows comes with its own encryption component called Secure Channel (aka SChannel), which is not susceptible to the Heartbleed vulnerability."

Also none of our internal or hosted messaging systems OR our Virtual Private Networks and associated routing hardware use (or have used) the OpenSSL service/protocol.

How does Keyfax handle data anonymity for the data within the application and / or database?

When personally identifiable information does need to be persisted Keyfax take measures to ensure this data is deleted when no longer needed. To comply with GDPR requirements customers can also define custom retention policies within Keyfax to periodically purge data within the Keyfax database that may contain personally identifiable information (PII). Options such as encrypting data at rest should ensure any long term personally identifiable information is unintelligible.