home-SAS    SAS-SAAS    First steps    Installation    Hardening    Operational    Using    My Notes
design/build    Metadata    Applicative      System monitoring    Application monitoring    backup restore      Checklist      Anomalies    No sense    Free info    top  bottom

Hardening an installation of SAS

building SAS

The SAS installation is ready to be used as you came to this point.
Question: is it safe using this installation?

Abuse of information is not wanted. The security, prevention of abuse and prevention of common failures, must be included in all steps.

Subjects - hacking & Hardening

No sense security

To get a secure environement conforming all requirements (policies) is difficult to adjust afterwards. It is the same reason as of developping correct software instead of trying to improve it out of test results or production problems.

The design including all security should be done before installing the SAS middleware before doing a "proof of concept".

Common installation approach

big brother It´s amazing how little information can be found on this subject with SAS. I am missing:
This means it is leaving the underpinning of the security and the auditing policies in aspect to the installation and the information process to be solved to the customer (business) or the internal support staff.

Common Business requirements

see: BI basics, SOX Basel Solvency why hardening the installation must done.
This BI usage it hitting the heart of confidential / secret information that should not easily got unwanted published in public.

The glossary contains a lot of links with backgrounds about mandatory regulations.
The DTAP Policies & regulations chapter, is the basics why and how in generic. The Samples with Unix templates should give a idea, why with Unix and Unix alikes, the way off a well defined security.

Very little information can be found about hardening BI-tools. This is very strange as it is processing the most confidential business information. Just using Excel is sometimes mentioned as too difficult to audit and too easy to make (un)controlled mistakes with.

At the same time about Hardening Linux is a lot of information on the web is present. This major barrier is protecting the operating system (OS) level . The OS has no focus on business information, it does not help for that level to harden.

Needed are a few persons understanding all the requirements and capable to translate these to not only a technical running installation but also let it conforming all the other internal business guidelines.


Building up technical environment

Focus (bu): is on business needs to get secured.
Focus (ti): is on tools/middleware (business) needs to get secured. Additional requirements security related to the default left open set up of the SAS environment.

The technical installation at OS-level should be segregated in duties already.
As the OS level is used, there are some attention points.

Business Information

DTAP lifecycle

Business environment (data & code)

It should not have conflicts in guidelines. Get all requirements clear. The impact on solving these requirements can result having many keys. When an other goal is having not many keys there is a troublesome situation. The most simple approach is running everything by root-key not having any security. That approach is not acceptable in a real business environment.

See the architecture reference Business DTAP

The workspace server is running by default with your personal key. In secure environments requiring traceability & audibility this the normal accepted approach. A Stored process server (or pooled workspace server) is running by a generic defined key. In that situation the actions are more difficult or even impossible to pinpoint to the person.

The security administration guide gives a lot of background.

Business DTAP secured

Your business environment (data & code) needs to be secured within: >
segregation within DTAP, generic key
Business DTAP (Develop Test Acceptance Production) at the same time with a centralized key administration? mediated access usage.
Solution: use different key-s within DTAP.
Aside sassrv use as proposal sassrv_d sassrv_t sassrv_a sassrv_p
segregation within DTAP, fully segregated
Business DTAP at the same time with a centralized key administration and power users (bypassing mediated access)?
Solution: use different key-s within DTAP for each business application. And use different keys for storing business code (software) and business data. Aside sassrv_d,t,a,p use as proposal
This segregation of business code and business data makes the security implementation on the host and in the meta data easy to fulfill. First, find the responsibilities to implement. Remember to sperate at required levels, Business Unit Separation

like hell

Mediated access or not

Don´t trust the SAS meta data security it can easily be bypassed, Authorization Overview . These indicate clients are Eguide and the Office Addin. Mediated Host access is the chapter with the mentioned items. The meta data security is not meant to replace host security. Access management Cautions. About SAS Meta data server (biov) is just containing a lot of descriptions. The mentioned access-controls are controlling some of the available menu-s. They don not control host-access where business data and logic is stored. mediated access (standard)

The setting: Use of clients introduces no risk, it is missing adequate configured host access in relation to business data / code.
Having that understood, you know what is to be solved

Along with its advantages, mediation introduces some risk.
If your deployment includes sensitive data in SAS tables, it is essential to review existing host-layer controls and to understand the effects of mediated access.

In the metadata authorization layer, not all permissions are enforced for all items.
It is essential to understand which actions are controlled by each permission.

Some clients enable power users to create and run SAS programs that access data directly, bypassing metadata-layer controls.
It is essential to manage physical layer access in addition to metadata-layer controls. For example, use host operating system protections to limit access to any sensitive SAS data sets.

In the document: 420-2013 What SAS® Administrators Should Know About Security and SAS Enterprise Guide, page 10,11,12 ending:
The only thing worse than a lack of security is a false sense of security. There are a couple of areas in SAS Enterprise Guide that might look or feel like security, but should not be relied upon for security. It is important to be aware of their limitations.

METADATA DATA ACCESS PERMISSIONS As I noted in a previous paper (Smith 2012), setting data access permissions in SAS metadata can give you a false sense of data security. One of the most important things to understand related to data access and SAS Enterprise Guide is that SAS Enterprise Guide does not force users to work in a metadata-aware context.

In the document: 297-2012 Best Practices for Administering SAS® Enterprise Guide page 10,11,12 ending:
As long as users have the necessary host operating system permissions, they will be able to directly access and read a SAS table. So, what this boils down to is that any real data security must be put in place at the physical host operating system layer.

