security

11月 022017
 

Managing SAS Configuration Directory SecurityNeed to grant one or more users access to part of your secure SAS configuration directory? You can do it without opening up your SAS configuration directory to everyone.

Most SAS 9.4 Platform deployments on Unix have been done using the SAS Installer account known as sas. The sas account is the owner of the SAS configuration directory. Along with the sas account comes a sas group that out of the box is given generous access to the SAS configuration.

SAS Configuration Directory

The SAS configuration not only includes scripts like sas.servers but it also includes configuration files and logs. It generally includes a lot of control over the SAS environment. Despite locked down security of the SAS configuration on Unix out of the box, there are still valid situations when you need to grant one or more users access to part of the SAS configuration. For example, you might need to enable logging for the workspace server and need to grant write access to the workspace server Logs directory. Or maybe you’re setting up an account to be used for autoloading data into the Public LASR Server. There are many more such examples where you might need to grant one or more users access to part of the SAS configuration.

The sas Group

How do you grant someone access to part of the SAS configuration directory? Why not add the user in question to the sas group? While this may grant your user the access you want, it also introduces the potential for a lot of problems. Keep in mind that the sas group has (and needs) broad access to the SAS configuration. When adding a user to the sas group you are granting that user the same access as the sas group. If the user is administering your SAS environment, that might be okay. If that user is not going to administer your SAS environment, you’ve opened the door for someone to modify or delete any and all of your SAS configuration.

So, what should you do? The short answer is that you should only grant the access needed to the users who need it.

Modifying Security for Workspace Server Logging

Let’s look at the example of enabling the workspace server to produce logs. This is typically done if you need to collect logs for troubleshooting. By default, the workspace server runs under each individual user’s credentials; therefore, each workspace server user would need to be given access to create logs under the workspace server Logs directory. By default, the sas user and sas group are given read, write and execute permission on the workspace server Logs directory. All other users have no access to the workspace server Logs directory. This is a situation where granting all other users read, write and execute access while you need to generate workspace server logs is the recommendation.

Be aware that if logging is enabled for the workspace server, any user who does not have read, write and execute access to the workspace server’s Logs directory will not be able to launch a workspace server session.

The complete steps for enabling workspace server logging can be found in the SAS 9.4 Intelligence Platform: System Administration Guide.

Modifying Security for Autoload

In SAS Visual Analytics, the autoload feature allows periodic synchronization between files on disk and data in memory in a LASR server. The autoload feature for the Public LASR Server is mostly configured out of the box; however, there are a few steps required in order for autoload to be fully enabled. The final step is to schedule the job that will perform the autoload.

By default, the autoload directory for the Public LASR Server is in the SAS configuration directory. It is owned by the sas user and the sas group. The first step in the documentation for how to start autoload is to identify which account will be used to schedule the autoload script. The account you use needs access to both metadata and to the autoload configuration directory. The sas account has access to the autoload configuration directory by default but is not registered in metadata. The ideal answer is to find a balance between overloading an account like sas and not overcomplicating your environment. You could register the sas account in metadata but that would not be my preference. You could also provide metadata server connection information in the autoload script but storing a user id and password in a file is less than ideal. A better solution is the one presented in the Visual Analytics 7.3 – Recommended Post-Install Activities: create an account for the purpose of running autoload, for example, lasradm. The account needs to exist on the operating system (or other authentication provider being used) and in metadata. You would change the ownership of the autoload directory to the lasradm account and to a group other than sas. Creating an operating system group for all of your SAS users is a convenient way to grant permissions or rights to the group of users who will be using SAS. You can create a sasusers group, add lasradm as a member, and make sasusers the group owner of the autoload directory. Now you can schedule the autoload script as lasradm.

SAS Admin Notebook: Managing SAS Configuration Directory Security was published on SAS Users.

4月 132017
 
The Penitent Magdalene

Titian (Tiziano Vecellio) (Italian, about 1487 - 1576) The Penitent Magdalene, 1555 - 1565, Oil on canvas 108.3 × 94.3 cm (42 5/8 × 37 1/8 in.) The J. Paul Getty Museum, Los Angeles; Digital image courtesy of the Getty's Open Content Program.

Even if you are a traditional SAS programmer and have nothing to do with cybersecurity, you still probably have to deal with this issue in your day-to-day work.

The world has changed, and what you do as a SAS programmer is not just between you and your computer anymore. However, I have found that many of us are still careless, negligent or reckless enough to be dangerous.

Would you scotch-tape your house key to the front door next to the lock and go on vacation? Does anybody do that? Still, some of us have no problem explicitly embedding passwords in our code.

That single deadly sin, the thing that SAS programmers (or any programmers) must not do under any circumstances, is placing unmasked passwords into their code. I must confess, I too have sinned, but I have seen the light and hope you will too.

Password usage examples

Even if SAS syntax calls for a password, never type it or paste it into your SAS programs. Ever.

If you connect to a database using a SAS/ACCESS LIBNAME statement, your libname statement might look like:

libname mydblib oracle path=airdb_remote schema=hrdept
	user=myusr1 password=mypwd1;

If you specify the LIBNAME statement options for the metadata engine to connect to the metadata server, it may look like:

libname myeng meta library=mylib
	repname=temp metaserver='a123.us.company.com' port=8561 
 		user=idxyz pw=abcdefg;

If you use LIBNAME statement options for the metadata engine to connect to a database, it may look like:

libname oralib meta library=oralib dbuser=orauser dbpassword=orapw;

In all of the above examples, some password is “required” to be embedded in the SAS code. But it does not mean you should put it there “as is,” unmasked. SAS program code is usually saved as a text file, which is stored on your laptop or somewhere on a server. Anyone who can get access to such a file would immediately get access to those passwords, which are key to accessing databases that might contain sensitive information. It is your obligation and duty to protect this sensitive data.

