I-0273: Auditing of Delayed Execution Jobs

NUMBER:               I-0273
STATUS:               Sent to CCEVS Management and CCIMB for Review

TITLE:                Auditing of Delayed Execution Jobs

FIRST POST:            [criteria 1888]
MOST RECENT REPOST:    [criteria 2254]

REQUIREMENT:          Identification and Authentication
CRITERIA CLASSES:     C2, B1, B2, B3, A1
DOCUMENT(S):          <None>
RELATED TO:
     I-0277           Audit of security database changes

STATEMENT:

The following interprets the requirement that ``The TCB shall also provide the capability of associating this identity with all auditable actions taken by that individual.''

For delayed execution jobs run on behalf of an identified user, the TFM shall specify a procedure or the TCB shall provide a mechanism (or both) for associating the auditable actions taken by the job with that identity.

PROJECTED IMPACT:

For some products, procedures may need to be specified in documentation.

SUPPORT:

There are four potential cases related to delayed execution jobs: (1) jobs running on behalf of the TCB; (2) jobs running on behalf of the administrator; (3) jobs submitted by a privileged user for another user; (4) jobs submitted by any non-privileged user.

For the first case, the delayed execution jobs and the corresponding scheduling database could be viewed as administrative databases. As a result, #0277 would require that changes to these administrative databases be auditable, thus providing the chain of evidence to trace the actions taken by a delayed execution job back to the responsible individual.

For the second and fourth cases, this interpretation is applicable. The product must provide, either procedurally or automatically, accountability to the individual responsible for the job.

For the third case, the actions that enable the job to be submitted under a different identity should be audited: either as a use of privilege or as a successful identification and authentication action. The actions taken by the delayed execution job are covered by this interpretation. The product must provide, either procedurally or automatically, accountability to the individual responsible for submission of the job.

It should be noted that there are many ways to define delayed execution jobs: submission for delayed execution (UNIX at and crontab, Multics absentee), mail processing filters (UNIX vacation, mail preprocessing programs). In some cases, the delay is time-based; in others, it is receipt of a message or a protocol request.

At minimum, the TFM should provide administrators with procedures necessary to associate that job with an appropriate individual responsible for the action taken by the job. This association could be procedural (e.g., ``All actions taken by the administrator during third shift are accountable to the third shift manager''--that is the person whose job is on the line). This association may also be done using audit log history, but this may be difficult as in some cases, the IDs in the audit log may be pseudo-IDs. However, automated association of the individual with the delayed execution job is a laudable goal, and should be acknowledged if achieved.