In the overview document this is already mentioned: Overview of SAS Intelligence Platform Security (biov)
The SAS Intelligence Platform´s security model cooperates with external systems such as the host environment, the Web realm, and third-party databases. To coordinate identity information, SAS keeps a copy of one or more IDs (such as host, Active Directory, LDAP, or Web account IDs) for each user.

These power users with the clients bypassing the metadata security, those are Enterprise Guide (Eguide) and the Office Addin Microsoft(AMO).

The clients that are promoted by SAS as the standard tools for annalists and the business user.

The approach to get them not installed is a contradiction to promoting to use these tools. The proposal not installing some Java clients is bypassing the fact these Java clients are easily be copied. Even other Java access or SAS is possible. Security by obscurity is a bad approach. The same is true in trying to eliminate WEB-access in the approach of trying disabling usage of browsers because web-sites (servers firewall´s) are badly secured.
The only thing to do is getting the host security well done. That with all other measures in the OS and networking.


Metadata bound (since 9.3)

With SAS 9.3 a new option to secure is with metadatabound libraries. In the header of SAS tables a relation to a metadaserver is made. With the SAS 9.3 enging a call back to SAS-metadata is forced. Authorization Model for Metadata-Bound Tables
mediated access (metabound)


Mediated access web only

Only in a web based access environment mediated access can be underpinned. This applies just to a part of the BI-environment with limited functionality.
On this subject detailed information is found. referring FIPS 140-2 and NIST. 358-2012 Security Hardening - Enterprise BI Web Applications


Store process - SAS/Intrnet application broker

The Stored process web interface with 9.3 has the same functions as SAS/Intrnet.
Run SAS Code at Server Session Boundaries (stpug). Is also indicating a failure with 913. At SAS913 the autoexec.sas is run at SP-server start and at user-session start. Only to be seen if some trace event (user-connect) happens.
Using the SAS Stored Process Web Application Pages (biasag). Are recognized as the Samples of SAS/intrnet.


Mediated access - SAS/Intrnet application broker

Application Broker and Web Server Security (brwebsec) is the classic WEB interface. All parameters and approaches have been duplicated in the Stored process options. The old options offers more technical options but is requiring a more dedicated understanding.
As a security precaution, you should protect your Application Broker configuration file. Your first priority should be to restrict file system access so that only specific individuals can update the configuration file. Protecting this file means that you can rely on the settings that you define in the file, such as DebugMask and Debug.

Compliance approach of data (progsec) You can protect access to your data by using password-protected data sets. This feature of SAS software lets you assign a password to a data set. You must then supply the password to access or to modify the data set. You can choose to code the password to the data set in your application or require the user to supply it. If you code the password into your application, ensure that the user cannot view that password by returning the SAS log to the Web browser or by reading your source code files.

Host authentication with the SAS/Intrnet application broker (auth=host) is also possible.

secure bypass

Assigning libraries

The native engine is not controlled by metadatasecurity.
Considerations for SAS Stored Process and SAS Pooled Workspace Servers (bidsag)

Within Eguide the autoexec project flow and with miner the startup code are settings adviced to users to define therei native code to be executed.
the-autoexec-process-flow (CH 2011)

Technical Installation

bi di SAS img
Installation / Configuration
The installation files shouldn´t be able to changed when updating the configuration?
use different key´s. Aside sasinst use as proposal sasconf

metadata service (running process)
The meta data process must be isolated well to a defined isolated environment?
use different key-s. Aside sasinst use as proposal sassys

metadata database
The meta data database and all other files, containing key - password combinations, must be isolated well?
use a dedicated group right Aside sas use as proposal sassys

Spawner processes
Spawner processes Object & Classic (other servers) can´t should not able to access sensitive data?
use different key-s. Aside sasinst use as proposal sasspw

These process do a fork to generate new processes and are switching to other keys with low level OS-calls changing just the user-identification part. For this functionality you must be able to explained this to auditors and security officers.

Sharing data - running business processes
Only one key, sassrv, is used with almost everything to be processed. When needed a clear segregation between sharing or storing sas-data and the processing (monitoring auditing)
use different key-s. Aside sassrv use as proposal sasshr

These processes are storing and retieving code and or data of the business. Care is needed is aspect to the technical ownership of files. Thes keys can become the technical owner of business information.
When using these processes a second security mechanism must be in place. This can be:
SAS links TI security
See also:

Due to Unix (linux) security limitations the approach of mentioning groups is done. With Mainframe Windows the security requirements are possible at dataset levels.

standard machine deployment

firewall midtag
Loggins - cleanups - BU Usage
So you have a standard implementation of your OS (stack). Is it acceptable to have this standard to be changed by an other installation like SAS?
Probably not as your support organization will not accept it. So how can you guarantee its functionality?

Machine anomalies
All these requirements are confronting you with anomalies of machine environments.
Don´t forget the bimtag firewall concepts and more firewall options. And the encryption in SAS.

Amazingly is the usage of root-key and similar behavior is still accepted. The root-kit is one type of the malware you don´t want to be experienced with. Just use in a documented way when no other options left. In the SAS installation some routines need to run at root-level.

You have security monitoring and auditing in place on the OS? Why would you by-pass and do something on your own? Sooner or later You´ll get into troubles with auditors.

Number of needed system keys
The number of needed System Keys differs to the level of requirements to security. A very high level of security will lead to more needed system keys.

The default installation out of the box requires six(6) system accounts (host:sasinst sassrv and host/internal: sasadm sasguest sastrust saswbadm).
Setting up a secure TI level is requiring three more accounts (host: sasshr sassys sasspw) having nine (9)
Segregation in aspect to business DTAP life cycle is splitting up sassrv and sasshr to an additional 6 keys having fifteen (15) keys.

