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

secaudit database structure [ See DEFINITION OF TERMS ]

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:

User notification might vary according to 

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
Current count  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:

For a vulnerability not scheduled for check at TIMESTAMP


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.