Collecting security audit messages in
the security audit log file is useless without periodically reviewing
it for suspicious activity. You use the Audit Analysis utility (ANALYZE/AUDIT)
to examine the data in the security audit log file.
ANALYZE/AUDIT generates a report from the log
file so that you become familiar with normal activity on your system
and can easily spot atypical activity. It summarizes events for you
and plots where activity is occurring on the cluster. The utility
also helps you analyze atypical activity because it is capable of
selecting a subset of information from an audit report and of providing
fuller information for your analysis. While the analysis of a single
audit log file might not be significant, audit records can, over time,
reveal a pattern of activity that indicates security violations.
Recommended Procedure |
 |
This section describes how to analyze audit log files
on your system. Although the way you use ANALYZE/AUDIT depends upon
the security needs at your site, there are a number of common steps
that you should follow, regardless of the extent to which you use
the utility. Before you can recognize potential security problems,
you need to become familiar with the normal operation of your system.
Then you can develop a procedure for generating and reviewing audit
reports on a periodic basis. Whenever your regular analysis of audit
log files leads you to suspect a security problem, you should perform
a detailed investigation of selected security events.
Step 1: Know What Is Normal
As a security administrator, you should be able
to answer the following questions before analyzing an audit log file:
What are the typical hours
of operation for most users of the system?
Are there specific users
who normally operate with advanced privileges?
Which images generate
system security events as part of other applications?
Are there any regular
batch or network jobs that run at specific times of the day?
By knowing the answers to these questions, you
can eliminate false alarms, which otherwise may cause you to wrongly
suspect a security problem.
Step 2: Periodically Analyze the Audit Report
The most common type of report to generate is
a brief, daily listing of events. You can create a command procedure
that runs in a batch job every evening before midnight to generate
a report of the day's security event messages. (You can use the
same procedure to create a new version of the audit log [see “Maintaining the File”].)
The following example shows the ANALYZE/AUDIT
command line to generate this report:
$ANALYZE/AUDIT/SINCE=TODAY/OUTPUT=31DEC2000.AUDIT - [1] |
_$SYS$MANAGER:SECURITY.AUDIT$JOURNAL
$MAIL/SUBJECT="Security Events" 31DEC2000.AUDIT SYSTEM [2] |
The first command in this
example produces an audit report named 31DEC2000.AUDIT, which contains
one-line descriptions of all the security event messages generated
during the current day.
The second command mails
the file to the security administrator for examination.
Depending on the number of security events that
you are auditing on your system, it can be impractical to review every
audit record written to the audit log file. In this case, you can
select a specific set of records from the log file, such as all audit
records related to changes in the authorization database and break-in
attempts, or all events occurring outside normal business hours.
Analyze any subprocess-related audits with the
knowledge that a pipe subprocess (created by the DCL PIPE command)
can generate the audits. The PIPE command can create a large number
of subprocesses to execute a single PIPE command. This can mean a
potential increase in auditing events that are related to subprocess
activities (for example, process creation, process deletion, login,
logfailure, and logout).
It is important that you review audit reports
as soon as possible. The sooner you inspect the reports, the sooner
you become aware of any possible breach of security on the system
and can determine the extent of the problem. You can make the inspection
of the previous day's audit report a regular part of your morning
routine, or you can create a program that reviews the report and notifies
you through the Mail utility (MAIL) when suspicious events appear.
Step 3: Scrutinize Suspicious Activity
If, during your review, you find any security
events that appear suspicious or out of place, like login attempts
outside normal business hours, then use the Audit Analysis utility
to perform a more detailed inspection of the security audit log file.
A full report can help you determine which security events logged
to the audit log file warrant a more thorough investigation.
The following command generates a full report
of selected security audit records:
$ANALYZE/AUDIT/FULL/SINCE=TODAY/OUTPUT=31DEC2000.AUDIT -
_$/EVENT_TYPE=(BREAKIN,RIGHTSDB,SYSUAF)
$MAIL/SUBJECT="Security Events" 31DEC2000.AUDIT SYSTEM |
The audit report for December 31, 2000 contains
information on all intrusion attempts and all modifications to the
system user authorization file (SYSUAF.DAT) and the rights database
(RIGHTSLIST.DAT).
Invoking the Audit Analysis Utility |
|
The Audit Analysis utility is the tool you use
to produce a meaningful report from a binary log file. This section
and the sections that follow describe how to use the utility, but
see the HP OpenVMS System Management Utilities Reference
Manual for complete documentation of the utility's
commands and qualifiers.
To invoke the Audit Analysis utility, use the
following DCL command:
For the file-name parameter,
substitute the name of the file from which audit reports are to be
generated. The default name of the security audit log file is SECURITY.AUDIT$JOURNAL.
You must specify the directory: SYS$MANAGER.
Providing Report Specifications |
|
With the Audit Analysis utility, you are able
to extract all or some of the security event messages from a single
audit log and produce reports with various levels of detail.
The audit report reflects events from the set
of event classes a site has enabled (see “Reporting Security-Relevant Events”). You
can tailor the report so only a subset of events are extracted. The
selection criteria can be based on time, on event class, or on field
of data within the event message. (See the documentation of the /SELECT
qualifier in the HP OpenVMS System Management Utilities
Reference Manual.) “Qualifiers for the Audit Analysis Utility” summarizes the qualifiers that determine
the content of the report.
Table 10-6 Qualifiers for the Audit Analysis Utility
| Type | Qualifier | Description |
|---|
Content | /BEFORE | Extracts event messages
logged before the specified time. |
| | /SINCE | Extracts event messages logged after
the specified of time. |
| | /EVENT_TYPE | Extracts event messages of a specific
event class (see “Kinds of Security Events the System Can Report” ). |
| | /SELECT | Extracts event messages based on data
in the messages. (For example, /SELECT=USERNAME=JSNOOP lists only
security event messages generated by user JSNOOP.) |
| /IGNORE | Excludes event messages from the report
based on data in the messages. |
Format | /BRIEF | Produces a report with
one line of information about each record in the audit log file, such
as the type of event, when it occurred, and the terminal from which
it originated (see “Brief Audit Report”). This is the default. |
| | /FULL | Provides all possible data for each record
in the audit log file being processed (see “One Record from a Full Audit Report”). “Alarm Messages” provides sample alarm messages for
each event class. |
| | /SUMMARY | Lists the total number of audit messages
for each event class in the log file being analyzed (see “Summary of Events in an Audit Log File”). It can
also plot the aggregate events per hour on each node. |
| | /BINARY | Produces a binary file so you can extract
records for further analysis using your own data reduction tools.
See the HP OpenVMS System Management Utilities Reference
Manual for a description of the audit message record format. |
Destination | /OUTPUT | Specifies
the report destination. By default, it goes to SYS$OUTPUT. |
ANALYZE/AUDIT produces
audit reports in different formats (see “Qualifiers for the Audit Analysis Utility”). The
utility produces a one-line summary of each record in the log file
by default. Brief, one-line reports are most useful for routine analysis
of a log file. The more detailed full reports provide the detail necessary
for analyzing records of a suspicious nature. If you are interested
in archiving portions of a log file, the binary listing lets you store
a subset of an audit log file.
A summary report helps you identify potential
security problems quickly. For each class of security event, a summary
report can list the total number of audit messages extracted from
the security audit log file being analyzed. A summary report can also
display a plot of auditing activity, based on the system generating
the event message, the time when it occurred, and the total number
of events seen.
“Brief Audit Report” shows a brief report of all the security
audit events logged to the system security audit log file. In the
ANALYZE/AUDIT command that generates the report, substitute the name
of your audit log file.
Example 10-4 Brief Audit Report
$ ANALYZE/AUDIT/BRIEF SYS$MANAGER:SECURITY.AUDIT$JOURNAL |
Date / Time Type Subtype Node Username ID Term
--------------------------------------------------------------------------
1-NOV-2000 16:00:03.37 ACCESS FILE_ACCESS HERE SYSTEM 5B600AE4
1-NOV-2000 16:00:59.66 LOGIN SUBPROCESS GONE ROBINSON 3BA011D4
1-NOV-2000 16:02:37.31 LOGIN SUBPROCESS GONE MILANT 000000D5
1-NOV-2000 16:06:36.40 LOGFAIL LOCAL SUPER MBILLS 000000E5 _TTA1:
[vellip] |
“One Record from a Full Audit Report” shows one record from a full format
audit report. In the ANALYZE/AUDIT command that generates the report,
substitute the name of your audit log file.
Example 10-5 One Record from a Full Audit Report
$ ANALYZE/AUDIT/FULL SYS$MANAGER:SECURITY.AUDIT$JOURNAL |
Security audit (SECURITY) on FNORD, system id: 19728
Auditable event: Object access
Event time: 6-AUG-2000 11:54:16.21
PID: 3D200117
Process name: Hobbit
Username: PATTERSON
Process owner: [ACCOUNTING,PATTERSON]
Terminal name: RTA1:
Object class name: LOGICAL_NAME_TABLE
Object name: LNM$SYSTEM_DIRECTORY
Access requested: WRITE
Status: %SYSTEM-S-NORMAL, normal successful completion
Privileges used: SYSPRV |
“Summary of Events in an Audit Log File” shows a summary report. In the ANALYZE/AUDIT
command that generates the report, substitute the name of your audit
log file.
Example 10-6 Summary of Events in an Audit Log File
$ ANALYZE/AUDIT/SUMMARY SYS$MANAGER:SECURITY.AUDIT$JOURNAL |
Total records read: 9701 Records selected: 9701
Record buffer size: 1031
Successful logins: 542 Object creates: 1278
Successful logouts: 531 Object accesses: 3761
Login failures: 35 Object deaccesses: 2901
Breakin attempts: 2 Object deletes: 301
System UAF changes: 10 Volume (dis)mounts: 50
Rights db changes: 8 System time changes: 0
Netproxy changes: 5 Server messages: 0
Audit changes: 7 Connections: 0
Installed db changes: 50 Process control audits: 0
Sysgen changes: 9 Privilege audits: 91
NCP command lines: 120 |
Using the Audit Analysis Utility Interactively |
|
When you send output to a terminal, you can analyze an
audit log file interactively. At any time during the display of a
listing, you can interrupt the report being displayed by pressing
Ctrl/C. This automatically initiates a full listing and gives you
the Command> prompt. In command mode, you can advance or return to
earlier records in the report and study them in greater detail.
At the Command> prompt, you can enter any of the
ANALYZE/AUDIT commands listed in the HP OpenVMS System
Management Utilities Reference Manual to modify the analysis
criteria, to change position within the audit report, or to toggle
between full and brief displays. To return to an audit report listing,
enter the CONTINUE command.
Examining the Report |
|
When a routine analysis of an audit log file leads you
to suspect that the security of your system has been compromised (through
an actual or attempted intrusion, repeated login failures, or any
other suspicious security events), you can investigate the source
of the security event through a more detailed inspection of the security
audit log file.
For example, assume that you see the security
events shown in “Identifying Suspicious Activity in the Audit Report” during a routine inspection of the previous day's audit report.
Example 10-7 Identifying Suspicious Activity in the Audit Report
Date / Time Type Subtype Node Username ID Term
--------------------------------------------------------------------------
[vellip]
26-OCT-2000 16:06:09.17 LOGFAIL REMOTE BOSTON KOVACS 5BC002EA _RTA14:
26-OCT-2000 16:06:22.01 LOGFAIL REMOTE BOSTON KOVACS 5BC002EA _RTA14:
26-OCT-2000 16:06:34.17 LOGFAIL REMOTE BOSTON KOVACS 5BC002EA _RTA14:
26-OCT-2000 16:06:45.50 LOGFAIL REMOTE BOSTON KOVACS 5BC002EA _RTA14:
26-OCT-2000 16:07:12.39 LOGIN REMOTE BOSTON KOVACS 5BC002EA _RTA14:
26-OCT-2000 16:23:42.45 SYSUAF SYSUAF_ADD BOSTON KOVACS 5BC002EA _RTA14:
[vellip] |
The security events displayed in the report shown
in “Identifying Suspicious Activity in the Audit Report” indicate
that user Kovacs logged in to the system following four unsuccessful
login attempts. Shortly after logging in, user Kovacs created a new
account in the system user authorization file (SYSUAF.DAT).
At this point, you must determine whether this
behavior is normal or abnormal. Is user Kovacs authorized to add new
user accounts to the system? If you believe that the security of your
system has been compromised, use the following command to generate
a more detailed report from the security audit log file to determine
if damage has been done to your system:
$ANALYZE/AUDIT/FULL/SINCE=01-JUN-2003:16:06 |
The command in this example generates a full report
of all security audit events written to the audit log file since user
Kovacs first attempted to log in to the system. In a full format report,
all the data for each record in the audit log file is displayed. Using
the full report, you can determine the name of the remote user who
logged in under the local KOVACS account and the node from which the
login was made, as shown in “Scrutinizing a Suspicious Record”.
Example 10-8 Scrutinizing a Suspicious Record
.
.
.
Security alarm (SECURITY) and security audit (SECURITY) on BOSTON,
system id: 20011
Auditable event: Remote interactive login failure
Event time: 01-JUN-2003 16:06:09.17
PID: 5BC002EA
Username: KOVACS
Terminal name: _RTA14:
Remote nodename: NACHWA Remote node id: 7300
Remote username: FOLLEN
Status: %LOGIN-F-INVPWD, invalid password
.
.
.
Security alarm (SECURITY) and security audit (SECURITY) on BOSTON,
system id: 20011
Auditable event: Remote interactive login
Event time: 01-JUN-2003 16:07:12.39
PID: 5BC002EA
Username: KOVACS
Terminal name: _RTA14:
Remote nodename: NACHWA Remote node id: 7300
Remote username: FOLLEN |
The information displayed in “Scrutinizing a Suspicious Record” indicates
that the login failures and subsequent successful login were made
by user Follen from the remote node NACHWA. Your next step is to determine
whether the security events were generated by user Follen or by someone
who has broken into the remote node NACHWA through the FOLLEN account.
