REST has become the standard for information exchanged between disparate platforms and applications within the enterprise. In the NonStop space it is being used more and more, to allow NonStop applications to communicate with other enterprise applications, and integrate with solutions outside the enterprise. In these environments security is critical. In this article we explain some of the best practices to consider to help protect your sensitive data and applications, while still making them easily accessible to your internal and external business partners that require access. We’ll also give some real-world examples showing how LightWave Server^TM and LightWave Client^TM users are doing exactly that.

When implementing a secure REST services strategy, one must consider the following items as part of your best practices.

• Network isolation
• Protection of sensitive data in transit and at rest
• Authentication
• Authorization
• Access control
• Auditing

We will elaborate on these best practices, with a goal of assisting those interested in deploying secure REST services. Not all of these security points will be required in every instance, but all should be considered. Specific organizations may have additional requirements that should be discussed with the organization’s security team.

Network Isolation

Network isolation typically involves using an HTTP proxy, or similar, to create a firewall. In most environments, the NonStop will already be protected by a firewall, however consideration will need to be given to the new REST services and their impact on the firewall. Do new ports need to be opened? Should additional examination of the REST service payload be considered? These issues should be discussed with the networking team.

Protection of Sensitive Data

In most cases, the new REST services will likely be carrying some sort of sensitive data, be it cardholder data (CHD), health care information, or other types of personally identifiable information (PII). This data will now be carried over an HTTP connection, and could potentially be picked up by a user with access to a network trace facility, either inside the enterprise, or even externally. This data needs to be protected using TLS. TLS 1.1 is now required by PCI DSS, with strong encouragement from the PCI security council to move to TLS 1.2. TLS 1.3 should now be under consideration for any REST implementation, and is now supported by both LightWave products.

Sensitive data should also be considered when it is written to disk. PCI DSS req 3.4 requires that any PAN data be rendered unreadable when stored on disk. LightWave solutions allow sensitive data to be protected and masked when written to diagnostic and HTTP logs, and even in internal memory.

Authentication

At its simplest, the process of authentication is validating that a user is who they say they are. In the case of REST services, authentication is the first step in determining whether access should be allowed to a particular service. Authentication can be achieved in a variety of ways, including with username and password, and there are a wide variety of newer OAUTH-based standards in use. LightWave solutions support HTTP Authentication to allow username and password to be safely carried and used for authentication, and also a number of OAUTH authentication options, to allow NonStop applications to connect to a wide variety of external REST services.

Authorization

Once the user is authenticated, the next important step is to determine whether they should be allowed to access the specified service they’re trying to invoke. In the case of REST services, the resource they are accessing is the API or the service. The REST service middleware solution needs to be able to link the authenticated user to the service being accessed to determine if access should be allowed. LightWave products allow authorization based on a number of different criteria, including client IP address, to ensure that only authorized access is permitted.

Access Control

The previous steps outlined will not be of much use if the management or administrative environment used by the REST service middleware is not itself secured. Without adequate Access Control in place, rogue users could reconfigure the solution allowing unauthorized access to the services. The solution needs to provide Access Control to ensure that only authorized users are allowed access to the administrative environment. LightWave solutions allow specific users to be configured with access to the management console, ensuring that unauthorized users are not given access to these sensitive functions.

Auditing

Auditing provides a historical record of what actions were performed within the REST service environment, and by whom. This record is important if ever a breach occurs, but it can also be used proactively by security incident event management (SIEM) solutions like Microfocus ArcSight and RSA Secure Analytics. These solutions piece together security information from across the enterprise to determine if a security incident might be occurring. Comprehensive auditing support is currently being added to LightWave products, allowing auditing of both the REST services operations being invoked, and also the administrative functions being performed through the console.

Real-World Implementation

A number of LightWave users are using LightWave and other components to implement most or all of these important security best practices.

RESTful architectures are particularly attractive in solving many financial services integration problems, leveraging infrastructure, skills, and systems already in place at financial service firms. A major US financial services company is using LightWave Client^TM to interface with FIS Global Services. This customer has a similar security infrastructure in place, including TLS, network isolation, access control, and they are authenticating to the FIS REST service using OAUTH2. More details are available here.

Another major US financial services company uses LightWave Server^TM for POS transactions. They are utilizing LightWave’s TLS support to protect their REST services, and have also implemented network isolation, user access control, and data masking to protect sensitive data in their REST services and in logs.

The same customer is using LightWave Client^TM to stream to Microsoft Azure for business intelligence analysis. In this deployment, they are once again using TLS to protect data in transit, have network isolation in place, and are protecting sensitive data via data masking.

Like financial services, the banking industry has strong data security requirements due to the sensitive and private data that they deal with. A major North American bank uses LightWave Client to interface with the Google Apigee API Gateway to obtain important branch and ATM information. This data exchange is protected via the use of TLS, and LightWave Client data masking, along with OAUTH2 for authentication. More details can be found here.

Modernization and Security

REST services are a powerful tool for integrating the NonStop with other parts of the enterprise, and with external customers, partners, and services, boosting the value of our NonStop platform and its applications. These best practices should help with the secure deployment of your organization, and the examples show how customers are achieving application modernization and opening up their NonStop platforms without compromising security.