secaudit-database(1)

secaudit-database(1) | Security Audit Application | secaudit-database(1)

## NAME

> secaudit-database -- audit report database manager

## SYNOPSIS

> secaudit-database [-logroot log-root -auditname audit-name] [-readdb read-db -writedb write-db]

## OPTIONS

> -auditname audit-name |  | Use audit-name as the name of the supported audit, e.g. tiger, tara, or secaudit (default)
> -logroot log-root |  | Use log-root as the directory path the host log area; default is /var/log (SunOS, Linux), /var/adm (IRIX)
> -readdb read-db |  | Use read-db as pathname of database to read, e.g. /var/log/tiger/Database
> -writedb write-db |  | Use write-db as pathname of database to write, e.g. /var/log/tiger/Database

## DEFINITION OF TERMS

> AUDIT_NAME
>   Name of supported audit tool, e.g. tiger, tara, uds/secaudit.
> LOG_ROOT
>   Log area of host OS; e.g. /var/log on SunOS and Linux, /var/adm on IRIX
> REPORTDB
>   Directory holding audit reports. The default value is the value of LOG_ROOT/AUDIT_NAME, e.g. /var/log/uds/secaudit
> READDB
> WRITEDB
>   Log area for reading/writing security audit database entries. The default is the value of LOG_ROOT/AUDIT_NAME/Database, which is /var/log/uds/secaudit/Database on Linux and Solaris, and is /var/log/uds/secaudit/Database on IRIX. Using different names for reading and writing is useful in testing and debugging.
> TIMESTAMP
>   String in date(1) format +%Y.%m.%d.%H.%M.%S, i.e. (in Perl lingo)

>       $TIMESTAMP =~ /^(\d\d\d\d)\.(\d\d)\.(\d\d)\.(\d\d)\.{\d\d)\.(\d\d)$/;
>       ($year,$month,$day,$hour,$min,$sec) = ($1,$2,$3,$4,$5,$6);

> LASTREPORT
>   The TIMESTAMP of the latest audit report found in LOG_ROOT/AUDIT_NAME secaudit-database writes database entries for the report for LASTREPORT into WRITEDB/LASTREPORT.
> VCODE
>   Tiger/Tara/Secaudit vulnerability code matches /^[A-Za-z][A-Za-z0-9]+$/
> VMSG
>   Summary message for vulnerability. Each report line read from the report file for LASTREPORT has the form `[VCODE] VMSG
> VLEVEL
>   Severity level matches /^[HMLIZ]$/ . High | Medium | Low | Information | Unclassified (Internal error)
> VSUM
>   UNIX check sum of database file. Used to distinguish vulnerabilities with the same VCODE. ( e.g. if sum(1) of the file is "123456 1", then VSUM is "1234561")
> VAGE
>   Age of an audited vulnerability in recorded in the database, roughly counted in days: a year has 365 days, a month has 30 days.
> VFILE
>   Name of vulnerability database file has the form VCODE.VSUM.VLEVEL.VAGE. The database file VFILE contains the line `[VCODE] VMSG from the VLEVEL section of the audit report file for LASTREPORT. The full path name of the VFILE is WRITEDB/LASTREPORT/VFILE

## DESCRIPTION

> secaudit-database post-processes audit reports from a tiger(1) `style' security audit tool and creates a vulnerability report database.

> ### tiger style audit reports

> - audit report files are named in the form `AUDIT_NAME.report.TIMESTAMP` where AUDIT_NAME is a name indicating the audit tool (e.g. tiger, tara, secaudit), and TIMESTAMP is the time of the audit represented in the date(1) format '+%Y.%m.%d.%H.%M.%S'.
> - Each report file `AUDIT_NAME.report.TIMESTAMP` contains report lines in the form

>   > --severity-code-- [vulnerability-code] audit-message

>   for example,

>   `--WARN-- [root001w] Remote root login allowed in /etc/ssh/sshd_config```

>   [See BUGS, 1.].

> ### secaudit database structure [ See DEFINITION OF TERMS ]

> - secaudit-database uses the UNIX file system to represent successive audits and the current audit state of the host system.
> - The database root directory AUDITDB is typically in the host log area, e.g. /var/log/secaudit/Database.
> - Entries representing each audit are stored under the TIMESTAMP of the audit, e.g. for the audit report AUDIT_NAME.report.TIMESTAMP, secaudit-database creates the database directory /var/log/AUDIT_NAME/Database/TIMESTAMP.
> - Corresponding to the vulnerability reported by the audit as `[VCODE] VMSG', secaudit-database creates the file named VCODE.VSUM.VLEVEL.VAGE in the directory /var/log/AUDIT_NAME/Database/TIMESTAMP and containing the report line `[VCODE] VMSG'. VLEVEL and VAGE are, respectively, the severity level and the age of the vulnerability. VSUM is a check-sum used to disambiguate reports with the same VCODE but different VMSG text. These parameters are discussed further in the next section.

