Security Auditing

[himabindu s]

Hi,

openVMS by default stores all the audit related data in a binary log file.
We have analyze/audit tool that can be used to generate reports from that binary file.
The output of the report can also be redirected to a file.
So,is there any other way to convert this binary log file to a normal text file?

Thanks,
S.Hima Bindu

[Jan van den Ende]

Hima,

you practically gave the answer yourself in the question:
$ ANALYZE/AUDIT for everything redirected to an output file.
Be aware that thet will take VERY MUCH more diskspace.
The audit file is stored in binary for this reason.

hth

Proost.

Have one on me.

jpe

[Volker Halle]

S.Hima,

there is no other utility in OpenVMS to read and display the SECURITY.AUDIT$JOURNAL file.

This is a sequential file, so you could write your own utility to read and display it's records. The record definitions should be in LIB.REQ (NSA$...).

Volker.

[himabindu s]

I want my binary audit files to be converted to ASCII files in some periodic basis(say every 2hr or so).

How can we achieve this?

[Volker Halle]

S.Hima,

write a little DCL procedure using ANAL/AUDIT and /OUTPUT=filename qualifier and specify /SINCE=. Then submit this procedure as a batch job and make it re-submit itself at the desired intervals.

As you could use a hard-coded value like "-2:0:0" or you could use the creation date of the previous output file, to make sure you don't miss any events.

Volker.

[John Gillings]

>So,is there any other way to convert this
>binary log file to a normal text file?

You could write your own program. There are interfaces, but the file is complex, so it's probably not a good idea!

The simplest conversion is:

$ ANALYZE/AUDIT/FULL/OUT=audit.txt SYS$MANAGER

The resulting file is relatively easy to parse. Entries have a heading starting with the word "Security" and are separated by a blank line. Each field in an entry is of the form:

:

continuation lines start with white space.

What format were you hoping for, and for what purpose?

[himabindu s]

Hi..
Thank You for ur answers.
When the output is directed to a text file, the audit events appear in name value pairs.
For example:

Event 1:

Security audit (SECURITY) on TRUTH, system id: 56622
Auditable event: Object creation
Event time: 16-DEC-2009 08:25:29.41
PID: 206000BC
Process name: TCPIP$FTPC0000E
Username: SYSTEM
Process owner: [SYSTEM]
Image name: $4$DKA200:[SYS0.SYSCOMMON.][SYSEXE]LOGINOUT.EXE
Object class name: FILE
File name: _$4$DKA200:[SYS0.SYSMGR]TCPIP$FTP_SERVER.LOG;31
File ID: (8505,15,0)
Posix UID: -2
Posix GID: -2 (%XFFFFFFFE)
Deaccess key: 81570BC0
Sequence key: 0000E7C2
Status: %SYSTEM-S-NORMAL, normal successful completion

Event 2:

Security audit (SECURITY) on TRUTH, system id: 56622
Auditable event: Object creation
Event time: 17-DEC-2009 06:09:56.42
PID: 20600105
Process name: _TNA15:
Username: SYSTEM
Process owner: [SYSTEM]
Terminal name: TNA15:
Image name: $4$DKA200:[SYS0.SYSCOMMON.][SYSEXE]SETAUDIT.EXE
Object class name: DEVICE
Object name: _TRUTH$MBA145:
Posix UID: -2
Posix GID: -2 (%XFFFFFFFE)
Status: %SYSTEM-S-NORMAL, normal successful completion

