Implementing C2 Auditing in the Solaris Environment

The C2 auditing facility provided in Solaris 2.x is often overlooked, despite the added system security that it can provide. In its absence, administrators often rely on application-level audit trails, such as syslog, for their primary source of security audit data. Unfortunately, these audit trails lack much of the security-relevant data that is normally found in a C2 audit trail. In this article, I will discuss C2 auditing and provide instructions and tips for implementing it in the Solaris 2.x environment. I will also present the BSM event Viewer application, which was written by the same authors to simplify Solaris C2 audit trail analysis.

What is C2 Auditing?

The C2 security rating was originally defined in the Trusted Computer System Evaluation Criteria (TCSEC), published by NCSC (National Computer Security Center) in the early eighties. Commonly referred to as the Orange Book because of the report's orange cover, TCSEC set forth to provide criteria for judging the effectiveness of the security controls built into operating systems. It defined four general divisions of security: D (Minimal Protection), C (Discretionary Protection), B (Mandatory Protection), and A (Verified Protection). The complete set of ratings from least to most effective are: D, C1, C2, B1, B2, B3, A1.

Most commercial operating system today are certified at the C2 level, and this is generally regarded as the lowest acceptable level of security. Among other criteria, a C2-compliant system must be able to provide a system-level audit trail. Specifically, C2 systems must be able to audit the use of identification and authentication mechanisms, the introduction of objects into a users address space (such as file opens and program initiation), the deletion of objects, and administrative actions (such as user account administration, mounts, reboots, etc.)