Thanks for that helpful documentation link Brian.

https://go.documentation.sas.com/doc/en/pgmsascdc/9.4_3.5/secref/n01i5rmae78r1dn1x3c0f7nqqnnq.htm

This and the pages around it on the left should sufficiently explain any other SAS/SECURE M8 differences for everyone!

Hi Ronan,

In that case you may also be interested in some upcoming blog posts too. The Activity Reviewer can work with the default logging config of the SAS 9 Metadata Server, but you can also make some changes to log some additional things related to access control changes (as you would have done). I plan to write some blog posts about how to find additional loggers including some that provide more information on the application and removal of ACTs on objects.

Cheers
Paul

You are more than welcome ! The Testing Framework is indeed a great source of information for revealing differences, changes between periods of time. I used to enable a second log file issued from the Metadata server
to single out the transactions dealing with security objects – Persons, Logins, IdentityGroups, ACT, ACE : creations, deletions, modifications, timestamp, acting user. I have never automated the parsing/extractions of the corresponding log files, this was available as a kind as Metadata security audit trail easy to manipulate. Your approach generalizes this to any kind of object or changes, enabling a full and comprehensive MD audit trail, with the integrated search pane into the SMC as a bonus :-).

Cheers
Ronan

Hi Ronan,

Thanks for that feedback, it’s really good to hear.

We still have some way to go with this plug-in. If it proves to be popular then we would like to add some log augmentation too. Many of the default log messages in the metadata server logs omit some useful audit information. As you know, the SAS APM setup changes the logging configuration to log additional messages that are useful for audit. We would like to add some other things too. For example when objects are added, renamed, and deleted only the name and object id are present. We would like to show the metadata folder path for the object too. We can’t change the log message content in the metadata server log itself, but we are looking at adding a watcher process that looks for these messages appearing in OpenSearch, does a lookup, and writes the additional info as a log record with the same timestamp into another log file. That log file is also tailed and sent to OpenSearch. That way a query from the Activity Reviewer plug-in will show those augmented log records mingled in with the original log records to provide additional information to the admin.

Regarding your well-said point about “unnoticed security impact”, for those that might want more immediate alerts when access controls are changed, we usually recommend setting up regularly scheduled automated metadata security tests using our Metadata Security Testing Framework. That way if someone makes an unexpected/unwanted change to access controls an email alert will go out to interested parties so they can follow up promptly.

I also expect that subsequent questions to the ones mentioned in the post above might include “What WAS the change this person made?” and “What WAS the change made to this object?” We don’t have concrete ways to answer those questions as it would required diff-ing before and after metadata (and possibly more). One thought I have for a partial solution also involves the Metadata Security Testing Framework. As well as automated testing, it supports automated export of tests, where those tests represent some of the before-state for security metadata. For example, if you automate the export of ACTs and Protected Object tests every hour, and at a later time detect a change was made (either through automated testing or inspecting the logs), you can run that previously exported test. Any test failures will represent changes of security metadata between now and when the test was exported. If you want to swap “now” for some other point in time you could use a diff tool to look at changes in the 2 closest Metadata Security Test XML export files.

Once again thanks for your comments, they are always thoughtful and very much appreciated.

Cheers
Paul

The Activity Reviewer looks terrific ! It really fills a gap, since real time observability is lacking with a SAS 9 platform, as well as in-depth Metadata log auditing. SAS EV APM reports are too static and based on nightly extractions, overdue for monitoring. The linking feature with other plugins is extremely useful, this way tracking a mere user or in some cases, tracking ACT/ACE modifications with potentially large albeit unnoticed security impact becomes possible. This significantly enhances SLAs levels for a SAS 9 platform.

Cheers
Ronan

Thanks Margaret for posting that quote from the SAS R&D developer.

“SAS/SECURE was a product that included encryption libraries and SAS encryption/hashing/TLS modules. The SAS encryption/hashing/TLS modules are still there, but now use operating system libraries instead of SAS shipped encryption libraries.

For AES encryption, SAS encryption modules previously used Crypto-C MicroEdition libraries but now use Bcrypt (on Windows), OpenSSL (on Linux/UNIX), and still use ISPF on z/OS.

For TLS encryption, SAS encryption modules previously used OpenSSL libraries shipped with SAS/SECURE on Linux/UNIX and z/OS (SAS on Windows has always used SChannel). Now TLS on Linux/UNIX will use the operating system OpenSSL libraries (versions 1.0.1, 1.0.2, 1.1.1, or 3.0.x) and on z/OS will be using the z/OS GSK subsystem.”

It’s great to hear that you have your deployment working. Regarding changing the issuer, it is not something I have had to do as yet. If it is something I need to do in future I’ll try and remember to blog about it. In the meantime it’s probably best for you to post a question on communities.sas.com where you can benefit from the experience of the wider SAS admin community or ask SAS Technical Support.

Cheers
Paul

I have one last, final question though
If I have a default cluster issuer set up, do you know how I might go about using this, as opposed to provided sas-viya-issuer issuer.

When I do a describe on the ingress I get this as part of the annotations

Annotations: cert-manager.io/issuer: sas-viya-issuer
Which isn’t my default cluster issuer

Thanks again for all your help and pointers.