In both of the events above, the task done is object creation, but the name (which appear on the left side of each name value pair)audited are different.(File name and File id doesn't appear in the second event)

Is there any way to get all the possible names that can appear for an event?
For example: For the event object creation what are all the possible fields that can be populated in the audit llog file?

Thanks,
S.Hima bindu

[Volker Halle]

S.Hima Bindu,

could you explain the reason behind your questions ? What are you trying to achieve ?

The 2 examples you've shown are a related to a FILE and a DEVICE object and therefore the audit messages have different parameters.

To get an idea about all the different parameters, look at the ANAL/AUDIT/SELECT qualifier and the values you can specify for this parameter. To get a full listing of all possible event and parameter names, you probably have to buy the OpenVMS source code listings and look at [AUDSRV]FORMATBL.LIS.

Did you have a look at the SYS$FORMAT_AUDIT system service ? It converts a security auditing event message from binary format to ASCII text.

Volker.

[himabindu s]

Volker,
We are actually trying to collect all the possible log messages that are possible on Open VMS.As the format of the log message changes for each event, can we get all the possible list of events generated by OpenVMS?

Thanks,
S.Hima Bindu

[Hoff]

You are describing potential solutions here, and not the particular problems or requirements that you are targeting. Please spend a few minutes at the keyboard and describe what problem you are solving here with this and with cron, and not how you have proposed to solve the problem(s). My guess is that there's a far better solution than you're working with here, too; catching the audits off a mailbox, for instance. Asking specific and targeted questions will get you answers, but not necessarily the best answer. Or even the right answer, in some cases.

As for formatting the events, use the provided system services for translating events. sys$format_audit being one of the key events here.

Don't presume you will ever get a list of all events; that's not how OpenVMS is designed.

You're expected to look for events you care about, and pass through the rest.

The intent of this scheme is one of upward-compatibility.

If an application or OpenVMS itself adds a new event (and that has happened) any design that is built on the premise of knowing all possible events will, well, fail.

Code that is built on parsing text output (whether from the auditing events or from DCL commands or other such output) is also considered precarious at best and typically unsupported and subject to change without notice; parsing command output is an application design that will fail.

If you need to parse and act upon auditing remotely, then I'd suggest passing over your own "encoded" format in the network records rather than depending on the details of the text translation of sys$format__audit, too.

Being unfamiliar with security services and the details of maintaining security can produce large (and expensive) security holes, too. This is an area of OpenVMS with very serious considerations around maintaining security and around avoiding exposures.

[Hein van den Heuvel]

First,

Like others I question the purpose of your quest.
Just go with what the system offers!
Do a high level parse if you must, and use ANAL/AUDIT provided text for details.
Or be prepared to write the 3000+ lines of code ANAL/AUDI uses to do its formatting.

May we assume you carefully studies the HELP ANAL/AUDIT?
It answer some questions you should have:
For example under: ANALYZE /AUDIT /SELECT ACCESS

And you've studied the book?
http://h71000.www7.hp.com/doc/732final/aa-q2hlg-te/aa-q2hlg-te.pdf

All the codes are defined in system provided include files. The "C" version has comments.
Grab a copy like so:

$ libr/extr=nsadef/out=nsadef.h sys$library:sys$starlet_c.tlb

Now SEARCH for hints:
$ search nsadef.h TARGET_DEVICE_NAME

You may also want to unravel the ANAL/AUDIT command definition using the VERB tool (Does not come with OpenVMS. FReeware)

$ verb analyze /out=verb_analyze.lis
$ edit/read verb_analyze.lis
.... look for AUDIT ...


Good luck!
Hein van den Heuvel

[John Gillings]

S.Hima,

As others have said, this is not necessarily a static list.

If you're trying to save the events in some kind of flat file, perhaps you should go for a self extending design?

For example, a CSV format where the header contains field names. As you extend the file, check the field name against those you already have. If it's new, add it to the end of the list of field names. Let the data tell drive the process, rather than trying to tell the code exactly what to expect.

But then I'd also recommend you think carefully before reinventing any wheels. If you can use the existing data file format and analysis tools, you'll have a lot less code to wrestle with.

[himabindu s]

Hi,

We need to parse all the events generated by OpenVMS. The parsing file should be written in such a way that it should be able to parse every event generated by OpenVMS.
For this purpose, im looking at some static set of events.
From ur discussion.. i came to know that a static set of events is not possible.
Let me ask one question..
For an event suppose (Object Access for a file(read)).Is the format(name parameters) of event same for every file access event?or the format changes ?

[Hein van den Heuvel]

>> We need to parse all the events generated by OpenVMS.

I seriously doubt it. I do believe that this is the task you are assigned, I just doubt it it is going add any value.

>> The parsing file should be written in such a way that it should be able to parse every event generated by OpenVMS.

I seriously doubt it. Just take the top 2 or 3 levels and include the rests as a piece of string.

To that point you may want to recognize just 5 - 10 common entry types and reduce the effort for the rest to the top and fixed lines (user, time,...), defaulting to 'unknown' if not present, and including whatever is NOT recognized as text.
If something pops up too often, then add it to the recognized set.


>> For this purpose, im looking at some static set of events.

Why? Just make the parser look for structures, not values. By dynamic?

>> From ur discussion.. i came to know that a static set of events is not possible.

That's largely incorrect. The ANALY/AUDIT program follows a strict and simple breakdown of the binary messages. The CODEs it uses for that are available to you. That NSADEF file I mentioned earlier.

>> For an event suppose (Object Access for a file(read)).Is the format(name parameters) of event same for every file access event?

Yes, by your definition, which includes tha fact that is the object as a file.
There are other object access records, for other object types.

Cheers,
Hein.

[Hoff]

Propriety prevents me from addressing the (lack of) design quality with the full strength of the verbiage that this abomination so richly deserves.

As for the implementation here...

Your code is implemented as a state machine and a design that works only with the binary audit data, and only with the key auditing records and only with the parts of the records that you require special-casing.

Your code does not look at the text-format translation, but simply calls sys$format_audit to get that text.

Your code is not cron-based and is not batch-based here and does not re-scan the auditing file (those files can get huge, and re-scanning won't scale), but rather your code operates as a server process (Unix daemon) reading auditing messages as the messages arrive via the auditing mailbox via $qio or analogous.

Your code does not parse auditing text. Ever.

Your code does not display attempted passwords.

Your code avoids disk buffers and other activities, uses encrypted or protected files, and uses only encrypted and secured links when transmitting auditing-related data off the host.

Your code always expects new auditing records will be added.

Your code expects that user applications can log application records, and that these may be of interest to the end users of your auditing package.

Your code always expects that the format of the text translations of the binary record formats and the languages of the translations can be changed.

Your code expects to operate in a cluster, and can coordinate its activities and traffic and its configuration appropriately across all hosts in the cluster; this might be sharing files, or it might be having a single source of (secured) data arriving off the cluster.

Your code uses UTC for its auditing, and translates the binary format time into UTC when sending messages off-host or when recording static data.

Accordingly and if these guidelines are followed, then the resulting product will be less likely to be considered a bad implementation of a bad (and insecure) software design.