Encryption and SAS is a wide ranging topic – so wide it gets its own book and features strongly in both the SAS(R) 9.4 Intelligence Platform: Security Administration Guide, Second Edition and SAS(R) 9.4 Intelligence Platform: Middle-Tier Administration Guide, Third Edition. In this blog we’ll take a high level look at what is involved in using HTTPS encryption in-transit within a SAS deployment.

This blog will provide an overview of considerations when designing for security requirements that include encryption and will be the first in a series of blog discussions around encryption.

Why use encryption?

Many customers both from a business and IT perspective are becoming more concerned about encryption. For some, this concern comes from industry regulation (think here of the banking sector). For many others, the sheer number of news stories about data breaches and the costs to business are raising the priority of encryption. We are definitely moving towards a world where the default is to encrypt.

This greater focus on security in general can be seen here at SAS as well. We have the Security Assurance page on www.sas.com and the associated SAS® Software Security Framework. We also have a place for security bulletins on www.support.sas.com.

One aspect of security that is becoming more and more common for SAS customers is the use of encryption for data in-transit. Customers’ are either externalizing resources, making them available to the wider internet, moving towards cloud based deployment models, or even becoming more concerned over network security within their own organizations.

In-Transit?

Does that mean it’s in a van? Nope – what we mean when we say data in-transit is that it is data passing from one process to another. The end points might be on the same host or on different hosts. For encryption, we split the topic into two areas: data being transmitted or in-transit, and data sitting in a file or database, so at-rest. Whilst many principles of encryption apply to either data in-transit or at-rest, most methods of applying encryption are different depending on whether the data is at-rest or in-transit.

The most common use of encryption for data in-transit is to wrap encryption around traditional HTTP transmissions. The move away from using HTTP as a default and defaulting to secure HTTP (HTTPS) can be seen in many areas of the World Wide Web. We expect our webmail or banking systems to encrypt the traffic from the browser to the server by using HTTPS, but this is now starting to extend through to many other sites as concerns over confidentiality spread. Google, Facebook, and even Wikipedia now use HTTPS as the default rather than HTTP.

HTTPS Focus

The expectation is that you can use HTTPS to replace HTTP connections. So, let’s highlight the use of HTTPS within a typical SAS deployment.

Most SAS administrators and security professionals will expect several items on this diagram. Obviously, if a customer is asking for HTTPS we would expect to see the SAS Web Server called out along with the browser based clients. Some of the other SAS components that need to communicate over HTTPS might not be so obvious.

• The SAS Environment Manager Server includes a web application server that can be configured for HTTPS on the default port of 7443.
• The SAS Web Application Server instances can also be configured for HTTPS instead of the default HTTP. There might be multiple instances of the SAS Web Application Server deployed to support scalability and redundancy of the SAS web applications. With multiple instances, the proven practice is to configure the connections for each instance in the same way, either with HTTP or HTTPS.
• Clients such as SAS Management Console can make connections to the SAS Content Server and will need to communicate over HTTPS if the SAS Web Server is configured for HTTPS.
• The analytical clients like SAS Enterprise Miner & SAS Forecast Studio make all their connections to the server tier via the middle-tier and are built to enable HTTPS communication, but this must be configured.
• The SAS Application Servers, such as Workspace Servers are also clients of the middle-tier for actions such as publishing to WebDAV, interacting with the LASR Authorization Service and components like the SAS Information Retrieval Studio.

What this illustrates is that just the requirement of having encryption for the SAS Middle-Tier i.e. HTTPS connections to the SAS Web Server can be quite complex, and requires understanding the interactions of the different components.

Setting up complete use of HTTPS requires a mixture of automatic and manual configuration. More details of these configuration steps can be found in the SAS(R) 9.4 Intelligence Platform: Middle-Tier Administration Guide, Third Edition. The options for how to configure the components to use HTTPS vary, and need to be managed carefully. The SAS Deployment Wizard is able to configure HTTPS with the SAS Web Server and SAS Environment Manager Server but does not configure the SAS Web Application Server.

Where does it end?

Important questions for the use of HTTPS with the middle-tier include: Just where does it end? How far do you want the encryption to go? Is it important to encrypt everything or just to encrypt the traffic to and from the SAS Web Server? The diagram below illustrates encrypting all the way through the middle-tier.

One issue which can impact on how far you carry the encryption is that of secure cookies. If you have a requirement to secure the cookies used in the environment, then you need to configure HTTPS for all the connections to and from SAS Web Server and SAS Web Application Server.

Who do you trust?

In addition to working out which components you need to configure for HTTPS, you also need to think about trust. The client, even if that client is a SAS Workspace session, needs to be able to trust the certificate presented by a server. Trust in the case of HTTPS means that the client must be able to “know” or “trust” who validated or signed the server certificate. When the client trusts the validator, it can then trust that the server is who it claims to be. So the client is able to trust that the bank is really the bank and not someone pretending to be the bank.

If you’ve gone with site-signed, self-signed, or even some third-party signed certificates, how do you tell the clients to trust them? You are not going to see a pop-up message from a remote Workspace session asking you if you are sure you want to trust the certificate, in the way a browser prompts the user as shown here:

Separate configuration steps need to be taken to make this trust automatic. This is an area where administrators can run into problems when implementing HTTPS. The issues of trust are important enough to warrant their own posting, so look out for my next blog where we’ll discuss trust in more detail.

Summary

Hopefully, this blog posting has given you a high level feeling for the considerations that can be involved in deploying some encryption technologies in your environment. Remember this blog only touched on the subject of TLS with the SAS Middle-Tier. Encryption for other parts of a SAS environment are provided with SAS/SECURE which is included with all SAS deployments (unless prohibited by import/export restrictions). I encourage you to review the Encryption in SAS® 9.4, Fifth Edition book and start to explore what is required for installing and configuring TLS and certificates. More implementation details can be found in in both the SAS(R) 9.4 Intelligence Platform: Security Administration Guide, Second Edition and SAS(R) 9.4 Intelligence Platform: Middle-Tier Administration Guide, Third Edition.

Look out for my next blog where we’ll look at issues around trust in a little more detail.