.@philsimon raises some chilling questions about the IoT and current threats.
Since the SAS 9.4 M2 release in December 2014, there have been several refinements and updates to the middle tier that are of interest to installers and administrators. In this blog, I’m going to summarize them for you. What I’m describing here is available in the newest SAS release (9.4 M4). I’ll describe them at a high level, and refer you to the documentation for details and how to implement some of these changes.
Preserve your TLS Customizations:
For security purposes, many of you will manually add TLS configurations, either to the SAS Web Server, the SAS Web Application Server, or both. In addition, you may prefer to use your own reverse proxy server (such as IIS), either instead of, or in addition to, the SAS Web Server. Before the 9.4 M4 release, when upgrading or applying maintenance, you had to undo these custom configurations, perform the upgrade, and then apply the custom configurations again. Now, the upgrade will preserve them, making the process much easier. See Middle-Tier Security in the Middle Tier Administration Guide, Fourth Edition for full details.
Newer versions of OpenSSL are now provided (see doc for specific version numbers):
A Java upgrade enables enforcement of TLSv2. TLS is now considered the security standard for https connections, (SSL is obsolete) and this can be enforced with configurations to the SAS Web Server and the SAS Web Application Server. The new version of Java SAS is using (Ver 1.7+) now allows for this. One important thing to be aware of is that certificates are completely independent of which protocol you are using, and therefore any certificates you may have been using with SSL should work equally with newer TLS protocols.
Management of the trusted CA (Certificate Authority) bundle:
SAS now has a trusted CA bundle, that can be managed by the SAS Deployment Manager, in a new location: SASHome/SASSecurityCertificateFramework/1.1/cacerts/. The CA certificates can be root certificates, intermediate certificates, or both. Here’s what the menu item looks like:
Previously it was necessary to manually add your root/intermediate certificates to the Java truststore “cacerts,” located inside the JRE; now it’s done through the new interface. If you are on Windows, you must also add trusted CAs to the Windows store (as before), which will make them available to any browsers running there. This is documented at http://www.sqlservermart.com/HowTo/Windows_Import_Certificate.aspx and elsewhere online.
Security Support for SAS Web Applications – white list external sites, and HTTP request methods:
For added security, web sites hosting SAS web applications can now maintain a white list of external URLs that are allowed to connect in. This provides protection against Cross Site Request Forgeries, and other vulnerabilities. This is what the prompt looks like in the SDW:
HTTP request methods can also be specified as allowed/not allowed. The list of URLs can be specified during installation in the SDW (shown above), or using the SAS Management Console. You can disable whitelist checking entirely, and you can add a “blacklist” or specific sites to always block. You can also block based on request method–ie, GET, POST, PUT, etc. See the Middle Tier Administration Guide for details.
Forward Proxy Configuration:
You can now set up SAS web applications to forward external URL requests through a proxy–here it’s called a forward proxy server. Many organizations do this behind their firewalls. See details for how to set this up in the administration guide.
Other miscellaneous changes:
As an administrator you can now force users to Log Off using SAS Web Administration Console. You can also send emails to one or more users from the same window. This is what the menu looks like:
Faster start-up time for the SAS Web Application Server
JMS Broker (ActiveMQ) now uses Version 5.12.2 (fixed bugs).
SAS Web Server now uses version 5.5.2 and includes an updated mod_proxy_connect module for TLS tunneling.
Tablets, phablets, smartphones.
These mobile devices not only travel to different corners of the earth with their owners; they participate in certain adventures that can result in an unexpected turn of events.
Thanks to their mobility, these devices can be misplaced. And they could be found later. In rare cases, they can get lost. In the event that a user is separated from his or her mobile device, there are security mechanisms in place for protecting access to your organization’s server where data and reports reside.
Whether mobile devices accompany their SAS Mobile BI 7.33 users to the Himalayas or to the Sahara Desert, they certainly need to be tracked and managed by administrators. In my last blog, I talked about how an app-specific passcode protects access to the SAS Mobile BI app by preventing anyone other than the SAS Mobile BI user from accessing the app on the mobile device. Now, let’s take a look at how your administrators manage and protect access from the SAS Mobile BI app on your devices to connect to servers in your organization.
The SAS Visual Analytics 7.3 suite of applications includes the Administrator application with the Mobile Devices tab. The Mobile Devices tab is somewhat like an air traffic control system for an airport. Just as airplanes that land and take off are monitored and managed at the air traffic control tower by personnel, mobile devices that connect to your organization’s server with the SAS Mobile BI app are monitored and managed in the Administrator application’s Mobile Devices tab.
SAS Visual Analytics Administrator runs on the same server where your SAS Visual Analytics reports are stored and accessed. It maintains a logon history that informs your administrator details regarding mobile devices that logged on or attempted to log on to the server from the SAS Mobile BI app. For example, a timestamp indicates when a device connected to the server. A management history equips administrators with data on mobile devices that were whitelisted, blacklisted, or removed from either the whitelist or the blacklist.
Managing Mobile Devices
Regardless of how many mobile devices are installed with the SAS Mobile BI app, security administration is required for every device that accesses data and reports on the server. Every mobile device has a unique identifier, and this unique identifier is used by SAS Visual Analytics Administrator to determine if the device is allowed to access the server.
To control mobile devices’ access to your organization’s server, your administrator manages server access by implementing either a whitelist or a blacklist from the server. By default, blacklisting is enforced on servers that are accessed by the SAS Mobile BI app.
Inclusion Approach to Managing Devices
The whitelist scenario follows the inclusion approach. By default, you cannot connect to the server via SAS Mobile BI until your device ID is added to the whitelist by your administrator. If the unique device ID is added to the whitelist by your administrator, you can use the device to subscribe, view, and interact with SAS Visual Analytics reports (via the SAS Mobile BI app).
Exclusion Approach to Managing Devices
In the blacklist scenario, it is the exclusion approach. By default, everyone can connect to the server from SAS Mobile BI on their mobile devices unless their device IDs are added to the blacklist by the administrator. Any device whose unique device ID is not added to the blacklist can connect to the server from the SAS Mobile BI app. For instance, if you lost your mobile device, your administrator can go to the Logon History, select the device (listed by device ID, user name etc), and add it to the blacklist. Then, you cannot use the device to log on to the server from the app.
The Easy Way to Switch from Blacklisting to Whitelisting
By default, blacklisting is enforced on the server that is accessed by the SAS Mobile BI app, and the viewerservices.enable.whitelist.support configuration property in SAS Management Console (SAS Configuration Manager for SAS Visual Analytics Transport Service) is set to false. If you are an administrator, and wish to switch from blacklisting to whitelisting, the easiest way to do it is to select whitelisting in the Administrator’s Mobile Devices tab and add the device IDs to the whitelist. Then, the viewerservices.enable.whitelist.support configuration property in SAS Management Console is automatically updated and set to true. This is an easier method for switching from blacklisting to whitelisting because it does not require a restarting of the server. If you were to go to SAS Management Console first and set the viewerservices.enable.whitelist.support configuration property to true, this action requires you to restart the server.
Request to Add Devices to a Whitelist
There are a couple of different ways that your administrator can obtain and add device IDs to a whitelist. If the unique device ID is already known to your administrator, he or she can easily add it to the whitelist in the Administrator application’s Mobile Devices tab. Alternatively, if you happen to install SAS Mobile BI app on a new mobile device that is not being managed from the server, the app can take you to your email with template text that includes your mobile device ID – just send that email to your administrator requesting server access from your mobile device.
Suspending or Allowing Server Access from the App
Now here is my most favorite part of device management. Access from SAS Mobile BI to the server, as we have just noted, is determined by either whitelist or blacklist management of devices, not by user accounts. This approach extends flexibility for SAS Mobile BI users. For example, I have an iPhone and a Galaxy Tab Pro tablet – I have SAS Mobile BI app on both devices, and I use both of them to access the server, subscribe to SAS Visual Analytics reports, view, and interact with them. If I happen to misplace my Galaxy Tab Pro tablet and can’t seem to find it, I notify my administrator so that server access from the app on this device can be removed.
My administrator, who follows the whitelist approach, removes my Galaxy Tab Pro’s unique device ID from the whitelist. Then, I can no longer use the SAS Mobile BI app on this device to log on to our server and subscribe to SAS Visual Analytics reports. However, I can continue to use my iPhone (which has remained in the whitelist) to log on to the server, subscribe, view and interact with reports on the server.
Few days later, I find my misplaced Galaxy Tab Pro tablet. I email my administrator indicating that the device is back in my possession. My administrator adds the unique device ID for my Galaxy Tab Pro back to the server’s whitelist. Voila – I am back in business, using SAS Mobile BI to connect to the server from my Android tablet.
In a Nutshell
There are several mechanisms available for securing the SAS Mobile BI app and access to your organization’s servers is one of them. In my next blog, we will take a look at how tethering works to protect data access for SAS Visual Analytics reports from the SAS Mobile BI app.
Mobile devices travel with humans pretty much anywhere that humans want to go. Unlike desktop computers that stay fixed and grounded within brick and mortar walls, mobile devices are used in all sorts of locales – offices, homes, cars, planes, swimming pools, soccer fields, movie theaters – the list goes on. So, it’s no surprise that your SAS administrator would want to protect SAS Visual Analytics reports that are viewed from the SAS Mobile BI 7.33 app running on mobile devices.
Several security strategies are available for SAS Mobile BI users. Let’s take a look at how passcode security, along with Touch ID for Apple devices, protects access to the app.
Required vs. Optional Passcode
There are two ways to apply passcode protection to SAS Mobile BI. Your administrator can enforce a passcode requirement for the server where the SAS Visual Analytics reports reside. On the server, this is done by enabling the Require Passcode on Mobile Devices capability and adding users as members of the group that is required to create and use a passcode for accessing SAS Mobile BI.
If a passcode is not required by your administrator, you can create an optional passcode to protect access to the app on your mobile device. In either scenario, if your mobile device is used by someone other than you, then you have the peace of mind that only you can access SAS Mobile BI by entering your passcode.
Creating an Optional Passcode
To set up an optional passcode for SAS Mobile BI, go to Settings for the app. Tap on the toggle switch for Passcode lock and create a passcode.
Optional Passcode Lock in Settings.
When presented with the Passcode dialog, create a 4-digit passcode for SAS Mobile BI.
Creating a Passcode
By default, anytime that you access SAS Mobile BI after 5 minutes of inactivity (or for the period of inactivity that is set by your administrator), you are prompted by the Passcode dialog to enter your passcode.
Entering Your Passcode to Access the App
If the passcode is mandated and not optional, then your administrator can customize and set a different inactivity timeout before a passcode needs to be entered.
What Happens If You Enter Incorrect Passcodes?
If you enter an incorrect passcode, you are given a total of 10 attempts to enter your correct passcode. This is the default behavior when you have an optional passcode for the app. Administrators that mandate the need for a passcode with the Require Passcode on Mobile Devices capability on the server can customize the settings for the server to determine the number of wrong passcode attempts.
Entering an Incorrect Passcode
If you enter an incorrect passcode 10 times, you are locked out for 15. When the lock-out expires, you are prompted again to enter your passcode.
When the lock-out expires, you are prompted again to enter your passcode. On the second attempt, if you exceed the allowed number of passcode entry attempts, SAS Mobile BI removes all reports, data, and server connections from your mobile device. The app is reset to its default settings.
Just Can’t Remember Your Passcode?
If you forget your passcode, the easy thing to do is delete the app, download and reinstall the app, create a new passcode, and set up your connections to the servers with SAS Visual Analytics reports.
Touch ID for Apple Devices
If you are an Apple device user who has simplified life further by using a Touch ID instead of a passcode, you can use the Touch ID to access the SAS Mobile BI app. To enable Touch ID on your iPhone or iPad, follow these instructions from Apple to add your fingerprint and create a Touch ID for your Apple device.
If Touch ID is enabled for your device, and there is an inactivity period with SAS Mobile BI, the app prompts you for your Touch ID fingerprint:
Touch ID Prompt for SAS Mobile BI on Apple Devices
If your Touch ID fingerprint is incorrect, then the app prompts you to enter your passcode:
Passcode Prompt if Touch ID is Incorrect
Now, you are familiarized with securing access to SAS Mobile BI on your devices. We will continue this journey to learn about various other security options available for the app.
Some weeks have passed since the United Kingdom voted, by a margin of 52 per cent for and 48 per cent against, to leave the European Union, the organization it's been a leading member of since 1973. The tumultuous global reaction to the vote has those of us in information […]
“Good afternoon, Mr. Yakamoto. How did you like that three-pack of tank tops you bought last time you were in?” Washington D.C. Year 2054. Chief of PreCrime John Anderton is running from the law for a crime he has not committed yet. After a risky eye transplant in order to […]
Location analytics and the 'Minority Report' approach was published on SAS Voices.
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.
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.
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.
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.
In researching material for an upcoming project, I investigated the SAS Deployment Backup and Recovery Tool available in SAS 9.4. Here are some of my findings on identifying what directories are included in a Backup and Recovery session and how to add custom directories to a backup configuration.
The SAS Backup and Recovery Tool is designed to provide an integrated method for backing up and recovering your SAS content across multiple tiers and machines. Note that this utility is a system-wide tool. It’s intended to back up an entire environment as opposed to a single machine in a multi-machine deployment.
What directories are included in a backup?
There is a directory called Backup created in the SAS configuration directory on the first execution of the Backup and Recovery Tool. This directory is created on every machine that is participating in the backup. It is used to contain the backup files and configuration information and is updated on each execution of the utility. In this directory, the file backupserver.log contains the log information associated with backups. Looking in this file, at the component com.sas.svcs.backup.server.handler.LevconfigBackupHandler, you can see the list of directories included in the backup.
Specifying additional directories for the backup
The Backup and Recovery Tool does not back up the entire contents of your SAS configuration directories. As you can see from the list above, it backs up only these directories:
- data directories
- SASEnvironment directories
- server configuration directories for each server in the SAS Server tier.
The custom directory is added to the backup configuration by using the sas-add-backup-customdir command in the batch tools directory (at SASHOME/SASPlatformObjectFramework/9.4/tools/admin). To display a list of additional directories that have been specified for backup, use the sas-display-backup-customdir command.
When performing an ad hoc backup, you will see the custom directory listed in the backup locations.
To learn more
More detail on the use of the Deployment Backup and Recovery Tool can be found in the SAS 9.4 Intelligence Platform: System Administration Guide under Backing Up and Restoring Your SAS Content.
There’s additional information about Using Backups and Restoring Customizations in the SAS 9.4 Guide to Software Updates.