HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Hours:
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Auditing SYSUAF modifications to the SYSTEM account

 
SOLVED
Go to solution

Auditing SYSUAF modifications to the SYSTEM account

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,
15 REPLIES
Hoff
Honored Contributor

Re: Auditing SYSUAF modifications to the SYSTEM account

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
Honored Contributor

Re: Auditing SYSUAF modifications to the SYSTEM account

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
Honored Contributor

Re: Auditing SYSUAF modifications to the SYSTEM account

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.
A crucible of informative mistakes
Craig A
Valued Contributor

Re: Auditing SYSUAF modifications to the SYSTEM account

Hi John

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

Craig

Re: Auditing SYSUAF modifications to the SYSTEM account

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.
Honored Contributor

Re: Auditing SYSUAF modifications to the SYSTEM account

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.
____________________
Purely Personal Opinion
Wim Van den Wyngaert
Honored Contributor
Solution

Re: Auditing SYSUAF modifications to the SYSTEM account

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
Wim
Craig A
Valued Contributor

Re: Auditing SYSUAF modifications to the SYSTEM account

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.
Honored Contributor

Re: Auditing SYSUAF modifications to the SYSTEM account

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 :-)

____________________
Purely Personal Opinion
Jess Goodman
Esteemed Contributor

Re: Auditing SYSUAF modifications to the SYSTEM account

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.
I have one, but it's personal.
Mike Kier
Valued Contributor

Re: Auditing SYSUAF modifications to the SYSTEM account

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.
Practice Random Acts of VMS Marketing
Wim Van den Wyngaert
Honored Contributor

Re: Auditing SYSUAF modifications to the SYSTEM account

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
Wim Van den Wyngaert
Honored Contributor

Re: Auditing SYSUAF modifications to the SYSTEM account

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
Wim
Hoff
Honored Contributor

Re: Auditing SYSUAF modifications to the SYSTEM account

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.

Re: Auditing SYSUAF modifications to the SYSTEM account

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.