Security Auditing

[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.