File Access audit alarm

[Paul Whapshott]

Hi,.

As an audit requirement I need to show whenever a file has been accessed. Type/deleted/edited/copied etc.
I would like an audit alarm to write to the audit file to show any access.

Can someone point me in right direction as to what acl I need to set up.

Thanks,
Paul

[Robert Gezelter · Accepted solution]

Paul,

The information you need is in the "OpenVMS Guide to System Security", available on the OpenVMS WWW site at http://www.hp.com/go/openvms

The information about adding an alarm will be found under "Adding Access Control Entries to Sensitive Files". Note that the procedures for establishing default Access Control Lists may also be appropriate if the business processes create new files an on ongoing basis, there can be more subtlety to this requirement than is often readily apparent at the outset.

- Bob Gezelter, http://www.rlgsc.com

[Jon Pinkley]

Make sure your backups are well protected, as nothing you do on your VMS system will audit access to what's on your backup tapes.

If you have a requirement for privacy, then you should probably be using encryption for any backups that aren't under your control.

Jon

[Paul Whapshott]

Thanks for your replies,

I do need however to set an ACL on the file such that each time the file is accessed it sends a WARNING to the audit file so these can be searched rather than a success message in the audit file. Only 1 User should have access to the file. I do need to accomodate the fact that there are a few users with elevated privilege which could access the file regardless of ACL set but I want the ACL to warn should it be accessed.

Regards,
Paul

[Jon Pinkley]

Depending on your requirements, and the knowledge of the users with elevated privileged, I will only say that VMS security is not intended to prevent access from privileged processes. Auditing will track what it tracks, but if you are watching for a specific event, you may not be getting the whole picture.

[Robert Gezelter]

Paul,

I recommend carefully reviewing the material in that section of the Guide to System Security. It is possible to cut down significantly on unneeded audit file entries by carefully crafting the ACL entries.

I also recommend that clients NEVER explicitly put a UIC in an ACE. I always recommend creating a standalone identifier, and then granting that identifier to the appropriate accounts. It is far easier to audit and manage when people change responsibilities or jobs, and when the organization changes.

- Bob Gezelter, http://www.rlgsc.com

[EdgarZamora_1]

To answer your specific question, use the SET SECURITY dcl command, example:

$ SET SECURITY filename.ext -
_$ /ACL=((ALARM=SECURITY,ACCESS=WRITE+DELETE+CONTROL+SUCCESS+FAILURE),-
_$ (AUDIT=SECURITY,ACCESS=WRITE+DELETE+CONTROL+SUCCESS+FAILURE))

You may just want the "AUDIT=SECURITY" and not the "ALARM=SECURITY" if you just want an entry in the audit file.

Also make sure your auditing is enabled for ACLs.

[John Gillings]

Paul,

Edgar's suggestion is on the right track. However, since you want TYPE access to be audited, you need to add READ to the access list access:

ACCESS=READ+WRITE+DELETE+CONTROL+SUCCESS+FAILURE

The key here is you need SUCCESS and/or FAILURE present for the alarm ACE to trigger. Your reqjuirement dictates you need SUCCESS, I'll assume the same as Edgar that you want to know about people who tried to access the file as well? (that's the FAILURE part).

You also need to make sure ACL audits are enabled:

$ show audit
System security alarms currently enabled for:
ACL <===
Mount
Authorization
Audit: illformed
Breakin: dialup,local,remote,network,detached
Logfailure: batch,dialup,local,remote,network,subprocess,detached

System security audits currently enabled for:
ACL <===
Authorization
Audit: illformed
Breakin: dialup,local,remote,network,detached
Logfailure: batch,dialup,local,remote,network,subprocess,detached

If they're not use

$ SET AUDIT/AUDIT/ENABLE=ACL
$ SET AUDIT/ALARM/ENABLE=ACL

[DECxchange]

Hello,
Depending on the size of your system (CPU speed, memory, disc drive space, number of users, number of file accesses) such extensive auding will potentially slow your system down and use up disc space. You are adding extra work for your system managers as well.

You might have to utilize automatic command and batch file mechanisms for cleaning up audit files so you don't end up shutting down your system from filling up disc drives. You might also want to offload your auditing files from the system disc. You probably want to get a fairly large disc to store all of this auditing. If you are going to audit every file access, you might be asking for a pretty huge log file(s).

[Paul Whapshott]

Thanks for the replies. I have set the following commands on my login.com file as an example;
set security/acl=(audit=security,access=read+write+delete+control+failure+su
ccess) login.com
set security login.com/acl=(alarm=security,access=write+delete+control+succe
ss+failure)

If i then type the file
On one server the audit displays;
Security audit (SECURITY) on SYSM01, system id: 6236
Auditable event: Object access
Event time: 17-JAN-2008 09:41:29.46
PID: 00000351
Process name: WHAPSHOTT_P
Username: WHAPSHOTT_P
Process owner: [SUPPORT,WHAPSHOTT_P]
Terminal name: FTA10:
Image name: S$DRA1:[SYS0.SYSCOMMON.][SYSEXE]TYPE.EXE
Object class name: FILE
File name: _$DRA1:[USERS.WHAPSHOTT_P]LOGIN.COM;38
File ID: (8354,45,0)
Access requested: READ
Privileges used: READALL
Posix UID: -2
Posix GID: -2 (%XFFFFFFFE)
Sequence key: 01095629

On the other server I have set the same ACL but nothing is displayed when analyzing the audit file. I have however noticed that the following is set on the server;
System security audits currently enabled for:
FILE access:
Failure: read,write,execute,delete,control

This is not set on the server that audits the type. I would of thought that this setting would record.

Paul

[Paul Whapshott]

Ignore previous message. I forgot to put READ on the ACL.

Apologies.

Once again thanks. I will assign points shortly.

Regards,

Paul

[John Gillings]

Paul,

>I have however noticed that the following >is set on the server;
>System security audits currently enabled for:
>FILE access:
>Failure: read,write,execute,delete,control

"FILE access: Failure" is a general audit of file access failures (duh!). Any file, any access failure. It's independent of any audit ACEs placed on individual files.

To enable audit and/or alarm ACEs use:

$ SET AUDIT/AUDIT/ENABLE=ACL
$ SET AUDIT/ALARM/ENABLE=ACL