Audit Policy

Audit Policy

Copyright 1991-2007, Sun Microsystems, Inc

Policy Synopsis

All security relevant operations must be auditable

Contents

• Audit Policy
• Applicability
• Audience
• Background
• Policy
• Advice
• Implementation
• Conformance
• Exemptions
• Appeals
• CaseHistory|
• ManPages|
• References

Overview

Applicability

•  Identification and Authentication (or reauthentication) of Solaris Users. 
•  Introduction of Objects into a user's address space. 
   Examples of objects: file creation/access, new processes, network endpoints, IPC objects, etc, by use of mechanisms such as open(), creat(), exec(), kill(), socket(), etc.
•  Removal of Objects from a user's address space. 
  This includes removal from the system's address space.
•  Actions by computer operators, system administrators, and system security administrators. 
   This is intended to include all configuration of the system and modification of "public information" supplied by the system. System "public information" is contained in objects (kernel data, files, data bases, name service data bases, ...) owned by the system (usually root, bin, sys or other system user) that are readable to all users, and are not modifiable by the normal user (e.g., the system clock, or /etc/*).
   Because the implementation always permits read access to all, read operations on public objects need not be auditable. However, modify operations are considered administrative actions and must be auditable.
•  All other security-relevant events. 
   This is intended to include all operations that use or enforce privilege or authorization, provide access control, directly or indirectly communicate with another process, etc. (e.g., password change, screen lock, modification of public objects, addition, deletion, or modification of user accounts, creation, destruction of encryption keys, access of processes or windows not owned, signal another process).

Audience

Background

 Solaris Trusted Extensions (TX) (and Trusted Solaris before it) is additionally evaluated against the Labeled Security Protection Profile (LSPP).

Policy

• Applies to All Sun administrative and security enforcing software which is delivered with, installed on, or executes on Solaris. The scope of this policy is intended to cover applications, utilities and system calls.
• Authority PSARC
• Approval PSARC/2007/016
• Effective Solaris 2.3
• Policy Software affected by this policy must:
  • generate Solaris Audit Trails,
  • protect those Audit Trails from modification, destruction, and unauthorized access,
  • include information in the Solaris Audit Trail for analysis of the actions taken on the system.
• Details 
   Each audit record in the Solaris Audit trail must be able to answer:
  • What happened?
     This is the audit event defined for this operation. It is defined by and supplied to the "Solaris Audit Infrastructure" by the program/system call.
  • Who is doing this?
     This is the Audit User ID (and TX Process Label) and is generally managed by the "Solaris Audit infrastructure."
  • What is affected? 
     This is supplied to the "Solaris Audit infrastructure" by the program/system call.
  • When did it happen?
     This is handled automatically by the "Solaris Audit infrastructure."
  • Where did it happen?
     This is the Audit Terminal ID and is generally managed by the "Solaris Audit infrastructure."
  • What was the result? Did it succeed or fail and why?
     This is supplied to the "Solaris Audit infrastructure" by the program/system call.

Advice

Implementation

 The majority of the audit for system calls is table driven. New system calls should fit in easily, but do require review by the Solaris Audit Project team to ensure they meet the Evaluation Criteria.

 If the project does administration through smf(5) properties, and the project meets the SMF policy of individual authorizations and delivery of those authorizations in Rights Profiles, administrative audit is generally handled by the SMF framework.

 If the project does administration through CLI where the entire operation is specified on the command line and the project delivers Rights Profiles, administrative audit is generally handled by the RBAC framework.

 If the project does anything security relevant (e.g., authentication, authorization or privilege enforcement, administration) that is not covered by one of the preceding areas, audit must be provided for with the C interfaces described in PSARC/2000/517 and PSARC/2003/397 or their Java equivalents described in LSARC/2001/409.

Conformance

Exemptions

 Note, this possible exemption does not include the administration/configuration of those programs on Solaris.

Appeals

CaseHistory|

Case|=Type|=Name|=Comment

ManPages|

Document|=Description

References

• Common Criteria for Information Technology Security Evaluation (CC):
  •  Common Criteria An Introduction (PDF)
  •  Part 1: Introduction and general model Version 2.3 (PDF)
  •  Part 2: Security functional requirements Version 2.3 (PDF)
  •  Part 3: Security assurance requirements Version 2.3 (PDF)
  •  Part 1: Introduction and general model Version 3.1 (PDF)
  •  Part 2: Security functional components Version 3.1 (PDF)
  •  Part 3: Security assurance components Version 3.1 (PDF)
• Historic Evaluation Criteria:
  •  Department of Defense Trusted Computer System Evaluation Criteria (TCSEC or Orange Book) 
  •  Information Technology Security Evaluation Criteria (ITSEC)
• Audit Specific Guidelines:
  •  NCSC-TG-001v2 A Guide to Understanding Audit in Trusted Systems
  •  NCSC-TG-20-C Trusted Unix Working Group (TRUSIX) Auditing in a Unix System (unpublished TRUSIX document) (PDF)
• Protection Profiles (PP) for Solaris 10 Evaluations:
  •  Controlled Access Protection Profile
  •  Role Based Access Control Protection Profile
  •  Labeled Security Protection Profile 
• Future Protection Profiles:
  •  Single-Level Operating Systems in Medium Robustness Environments PP
  •  Multi-Level Operating Systems in Medium Robustness Environments PP
•  Service Management Framework (SMF) usage
• Rights Profiles/RBAC Framework
  •  Adding RBAC Authorizations
  •  Building RBAC Rights Profiles
  •  suid and rbac authorizations
  •  PSARC/1997/332 Execution Profiles for Restricted Environments