Best Practices – platformadmin.com

Following SAS GEL Security Rules with Metacoda Security Tests

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. Continue reading “Following SAS GEL Security Rules with Metacoda Security Tests”

Tracing Permissions for SAS Metadata Security

SAS Global Forum 2016 is just over 2 weeks away, and I’m really excited about showing a Permissions Tracer feature we’ll be releasing in the next version of our Metacoda Security Plug-ins. Metacoda is a SASGF sponsor again this year and we’ll be showing a preview of this new version at our Metacoda stand in The Quad, so please stop and say hello if you’re going to be there too.

We’ve had some very positive feedback about how helpful our Identity and Object Permissions Explorers have been, so I’m looking forward to getting some feedback on this new feature too. One of the other reasons I’m excited is that this is something we’ve been building up to for several years as we’ve expanded our code base to help visualize the richness of the SAS metadata security model, including its interacting object inheritance paths, user identity hierarchies, and role-implied special conditions.

So what business problems does the Permissions Tracer solve? It expands on Continue reading “Tracing Permissions for SAS Metadata Security”

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. Continue reading “Testing Recommended Practices with SAS Metadata Security”

Protecting your Metadata Protections: Part 2

In a guest post on blogs.sas.com in January, I wrote about protecting your metadata protections. In that post I said that “Ideally, a SAS® metadata security plan should address both ACT permissions and access to the Authorization Manager.” and went on to explain a method for addressing Access Control Template (ACT) permissions.

In this second part, I’ll talk about reducing access to the SAS Management Console Authorization Manager plug-in as further protection for your ACTs.

Of course, for some smaller SAS sites, and those with simple security requirements, this might be overkill. However, for other possibly larger organizations, those with potentially sensitive data/content, and perhaps those with specific regulatory requirements, it might be a necessity to implement a comprehensive metadata security implementation with multi-layered protections like these.

In the default metadata security implementations for SAS 9.3 and SAS 9.2, all SAS users have the capability to access a limited set of features in the SAS Management Console. This includes access to the Authorization Manager plug-in where any accidentally unprotected ACTs could be modified. In order to be able to take advantage of this capability, and modify an ACT, a user has to be able to fulfill all of the following requirements: Continue reading “Protecting your Metadata Protections: Part 2”

WriteMemberMetadata Permission

The WriteMemberMetadata (WMM) permission was a welcome addition back when SAS 9.2 was released, because it allowed an administrator to distinguish between a users ability to manage a metadata folder from their ability to manage its contents.

In SAS 9.1.3 there was only the WriteMetadata (WM) permission and, if you had the ability to manage a folders contents, then you also had the ability to manage the folder too (and that could mean being able to change its permissions as well).

Starting with SAS 9.2, if someone had an effective grant of WMM then they could add and remove items from a folder, but to rename, move, delete, or modify the permissions on a folder then they would also need an effective grant of WM too. To allow someone to manage the contents of a folder, but not the folder itself, then we just needed to ensure that person had an effective grant of WMM and an effective denial of WM. As an aside, to avoid conflicts, the effective denial would ultimately be coming from a denial to PUBLIC, in combination with grants to appropriate groups, rather than a denial to the user themselves.

WMM Permission Patterns

In explaining some common patterns in the use of the ReadMetadata (RM), WriteMetadata (WM) and WriteMemberMetadata (WMM) permissions on SAS metadata folders, I find the following “truth” table useful:

Row	Effective Permissions			Comment
Row	RM	WM	WMM	Comment
1				-RM, -WM, -WMM: Folder not visible, can’t be modified, contents can’t be modified.
2				-RM, WM, WMM: Folder not visible, any WM and WMM grants are irrelevant.
3
4
5				+RM, -WM, -WMM: Folder and contents visible, folder cannot be modified, folder contents cannot be modified.
6				+RM, -WM, +WMM: Folder and contents visible, folder cannot be modified, folder contents can be modified.
7				+RM, +WM, -WMM: Folder and contents visible, folder can be modified, but folder contents cannot be modified!
8				+RM, +WM, +WMM: Folder and contents visible, folder can be modified, folder contents can also be modified.

When planning for effective permissions the green rows are the ones I aim for. They represent the common patterns, in increasing order of ability, as:

Row 1: Folder not visible to the user
Row 5: Folder and contents visible only
Row 6: Folder contents can be modified but not the folder itself
Row 8: Folder and contents can be modified

The grey rows (2,3,4) are variations on folder-not-visible: any WM and WMM grants are irrelevant because of the RM denial. I try to aim for the row 1 version. I find it looks neater and, when I don’t see any grant ticks, I don’t have to think at all about whether or not any permission is realistically available.

The pattern to avoid is row 7 with the red background. If someone ends up with those effective permissions they are in a confusing situation because they can manipulate the folder but not the folder contents.

WMM Permission Inheritance

The way in which WM and WMM inherit from their parents is a bit different to the other permissions. I find the diagrams below useful when explaining how the RM, WM and WMM permissions are inherited down an inheritance path.

In SAS 9.1.3 it was straightforward. Each permission on a folder, unless specifically set on that folder through an ACT or ACE, would inherit from the same permission on its parent folder:

With the introduction of WMM in SAS 9.2 this changed. Whilst the RM permission continued to inherit from RM in the parent folder, the WM and WMM permissions inherit from each other:

Unless specifically overridden, WM inherits from WMM on the parent folder (except on the root folder which doesn’t have WMM) and WMM inherits from WM on the same folder. You may have noticed WMM following WM when working in the SAS Management Console authorization tab. This might seem complex at first, but when you think about it, it becomes clear why this is necessary. A common pattern for allowing someone to manage a folder’s contents, but not the folder itself, is +RM,-WM,+WMM. With this inheritance model the inherited permissions on any sub-folders created by such a user would be +RM,+WM,+WMM and allow the user to manage any sub-folders they create. However, if the inheritance model was simple, with WM and WMM inheriting from the same parent permissions, that would mean the users permissions on any sub-folders they created would be the same as the parent (+RM,-WM,+WMM). They would be able to create sub-folders but then not have the ability to manage them (delete, rename, move etc) – very strange. This makes it clear to me why the WM/WMM inheritance model needs to be the way it is in SAS 9.2.