Remember the sounds of roadies testing microphones with phrases like ‘Check one two, check, check’?
Thinking about it probably conjures up the feelings of excitement and anticipation waiting for a live event to start (which – for most of the world – is a distant memory at the moment!).
Or perhaps – being a new year – the phrase gets you thinking about new beginnings, new habits, and the importance of regular checking?
For instance, how long since you’ve reviewed your SAS security implementation?
Maybe you’d like to do your very own ‘check one two’ to see if your system is in line with the SAS Global Enablement and Learning (GEL) Recommended SAS 9.4 Security Model Design papers and rules for SAS metadata security?
If so, you can start by downloading a 30-day free Metacoda Plug-ins evaluation.
The Metacoda Security Testing Framework makes it easy to assess your SAS platform against each of the SAS GEL Security Rules (and to enforce the rules):
- GEL Rule #1 (4.1): Only use ACTs, never ACEs
- GEL Rule #2 (4.2): Only add groups to ACTs
- GEL Rule #3 (4.3): ACTs only grant access to explicit groups, never deny
- 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
- GEL Rule #5 (4.5): Always apply the SAS Administrators ACT when PUBLIC and SASUSERS are denied access
- GEL Rule #6 (4.6): Design your security model first and implement it early
- GEL Rule #7 (4.7): Apply ACTs to folders where possible
- GEL Rule #8 (4.8): Name security model objects clearly and simply
For more details about the rules, check out Paul Homes’ blog post Following SAS GEL Security Rules with Metacoda Security Tests.
And follow the steps below to get started with checking your SAS metadata security with the Metacoda Security Testing Framework:
Step 1
If you’re not an existing Metacoda customer, register, download and install a 30-day free Metacoda Plug-ins evaluation.
Step 2
To run the recommended practice tests, you’ll need to download the metacoda-recommended-practices.xml tests from the Metacoda Plug-ins Batch Interface Setup Utility GitHub repository. This repository provides a utility to help Metacoda customers and partners set up and use the batch interface for Metacoda Security Plug-ins with SAS software. These can be used with Metacoda Plug-ins version 6.1 R1 onwards with SAS Software versions 9.2, 9.3 and 9.4.
If you are only interested in running the Metacoda recommended practice tests, then simply download the XML file from metacoda-recommended-practices.xml (and click on the ‘Raw’ button for the clean text version of the file).
Step 3
With Metacoda Plug-ins successfully installed, and the metacoda-recommended-practices.xml file downloaded, start ‘SAS Management Console’ and navigate to the ‘Test Runner’ plug-in as shown below.
Step 4
Open the downloaded metacoda-recommended-practice.xml test script using the ‘Open…’ button in the top right corner then click on the ‘Run Test’ button next to it.
Step 5
A ‘Metacoda Security Testing Progress…’ dialog will appear, as shown below.
Step 6
Once testing is complete, you’ll receive a Status update. In our demo below – which is purposely not following the GEL recommended security practices because it models a less than ideal environment so we can show issues – you’ll see there are 29 failures, with 2,810 tests run.
Step 7
After clicking on the ‘Close’ button, you can scroll through the test failures. Select each one to see what test failed and why.
As an example, let’s step through Test Failure #5 AllowOnlyGroupsInACTs/ACT(‘Vegas Enterprises: AU/TAS (Read)’)/‘sasdemo’
This test failure is against GEL Rule #2 (4.2): Only add groups to ACTs because the sasdemo user has been added to the ACT to grant the ReadMetadata (RM) permission. A SAS administrator may have done this as a quick fix to allow the sasdemo user access to content protected by the ‘Vegas Enterprises: AU/TAS (Read)’ ACT.
If you flick to the ‘ACT Reviewer’ plug-in on the left-hand side and navigate to the ‘Vegas Enterprises: AU/TAS (Read)’ ACT, you will see some warning indicators across the row. The ‘User Ref?’ column shows that an individual user is being referenced and in the ‘Permissions’ tab in the lower pane we can see that the sasdemo user has been added.
We can resolve this failure by either removing the sasdemo user from the ACT or by replacing them with an appropriate group.
Let’s return to the ‘Test Runner’ plug-in, to investigate another test failure, AllowOnlyImplicitGroupDenials/ACE(Folder ‘/Metacoda Demos/Conflict’)/’VegasPowerUsers’.
This test failure is against GEL Rule #3 (4.3): ACTs only grant access to explicit groups, never deny because the explicit ‘Vegas Enterprises: Power Users’ group has been denied the RM permission on the folder ‘/Metacoda Demos/Conflict’.
Permission denials for explicit groups (instead of the implicit groups PUBLIC and SASUSERS) can result in unexpected access within a SAS environment that is hard to troubleshoot. It can also be an indicator that security governance has deteriorated, ad-hoc changes have accumulated, or an inexperienced SAS administrator is managing the environment.
If you switch to the ‘ACE Reviewer’ plug-in on the left-hand side and sort by the ‘RM’ column, you can see all of the RM denials in one place. Scanning the identity names within those denials for non-PUBLIC and non-SASUSERS group, you’ll see the explicit ‘Vegas Enterprises: Power Users’ group has an RM denial on the ‘/Metacoda Demos/Conflict’ folder that is likely to cause problems (and is the reason for the test failure).
This is a valuable test because denying permissions to anyone other than the implicit groups (PUBLIC or SASUSERS) is one of the most common reasons for unexpected access, permission conflicts, and lengthy security troubleshooting sessions.
Step 8
A test results report is a useful tool to share with colleagues, management or auditors, or to follow up on later.
Simply right-click over the ‘Test Runner’ plug-in on the left-hand side and select ‘Export HTML’ to create a report as displayed here.
So, as you can see, you can easily start the year with your very own step-by-step ‘Check one two’ of your SAS 9 platform metadata security!
How did you go? Did you find any surprises?
We’d love to hear from you – simply add a comment below and/or contact us.
And if you’d like to have the test scheduled on a regular basis to meet your own recommended practice metadata security and implementation test regime, please contact us about a commercial license.