The out of the box sasdemo should not be used. Instead a business like environment with goal of validation should be used. As business is using a segregation in eight(8) system keys, eight are needed.

With every business application added, needed a segregation at host security, an other eight(8) system keys are needed. These are owned at business level.

In the sample of hypothetical notepad Webthing , the Unix implication to system keys is worked out.

Restricted options - logging
With restricted options fucntionality may be defined restricted. The location of these files are however within the installation part not the configuration.
config guide Unix (93 ikfdtnunxcg)

kb35165 Using restricted options to create dynamic Application Response Measurement (ARM) log files in UNIX environments (913 proposal)
Using a combination of the restricted option facility and the ARM feature allows an administrator to create logs for each SAS session, including distributed environments with SAS® Enterprise Guide, SAS® Enterprise Miner, or SAS® Data Integration Studio clients. The ARM records generated by the SAS session include the date and time of the SAS session, userid, elapsed time, and processor utilization information. Additionally, through the use of the ARMSUBSYS option, the ARM log will contain the SAS procedures and data sets that were utilized within the SAS session.
Attention: As the user/key writing the logfile always will have access, it only makes sense to do this with a switched users like normally by a SP-server.

Ronan Martorell Restricted options are extremely useful for the SAS Admin, I agree. However,in 9.2 Linux there is an unreported bug if you happen to create an empty Restricted option file (a line of comment won't count): it makes all "restricted" sessions crashing at startup with an error message not human-readable. So be careful in 9.2. SAS Support has acknowledged the issue, fixed in 9.3, and we expect a SAS Note about it anytime soon.

design/build    Metadata    Applicative      System monitoring    Application monitoring    backup restore      Checklist      Anomalies    No sense    Free info    top  bottom

Meta Data security

Focus is on the special way of SAS metadata behavior.

One special is the way of working with ACT's Access Control Templates. Meaning a generic rule can be applied to a object.
This way is quite different to the Windows Unix or Mainframe known approaches. It is more SE-Linux approach.

meta secure 1

Meta Data security implementation

Generic level
The first thing is to get the meta data secured.
The approach of security described with DTAP to the host level can be implemented in a similar way
Access to application servers is controlling access to business data. Access to folders is controlling access to business logic.

In the document: 376-2011 denmark best practices. The steps are mentioned. You have to do step-one: ´Understanding the needs of your organization´

How logins are used
How Logins Are Used is an overview of the logins usage.
The general servers group is the one that must contain all Launch credentials (key/pswd).
Logins are used for inbound and outbound. Logins are required to be unique.
The last requirement can result in a contradiction, in practice outbound login are not unique. This will require a different solution to implement.

Other requirements are the used dedicated in the SAS setup are not allowed to be combined. (eg) kb 36244 Requirement: sastrust/sassrv may not be unrestricted admin.

General servers group
When running an Application server (Stored process) at the key of the business data. This key must be defined at the general servers group login fields.
As result when knowing the password of this key all access with that key can executed with.

Library definitions
Library definitions and related fields are registered in the SAS metadata connected to application servers.
This is requiring: Eguide is positioned as a tool for this type of maintenance and creating definitions. Opening up with a login defined at general servers is possible. kb 13883
Proc metalib;
Omr (library="library name" Metarepository="Foundation");
* Uncomment one line below;
* Update_rule=(delete); /* syncs entire directory */
* Select ("table name"); /* syncs one table */

Using logins defined at the level/group of general servers is possible. In this way there is no possible trace back to a person. The trace-back is only possible to a used IP-address as the origin of an action. This can be hopefully correlated to a person with used ip-address to person logging´s.

Menu options / Permissions by task - object type
Permissions by Object Type is a bisecag chapter. With indications of common needed adjustments. The same but different is, Permissions by task describes the related action need a level of access to components.
Relational data that is accessed through other methods is unaffected by the Read permission.
Do not rely exclusively on the metadata authorization layer to protect relational data. Use host-layer protections also. See Host Access to SAS Tables.
(mediated acces)

menu capabilities
The words capability and roles are used, in this context of, SAS metadata security, it is menu tailoring.
If the identity that the object spawner uses to retrieve server launch credentials from the metadata has the user administration role (or the unrestricted role), the spawner will not operate properly.
Do not give user administration capabilities to the identity that the object spawner uses to retrieve server launch credentials from the metadata. In a typical configuration, the spawner uses the SAS Trusted User to retrieve server launch credentials (through a raw metadata request).

Roles manage the visibility of application features such as menu items, plug-ins, and buttons. In the initial configuration, registered users have almost all nonadministrative capabilities.
Role Based Access to Application Features is no business data related security. CAUTION:
In general, roles do not protect data or metadata. Roles just control which features in a particular application are available to which users

Baseline ACT-s
Baseline ACT-s is a approach to simplify secure of open items To hide/protect data, eg Application Servers, not to be used by other users the hide/protect approach is needed.
To limit access to read enabling to go to the subfolders, a readonly approach is needed.

Business security Concept
The security at OS-level already is worked out. The same logic ot that security is to follow in the metadatasecurity. The same segregation in business logic and business data is t o be followed
The same segregation in duties is to be followed.
Even naming conventions are abel to be duplicated. Minor differences are possible optimizing administration efforts.

Restricted admins
The normal daily used key (personal key) should not be used for administrator actions.
The unrestricted admin should also not be used in daily work.
Dual accounts was documented in 92 bisecag and 93 bisecag . It is the segragation of duties accountability traceability that can be fullfilled.

SAS internal Authentication Internal accounts aren't intended for regular users (they are intended for only metadata administrators and some service identities).

Security administrators
As procedures to organize security administration are implemented are company wide, it would be ideal this part would be lined up in those administrations

A dedicated group meant for auditors is to set up. This group is given read access within metadata to almost everything. Excluded are the Application Servers as they grant access to business data at OS level.


Meta Data security logging

log server
As the meta data security is able to control the switching to Non Personal Accounts (keys) this part is concern to security monitoring and auditing.
log server Should be connected to your security monitoring.

Monitoring & logging (bisag) is new since 9.2 it is the key concept of monitoring. It is technically implemented by ARM 4.0. Arm has the origin by Tivoli (nowadays IBM).
Getting the Monitoring & logging attached to existing operating is changing XML-files.

The sasauth module is the central pint of SAS with security calls in Unix. With sasauth.conf Config 93 Unix the interface to OS can be configured. The most options are implemented for AIX. This is offering using OS logging and OS control
AIX_REPORT_RESULT log fails logins to the OS.
AIX_LOGIN_CHECK control logins by AIX s_loginchk field.     ibm v5r3 getuserattr

Security breaches
Buffer overflows and more of the common programming failures are also appplicable to SAS.

Even worse is the exposure to other vulnerabilities as of eg JAVA.

Metadataevents debugging
Debugging on events is possible. The XML meaning is an other to get the interpretations.
To assist in troubleshooting, SAS Technical Support might request that you capture generated XML entries in the metadata server log.
Not meant to have it on operational processing:
To avoid adverse effects on performance, you should remove the App.OMI logger from logconfig.xml and restart the server when you are finished capturing XML information.

meta secure 1

Meta Data security connecting to AD/LDAP

It is possible to connect to meta data users & groups to Ad or LDAP in a synchronization process.

The way of support is connecting to the metadata. Described as OMA Open Metadata Architecture, in Integration Technologies. itechov components of SAS Integration Technologies.

Directory Services is the LDAP interface. AD (Microsoft) RACF (mainframe) are also working as LDAP. itechdsref How Does SAS Implement Directory Services?
Connecting to AD/LDAP sample using LDAPS_OPEN LDAPS_CLOSE.

There is a lot of developers guide to ittech: ittech win developers guide   ittech Java developers guide

To develop something much more found: Stored Processes Developers guide This explains much about the SP. The chapter " using sessions " is the web-server connection. The chapter "Using Reserved Macro Variables" is giving some information about the connections of components.

Unix sasauth
Direct LDAP access
It is possible to define security call´s to use LDAP directly in stead of using Host authentication. It is a difficult way and not the primary advise.
By using Host authentication the process uses the host an everything that is already done.

It is possible to integrate authentication with Windows. Integrated Windows Authentication. The single-signon will be achieved.
The configuration guide and security administration guide are containing the most necessary information

design/build    Metadata    Applicative      System monitoring    Application monitoring    backup restore      Checklist      Anomalies    No sense    Free info    top  bottom

Applicaton level security

olap 1
Focus is on business aspects with the technical objects.


Workspace (WS) an Stored Process (SP) Servers

Security Difference WS SP Servers
The WS server process will normally run on the OS-level related to the personal login key. Under the condition of all security well implemented on OS-level no additional risk are involved.

The SP server process will normally run on the OS-level related to a more generic / system key. This server-process is started by the object spawner needing the key and password of that key.
The logic of the switching to this NPA is managed by metadatasecurity. The usage of servers in this pool is governed by the authorization rules that are set on the servers in the metadata. .. .. that connect to SAS by using a single set of credentials called the puddle login
It has the same functionality as using the well known "Unix Sudo". The same level of review of risks involved should be applied.

The Pooled WS server. (new since 92) Server_side Pooling has the same security disadvantage of using generic keys/passwords (non personal keys) like the stored process server. It has the advantage to be able better tuning in limiting priority and resources. As they are up en running start-up time is an advantage compared to a standard WS.


Olap usage

When the original data contains elements not to be given free in the query, additional measures must be taken. This situation is occurring in the OLAP approach where cubes are defined to contain all information and tuples are given to user-views.
With a traditional database approach this wouldn´t easily happen.

In MDX code the extra needed level of hiding is possible. Only in a DTAP process with mediated access this is leading to a secure environment.

Some sample and links: mdx dynamically hiding measures for compliance
kb 38756 security subset   olap ug - cube security

wiki rolap   wiki Comparison_of_OLAP_Servers wiki xmla
Data dictionary or metadata repository wiki Metadata


Load balancing - High availability

Understanding the Client-side Pooling It is not the client/desktop but the midtier server running the web-clients that is planned with pooling. It is Better to bed described as higher availability and load balancing.


Business application, coded security

With all options on Host security and metadata security it is still possible not enough granularity is achieved. In that case the security is possible to code by handcraft.
kb 26094 determine group memberships.


Functional Difference WS SP Servers

There are kb 31155 functional differences between SP-servers and WS servers.

design/build    Metadata    Applicative      System monitoring    Application monitoring    backup restore      Checklist      Anomalies    No sense    Free info    top  bottom

System monitoring

Should be implemented in some way.

design/build    Metadata    Applicative      System monitoring    Application monitoring    backup restore      Checklist      Anomalies    No sense    Free info    top  bottom

Application monitoring

Should be implemented in some way.

design/build    Metadata    Applicative      System monitoring    Application monitoring    backup restore      Checklist      Anomalies    No sense    Free info    top  bottom

Application backup restore

Should be impelmented in some way.


Backup Functional Difference WS SP Servers

The standaard metdatabackup does not fullfil the normal backup and restore requirements of user objects
The batch exoprt can help to solve this. Admins – Need to Restore One Metadata Object from a Backup? (TA 2013 )

design/build    Metadata    Applicative      System monitoring    Application monitoring    backup restore      Checklist      Anomalies    No sense    Free info    top  bottom

SAS information

Almost nothing related to good practices is Found at the official SAS site.
This subject is getting some attention as of 2013 in proceedings.

In the document: 481-2013 Hardening a SAS® Installation on a multi tier installation on Linux
At least the reference to Fips 140-2 and the Conlusion>
The securing of SAS system is not a simple project. To achieve a working configuration of SAS 9.3 in such an environment requires a basic understanding of several technologies: First the knowledge on how to handle and create SSL certificates. Second the configuration possibilities of the underlying 3rd party software components like the web application server, web server or the data base clients on the SAS compute nodes. Also the vulnerability testing of system is part of the implementation of secured SAS Installation. This effort allows the use of SAS in use cases with enhanced data protection regulation.
However: OWASPp,same as ISTQB technical testing Adv, is nicely mentioned but was not being practiced at SAS environment.

design/build    Metadata    Applicative      System monitoring    Application monitoring    backup restore      Checklist      Anomalies    No sense    Free info    top  bottom


Auditors do like to work (audit) with a checklist of attention points.
I will give one for a SAS installation as complete environment.


SAS basics

question Risk measure
1.1 business Data Is this business data environment secured? Aside SAS also access with other tools is possible (terminal emulation). Host security setting should have already been done
check consistency
1.2 business Logic Is this business logic environment secured? Aside SAS also access with other tools is possible (terminal emulation). Host security setting should have already been done
check consistency
1.3 Home Is the personal setting area (sasuser) secured? personal data possible user and passwords open to other users Host security setting should have already been done
check consistency
1.4 Work Is this temporary data environment secured? Intermediate business results open to other users Host security setting on saswork
check files security in the shared location os Unix security - fileatt
1.5 executable´s Is this installation environment secured? Installation can be changed bypassing change processes.
Blocking operations can be unpredictable
Host security setting on SAS executable´s
Use dedicated installation key when applicable
1.6 configuration
meta data level excluded
Is the configuration controlled/secured? Configuration options are changed uncontrolled.
Blocking operations can be unpredictable
Host security setting on SAS configuration
Use dedicated configuration key when applicable
1.7 configuration keys/passwords Are keys passwords in configuration files just controlled accessible for the related (trusted) administrator? Keys passwords with possible opening access leaked to not trusted persons. Abuse of these keys can open up uncontrolled business access or changing configuration. Host security setting on SAS configuration
Setting of additional rules to specific files where applicable.
see note about pwencode
1.8 auditing keys/passwords As SAS is using Host authentication, is the auditing of usage of keys aligned? monitoring of usage who when what is not possible violating requirements. Unix is having a problem by usage of the "sasauth" module used in the forking process
see note about sasauth


Meta data
SAS related

question Risk measure
2.1 Configuration
meta data level
Is the configuration controlled/secured with a security concept? By default access within SAS meta data is not controlled.
Possible opening of business data or business logic access
possible change the configuration stored as meta data objects
Meta data security setting with detailed planning
Can follow normal security agreements at host-level
Segregation of central SAS administrator other administrators, business LCM, business usage conforming normal security guidelines
2.2 ACT
Access Control Templates
Should be used to get a manageable and understandable implementation. Is this correctly done? An impossible to understand functionality at meta data security level? Should be Part of the security concept meta data
see note about SP-keys connected to group general servers
2.3 Roll based access
is this option correctly implemented? Is it goal of fine tuning menu-options in clients abused as security? Roll based access of meta data, is no security but menu tailoring. functions can still be used by adding code. Should be Part of the security concept
see note about Roll based access meta data
2.4 meta data users Is the update of security in meta data by the user on his own key impossible? User is able to change his own security, opening up unwanted access Should be Part of the security concept
see note about user settings meta data
2.5 meta data access management Is the SAS meta data access ( keys login password) conforming the standard rules? As having his own security implementation, it can bypass normal guidelines opening up data and configuration Should be Part of the security concept meta data
see note about user settings meta data
2.6 meta data Admin´s Are dedicated keys for administrators functions used? As admin´s having special privileges it can cause failures having these access continuously open. The unrestricted admin can be segregated to a dedicated key/pswd
restricted admin keys must be set up to segregated functions.
The client SMC is not offering any protection see OMA notes.
2.7 meta data users
synchronized to host security
Is the synchronization of users/groups in SAS meta data synchronized on regular times? Not synchronizing can leave open access to users to unwanted data Should be Part of the security concept meta data
see note about synchronizing user groups
2.8 meta data auditing is log-server as monitoring connected to standard monitoring? Security incidents can happen not monitored or evidence is destroyed. Monitoring, Security monitoring for sure, should be done by other persons than normal SAS administrators. Or usage logging's.


SAS related

question Risk measure
3.1 root key(s) Is the access to highly privileged keys with uncontrolled open access closed? Configuration options are changed uncontrolled use of "sudo" or similar approach and restricted validated scripts on dedicated locations.
Conforming hardening an OS.
3.2 service accounts Are the passwords of these accounts (coded in files SAS configuration) kept outside password change policies? requiring change passwords will block the operations Policy setting of these keys.
Conforming hardening an OS.
3.3 Network traffic Is the data traffic sufficient encrypted? business data /logic can be hacked and hand over to unwanted destinations for further abuse encryption of traffic.
VPN/internal: probably SAS-proprietary is sufficient
Public: High level up to date encryption as delivered with SAS/Secure (global) and SSL with certificates (SAS/Connect).
3.4 Release - Fix Levels Are Release and fix levels of all related components sufficient up to date? Interactions of outdated components can cause unpredictable effects.
Blocking operations can be unpredictable
Release and Fix levels must be brought up level. Release/fix must be supported by the suppliers
3.5 Disaster Recovery
backup & restore
When using this procedure it is not opening up everything normally closed? Having all measures met possible an other process like DR or Bacup/Restore can break everything. Disaster Recovery process to be verified not having this issue.
Backup/restore data (business or meta data) not having this issue
3.6 External connections Access to other data / databases is controlled audited and auditable? Having all measures met possible an other process external connections can break everything. Check: hard coded keys passwords in code business logic (eliminate)
Check: access with no authentication (eliminate)
Check: hidden communication connections (web virtualization) and shared information to external support.

References to audit approaches:

design/build    Metadata    Applicative      System monitoring    Application monitoring    backup restore      Checklist      Anomalies    No sense    Free info    top  bottom

anomalies of machine environments

Way problems

sas logo

SAS Enterprise Intelligence to OS layers

weakest link
Protecting your metadata protections
Something that can be easily forgotten though, is the need to secure those ACTs so that they can only be modified by administrators. protecting-your-metadata-protections (PH jan 2013)

weakest link
No Use of sassrv - shared
494-2013 IT in the sky: Building a private SAS® cloud One key example is the SAS General Servers account - or SASSRV as it is commonly called. This is a technical account which users inherit access to via SAS Metadata. It is imperative in a cloud environment that this account is not shared amongst all tenants. A more effective solution is to provide a dedicated SASSRV account for each tenant. That way, we can secure operating system directories and data even for the “on demand” SAS server processes that use these shared accounts.

weakest link
Reset Unrestricted Admin
The unrestructed admin should not be used for daily work.
When an internal accoutn get blocked some actioan are needed th ope it. The unrestricted could be got from a digital safe. It this one gets blocked it must be changed from the bootstrap proces. Unlock an Internal Account (9.3) Reference Information for omaconfig.xml (9.3)

Getting to password policies and updating service accounts:
Password Updates for Service Accounts (9.2) SAS 9.3 has also to option of internal SAS defined accounts, documentation 9.3 is less complete. Update a Managed Password (9.3)

snake pit
Open meta security access for users is required
If some update by a user related on his own key is possible or required, the default access of users must be set all open.
Al lot of work (if possible) to get it closed again.

Settings of some tools (DI, Miner) are requiring updates of the user his own record.
This looks a bad security design
913 eip: With usage of DI the meta data security to the user must left open. (just 913?)
Yes the user is able to change his own security in a way he likes. Secure?, in no way. Lucky enough it can be isolated to developers. Don´t use DI in production.

All access is possible using MS power shell scripting
Getting to metadata does not need SMC,
Getting to SAS data does not need SAS tools,
More ways are open.:

SAS data step accessing the metadata
More ways are open.:

sas logo

SAS Enterprise Intelligence (Metadata)

weakest link
Host registration - metadata registration
Proposing the host-layers is leading security there is no way to get it synchronized in a easy way. See the remarks on synchronization.

weakest link
SASusers requiring wm access
having this weird behavior experienced by DI for a user setting Di for the first time, more notes found.
A linkedin question (Tony Walton) with the system folder involved in this. The signal is that unrestriced admin works well but normal user not.

weakest link
Storing personal key-pswd data
Settings of desktop clients are stored at the desktop client side. All other personal settings are stored in the SAS meta data. this means:

The .Net clients (Eguide AMO) store users/keys at ..Application Data\SAS\SAS Directory Services\SDSConfigV4.xml
There is a long number presenting the password. No choice to set caching off.
The hack is to copy this file to you own personal location. Including all information no need to know the original password. It works with all connections.

The Java clients (SMC DI etc) store users/keys at ..\.swa
There is an option to not cache passwords. When cached, the same hack works.
Keep this persoal settings/files to safe not shared locations.

weakest link
Use of privileged keys
Use of generic keys per application (host layer security) requires logins to be defined as part of -general servers-
No other dedicated usage of these keys (Eguide) is possible. Looks A secure compliant method.
The logins are defined of as part of -general servers-. All rights of that group is inherited within the meta data.
And if password known you login and use it (no monitoring of personal attributes).

The password can not be blocked as it used as a service with automatic start requiring key and password

Meta data - External connections

Working with external connections, SAS is doing some strange things. A list:

weakest link
A login (keys) may only once defined
A key (login) may only exist once. No way to get it organized when the same keys is used more than once in different outbound connections

Knowing the way of caching password of keys this property is a logic result.
Having a wish to a secure environment it looks as a design mistake using this field everywhere.
weakest link
External connect requiring different keys situation depended not possible
Suppose you have the requirement of: external database personal key just read-only access, stored process (approved program) by a generic key - update access.
No way found other than solving is in a autoexec.sas solution. Recognizing the situations and switching key-pswd in pre-assigned approach.

Meta data - XML

weakest link
Metadata interfaces
The SAS meta data is sometimes indicated as Open Meta Architecture (OMA) . The interface to the meta data is build in Java JRE JAR OMA interfaces are available. With appdev you can build you own Java applications accessing SAS and SAS meta data. SAS integration Technologies still exist and contains a lot of the connections to OMA Integration tech The oma model reference contains data types and hierarchies of the meta data database.
weakest link
XML to metadata
Interfaces from SAS-language exist see: lrmeta . With this the meta data base and meta data server can by handled. No dedicated client interface needed.

All interfacing en results to SAS (meta data server) are handled with XML requests. These can be build at home.
I wonder if the xhtml-request of the WEB interfacing will also do the job. In that case an AJAX approach can open up the environment. As SAS is running as WEB-interface this functionality is likely to be present.

linux logo

Unix (Server)

Many Unix versions exist, they all share the same fundamentals of file directory authorization. users and groups. See: os Unix security

weakest link
With Host-authentication (SAS). All keys are required to have the attribute login=true.
15/467 16/230 This is also for all the generic key-s not belonging to a person. Is this allowed by your sites policies?
Normal users are expected to able to login (terminal-based) because of file transfers and log-file contents.
weakest link
The user limits should be personal
When using a SAS spawner the forked process get the setting of this used key. An other argument to use a dedicated key for the spawner.
So you can set up limits that are the same for all users. (spawned processes).

Windows logo

Windows (Server)

The security of Windows is advanced. See: os Windows security

weakest link
Services running (services.msc) must be managed and created with knowledge.
weakest link
itechwcdg describes com dcom security with windows SAS processes

Mainframe img

Mainframe (Server)

The security of Mainframe is different. See: os Mainframe security

weakest link
An open MVS segment must be created for all users using the spawner.
There is no way to validate the setting.
weakest link
Classic SMF record (Foundation) can be created and analyzed.

design/build    Metadata    Applicative      System monitoring    Application monitoring    backup restore      Checklist      Anomalies    No sense    Free info    top  bottom

No sense Limitations, failing conform standards

Way problems

Nonsense limitations

old time

NO Xcmd

Xcmd open at Windows
but for one decision that SAS R&D made back before the turn of the century (yes, 1999): by default, SAS workspace servers are configured with NOXCMD in place. The case for XCMD privileges in SAS Enterprise Guide (aug 2012 CH)

Xcmd needed at Unix
414-2013 Stealing the Admin's Thunder: SAS® Macros to Interact with the UNIX OS from within SAS® Enterprise Guide® For SAS® users who are unfamiliar with the UNIX environment, simple tasks like copying, renaming, or changing the permission settings on a file can be very non-intuitive. Many of these tasks are not even possible through the SAS® Enterprise Guide® Server List Window. .... Please note that for these macros to work, the X command must be allowed on the SAS server.

Xcmd needed at Windows
Query settings out of the registry. Example: Internationalization(dateformat), TypeGuessRows keys (proc import) Query the Windows registry within your SAS program (may 2012 CH)
like hell

password change very difficult

913 eip: sasinst, sassrv, ... password are nearly impossible to change. There is no good documentation in which files or where in the meta data this has been hard coded.
So when a combination has been leaked than what to do? Or even when someone is changing a password and there is no way to get it back?
Start over with the configuration and implement everything from scratch.... >

The java container services at the webpart are calling back to SAS with a key/pswd. Logical requirement that combination must be working.
WARN 2013-03-05 17:40:41,451 - Have received 60 failures while trying to access an auto-discoverable service to satisfy request for 'com.sas.svcs.config.client.ConfigurationServiceInterface'. Please ensure that the application and/or process surfacing this interface is still in the process of starting.
com.sas.svcs.cluster.balance.ZeroResultsException: Info object, '/sas/auto/services/com.sas.svcs.config.client.ConfigurationServiceInterface', provided no results to choose from. Is a required process available?

kb/44/312 These messages are normal messages that appear when some of the Web applications try to access the SAS Web Infrastructure Platform before it is initialized.

old time
Location metadata base logins
The audit trail option is use full to investigate the location of updates.
Activating the audit trail: Changes - cntainer.sas7bdat

Deletion changing a key: Changes - login.sas7bdat mdassoc.sas7bdat person.sas7bdat
Changing the sas-table: login It contain keys (multiple) and passwords. This must be the cached location.
The password found is not in clear text. SAS must be able to present it as clear text. Next question is how to decrypt it.

One conclusion is clear: Define the access to this tables in a very controlled way. It is the same requirement like the Unix password hash-tables.

Failing conform standards

security monitoring
Must be implemented with SAS. Will decrease the risk of possible leaking secret information.

Normal are usage of: sudo , boks (Unix alikes) - UAC runas (Windows AD) - surrogate (racf mainframe) to do a controlled way(logged and autorised) in switching the user-context.
This approach is failing. The only option is to do something with the LOG-server and connect this to the already present procedures.

Common products are like netiq and tripwire , with and operational process.
This approach is failing. The only option is to do something with the LOG-server and connect this to the already present procedures.

operational monitoring
Must be implemented with SAS. Will decrease the risk of getting out of service.

Common products are like Tivoli (ibm) (many more options) based on Arm. These are already presetn somewhere.
This approach is failing. The only option is to do something with the LOG-server and connect this to the already present procedures.

Disaster recovery - backup
Must be implemented. Will decrease the risk impact of uncontrolled events.

With a Disaster_recovery procedure in place it should be a SAS implementation following this.

No security awareness

like hell
sassrv like root
Usage of generic sassrv as user is described by hardening actions.
When an open sassrv key is used, do your own libnames (Eguide / Office Addin) it will open all up. It is like using the root key.

pwencode offer no protection
sas001 ...=
sas002 ...=
Find this code and copy/paste this to you session, it will work as intended in this way.

search in the configuration-files fore. sas001 ...= sas002 ...=
You probably will able to login to the machine in terminal-mode or with file-transfer.
When not present also a SAS session with SAS code can do the job.

With a How to use encryption in Base SAS 9.4 (nov 2013 Wendy McHenry) Note the repsonse in the questions. Using the definiton in a own autoexec.sas

Interfaces bypasses

like hell
Excel getting data
Usage of any data type can tried to get limited. This will be ever lastsing battle as still new options will appear to capture it.

Blocking the office addin in but still having Excel? It is still easy to get data into Excel.
SAS Stored Processes: Querying a Stored Process from Excel without the Add-In (TA feb 2013)
Excel will do this with any kind of data presented by a webpage not jsut SAS. br>

design/build    Metadata    Applicative      System monitoring    Application monitoring    backup restore      Checklist      Anomalies    No sense    Free info    top  bottom

Free to find information

Way problems

How to find information with goal of abuse

like hell
Bypassing with OS layers.
There are many ways to circumvent security. See security OS and you con imagine some approaches. The most simplified is running by root or a global key.

Location sastrust sasadm keys-pswd
the location of sastrust and sasadm with key/pswd are documented
objectspawner <SASConfg>/<Level>/SASMain/ObjectSpawner\OMRConfig.xml typical sastrust
!SASROOT/SASAPCore/conf/server.config (913) omr_user, typical sasadm (unrestricted admin) , omr_password= ... Yes, it is updating the metadata. Filling all kind of information of the solution/tool

Jboss admin key
Under UNIX, the following exception occurs when you attempt stop JBoss Enterprise Application Platform (EAP) 4.2.0 or later:
Exception in thread "main" java.lang.SecurityException: Failed to authenticate
principal=null, securityDomain=jmx-console
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
This exception occurs because JBoss EAP enables security by default. Therefore, a user name and password are required in order to stop JBoss. For additional details about this JBoss issue, see JBoss Enterprise SOA Platform SOA-980.
To work around the problem, add the -u user-name -p password options to the shutdown.sh section of the SASServer1.sh script.
Note: The user name and password are defined in the jmx-console-users.properties file that resides in the JBoss-home-directory/server/SASServer1/conf/props/ directory. The following example includes the -u user-name -p password options, with both the user name and password defined to be admin: kb46371

old time
propiertary encryption
By the way if you want to decode a {sas001} encoded password just remove the prefix and feed it into this page: Base64Decode

The propiertary encryption of SAS is MD5 (see 93 bisecag).
MD5 can be decrypted examples: md5encryption.com   hash-cracker
Not the whole truth I have seen different methods used.

Better internal hashing (bimig) md5 to SHA256 (Fips 140-2) requires SAS/Secure.


Object spawner login

Fields for the Spawner Definition. Operator Login (/itech/doc9/admin_oma) Operator Login (biasag) In SAS Management Console:
Initialization: Operator
Login .. Operator Login
Required The login that contains the password the spawner uses when starting a server as an operator connection. Click New to define a new login. If you do not specify a login, the operator password defaults to sasobjspawn.

Open in 9.1.3 optional as accessed by telnet with 9.3.

security holes

There are also security holes as with many other software.

Data transport / Screen encryption
password/key combination may be encrypted. The data (screens) and all transport isn´t.
SSH tunneling can be defined for the classic spawner/connect and sas/share. All the newer clients of eip/baf are needing sas/secure.

old time
Bypassing by Hard coded key passwords
Getting the advice to use hard coded keys-passwords like: note 14545 avoiding user authentication window

Documented sources - interfaces

like drama
security source
The sasauth sasperm are documented as they where to modify by business. note 8073. Knowing the calls thy could be used by own build programs. Possible finding a way to get root-access. The real-uid effective uid are the unix security concepts.
See: os Unix security - setuid setgid
Do not exaggerate this. The common SSH-shell is build with the same principles using this. The trick is to not mention SSH-software as applications. In that way there are no application risks. Still the risk of hacked, but can set out of scope.

In the companion of Unix the information can be found again.
The !SASROOT/utilities/src/auth/docs.pdf file describes how to implement custom authentication implementations.
Utilities in the /utilities/bin Directory   The UNIX Authentication API


permtest - log /tmp

Test of authentication/pswd note 33751: proc permtest (913) &mbsp note 39891: proc permtest (92 93) testing with nodms. Also available in SAS 913 note 33751. The difference is the sasauth.conf file activating logging. The default location of these logfiles is /tmp

Watch the linemode usage an the path overwrite. The call to sas con be different without current path (. usage) like:
sas -path /appl/sas/eip91/SAS_9.1/utilities/src/auth -nodms

old times archive
Telnet usage
Telnet was the original start of using SAS/Connect sessions. A lot of this history stil can be found in modern approach:


Client Altneratives

old times archive
Powershell .Net

Third party access

handy tools
Excel password handy
Excel spreadsheet can be saved with a password. When accessing like a table, this option is not available. How can it be solved?

weakest link
Hard code passwords in sources (readable)
Keys passwords hard coded in sources is a no good solution. It is still practiced often as no other way is known by the developer.

Eliminating hard coded user/pswd from SAS sources may vary by approach: The solution of password keys in encrypted password protected SAS-file is easy to implement (my samples)

Open Data access

weakest link
Open Databases
If the SAS environment is secured well and the database is left open, all is still open.

weakest link
well known keys/passwords
If default keys and passwords are left open and unchanged this will be possible an easy uncontrolled access to sensitive business information.

weakest link
Open Datatransport
big brother Database data is following the database clients. Their traffic has normally no encryption or using well known transmission codings.

The best thing for network traffic is having no network traffic at all. The alternative next best approach is having it encrypted as a whole.


OS violations

weakest link
Windows UAC
big brother These are the worst kind of problems as they are a signal of not being aligned with other requirements.


For more information about the User Access Control, see these links::

design/build    Metadata    Applicative      System monitoring    Application monitoring    backup restore      Checklist      Anomalies    No sense    Free info    top  bottom
home-SAS    SAS-SAAS    First steps    Installation    Hardening    Operational    Using    My Notes

© 2012 J.A.Karman (21 apr 2012)