How to Create New Audit Archive files?

[Johan Eklund_1]

Hi!

As you probably already know one can have secondary destinations for security event messages. Not only retaining them in the Security.audit$journal file(s) (primary destination).

My secondary destination resides on another node, created by doing a
$ Set Audit/archive=All -
/Destin=OtherNode::Disk1:[audit_dir]audit.file on the primary node.

The file on the secondary destination is created and filled with the General audit records I expect.

But if I want to start a new Archive file on a daily basis I have only one solution from what I have found. And that is to rename the file on the secondary destination and RESTART the secondary, remote node. Or does anybody know of anther way of doing it?

regards
Johan

[Wim Van den Wyngaert]

Any idea what happens if the remote node goes down and you get audit alarms ?

Wim

[Wim Van den Wyngaert]

If the network goes down, messages intended for the security archive file are lost. Security operator terminals
receive notice of the lost connection and the number of lost messages. Once the network is up, the audit server
reestablishes connection to the original archive file and continues writing event messages.

[Wim Van den Wyngaert · Accepted solution]

You simply do a /destination=xxx where xxx is the name of the new file (e.g. with the date in it). The old file is closed and the new one opened.

If you specify user name + pwd in the file spec it won't work. It needs a proxy (or double quotes ?).

Wim

[Hoff]

A general question: What's the particular security and network environment, and what problem or attack are you seeking to defend against here?

You can rename the remote archive file while underway. The file is then recreated when auditing is restarted. Or restart auditing with a new destination. (The auditing archive is intended to just keep recording stuff. The main file is the one that is intended for daily processing.)

Depending on local requirements, you could replicate the regular archive somewhere, or periodically copy its contents using ANALYZE commands.

Security audits in cleartext shipped over a DECnet connection to a remote node? (Ok, so I'm certainly a bit paranoid in general, and I don't know how far your DECnet network extends in this particular case.)

Stephen Hoffman
HoffmanLabs

[Johan Eklund_1]

Thank you Wim and Hoff. I do feel a bit silly that I never tried the obvious way, just changing the destination file name. Works like a dream.

I think the main reason for wanting an archive file is that the internal audit guys want's to "be sure" that nobody has touched, tempered with the local copy, the Sys$manager:Security.audit$journal.

I'm aware that there are a lot of "holes" just doing so. But I think we will start from here and later build a more secure and reliable solution. Perhaps using a listener mailbox.

/Johan

[Hoff]

The approach I've used is a daily series of auditing logs, and getting these remote and then off-site. The same for a BACKUP sequence.

When an auditor makes these sorts of (reasonable) requests, I ask them for a WORM-capable DLT or equivalent, possibly SAN based. Might as well ask to do it right, after all.

If the auditor happens to balk about this daily sequence, I then ask them if they want auditing data in cleartext DECnet over a LAN (and possibly WAN) link. That either leads to an um-err-no response, or an encrypted data link, or clearance to use the sequence. Or it might produce a DLT WORM. It might well also lead to an investigation of what is flying by on the datalink. Classic vanilla telnet or DECnet SET HOST, for instance, can be somewhat evil. Any of which can helps security, and usually leads to an explicit decision to deal with the exposure, or to ignore the particular risk.

If there's interest, I certainly know how to write audits, transactions or other data out to DVD+R media or to DLT WORM devices and can create a tool for same, and rather likely BD and HD media can be similarly gotten to work, too. Yeah. That would keep me entertained for a while. :-)

Stephen Hoffman
HoffmanLabs

[Johan Eklund_1]

Well, we do create new audit logs every day and take them off site. But they are a bit worried about the fact the we can "touch" these files and remove or alter records within before submitting the files to them. So, at least they think they wan't a "constant" flow to a log node where we can not touch any audit data.