Hiding passwords in a macro variable or a macro?

I’ve seen some shrewd SAS programmers who do not openly put passwords in their SAS code. Instead of placing the passwords directly where the SAS syntax calls for, they assign them to a macro variable in AUTOEXEC.SAS, an external SAS macro file, a compiled macro or some other SAS program file included in their code, and then use a macro reference, e.g.

/* in autoexec.sas or external macro */
%let opw = mypwd1;
 
/* or */
 
%macro opw;
	mypwd1
%mend opw;
/* in SAS program */
libname mydblib oracle user=myusr1 password=&opw
        path=airdb_remote schema=hrdept;
 
/* or */
 
libname mydblib oracle user=myusr1 password=%opw
        path=airdb_remote schema=hrdept;

Clever! But it’s no more secure than leaving your house key under the door mat. In fact it is much less secure. One who wants to look up your password does not even need to look under the door mat, oh, I mean look at your program file where the password is assigned to a macro variable or a macro. For a macro variable, a simple %put &opw; statement will print the password’s actual value in the SAS log. In case of a macro, one can use %put %opw; with the same result.

In other words, hiding the passwords do not actually protect them.

What to do

What should you do instead of openly placing or concealing those required passwords into your SAS code? The answer is short: encrypt passwords.

SAS software provides a powerful procedure for encrypting passwords that renders them practically unusable outside of the SAS system.

This is PROC PWENCODE, and it is very easy to use. In its simplest form, in order to encrypt (encode) your password abc123 you would need to submit just the following two lines of code:

proc pwencode in="abc123";
run;

The encrypted password is printed in the SAS log:

1 proc pwencode in=XXXXXXXX;
2 run;

{SAS002}3CD4EA1E5C9B75D91A73A37F

Now, you can use this password {SAS002}3CD4EA1E5C9B75D91A73A37F in your SAS programs. The SAS System will seamlessly take care of decrypting the password during compilation.

The above code examples can be re-written as follows:

libname mydblib oracle path=airdb_remote schema=hrdept
	user=myusr1 password="{SAS002}9746E819255A1D2F154A26B7";
 
libname myeng meta library=mylib
	repname=temp metaserver='a123.us.company.com' port=8561 
 		user=idxyz pw="{SAS002}9FFC53315A1596D92F13B4CA";
 
libname oralib meta library=oralib dbuser=orauser
dbpassword="{SAS002}9FFC53315A1596D92F13B4CA";

Encryption methods

The {SAS002} prefix indicates encoding method. This SAS-proprietary encryption method which uses 32-bit key encryption is the default, so you don’t have to specify it in the PROC PWENCODE.

There are other, stronger encryption methods supported in SAS/SECURE:

{SAS003} – uses a 256-bit key plus 16-bit salt to encode passwords,

{SAS004} – uses a 256-bit key plus 64-bit salt to encode passwords.

If you want to encode your password with one of these stronger encryption methods you must specify it in PROC PWENCODE:

proc pwencode in="abc123" method=SAS003;
run;

SAS Log: {SAS003}50374C8380F6CDB3C91281FF2EF57DED10E6

proc pwencode in="abc123" method=SAS004;
run;

SAS Log: {SAS004}1630D14353923B5940F3B0C91F83430E27DA19164FC003A1

Beyond encryption

There are other methods of obscuring passwords to protect access to sensitive information that are available in the SAS Business Intelligence Platform. These are the AUTHDOMAIN= SAS/ACCESS option supported in LIBNAME statements, as well as PROC SQL CONNECT statements, SAS Token Authentication, and Integrated Windows Authentication. For more details, see Five strategies to eliminate passwords from your SAS programs.

Conclusion

Never place unencrypted password into your SAS program. Encrypt it!

Place this sticker in front of you until you memorize it by heart.

PROC PWENCODE sticker

 

One deadly sin SAS programmers should stop committing was published on SAS Users.

2月 102017
 

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.

Security enhancements

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:

Middle Tier Changes and Upgrades in SAS 9.4 M4

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:

Middle Tier Changes and Upgrades in SAS 9.4 M4

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:

Middle Tier Changes and Upgrades in SAS 9.4 M4

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.

References

SAS 9.4 Intelligence Platform: Middle Tier Administration Guide, Fourth Edition

Encryption in SAS 9.4, Sixth Edition

 

tags: SAS 9.4, SAS Administrators, SAS Professional Services, security

Middle Tier Changes and Upgrades in SAS 9.4 M4 was published on SAS Users.

8月 232016
 

Managing Server Access for SAS Mobile BI UsersTablets, 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.

tags: SAS Mobile BI, SAS Visual Analytics Administrator, security

Managing Server Access for SAS Mobile BI Users was published on SAS Users.

8月 082016
 

Passcode security for SAS Mobile BIMobile 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.

Passcode security for SAS Mobile BI

Optional Passcode Lock in Settings.

When presented with the Passcode dialog, create a 4-digit passcode for SAS Mobile BI.

Passcode security for SAS Mobile BI01

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.

Passcode security for SAS Mobile BI02

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.

Passcode security for SAS Mobile BI03

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.

Passcode security for SAS Mobile BI04

Application Reset

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.

Passcode security for SAS Mobile BI05

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:

Passcode security for SAS Mobile BI06

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 security for SAS Mobile BI07

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.

 

 

tags: SAS Mobile BI, security

Passcode security for SAS Mobile BI was published on SAS Users.

8月 032016
 

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 […]

How will Brexit impact cybersecurity? was published on SAS Voices.

6月 142016
 

“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.