Testing Recommended Practices with SAS Metadata Security

If you use our Metacoda Security Testing Framework to continuously and automatically validate your SAS® platform metadata security implementations, then you’ll be interested in some new ‘recommended practice’ tests that are coming in the next release of Metacoda Plug-ins (version 5.0).

Are you are a fan of the Danish Golden Rules for SAS metadata security? Several of our new recommended practice tests can also help you enforce those rules for your SAS platform installations. The six golden rules can be found in SAS Global Forum 2011 paper 376-2011 “Best Practice Implementation of SAS® Metadata Security at Customer Sites in Denmark” by Cecily Hoffritz and Johannes Jørgensen from SAS Institute Denmark. It’s excellent paper that I often recommend to other SAS platform administrators. By following the golden rules presented in that paper you’ll find SAS metadata security much easier to understand and manage.

You might also notice that some of these recommended practice tests look like test-based alternatives to the recommend practice indicators currently available in Metacoda Security Plug-ins. These new recommended practice tests are a little bit smarter and also allow for exclusions – where you know a recommended practice is not being followed but have a good reason for doing so. While the indicators require someone to regularly look for them, the recommended practice tests can be scheduled to email an alert to someone whenever deviations from the practices are detected.

Here are some details and examples of the new recommended practices tests that will be available in Metacoda Security Plug-ins 5.0. I also point out which tests will help with enforcing the Danish Golden Rules.

AllowOnlyGroupsInACTs

The AllowOnlyGroupsInACTs test is used to enforce the use of groups in ACTs (Access Control Templates) and avoid users. This test will help you to follow Danish Golden Rule #2 “Add Only Groups In ACTs”. The test will generate test failure alerts whenever it finds users in the definition (permission pattern) of an ACT. Sometimes you may need to allow some deviations from this rule and so the Ignore tag allows you to exclude particular ACTs or users. This is useful with SAS Enterprise BI deployments where the standard Portal ACT has the SAS Trusted User in its permission pattern by default. The following example shows two ways to allow this as an exception in the test specification XML:

<SecTest>
  ...
  <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>
  ...
</SecTest>

AllowOnlyGroupsInACEs

The AllowOnlyGroupsInACEs test is similar to the AllowOnlyGroupsInACTs test above, but used to enforce the use of groups in ACEs (also known as Access Control Entries or explicit permissions). This test will generate test failure alerts whenever it finds explicit permissions granting or denying permissions for users. Some exceptions are necessary because there are locations, such as portal permission trees and private user folders, where ACEs for individual users are required. As above, these exceptions can be specified with the Ignore tag. You can specify allowed users and/or metadata tree paths. The following example shows exceptions for standard locations where valid user ACEs can be found. Any user ACEs detected outside of these locations will result in test failures.

<SecTest>
  ...
  <AllowOnlyGroupsInACEs>
    <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="/Products/" prefix="true"/>
      <TreePath path="/User Folders/" prefix="true"/>
      <TreePath path="/Users/" prefix="true"/>
      <!-- You can ignore a user and allow that user to appear in any ACE. -->
      <User name="sastrust"/>
    </Ignore>
  </AllowOnlyGroupsInACEs>
  ...
</SecTest>

This test doesn’t map to a golden rule because Danish Golden Rule #1 “Apply Access Control Templates (ACTs) To Resources” prohibits the use of ACEs. If you follow a different approach that uses a hybrid of ACTs in combination with ACEs then this rule will help make sure those ACEs only refer to groups (and not users). Personally, I tend to follow the approach of only using ACTs (the Danish model) except where that approach leads to the proliferation of a significant number of single-use ACTs (simply because large numbers of ACTs can be harder to manage in SAS Management Console).

AllowOnlyImplicitGroupDenials

A common scenario (perhaps an anti-pattern) that can be the source of considerable confusion for new administrators is when SAS metadata permissions are denied to explicit groups (any group other than the implicit groups SASUSERS and PUBLIC). I presented an example of this in my SAS Forum Australia & New Zealand 2010 presentation “Best Practices with SAS® 9 Metadata Security” specifically “Slides 15 & 16: Wide Denials, Narrow Grants”. In that example, two users who were members of the same distinct set of groups (but by different mechanisms) confusingly had different effective permissions on a resource. This type of situation can be avoided by only ever denying permissions to the implicit groups (SASUSERS and PUBLIC).

The new AllowOnlyImplicitGroupDenials recommended practice test can be used to avoid these types of problems because it generates test failures whenever it detects any ACTs or ACEs that contain permission denials for any explicit group or user (i.e. any identity other than the implicit SASUSERS or PUBLIC groups).

This can help to enforce both Danish Golden Rule #3 “ACTs with explicit Groups (not PUBLIC or SASUSERS) are only allowed to grant access, never deny it” and Danish Golden Rule #4 “Apply, whenever needed, ACTs with explicit groups granting access in combination with ACT denying RM for SASUSERS”.

The Danish paper contains permission denials for the SASUSERS group. Personally, I prefer to only ever deny permissions to the PUBLIC group (because of the potential gap between PUBLIC and SASUSERS) and so the AllowOnlyImplicitGroupDenials test can be further constrained to enforce this with the use of the publicOnly attribute.

