| Solaris Security Toolkit 4.2 Administration Guide |    
|
| Solaris Security Toolkit 4.2 Administration Guide |
|
| C H A P T E R 6 |
|
Auditing System Security |
This chapter describes how to audit (validate) a system's security using the Solaris Security Toolkit software. Use the information and procedures in this chapter for maintaining an established security profile after hardening. For systems that are already deployed, you might want to use the information in this chapter to assess security before hardening.
This chapter contains the following topics:
Maintaining security is an ongoing process that must be reviewed and revisited periodically. Maintaining a secure system requires vigilance, because the default security configuration for any system tends to become increasingly open over time. (For more information about maintaining security, see Maintaining System Security.)
Solaris Security Toolkit provides an automated method to audit the security posture of a system, by determining its level of compliance with a specified security profile.
|
Note - This method is only available in stand-alone mode using the jass-execute -a command and cannot be used during a JumpStart installation. |
Audit the security posture of your systems periodically, either manually or automatically (for example, via a cron job or an rc script). For example, after hardening a new installation, execute the Solaris Security Toolkit software audit command (jass-execute -a driver-name) five days later to determine if the system security has changed from the state defined by the security profile.
How often you audit security depends on your security policy and the criticality of the environment. Some users run an audit every hour, every day, or only once a month. Other users run a mini-scan (limited number of checks) every hour, and a full scan (with all the possible checks) once a day. Your security posture should definitely be checked after every system reboot in addition to other audits you do routinely.
Audit all essential components to maintain the security posture of deployed systems. If your security posture is not periodically audited, then configurations often drift over time due to entropy or modifications that unknowingly or maliciously change the desired security posture. Without periodic review, these changes go undetected and corrective measures are not taken. The result is a system that becomes less secure and more vulnerable.
In addition to periodic audits, perform audits after upgrades, patch installations, and other significant system configuration changes.
In some cases, you might find it useful to review the security posture on deployed systems before hardening them. For example, if you assume responsibility for deployed systems that another person administrated, inspect the state of the systems so that you know their posture and, if necessary, can bring them into compliance with the same security profiles used on your other systems.
The audit option provides a highly flexible and extensible mechanism for evaluating the state of a system. As with hardening scripts, you can customize the actions of audit scripts. For example, you can customize environment variables, customize framework and helper functions, add new checks, and add functionality to the audit framework.
Most users find that the standard and product-specific audit scripts are suitable as templates from which to customize auditing for their environments. For this scenario, customize audit script actions through drivers, finish scripts, environment variables, and file templates. These custom changes can be made with little effort and without modifying the code. Whatever changes you make for hardening are automatically known by the Solaris Security Toolkit software when you perform auditing.
Some users need to create entirely new proprietary, or site-specific, drivers and scripts. Use the templates and samples as guidelines when coding the new drivers and scripts. Be advised that site-specific drivers, finish scripts, variables, and functions are not automatically known to the Solaris Security Toolkit software when you use the audit option. For example, if you add a site-specific driver named abcc-nj-secure.driver that contains a site-specific finish script, abcc-nj-install-foo.fin, then you need to create a site-specific audit script, abcc-nj-install-foo.aud. Similarly, if you start with only the audit script, you should create the matching finish script.
Occasionally, users find it necessary to add checks or functionality that the Solaris Security Toolkit software does not provide. For this scenario, add the checks or new functionality to the audit script. (You might want to make related changes in the corresponding finish script.) Use extreme care when performing code additions and modifications through the user.run file to avoid introducing bugs and failures.
To customize or create new drivers, scripts, variables, and functions, refer to the Solaris Security Toolkit 4.2 Reference Manual.
For example, you might need to add a patch that the Solaris Security Toolkit software does not install. You can extend one of the standard or product-specific templates, or you can create your own. If you create your own templates, create a finish script to add the patch, then create the corresponding audit script to check for the patch installation.If you use existing finish (.fin) and audit (.aud) scripts as your templates, you must copy both the scripts to new and uniquely named files.
To use the instructions and guidelines in this chapter, you need a security profile. For information about developing and implementing a security profile, see Chapter 2.
A variety of security profiles are included with the Solaris Security Toolkit distribution as drivers. As mentioned earlier in this book, the default security profiles and changes made by them might not be appropriate for your systems. Typically, the security profiles implemented are "high-water" marks for security. By this, we mean that they disable services that are not required, and they enable optional security features disabled by the secure.driver.
Many Solaris Security Toolkit software users find that the standard and product-specific security profiles are acceptable for their environments. If this applies to your situation, then determine which security profile is closest to the security posture you want, and use it for both assessing and hardening your systems.
Review and customize the security profile templates for your environment, or develop new ones. Techniques and guidelines for customizing security profiles are provided in the Solaris Security Toolkit 4.2 Reference Manual. This approach provides a security posture tailored for your organization, and it minimizes the number of false errors returned during a security assessment. For example, if you know that Telnet needs to be enabled, you can customize the security profile so that when performing a security assessment, the software does not consider Telnet a vulnerability. Thus, a site using Telnet with Kerberos, for authentication and encryption, would not consider the use of Telnet a vulnerability.
This section describes the options available for executing an audit run and the options for controlling output. This section contains the following topics:
The following command-line synopsis shows how to audit a system against a security profile:
When executing the Solaris Security Toolkit software audit command, you can use the options listed in TABLE 6-1.
For detailed information about the options available with jass-execute -a command, see the following sections:
The -h option displays the jass-execute help message, which provides an overview of the available options.
The -h option produces output similar to the following:
The -m email-address option provides a mechanism by which output can be emailed automatically by the Solaris Security Toolkit software when the run completes. The email report is in addition to any logs generated on the system using other options.
A Solaris Security Toolkit run calling sunfire_15k_sc-config.driver using the email option would be similar to the following:
The -o output-file option redirects the console output of jass-execute runs to a separate file, output-file.
This option has no effect on the logs kept in the JASS_REPOSITORY directory. This option is particularly helpful when performed over a slow terminal connection, because there is a significant amount of output generated by a Solaris Security Toolkit run.
This option can be used with either the -d, -u, or -a options.
The -o option produces output similar to the following:
# ./jass-execute -o jass-output.txt -a secure.driver [NOTE] Executing driver, secure.driver [NOTE] Recording output to jass-output.txt # |
The -q option disables Solaris Security Toolkit output to a standard input/output (stdio) stream during a hardening run.
This option has no effect on the logs kept in the JASS_REPOSITORY directory. Similar to the -o option, this option is particularly helpful when running the Solaris Security Toolkit software through a cron job or over slow network connections.
This option can be used with either the -d, -u, or -a options.
The -q option produces output similar to the following:
# ./jass-execute -q -a secure.driver [NOTE] Executing driver, secure.driver |
The -V option specifies the verbosity level for an audit run. This option is only available for auditing. Verbosity levels provide a highly flexible way of displaying the results of an audit run. For example, if you have 100 machines to audit, you might want to limit the output to a single line for each machine to simply determine which machines pass or fail. Then, for the machines that fail, you might want to run an audit that produces expanded output, to focus on the problem areas.
The five verbosity levels (0 through 4) are controlled by the -V option. Each incremental level provides additional detail that you can use to more fully understand which checks are passing and which are failing. TABLE 6-2 describes the verbosity levels.
|
Note - The default verbosity level for the jass-execute -V command is 3. |
For complete descriptions of the audit verbosity levels, refer to the jass-execute man page or "JASS_VERBOSITY" in Chapter 7 of the Solaris Security Toolkit 4.2 Reference Manual.
You can configure the Solaris Security Toolkit audit option to report or omit banners and messages. The JASS_LOG_BANNER variable cannot be used with verbosity levels 0 through 2. These output options apply to verbosity levels 3 and 4. For example, you might want to eliminate pass messages (JASS_LOG_SUCCESS variable) from the output so you can report and focus only on fail messages (JASS_LOG_FAILURE variable).
TABLE 6-3 lists the banners and messages that you can control through logging variables. (For detailed information about logging variables, refer to "JASS_LOG_BANNER" in Chapter 7 of the Solaris Security Toolkit 4.2 Reference Manual. For more information about verbosity levels, refer to the jass-execute man page or "JASS_VERBOSITY" in Chapter 7 of the Solaris Security Toolkit 4.2 Reference Manual.) If the logging variable is set to 0, then no output is generated for messages of that type. Conversely, if the logging variable is set to 1, then messages are displayed. The default action for each of these variables is to display the output. TABLE 6-3 describes the logging variables.
Using these options is very useful when you need to view specific messages only. By setting these options, you can minimize output, yet still focus on areas you deem critical. For example, by setting all logging variables to 0 except for JASS_LOG_FAILURE (leave it at the default of 1), the audit reports only on failures generated by the logFailure function.
You can configure the Solaris Security Toolkit audit option to include host name, script name, and timestamp information for verbosity levels 0 through 2. For example, if you have many machines to audit, you might want to be able to sort the output by host name, script name, or timestamp. TABLE 6-4 lists the variables.
By configuring the Solaris Security Toolkit software to prepend host, script, and timestamp information, you can combine many runs from either a single system or group of systems and sort them based on the key data. You can use the information to look for problems that span several systems or that are symptomatic of deployment processes. For example, using the information in this way, an administrator can tell if every system built using a given process always has the same failed checks.
By setting the JASS_DISPLAY_TIMESTAMP parameter to 1 and setting the JASS_DISPLAY_SCRIPTNAME value at 0, output similar to the following is generated.
Performing a security assessment periodically on your systems provides a benchmark of how closely the security matches the security profile you implemented. The most common scenario for performing security assessments is as a security maintenance task sometime after hardening new installations. The security assessment option is designed so that you simply execute the same hardening drivers that you used to harden the system, but now you use the -a option to check the current state compared to the security profile implemented during hardening. This design eliminates complexity and provides flexibility. For example, when you update your security profile, subsequent security assessments use the updated security profile.
In another possible scenario, you might be responsible for securing systems that are already deployed. Before you harden them, you want to perform a security assessment. In this scenario, you would define your own security profile, customize a Solaris Security Toolkit security profile template, or use one of the security profile templates as is.
|
Before performing an audit, you need to define or choose a security profile. For more information, see Preparing to Audit Security.
1. Choose the security profile (hardening driver) that you want to use:
For example, secure.driver or abccorp-secure.driver.
For a complete and up-to-date listings and information about available standard and product-specific drivers, refer to the security_drivers man page or Chapter 4 in the Solaris Security Toolkit 4.2 Reference Manual.
2. Determine the command-line options you want and how you want to control the output.
See Using Options and Controlling Audit Output.
3. Enter the jass-execute -a command, the name of the security profile, and the options you want.
The following is a sample audit run using the abc-secure.driver.
When an audit run is initiated, the Solaris Security Toolkit software accesses files from the JASS_HOME_DIR/Audit directory. Although the files in both the JASS_HOME_DIR/Audit and JASS_HOME_DIR/Finish directories share the same base file names, they have different file name suffixes. The driver.run script automatically translates the finish scripts defined by the JASS_SCRIPTS variable into audit scripts, by changing their suffixes from .fin to .aud along with pointers to files containing all messages generated at each alert level during the run.
The audit run starts and initializes the state of the Solaris Security Toolkit software. Each driver that is accessed during the run evaluates the state of all of its file templates and audit scripts. Each check results in a state of success or failure, represented by a vulnerability value of either zero or nonzero, respectively. In most cases, failure is represented by a number 1. Each script that is run produces a total security score, based on the total vulnerability value of each check contained within a script. The total vulnerability value result for each driver is displayed at the completion of a driver's assessment. A grand total of all scores is presented at the end of the run.
The security assessment option provides a comprehensive view of the state of a system at the time the assessment run is initiated. The Solaris Security Toolkit software checks the stored state of the system by inspecting configuration files and checks the running state of the system by inspecting process table information, device driver information, and so on. The Solaris Security Toolkit software checks for the existence of each file or service, and checks if the software associated with a service is installed, configured, enabled, and running. This approach yields an accurate snapshot of the current state of a system.
| Solaris Security Toolkit 4.2 Administration Guide | 819-1402-10 |
|
Copyright © 2005, Sun Microsystems, Inc. All Rights Reserved.
To Perform a Security Audit
