Metadata bound libraries, is it worth the administrative overhead?

[MRSA]

@SASKiwi

I am interested to know that as well. Could we exclude the location where users are expected to store their output and results from the lockdown list and still be functional?

[Kurt_Bremser]

---

@MRSA wrote:

@SASKiwi

I am interested to know that as well. Could we exclude the location where users are expected to store their output and results from the lockdown list and still be functional?

---

There is a perfect tool for restricting write access to resources. It's called the operating system.

All this talk about MBL misses the core of the problem. Even if you have encrypted datasets, any user who has access to those datasets can still write a flat file from them, and if the system itself is not encrypted, this data will be open. And any data written back to the desktop via EG will also be open, unless the desktop is encrypted as a whole.

[MRSA]

@Kurt_Bremser

I don't think this discussion is missing the point that you mentioned. This whole discussion is mostly about that point, i.e. whether MBL and encryption provides a robust protection (which it may not). Regarding dumping out data, at least in our implementation we have disabled copy and paste, and also export of data. Also disabled access to local desktop through EG. So they can only write to server, and only the folders they have been granted access to.

[ronan]

I am not sure I answer your question completely. Locked Down works this way :

A. Before lockdown enablement (that's called Lock Down point, I think) : libnames declared at launching steps (autoexec, sasv9.cfg, initstmt) or libnames pre-assigned & referenced in metadata are assigned even if their locations are forbidden, excluded from the LD whitelist. The whitelist is enforced only afterwards :

B. After lockdown enablement, then users can only assign new libnames in authorised folders, those included in the whitelist

Summing up, it seems we could indeed use pre-assigned libraries or more generally - IT controlled libraries (permission to edit autoexec, sasv9 at SAS application server level being forbidden to the end user) as mandatory storage area for output. However, I am not sure declaring an empty LD whitelist works as well, in order to forbid any user assigned libnames. We could of course leave in the whitelist only a small user space like Home folder ( ~) under restricted quota, this looks more realistic. 

[ChrisHemedinger]

For those interested, here's more about how LOCKDOWN works.

LOCKDOWN's primary purpose is to allow admins to close two perceived holes when supporting SAS programmers:

1. It shuts down any SAS language feature that provides direct or indirect access to the operating system shell. This includes PROC GROOVY, and the DATA step Java Object and others. You also need to make sure that NOXCMD (shell command integration) and NORLANG (R language integration) are in place, since those avenues would circumvent any SAS-enforced system access.
2. It allows file access to only those directories that a SAS admin adds to a "whitelist". This is the key benefit, since it prevents users from assigning arbitrary file-based libraries.

[angieh · Accepted solution]

There has been a lot of good discussion on this topic thus far, but I've seen some possible confusion that I wanted to clarify. Metadata-bound libraries are a unique configuration that are different from libraries simply defined within the metadata. You can define libraries in the metadata for various types of data sources, such as SAS data sets or external database data. However, metadata-bound libraries (MBLs) are only applicable to SAS data sets and associated SAS indexes.

When you define a metadata-bound library, you run PROC AUTHLIB code to password-protect and physically bind all data sets in a defined path to metadata. With this approach, the data set password gets stored in metadata and you effectively lock down direct access to SAS data via a BASE engine libname statement and enforce metadata permissions for access to the SAS data. Users don't need to supply the password for data access, they instead just require a metadata aware SAS session and metadata permission to access the data.

If you want to encrypt the data at rest, then you would also use the REQUIRE_ENCRYPTION, ENCRYPT, and ENCRYPTKEY options on the PROC AUTHLIB statement to enforce encryption of the MBL data. See the SAS 9.4 Guide to Metadata-Bound Libraries for more information PROC AUTHLIB.

SAS Management Console has a user interface for defining MBLs, which effectively just generates and executes PROC AUTHLIB code behind the scenes. However, I typically like to write the code myself and run it outside of SAS Management Console just to clearly define and document the code options used.

As an FYI, I am a member of a SAS Consulting team that works with customers on architecture, administration, and security topics. In our experience, we have primarily only utilized Metadata-bound libraries for implementations which require encryption of SAS data. There is definite administration overhead in implementing MBLs, but they are the best way to seamlessly enforce encryption of SAS data. I always inform our customers that SAS data set encryption also requires defined user and administration processes in order to monitor and enforce the use of MBLs. Deepali Rai is another SAS consultant I work with and she will actually be presenting a SAS Global Forum 2018 paper on this topic based on best practices we have learned in wo.... Look for her in Denver in April!

Regards,
Angie Hedberg

[ronan]

No, that wouldn't as far as I understand how the two features can cooperate.

See Locked-Down Servers

MBL & Locked-down mode adress confinement differently (from my understanding, as a personal note, I only played with Locked Down, never myself with MBL directly although I discussed inner details of MBL in-depth with  SAS R&D years ago while another colleague was doing the tests for us. Let's say also frankly that I am not favorably biased towards MBL since then even if I admit that R&D has duly done its job in this regard . ). 

MBL enforces permissions selectively on certain libraries, enabling different degrees of "confinement" table by table (even at row-level also). This adds some security to pre-assigned libraries defined in metadata which, using MBL, cannot be re-assigned and whose rights defined in metadata are strictly controlled. Without MBL, base 9 engine Libraries can circumvent metadata permissions on pre-assigned libnames.

Locked Down mode works more broadly and notably completes the NOXCMD state when system commands are disabled (the normal state of any proper SAS platform, tells me Mordac). For instance, on Linux servers, even with NOXCMD, a simple filename gives some access to the OS using /proc filesystem (https://en.wikipedia.org/wiki/Procfs), for instance. Once Locked Down in place, then not anymore. Furthermore, Locked Down can also secure access to folders, regardless of OS permissions, using two well thought features, simple yet powerful :

  1. a white-list of system folders accessible (lockdown path list) : any folder not listed cannot be assigned with SAS base Libnames

  2. the ability to hide this whitelist from the prying eye : the corresponding parameter file can be conveniently stored outside the very whitelist scope which is an ultimate safety that even MBL cannot give (ReadMetadata permission is required as a bare minimum for MBL users thus authorizing to "draw the map" of secured area...)

As explained in the doc above, Lock Down withelist is compatible with pre-assigned libraries therefore (I guess) with pre-assigned MBL : but is it worth the effort in every (any) case ? 

[LinusH]

I just want to add a quite strong use case for MBL (perhaps not applicable for OP) which is Record Level Security for data at rest.
http://support.sas.com/documentation/cdl/en/seclibag/66930/HTML/default/viewer.htm#n0besvw44ac4kqn1q...

[ronan]

Thanks @LinusH for mentioning the MBL "Record Level Security", this looks useful :).

SAS Base altready provides a corresponding capacity, powerful though little-known, with Proc SQL views using "USER literal" in their Where clauses :

https://support.sas.com/documentation/cdl/en/sqlproc/63043/HTML/default/viewer.htm#p020urejdmvi7vn1t...

this amounts to filter upon the user system account, whereas MBL "Record Level Security" uses the Metadata user if I'm correct.

[lethcons]

While I've not yet had the pleasure of playing with MBLs, a few points come to mind.

Security

If people wish to write their own libnames then they will need all the connection information, including passwords, in order to do this. Enforcing access through metadata will mean that connection details stay within the realm of admins.

Portability

A non-MBL libname will not be portable. Thus a program developed in a Dev environment and promoted through other environments, eventually to Prod, would need to change that libname statement in each environment. A MBL would pick up everything it needs from the metadata in the current environment, irrespective of the environment. Similarly, if a database is moved to a different server, or a password changed - a MBL libname statement would not need to be modified.

Passthrough

I may have this wrong, but I believe a MBL greatly simplifies specifying connection details for SQL passthrough and means that actual connection details are not required.

By the way, what is "data at rest"? Never heard this term before.

[Kurt_Bremser]

---

lethcons wrote:

By the way, what is "data at rest"? Never heard this term before.

---

See here: https://en.wikipedia.org/wiki/Data_at_rest

[lethcons]

Thanks - one more term to tuck away in my own personal data at rest store.

[LinusH]

@ronan I haven't heard it so thanks for pointing it out. Should definitely look that up!

[LinusH]

@ronan not sure what you mean by full security. MBL data is encrypted, and metadata access rights are enforced. So IMO this should be enough for most use cases.

[Quentin]

@LinusH I assume you are asking about @ronan's statement:

Per se, MBL cannot guarantee full security unless you also assign some security at filesystem level (POSIX or NTFS based, in practice). This means, as @PaulHomes said, that perhaps only when strong encryption at rest is required, MBL own requirements prove beneficial all things considered. 

I assume by full security Ronan means including security from non-SAS interfaces to the dataset (file).  Without an OS security model, any user with file system access could move, over-write, or delete a SAS dataset, because the OS doesn't know anything about SAS metadata rules.

Last time I read the SAS metadata security docs (this was a couple years ago; I'm not an admin) they were full of statements along the lines of "Metadata security is layered on top of OS security, it is not a replacement for OS security."  More recent improvements like MBL and lockdown don't make that any less true.  My guess is the folks in Cary know that there are far too many Linux SAS servers out in the world where the only OS level security is obscurity.  At a conference once I heard someone say "sure, our file server is rwxrwxrwx  so that we don't have to deal with Linux permissions/groups, but it's okay, because not many people in our company are going to figure out that they could download putty, log in, and do damage." sigh. : )

 I imagine there are plenty of valid balance points between metadata security and OS security.  If I were made an admin and I was a Linux expert, I would probably rely heavily on OS security.  Because if I was confident in my OS security model and it met my needs, I might not need to worry much about metadata security.  But since I'm not a Linux expert, I would probably come up with some sort of basic OS security scheme which wouldn't be too painful to maintain, and then look for a tool like Metacoda security plug-ins to layer on more granular security.