The following sample test specification XML will complain about any non-PUBLIC permission denials found. It allows a single exception for the /System/Applications/SAS Web Report Studio folder which I found to have a SASUSERS denial created by default at the time of installation/deployment.

<SecTest>
  ...
  <AllowOnlyImplicitGroupDenials publicOnly="true">
    <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>
  ...
</SecTest>

AllowNoACEs

If you like to follow Danish Golden Rule #1 “Apply Access Control Templates (ACTs) To Resources” and avoid the use of ACEs (explicit permissions) then the AllowNoACEs test can help you. It can be used to enforce the use of ACTs over ACEs by generating test failures whenever it finds any ACEs which have not been specifically ignored. It’s normally necessary to configure some exclusions for this test (with the Ignore tag) because there are several locations where SAS applications automatically secure content with ACEs. By excluding those standard locations, as shown in the example below, you can detect and complain about ACEs in any other location. When required, you can also allow ACEs for specific users or groups.

<SecTest>
  ...
  <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 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>
  ...
</SecTest>

AllowNoUnprotectedACTs

The AllowNoUnprotectedACTs test helps to avoid situations where new ACTs are accidentally left unprotected. This is a topic I discussed in a guest post on blogs.sas.com “Protecting your metadata protections”.

This new test checks effective permissions for the SASUSERS and PUBLIC groups on all ACTs to ensure they have basic protections in place. It verifies that the PUBLIC group has effective denials of both ReadMetadata (RM) and WriteMetadata (WM) on all ACTs, and that the SASUSERS group has an effective denial of WM on all ACTs. If the effective permissions for PUBLIC or SASUSERS on any ACT results in grants for these permissions then test failures will be generated.

<SecTest>
  ...
  <AllowNoUnprotectedACTs/>
  ...
</SecTest>

AllowNoGroupMembershipLoops

The AllowNoGroupMembershipLoops test is used to ensure there are no groups with memberships loops. Membership loops can occur where the group has itself as an indirect member through membership of one of its nested group members.

<SecTest>
  ...
  <AllowNoGroupMembershipLoops/>
  ...
</SecTest>

AllowNoRoleContributionLoops

The AllowNoRoleContributionLoops test is used to ensure there are no roles with capability contribution loops. Contribution loops can occur where the role indirectly contributes capabilities back to itself by contributing to other roles which in turn contribute back.

<SecTest>
  ...
  <AllowNoRoleContributionLoops/>
  ...
</SecTest>

AllowNoGroupsWithImplicitMembers

The AllowNoGroupsWithImplicitMembers test is used to ensure there are no groups that have an implicit group (either SASUSERS or PUBLIC) as a member. We have found that groups containing an implicit member can be an indicator of a security model that has not been well planned.

This test XML sample shows how you can configure an exception – in this case the standard BI Dashboard Users group which acts more like a role and might have had SASUSERS added as a member.

<SecTest>
  ...
  <AllowNoGroupsWithImplicitMembers>
    <Ignore>
      <!-- You can ignore a group to allow that group to have implicit members. -->
      <Group name="BI Dashboard Users"/>
    </Ignore>
  </AllowNoGroupsWithImplicitMembers>
  ...
</SecTest>

AllowNoRolesWithImplicitMembers

AllowNoRolesWithImplicitMembers is an optional test for those SAS platform administrators that might want to carefully control the use of implicit groups in roles. It’s normal to include implicit groups (SASUSERS or PUBLIC) as members of roles, so this test will not be for everyone. If, however, you want to follow a policy where roles shouldn’t contain the very broad implicit groups until the ramifications have been reviewed, you can use this test and include the reviewed cases as exceptions to the test. Any other unspecified roles which are subsequently modified to include an implicit group will then generate test failures – at which time they can either be added as a test exclusion or have the implicit group removed as a member.

This test XML sample shows how this test could be used with some standard exclusions for roles which often contains implicit groups as members.

<SecTest>
  ...
  <AllowNoRolesWithImplicitMembers>
    <Ignore>
      <!-- You can ignore a role to allow that role to have implicit members. -->
      <Role name="Add-In for Microsoft Office: Advanced"/>
      <Role name="Enterprise Guide: Advanced"/>
      <Role name="Management Console: Content Management"/>
      <Role name="Visual Analytics: Basic"/>
      <Role name="Web Report Studio: Report Viewing"/>
      <Role name="Web Report Studio: Report Creation"/>
      <Role name="SAS Studio: Usage"/>
    </Ignore>
  </AllowNoRolesWithImplicitMembers>
  ...
</SecTest>

Final Thoughts

I’m excited about how these new tests will help our customers to follow recommended practices for SAS metadata security, including the Danish Six Golden Rules, and how that in turn will help them to maintain secure and manageable SAS platform installations. If you’re as excited about these new recommended practice tests as I am, and would like to try them out in your own environment, then leave a comment below or send me a message. We’re looking for testers for an upcoming Metacoda Plug-ins 5.0 beta, so please let me know if you’d like to participate – SAS 9.4, 9.3, or 9.2 platform installation required :)