Auditing SYSUAF modifications to the SYSTEM account

[Steven Fletcher_1]

Hi,

I'm looking for a way to audit modifications to the system account in the SYSUAF file. I've used the help files to generate a command which returns all SYSUAF modifications, but just wondered if there is a way to narrow the select statemnet down to an actual account (i.e. the system account).

This is what I have:
$ analyze /audit sys$manager:security.audit$journal /full /select=subtype=sysuaf_modify

I've tried using the "account" flag, but that doesn't seem to return what I need.

Is it possible, or will I need to write a batch file that will break down the results and find only what I need?

Many thanks,
Terry,

[Hoff]

Off-hand, I don't know of a way to do this short of processing the audit records directly (the record format for the file is in the back of the system manager's utilities manual, IIRC) but I'd tend to be concerned around any changes to any UAF entries regardless, not just changes to the SYSTEM username. Other than the last login times and such, most anything in that file that changes is interesting.

[Hein van den Heuvel]

All records in the SYSUAF.COM are created equal. Well no, they are not created equal, but any process having access to one, has access to all. As such FILE level autditing is typically all that is needed.

If you wanted to know about changes to one particular record, then you you could just use MCR AUTORHIZE SHOW xxx into a file very so often and keep on comparing. That may tell you that is was changed (and not reset back) but not when nor by who.

With the right license in place you can enable RMS AFTER IMAGE JOURNALING on SYSUAF, which will (with some work) tell you WHEN the record was changed, and maybe by who (I forget whether that's retained. Probably for the purpose of RU journalling, but... Journalling is not auditing)

Maybe it would help if you indicated exactly what problem you are really trying to solve.
- Can not trust the folks with privs?
- some mis-guided security audit?

Hope this helps a little,
Hein

[John Gillings]

Terry,

In general, look at an audit record like the one you're interested in to determine the field names to select on. In this case you'd expect it to be /SELECT=(USER_RECORD=SYSTEM) but it doesn't exist.

Although ANALYZE/AUDIT should be able to perform these types of query, not all possibiities are available, and sometimes working out the exact syntax of the command required is too much like hard work. I often find it's simpler to dump a /FULL listing into a file and use SEARCH, or some DCL parsing to narrow down exactly what I want.

$ ANALYZE/AUDIT/FULL/SELECT=(SUBTYPE=SYSUAF_MODIFY) SYS$MANAGER/OUTPUT=AUD.TMP
$ SEARCH AUD.TMP "User record: SYSTEM" /WINDOW=(10,10)

Unfortunately SEARCH of a pipe can't do a prior window, so this needs to go via a temporary file.

[Craig A]

Hi John

You can use the ANAL/AUDIT command with PIPE as long as you add /NOINTERACTIVE to the ANAL/AUDIT command.

Craig

[Steven Fletcher_1]

Hi,

thanks for the replies.
Looks like I'll just do an output and parse it through DCl commands.

In response to what it's needed for, it's to combat a point in PCI-DSS compliancy where we are not allowed to use shared accounts.
Previously, the system account had a password which all the system administrators knew, but this breaches PCI-DSS. As a result I have reset the password on the System account and only I know it. We now need auditing on the system account so that if I'm not around and someone needs to use the system account they can reset the password, but it is logged automatically that another user has had access to the system account.

Ideally we'd like to just disuser (and maybe remove) the system account altogether, but after lots of reading up I don't think this is possible, hence the need for this workaround.

Thanks,
Terry.

[Ian Miller.]

Normally I disable interactive and network use of the SYSTEM user so it can be used for batch only, and set a long generated password to discourage password guessing. Then all support staff have their own username which have system level privs.

If the SYSTEM user is then needed then its password is set and perhaps interactive access enabled - of course all of this appears in the AUDIT log against the user that did it.

[Wim Van den Wyngaert · Accepted solution]

Note that audit can be bypassed.

On another node do :
$ def/us sysuaf yournode"us pwd"::sys$system:sysuaf.dat
% mc authoriz4e mod system/pass=toto

and the audit records will be in that other node's audit.

I would go for your own solution (e.g. list/fu system to a file and do a diff).

Wim

[Craig A]

Wim

I suppose a belt and braces approach would be to also add a SUCCESS+WRITE ACL (Audit) on SYSUAF.DAT so that network modifications can be tracked that way.

Craig

[Ian Miller.]

the audit ACL on SYSUAF, RIGHTLIST, PROXY is a a good idea

and Wim has successfully demonstrated one reeaon why a proxy for privilged username is a bad idea :-)

[Jess Goodman]

The following command will do what you are looking for:
$ ANALYZE/AUDIT/EVENT=SYSUAF/SELECT=UAF_SOURCE=SYSTEM/FULL

The /SELECT=UAF... keywords have not been documented since VMS 6.2 but they still work the same way they always did. By that I mean /SELECT=UAF_MODIFY= never worked right, but /SELECT=UAF_SOURCE= seems to work fine.

[Mike Kier]

Jess,

That sounds like a good addition to Parsec's Undocumented VMS Features page at http://www.parsec.com/openvms/undocumented.php
- perhaps you can get them to add it.

[Wim Van den Wyngaert]

SUCCESS+WRITE ACL (Audit)

Almost. This still allows to copy the sysuaf, modify it, delete the original and put the copy back in place. And then finish with adding the acl again.

I would add the delete to the acl too.

Wim

[Wim Van den Wyngaert]

Make sure that you have the ACL option in show audit.

If not, the user can remove the ACL, modify the file and put it back again. And monitor audit entries of course. Otherwise it's logged but nobody knows.

Wim

[Hoff]

Have you considered using the two-password login on the privileged user(s)?

That's a mechanism specifically intended for this situation.

Two users, both of which must be present to perform the privileged action(s).

As for all the auditing and accounting, that's comparatively insecure around privileged users; if you're privileged (and reasonably competent at DCL) it's usually easy to get rid of that stuff or (if you're somewhat better at OpenVMS and at your nefariousness) at covering your tracks.

[Steven Fletcher_1]

Thanks folks, lots of usefull info here.
I like the two password setting for the system account, that will help.
I think it's going to end up being most of the suggestions on here to get a comprehensive audit trail.

Obviously there is the priv user issue being able to cover their tracks, but from a PCI-DSS standpoint, we're auditing what we need to, so that's good enough.

There's always got to be some element of trust with your priveledged users, otherwise the system just wouldn't work, you could spend months/years going to the nth degree of security access.