REST has become the de facto standard for information exchange between disparate platforms and applications. 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 steps that can be taken to 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 and LightWave Client users are doing exactly that.
The following items should be considered as part of a secure REST services strategy:
- Network isolation
- Protection of sensitive data in transit and at rest
- Authentication
- Authorization
- Access control
- Auditing
This article will elaborate on each of these areas of security, 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 card holder 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 has 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 specific 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 a lot of 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.
A number of LightWave users are using LightWave and other components to implement most or all of these important security fundamentals.
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 to interface with FIS Global Services. This customer has 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 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 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.
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 guidelines should help with secure deployment your organization, and the examples show how customers are achieving application modernization and opening up their NonStop platforms without compromising security.
Andrew Price
Andrew Price has over 28 years of experience in the NonStop space. After working at Insession and ACI in numerous positions, including Director of Solutions Consulting and Sales Support, he moved on to XYPRO, where he was initially Director of Product Management and then VP Technology. Today, he is Director of Sales and Business Operations in Asia Pacific for NuWave; focusing on sales, business development, and first-level support in the region.
Phil Ly
Phil Ly is the president and founder of TIC Software, a New York-based company specializing in software development and consulting services that integrate NonStop with the latest technologies, including Web Services, .NET and Java. Phil’s passion for NonStop, and educating the larger technology community – both industry veterans and next gen alike – on the power the platform leverages, are central to TIC’s business philosophy. While Phil (and TIC) have always evangelized modernization as a NonStop keystone, he is especially focused, as of late, on identifying applications and services to “future proof NonStop,” so as to extend the platform’s efficacy and impact for years to come. Prior to founding TIC in 1983, Phil worked for Tandem Computers in technical support and software development.
Be the first to comment