> ### secaudit-database actions

> 1. Checks for latest audit report.
>    When the latest report is AUDIT_NAME.report.LASTREPORT and the database directory AUDITDB/LASTREPORT already exists, takes no further action.
> 2. Creates database files.
>    When a new AUDIT_NAME.report.LASTREPORT is found,
>    1. creates new database directory AUDITDB/LASTREPORT
>    2. reads audit report lines from AUDIT_NAME.report.LASTREPORT
>    3. extracts each report line `[VCODE] VMSG', assigns the report a VLEVEL based on the context of the report file, and computes a disambiguating VSUM for the report line.
>    4. populates AUDITDB/LASTREPORT with files VCODE.VLEVEL.VSUM.0.
>       (Note that every file at this stage has a default age of 0).
> 3. Computes vulnerability ages.
>    Locates the previous audit database, if any, in AUDITDB/PREVREPORT. If there is no previous audit, each report in the current audit retains the default age of 0.
>    For each vulnerability report file, AUDITDB/PREVREPORT/VCODE.VSUM.VLEVEL.VAGE, handles three cases:
>    1. Resolved Vulnerability
>       If there is no corresponding AUDITDB/LASTREPORT/VCODE.VSUM.VLEVEL.0 in the new audit database then assumes VCODE.VSUM.VLEVEL represents a vulnerability that has been resolved since the audit at PREVREPORT and ignores it.
>    2. Unresolved Vulnerability
>       Renames the corresponding file VCODE.VSUM.VLEVEL.0 in WRITEDB/LASTREPORT, to VCODE.VSUM.VLEVEL.NEWAGE where NEWAGE is VAGE plus the NUMBER_OF_DAYS between PREVREPORT and LASTREPORT.
>    3. New Vulnerability
>       The new vulnerabilities are those that remain with the VAGE of 0 in WRITEDB/LASTREPORT.

## DISCUSSION

> ### Data Integrity

> The 'report-database' manager NEVER writes to any database file after the initial creation and naming. Each file is set to mode 444, and, until it is deliberately removed by garbage collection, has the same life expectancy as the host system disk. In case of disk replacement, reformatting, or system upgrade it is appropriate to restart the host's security audit history.

> ### Database `memory'

> The audit report database structure described here retains the following information:

> 1. Audit history
>    The directories database root LOG_ROOT/AUDIT_NAME/Database are each named with the TIMESTAMP of a past security audit performed on the host system.
> 2. Active vulnerability records
>    Each file TIMESTAMP/VCODE.VSUM.VLEVEL.VAGE contains, in a single line, the vulnerability code, VCODE, and summary VMSG of a vulnerability reported by the audit taken at TIMESTAMP.
> 3. New vulnerability records
>    The new vulnerability records have a VAGE of 0.
> 4. Unresolved vulnerability records
>    An unresolved vulnerability record has a positive VAGE which represents, roughly, the number of days between the first audit reporting the vulnerability and the most recent audit.
> 5. Resolved vulnerabilities
>    Vulnerabilities that have been resolved during the time between the MostRecentAudit and the PreviousAudit are recorded in the Database/PreviousAudit but are absent from the Database/MostRecentAudit and are forgotten thereafter unless they they reoccur.
> 6. Security Audit report data
>    The files in Database/TIMESTAMP contain all information needed to (re)write the original security
>    audit report file AUDIT_NAME.report.TIMESTAMP.

> ### Garbage collection

> Repeated use of a report generating audit tool raises two undesirable "garbage collection" issues for the administrator of the host system:

> #### Garbage collection issues

> 1. report files accumulate
> 2. consecutive audit reports may have identical report lines

