Skip Navigation Links | |
Exit Print View | |
Oracle Solaris 11.1 Administration: Security Services Oracle Solaris 11.1 Information Library |
1. Security Services (Overview)
Part II System, File, and Device Security
2. Managing Machine Security (Overview)
3. Controlling Access to Systems (Tasks)
4. Virus Scanning Service (Tasks)
5. Controlling Access to Devices (Tasks)
6. Verifying File Integrity by Using BART (Tasks)
7. Controlling Access to Files (Tasks)
Part III Roles, Rights Profiles, and Privileges
8. Using Roles and Privileges (Overview)
9. Using Role-Based Access Control (Tasks)
10. Security Attributes in Oracle Solaris (Reference)
Part IV Cryptographic Services
11. Cryptographic Framework (Overview)
12. Cryptographic Framework (Tasks)
Part V Authentication Services and Secure Communication
14. Using Pluggable Authentication Modules
17. Using Simple Authentication and Security Layer
18. Network Services Authentication (Tasks)
19. Introduction to the Kerberos Service
20. Planning for the Kerberos Service
21. Configuring the Kerberos Service (Tasks)
22. Kerberos Error Messages and Troubleshooting
23. Administering Kerberos Principals and Policies (Tasks)
24. Using Kerberos Applications (Tasks)
25. The Kerberos Service (Reference)
Part VII Auditing in Oracle Solaris
How to Plan Who and What to Audit
How to Plan Disk Space for Audit Records
Because auditing consumes system resources, you must control the degree of detail that is recorded. When you decide what to audit, consider the following costs of auditing:
Cost of increased processing time
Cost of analysis of audit data
If you are using the default plugin, audit_binfile, you must also consider the storage cost of audit data.
The cost of increased processing time is the least significant of the costs of auditing. The first reason is that auditing generally does not occur during computation-intensive tasks, such as image processing, complex calculations, and so forth. If you are using the audit_binfile plugin, another reason is that audit administrators can move the post-selection tasks from the audited system to systems that are dedicated to analyzing audit data. Finally, unless kernel events are preselected, the audit service has no measurable impact on system performance.
The cost of analysis is roughly proportional to the amount of audit data that is collected. The cost of analysis includes the time that is required to merge and review audit records.
For records that are collected by the audit_binfile plugin, cost also includes the time that is required to archive the records and their supporting name service databases, and to keep the records in a safe place. Supporting databases include groups, hosts, and passwd.
The fewer records that you generate, the less time that is required to analyze the audit trail. The sections Cost of Storage of Audit Data and Auditing Efficiently describe ways to audit efficiently. Efficient auditing reduces the amount of audit data, while still providing enough coverage to achieve your site's security goals.
If you are using the audit_binfile plugin, storage cost is the most significant cost of auditing. The amount of audit data depends on the following:
Number of users
Number of systems
Amount of use
Degree of traceability and accountability that is required
Because these factors vary from site to site, no formula can predetermine the amount of disk space to set aside for audit data storage. Use the following information as a guide:
Understand the audit classes
Before you configure auditing, you should understand the types of events that the classes contain. You can change the audit event-class mappings to optimize audit record collection.
Preselect audit classes judiciously to reduce the volume of records that are generated.
Full auditing, that is, with the all class, fills disk space quickly. Even a simple task such as compiling a program could generate a large audit file. A program of modest size could generate thousands of audit records in less than a minute.
For example, by omitting the file_read audit class, fr, you can significantly reduce audit volume. By choosing to audit for failed operations only, you can at times reduce audit volume. For example, by auditing for failed file_read operations, -fr, you can generate far fewer records than by auditing for all file_read events.
If you are using the audit_binfile plugin, efficient audit file management is also important. For example, you can compress a ZFS file system that is dedicated to audit files.
Develop a philosophy of auditing for your site.
Base your philosophy on sensible measures. Such measures include the amount of traceability that your site requires, and the types of users that you administer.