I think most people would agree that there's not much point in locking your front door if you're going to leave the keys in the lock. With a SAS platform metadata security implementation, it is just as important to ensure that the metadata access controls that you have carefully put in place cannot just as easily be unlocked. This blog post is going to focus on one aspect of this and that's securing Access Control Templates (ACTs).

Many SAS administrators use ACTs as the primary means of implementing SAS metadata security and for good reason. They are flexible, easily managed, reusable bundles of permission settings for users and groups. ACTs allow you to take common patterns of access controls and apply them consistently in multiple locations.

Why ACT security is often overlooked

Something that can be easily forgotten though, is the need to secure those ACTs so that they can only be modified by administrators. I find that new SAS administrators are often not aware of this fact. While, with a standard SAS installation, the predefined ACTs, such as Default ACT and SAS Administrator Settings are all appropriately secured, any new custom ACTs that they create can be modified by any SAS user with access to a workstation with SAS Management Console installed.

I sometimes demo this security gap with the following sample scenario:

• Alice, an administrator, logs into SAS Management Console to create a new HR folder and secures it with a new HR ACT that denies access to PUBLIC and grants it back to HR Users, SAS Administrators and SAS System Services. Unfortunately she forgets to secure the new ACT. Into the newly secured HR folder goes some sensitive HR content.
• Bob, a tech-savvy employee, wants to have a nose around the HR content. He finds a workstation with SAS Management Console installed, locates the HR ACT and adds himself with all permissions granted. After Bob has a look at the HR content, he tries to cover his tracks by removing himself from the ACT.

This scenario is possible for two reasons:

• ACTs inherit their authorization from the repository ACT. In a standard SAS installation, the repository ACT is called Default ACT, and it grants the WriteMetadata permission to SASUSERS. The Default ACT gives every SAS user the permissions they need to modify any new ACTs by default until additional security is applied to those new ACTs to protect them.



• ACTs are created and modified using the SAS Management Console Authorization Manager plug-in. In a standard SAS installation, the ability to create and modify ACTs is available to all SAS users by default. This capability is granted via the Management Console: Content Management role, which has the SASUSERS group as its only member.

Address both entry points in your security plan

Ideally, a SAS metadata security plan should address both ACT permissions and access to the Authorization Manager. By addressing point 2 only, our culprit Bob would not have access to the capability (Authorization Manager) he needs to edit the ACTs by point and click means. By addressing point 1 only, Bob would not have the permissions he would need to edit the ACTs, even if he did have access to the Authorization Manager plug-in (and, perhaps less likely, even if he knew how to write a program that uses the SAS Open Metadata Interface to modify the ACT).

I'll discuss how to address ACT inheritance here in this post, but I'll leave addressing Authorization Manager access for a future post.

A two-step approach to securing new ACTs

One might initially think that a potential way to prevent new ACTs inheriting an indirect grant of WriteMetadata for SASUSERS from the Default ACT is to remove the grant in Default ACT itself. However, you should avoid this step because granting default write permissions is necessary for any SAS user to be able to create new metadata, including metadata created just by using SAS applications. Instead of removing the grant, you must override that grant for each new ACT. While you could do this via explicit permissions, my recommendation is to use ACTs.

All of the predefined ACTs are already secured, so one way to secure new ACTs is to look at one of those pre-defined ACTs (such as Default ACT), see how it has been secured, and use the same settings to secure new ACTs. This method involves two steps:

1. Adding an explicit permission denying WriteMetadata to PUBLIC which removes everyone's update access (except unrestricted users of course).
2. Applying the pre-defined SAS Administrator Settings ACT, which grants update access back to the SAS Administrators group.

In a little twist of mind bending self-referencing you might also notice how the SAS Administrator Settings ACT is used to protect itself!

My preferred one-step approach

Personally, I prefer an alternative approach which involves a single step rather than two steps. My preference is based on the fact that with two steps it's easy to accidentally forget one of those steps!

In an excellent series of metadata security examples, the SAS Intelligence Platform: Security Administration Guide shows how to create a baseline Protect ACT. In a single step, you can apply that Protect ACT to any new ACTs (including itself) to accomplish the same end-results as above and ensure that those new ACTs can only be modified by unrestricted users and members of the SAS Administrators group.

To help me remember to protect any new ACTs, I also use a security plug-in that my consultancy developed for reviewing ACTs. Its Protected indicator feature displays a warning icon for any ACTs that haven't had any access controls applied to them. With just a quick glance, I can see any ACTs I might have forgotten to protect. You can contact me directly for more information.

I hope this post has given you a few ideas on how to protect your carefully crafted metadata security implementation. In a later installment, I’ll discuss how to ensure that the SAS Management Console Authorization Manager plug-in is only available to appropriate users. Taking this additional step, in reducing the scope of access to the primary tool used for modifying ACTs, can help to protect any accidentally unprotected ACTs. Keep an eye out for this second installment on my platformadmin.com blog.

Please let me know if you have any questions or comments. I'd also be keen to hear from other administrators about how you go about protecting your protections.