> These issues also apply to the audit database managed by secaudit-database. Using the `memory' properties of the audit database listed in the previous section, we can state policy assumptions that lead to a rational plan for garbage collection.

> #### Security policy assumptions

> 1. In support of network and host security at an audited site, we focus on the present security state of a host system, including a description of each reported vulnerability, the severity and the `age' of the vulnerability.
> 2. In support of network and host security at an audited site, a complete history over time of reported vulnerabilities and their resolution is expendable.(The operational assumption here is that we don't need to keep a history of the behavior of security administrators.)

> #### Garbage collection plan

> 1. After each Database/MostRecentTIMESTAMP is created, remove the contents of Database/PreviousTIMESTAMP .
>    Since the content of the most recent Database/TIMESTAMP describes the security state of the host at the time of that audit, the contents of the database describing previous audits are no longer useful. It might be prudent to keep the two most recent audit database contents. It might also be useful to retain the (empty) TIMESTAMP directories which provide a record of recent audit dates.
> 2. Remove any Database/TIMESTAMP directory that is older than the largest `age' of the most recently reported vulnerabilities.
>    The `older' audit history is not relevant to the active vulnerabilities.

> ### Support for audit notification scheduling

> Database/TIMESTAMP saves two parameters for each vulnerability report that can be used to control notification:

> - The severity level H | M | L | I
> - The age in days of the vulnerability
> User notification might vary according to
> - Selecting which reports warrant notification (e.g. 'H' report always, 'L' report never )
> - Frequency of notification (e.g. every day, once a week, ...)
> - Duration of notification (e.g. 3 consecutive notices each week, month .. )
> - Selecting notification recipients (e.g. system owner always, supervisor only for aged reports)
> - "Tone" of the notification text (e.g. "You may want to consider using the security best practices described in the explanation of these 'L' or 'I' reports", or "Hey, Jack! Your root password has been empty for X hours. Set your root password within (1,2,4,8) hours or we pull your network connection.)

> ### Assessment of security compliance effort

> As an example of how the audit database might support a security compliance mission by enabling assessment of complience effort: Periodic summary reports to a security manager in the form:

> > Severity Level | H | M | L
> > Current count | 4 | 10 | 12
> > Oldest (days) | 100 | 24 | 45

> A consistent pattern of aging 'H' vulnerabilities might be viewed as negligent non-compliance by some security managers.

> ### Extension to scheduled audits

> A scheduled audit is a regime of audits performed according to a cron(1m) schedule. A scheduled audit can consist of a rotating list of partial audits. For example, audits directed to intrusion detection might be performed a number of times each day while a general vulnerability audit might be performed once a day.

> The algorithm used by secaudit-database can be easily adjusted to accomodate scheduled audits by changing the vulnerability aging rule.

> For a vulnerability scheduled for check at TIMESTAMP:

> - Apply rules for Resolved, Unresolved, and New vulnerabilities as already described.

> For a vulnerability not scheduled for check at TIMESTAMP

> - Treat the unscheduled vulnerability as unresolved, compute its new age
> - Copy the vulnerability file from the previous database to Database/TIMESTAMP.
> - Rename the unscheduled vulnerability file in Database/TIMESTAMP to reflect the new age and its unscheduled status

## PRIVILEGE

> secaudit-database requires UNIX root priviledge.

## FILES

> /afs/.nih/uds/
>   The root directory of the UDS database area is a mount point for the replicated volume root.uds.

## SEE ALSO

## BUGS

> 1. tiger(1) style vulnerability reports not supported

>    Instead of reading vulnerability reports in the tiger(1) style form

>    > `--WARN-- [root001w] Remote root login allowed in /etc/ssh/sshd_config`

>    secaudit-database accepts the secaudit style form

>    > `[root001w] Remote root login allowed in /etc/ssh/sshd_config`

>    assumes the vulnerability report lines are grouped by severity code, and computes the severity code H | M | L | I from the context of the report file.

> 2. The assignment of a secaudit style severity code [HMLI] with a tiger(1) style severity code -- ERROR, FAIL, WARN, ... -- is performed by means of a translation table external to secaudit-database. This assignment is not reversible.

> 3. In some cases, tiger(1) may assign a vulnerability code to more than one vulnerability report. This creates an ambiguity for secaudit-database which, for the purpose of vulnerability aging, must recognize a unique identity for a vulnerability report from one audit to the next.

## AUTHOR

>     Sanford M. Orlow, Computer Engineer
>     Center for Information Technology, National Institutes of Health
>     12 South Dr. 12B/2N207 MSC-5680 , Bethesda, MD 20892-5680
>     PHONE 301.496.5362 FAX 301.496.0223 EMAIL sandor@mail.nih.gov

## LICENSE

>     THIS SOFTWARE FITS THE DESCRIPTION IN THE U.S. COPYRIGHT ACT OF A
>     "UNITED STATES GOVERNMENT WORK".  IT WAS WRITTEN AS A PART OF THE
>     AUTHOR'S OFFICIAL DUTIES AS A GOVERNMENT EMPLOYEE.  THIS MEANS IT
>     CANNOT BE COPYRIGHTED.  THIS SOFTWARE IS FREELY AVAILABLE TO THE
>     PUBLIC FOR USE WITHOUT A COPYRIGHT NOTICE, AND THERE ARE NO
>     RESTRICTIONS ON ITS USE, NOW OR SUBSEQUENTLY.