SAS Metadata Security Testing

SAS® Global Forum 2014 is now only a few days away, and I’m excited (and a little nervous) about presenting my paper Test for Success: Automated Testing of SAS® Metadata Security Implementations.

Update 03Apr2014: My paper is now available for download from the SAS Global Forum 2014 Online Proceedings.

SAS metadata security testing is a topic I’ve been contemplating for a long time now. For many organizations, metadata security is an important feature of the SAS platform. It enables them to control access to business resources described by the metadata and ensure their users can only use SAS applications to view and modify resources appropriate to their roles within the organization.

When metadata security is important, conducting security testing on a regular basis is important too. Regular testing allows an organization to feel confident in the security of their platform and to promptly detect deviations from a carefully crafted metadata security implementation. Many times I’ve seen accidental changes, or quick fixes, which had a detrimental impact on an installation’s metadata security. Without regular testing, these types of issues can go undiscovered for a long time.

What I have noticed, however, is that comprehensive metadata security testing is done very infrequently (if at all). I think the primary reason for this is because testing is usually done manually, and manual metadata security testing is a very time consuming process, involving the inspection of many property dialogs in SAS Management Console. SAS administrators are very busy people, and so we looked at ways to automate this process for those that need it. We wanted to enable metadata security testing to be done quickly, frequently, and easily, without requiring programming expertise in the SAS metadata model and interface.

My SAS Global Forum paper, and associated presentation, discuss these concepts and outline several example test specifications from an automated metadata security testing framework which has been developed by Metacoda. If this topic interests you, then please come along to my presentation on Monday 24th March at 3:50PM in Chesapeake 2-3. If you can’t make it to SASGF14 then the paper should also be available to download from the online proceedings shortly after the conference.

As a sneak peek, the diagram below highlights how our testing framework connects to a SAS metadata server and compares the current metadata security implementation against a set of test specifications contained in XML files. If the current implementation doesn’t match the tests, a report is generated which details the problems. An alert email can also be sent out. To help with the generation of the XML test specifications, we also have an export engine which can generate a “starter” set of XML files from an existing SAS metadata server.

When using this framework, the focus of the administrator changes. Rather than repeatedly performing time consuming manual tests, they focus their effort on specifying (in the XML files) what metadata security should look like in their installation. They don’t have to start from scratch because they can export tests from their current environment, review them and make any required modifications. These tests can be scheduled to run in batch and from that point onwards they only get involved when the tests fail and investigation is required, or when requirements change and the tests need to be updated.

As an example, here’s a fragment of a test specification file which describes the highly privileged unrestricted role: who the members should be, and how it has been protected with access controls. If any of those things change the test will fail and alert the administrator.

<SecTest ... >

  <Roles complete="true">

    <Role required="true" repository="Foundation" name="META: Unrestricted Users Role"
        displayName="Metadata Server: Unrestricted"
        desc="Provides all capabilities in SAS Management Console and provides access to all metadata [implicit]."
        external="false">
      <DirectMembers complete="true">
        <User required="true" name="AdminJane"/>
        <User required="true" name="AdminKoby"/>
        <User required="true" name="sasadm"/>
      </DirectMembers>
      <AccessControls complete="true">
        <ACT required="true" name="SAS Administrator Settings"/>
        <Group required="true" name="PUBLIC" permissions="-WM,-CM"/>
      </AccessControls>
    </Role>

    ...
  </Roles>

  ...
</SecTest>

As another example, here’s a fragment of a test specification file which describes the “SAS Administrator Settings” ACT: how it is defined, where it has been applied, and how it has been protected.

<SecTest ... >

  <ACTs complete="true">

    <ACT required="true" repository="Foundation" name="SAS Administrator Settings"
         desc="Gives the SAS Administrators group full access to metadata."
         repositoryACT="false">
      <PermissionPattern complete="true">
        <Group required="true" name="SAS System Services" permissions="+RM"/>
        <Group required="true" name="SASAdministrators" permissions="+RM,+WM,+CM,+A"/>
      </PermissionPattern>
      <Objects complete="false">
        <ACT required="true" name="Default ACT"/>
        <ACT required="true" name="SAS Administrator Settings"/>
        <ACT required="true" name="Private User Folder ACT"/>
        <ACT required="false" name="Portal ACT"/>
        <Group required="true" name="PUBLIC"/>
        <Group required="true" name="SASUSERS"/>
        <Group required="true" name="SAS System Services"/>
        <Group required="true" name="SASAdministrators"/>
        <Role required="true" name="META: Unrestricted Users Role"/>
        <Role required="true" name="META: User and Group Administrators Role"/>
        <Role required="true" name="META: Operators Role"/>
        <Object publicType="RootFolder" name="BIP Service"/>
        <Object publicType="Folder" parentFolder="/" name="System"/>
      </Objects>
      <AccessControls complete="true">
        <ACT required="true" name="SAS Administrator Settings"/>
        <Group required="true" name="PUBLIC" permissions="-WM"/>
      </AccessControls>
    </ACT>

  ...
  </ACTs>

  ...
</SecTest>

The next major release of Metacoda Plug-ins will include these metadata security test and export engines. The ACT, User, Group, Role, Capability, Protected Object and Internal Login Reviewers all provide the ability to export Metadata Security Test XML specification files.

There’s also a new Test Runner that allows you to run tests interactively and review any test failures.

When the tests are all running successfully, you can use your favourite scheduler to run them in batch as often as you want.

If you’d like to find out more about automated metadata security testing, please come along to my presentation at SAS Global Forum 2014 and ask some questions. Afterwards, if you also want to see the software in action, pop down to the Metacoda stand in the SAS Alliance Members section in the SAS Support & Demo Area, where we can show you a demo.

I hope to see you next week.