If you’re responsible for managing SAS® platform security, and you haven’t seen them yet, then I’d definitely recommend reading Five papers on Recommended SAS 9.4 Security Model Design (part 1 & part 2) as published by David Stern, Principal Technical Architect from the SAS Global Enablement and Learning (GEL) team.
These papers are an excellent resource for SAS customers and partners to use when designing security for their SAS platform implementations. Having resources like these gives new administrators the opportunity to get it right early on and not have to learn from their own mistakes. I remember the early days of SAS 9.1 when the platform was new and best practices had yet to be discovered. At that time we were learning what practices worked and what didn’t through trial and error. Now, of course, we have the benefit of SAS documentation and published papers to learn from the prior experience of others. The first of these was the Danish Golden Rules as found in the SAS Global Forum 2011 Paper 376-2011 Best Practice Implementation of SAS Metadata Security at Customer Sites in Denmark by Cecily Hoffritz & Johannes Jørgensen. There’s also Angie Hedberg’s SAS Global Forum 2017 paper: Getting Started with Designing and Implementing a SAS 9.4 Metadata and File System Security Design. With the addition of the new GEL recommended practices, the pool of SAS security best practice information has been expanded further with a content rich guide that provides lots of detail, examples, explanations of the rules, and much more. It was also lovely to see Metacoda software get a mention in the GEL papers too. :)
I was fortunate to be able to meet with David at SAS when I was in the UK last week and we spoke about the GEL recommended practices and how the Metacoda Security Testing Framework could be used to help SAS customers and partners follow these practices.
It seemed like to a good time to provide a follow up to an older 2015 blog post I wrote on Testing Recommended Practices with SAS Metadata Security. That post was focused on the Danish Golden Rules, so in this post I’ll show our Metacoda Security Testing Framework can be used to help people follow the GEL rules.
Below you will find, for each of the GEL numbered rules, a description of which of our Metacoda security tests can be used to help enforce those rules. Using the Metacoda Test Runner plug-in you can run them manually. Alternatively, to help ensure continuous adherence, you can use the Metacoda Plug-ins batch interface to schedule the recommended practices tests (and other implementation tests) to run regularly and get an email alert whenever a deviation from recommended practices is detected. This is particularly useful in environments with multiple administrators of varying experience levels in multiple locations.
Metacoda customers will find many of these examples in the metacoda-recommended-practices.xml file available in the Metacoda Plug-ins Batch Interface package available for download from support.metacoda.com.
GEL Rule #1 (4.1): Only use ACTs, never ACEs
Rule #1 can be enforced with the Metacoda Security Testing Framework <AllowNoACEs> test (optionally adding any necessary exclusions)
<AllowNoACEs>
<Ignore>
<!-- You can ignore all ACEs on objects under specific metadata tree paths. -->
<TreePath path="/Portal Application Tree/" prefix="true"/>
<TreePath path="/System/Applications/" prefix="true"/>
<TreePath path="/System/Services" prefix="false"/>
<TreePath path="/Products/" prefix="true"/>
<TreePath path="/User Folders/" prefix="true"/>
<TreePath path="/Users/" prefix="true"/>
<!-- You can ignore a user and allow any ACE that specifies permissions for that user. -->
<User name="sastrust"/>
<!-- You can ignore a group and allow any ACE that specifies permissions for that group. -->
<Group name="PUBLIC"/>
<Group name="SASUSERS"/>
<Group name="SAS System Services"/>
</Ignore>
</AllowNoACEs>The AllowNoACEs test will generate test failures if it finds any ACEs that are not specifically configured to be ignored. We have to ignore certain locations such as portal permission trees and private user folders because those locations are automatically and necessarily secured using ACEs for the appropriate users and groups.
GEL Rule #2 (4.2): Only add groups to ACTs
Rule #2 can be enforced with the Metacoda Security Testing Framework <AllowOnlyGroupsInACTs> test (optionally adding any necessary exclusions)
<AllowOnlyGroupsInACTs>
<Ignore>
<!-- You can ignore an ACT and allow that ACT to contain (any) users. -->
<ACT name="Portal ACT"/>
<!-- You can ignore a user and allow that user to appear in any ACT. -->
<User name="sastrust"/>
</Ignore>
</AllowOnlyGroupsInACTs>The AllowOnlyGroupsInACTs test will generate test failures if it finds any ACTs that have users present in their permission patterns (definitions). If necessary we can ignore certain ACTs, such as the Portal ACT which is pre-defined using the SAS Trusted User.
GEL Rule #3 (4.3): ACTs only grant access to explicit groups, never deny
Rule #3 can be enforced with the Metacoda Security Testing Framework <AllowOnlyImplicitGroupDenials> test
<AllowOnlyImplicitGroupDenials>
<Ignore>
<!-- You can ignore all ACEs on objects under specific metadata tree paths. -->
<TreePath path="/System/Applications/SAS Web Report Studio" prefix="false"/>
</Ignore>
</AllowOnlyImplicitGroupDenials>The AllowOnlyImplicitGroupDenials test will generate test failures if it finds any instances of permission denials for any groups other than PUBLIC or SASUSERS.
GEL Rule #4 (4.4): Where necessary, apply ACTs to deny access to PUBLIC/SASUSERS, in combination with ACTs to grant a reduced set of permissions to explicit groups
There are several Metacoda Security Testing Framework test that can help with Rule #4:
The ACT test can be used to enforce the definition (permission pattern) of ACTs (and not shown here optionally test their usage and protection)
<ACTs complete="false">
<ACT repository="Foundation" name="SAS Administrator Settings">
<PermissionPattern complete="true">
<Group required="true" repository="Foundation" name="SASAdministrators" permissions="+RM,+WM,+CM,+A"/>
<Group required="true" repository="Foundation" name="SAS System Services" permissions="+RM"/>
</PermissionPattern>
</ACT>
<ACT repository="Foundation" name="PUBLIC and SASUSERS Denied ACT">
<PermissionPattern complete="true">
<Group required="true" name="PUBLIC" permissions="-RM,-WM,-WMM,-MMM,-MCM,-CM,-R,-W,-C,-D,-I,-S,-U,-CT,-DT,-AT,-A,-X" />
<Group required="true" name="SASUSERS" permissions="-RM,-WM,-WMM,-MMM,-MCM,-CM,-R,-W,-C,-D,-I,-S,-U,-CT,-DT,-AT,-A,-X" />
</PermissionPattern>
</ACT>
<ACT repository="Foundation" name="HR Department Read ACT">
<PermissionPattern complete="true">
<Group required="true" name="HR" permissions="+RM,+R,+S" />
</PermissionPattern>
</ACT>
</ACTs>The Object test can be used to enforce the use of a combination of ACTs (and only ACTs) on an object:
<Objects>
<Object required="true" publicType="Folder" parentFolder="/Departments" name="HR">
<AccessControls complete="true">
<ACT required="true" name="PUBLIC and SASUSERS Denied ACT"/>
<ACT required="true" name="SAS Administrator Settings"/>
<ACT required="true" name="HR Department Read ACT"/>
</AccessControls>
<Object>
<Objects>The EffectivePermissions test can be used to verify you get expected results, by testing effective permissions for PUBLIC, SASUSERS and other candidate users/groups on candidate objects.
<Objects>
<Object required="true" publicType="Folder" parentFolder="/" name="SharedData">
<EffectivePermissions>
<User name="sasadm" default="granted" permissions=""/>
<User name="sasdemo" default="denied" permissions="+RM,+R"/>
<Group name="SASUSERS" default="denied" permissions="+RM,+R"/>
<Group name="PUBLIC" default="denied" permissions=""/>
</EffectivePermissions>
<Object>
<Objects>GEL Rule #5 (4.5): Always Apply the SAS Administrators ACT when PUBLIC and SASUSERS are denied access
For Rule #5 the Metacoda Security Testing Framework Object test, as previously shown, can be used to enforce the application of both ACTs on an object:
<Objects>
<Object required="true" publicType="Folder" parentFolder="/Departments" name="SASAdmin">
<AccessControls complete="true">
<ACT required="true" name="PUBLIC and SASUSERS Denied ACT"/>
<ACT required="true" name="SAS Administrator Settings"/>
</AccessControls>
<Object>
<Objects>GEL Rule #6 (4.6): Design your security model first and implement it early
We don’t have any specific rules for this, but we know the Metacoda Security Testing Framework will help you verify it when you implement it early AND continue that verification on an automated ongoing basis to get alert emails when future changes are made that break the rules.
GEL Rule #7 (4.7): Apply ACTs to folders where possible
We don’t have a special Metacoda Security Testing Framework test that fails when an ACT has been applied to non-folder objects, but the ACT and Object tests can be used to check that ACTs have been applied to specific named objects of specific types in specific locations.
GEL Rule #8 (4.8): Name security model objects clearly and simply
We can’t help you choose the names, but once you have decided on them, you can use the Metacoda Security Testing Framework ACTs test to create a list of the named ACTs you expect to find and, if someone later changes the names, deletes any, or adds any other ones, you’ll get a test failure alert email to let you know.
<ACTs complete="true">
<ACT name="SAS Administrator Settings" />
<ACT name="PUBLIC and SASUSERS Denied ACT"/>
<ACT name="HR Department Read ACT"/>
</ACTs>Extras
In addition to tests that support the GEL rules above, we also have a few other recommended practice tests that you can use:
- <AllowNoUnprotectedACT/> : Make sure all of your carefully constructed ACTs have basic minimum protections so SASUSERS can’t change them.
- <AllowNoGroupMembershipLoops/> : Make sure you don’t have any circular references/infinite loops in group memberships that have the potential to cause performance problems.
- <AllowNoRoleContributionLoops/> : Make sure you don’t have any circular references/infinite loops in role contributions.
- <AllowNoGroupsWithImplicitMembers/> : Make sure that none of your groups have SASUSERS or PUBLIC as members.
All of the tests above can be used with SAS versions 9.2, 9.3 and 9.4.
If you’d like to find out more about the Metacoda Security Testing Framework and perhaps try it out in your own environment, then leave a comment below, send me a message, or contact us at Metacoda.