Security Auditing under VMS V5.2 and following:

This is a collection of command  procedures
that I'm using for setting up and monitoring security auditing.

The SYSECURITY.COM is from SYS$MANAGER:.

LOC$SECURITY.COM is from SYS$COMMON:[SYS$STARTUP].
Here is how I have it entered in SYSMAN STARTUP:

Phase        Mode   File 
------------ ------ ---------------------------------
LPBEGIN      DIRECT LOC$SECURITY.COM
      Enabled on All Nodes
      P1: P2: P3: P4: P5:<def> P6:<def> P7:<def> P8:<def> 

AUDIT_LOG.COM is from a directory where I keep daily/weekly batch procedures.

GETNODE.COM and CVTIME.COM are from a utility directory.

CLUSTER_DO.COM is also from the utility directory, although, since it
requires OPER privelege at a minimum in order to use SYSMAN, it
may be appropriate to put somewhere else.

There are some interesting & ANNOYING quirks in the V5.2 release of
the AUDIT_SERVER code.  A lot of the facts are discussed (and disgust)
in the AUDIT_LOG.COM comment notes.

If you haven't already worked out your own way of dealing with this
wonderful new toy, here is a way that I've done it.  

AUDIT_LOG.COM is set up to set, modify, and summarize the audit journal and
archive files on a daily basis.  If any interesting events are found, it
sends mail to the appropriate individual(s).  This procedure is called
from LOC$SECURITY.COM (in startup phase LPBEGIN) in order to create logical
names.  It is then called every day shortly after midnight on 1 node in
the cluster.  We have a job we run on each cpu at midnight.  It is coded
so that the secondary audit analyzer checks to see if the primary is up.
If not, the secondary one completes the analysis and updates all of the
logicals and SET AUDIT settings on the cluster.

There is one event that I haven't covered yet that would include the
instance where both the primary and secondary analysis cpus are down
across midnight.  In this instance, the midnight job will invoke the
procedure when the machine is booted up, but the procedure as coded will
not pick up the previous journal file(s) for analysis.  If it happened
at midnight of the end of the month it could also fail to perform the
monthly analysis.  I have further enhancements in mind to handle these
circumstances, but they will involve a little more coding.  My plan is
to check for the existence of daily summary markers and monthly markers
in a file.  If the marker doesn't appear for a particular date/month then
the analysis will be performed for the missing time(s) as well as the
current date.  Do you have any experience with coding for solving similar
problems?  Basically it is devising a scheme for catching up to get 
current without skipping anything unnecessarily.

If you like/dislike anything you find in this collection, please send
me feedback.  I'm planning to release it to DECUS for distribution if
it is satisfactory.

How to start using this setup:

1.  Edit the SYSECURITY.COM file.

2.  Create the necessary directory(s) where everything will go

3.  Edit AUDIT_LOG.COM to reflect the site specific things you want to
    do with it.

4.  Put AUDIT_LOG.COM into the [AUDIT.EXE] directory

5.  Look for a time when you think you can pull this off without leaving
    too much of a gap when auditing is disabled.

6.  For each node in your cluster:

	a. Login to the system manager's account (or do all of your nodes
           at once by using sysman to do this)
	b. SET AUDIT/SERVER=EXIT
	c. @SYS$MANAGER:SYSECURITY
	d. SET AUDIT/SERVER=START
	e. @SYS$STARTUP:LOC$SECURITY

7.  Add a command to your new day(or midnight) job to execute AUDIT_LOG
    on one node in your cluster each day.

-----------------------------------------------------------------
 Bob Boyd                     Usenet:    n/a at present time
 Harris Microelectronics Ctr. Internet:  ,,
 POB 13049, MS 7T3-01         BitNet:    ,,
 RTP, NC 27709-3049           Voice:     (919)549-3627 
 Harris or GE DECnet: RTPARK::RLB