Design. Syntactic Issues

Transcription

1 Design A single unified logging process is an essential component of computer security mechanisms. The design of the logging subsystem is an integral part of the overall system design. The auditing mechanism, which builds on the data from the logging subsystem, analyzes information related to the security state of the system and determines if specific actions have occurred or if certain states have been entered. The goals of the auditing process determine what information is logged. In general, the auditors desire to detect violations of policy. The goal of the auditing is to determine if the policy has been violated, causing a breach of security. The Bell-LaPadula model clearly prohibits a subject at a lower security level reading objects at a higher security level, and it also prohibits a subject at a higher security level from writing an object at a lower security level. Auditing in a computer system that implements the Bell-LaPadula model requires auditing for such writes and reads. Logs must contain the security levels of the subjects and objects involved, the action taken to determine which constraint applies, and the result of the action, success or failure. From such logs testing for the violations of the constraints is very straight-forward. Surprisingly, the names of the subjects and objects do not need to be recorded. In practice, the site s security policy would most likely require the security analyst to identify both the subject and object of any violation. Hence, the auditing of reads and writes in a Bell-LaPadula-based system would require logging the subject s name, the subject s security level, the object s name, the object s security level, and the result of the action. The time of such action would also most likely be recorded. What does write mean? Append Create directory Altering protection mode Setting system clock etc If the security policy said that all writes to a file must be audited, what do you audit? In the UNIX operating system there are 2 ways to write to a file. 1. Access through file system - easy to log 2. Low-level raw disk device - typically not logged Syntactic Issues One critical issue is how to log. What data should be placed into the log file? How should that data be expressed to allow an audit to draw conclusions that can be justified through reference to the log? By having the right information in the log file, an analyst can justify her reasoning about conclusions that are drawn from the log file. A major problem is that many systems log data ambiguously or do not present enough context to determine what the elements of the log entry refer to.

2 A Unix system logs the names of the files that a user retrieves using ftp. Suppose that the log contains the file name /etc/passwd or /etc/shadow. This may or may not be bad. If the user is anonymous, indicating an anonymous ftp login, then the file actually retrieved is the password file for the anonymous ftp server, not the system s password file. Explain how anonymous ftp is set up. This example demonstrates that a single log entry may not contain all of the information needed about a particular action. In this case, the context of the log entries conveys important information. An analysis program would benefit from analyzing the context as well as the entries. Log Sanitization A site may consider some of its information confidential. Audit logs may contain some of this information. Hence, if a site wants to make audit logs available, it must delete the confidential information. Let U be a set of users. The policy P defines a set of information C(U) that members of U are not allowed to see. Then the log L is sanitized with respect to P and U when all instances of information in C(U) are deleted from L. Confidentiality policies may impact audit logs in two distinct ways. First, P may forbid the information to leave the site. The audit log may contain file names that give an indication of propriety projects or enable an industrial spy to determine the IP addresses of machines containing sensitive information. In this case the unsanitized audit logs are available to the site administrators. Second, P may forbid the information from leaving the system. In this case, the goal is to prevent the system administrators from spying on the users. Many times, privacy considerations affect the policy. Laws may allow the system administrators to monitor users only when they have some specific reason to believe that that user is attacking the system or engaging in illegal activities. In such cases, when the site administrators do look at the logs, the site must protect the privacy of the other users so that the investigators cannot determine what activities the unsuspected users are doing. An anonymizing sanitizer deletes information in such a way that it cannot be reconstructed by either the recipient or the originator of the data in the audit log. The figure below depicts the audit log file being sanitized for external viewing. This protects company confidentiality because the external viewers are denied information that the company wishes to keep confidential. However, it does not protect users privacy because the site administrators has access to the unsanitized log.

3 A pseudonymizing sanitizer deletes information in such a way that the originator of the audit log can reconstruct the deleted information. The figure below depicts the audit log file being sanitized for the privacy of the user because the data is sanitized before it is written to the audit log. The system administrators cannot determine the true value of the sanitized data because it is never written to the log file. If the system administrators must be able to recover the data at some future point to satisfy a court order, the sanitizer can use cryptography to protect the data by using a cryptographic scheme allowing a reidentifier to reassemble the unsanitized data. Application and System Logging Application audit logs consist of entries made by the application. These entries describe the problems encountered by the application. For example, su: bishop to root on /dev/ttypo smtp: delivery failed: could not connect to mail.host:25 These logs usually do not include detailed information about the system calls that are made, the results that are returned, or the sequence of events leading up to the log entry. System logs consist of entries of kernel level events. These entries do not include high-level information. They report system calls and events. The difference in the two logs is their focus. If the audit is to focus on application events, such as a failure to provide a correct password or failure to deliver , an application log provides a simple way of recording the events for later analysis. If system events such as file access or memory mapping affect the outcome of the auditing, then system logging is appropriate. In some cases audits using both logs can uncover the system events leading up to an application event. By understanding the events at both the system and application levels, the auditor can learn about the causes of failures and determine if they are the results of attempts to breach system security. Posteriori Design In this situation we have a system in which the auditing component is not designed into it. Most security breaches arise on existing systems that were not designed with security considerations in mind. In this case auditing may have two different goals. The first goal is to detect any violations of a stated policy. The second goal is to detect actions that are known to be part of an attempt to breach security. The first goal focuses on the security policy and records attempted actions that violate the security policy. The second goal focuses on specific actions that the managers of the system have determined indicate behavior that poses a threat to system security. Thus, one approaches the first goal by examining the desired policy while one approaches the second goal by examining the actions that pose a threat to the system.

4 Auditing to Detect Violations of a Known Policy The idea is to determine whether or not a state violates the security policy. Unlike mechanisms designed into the system, the auditing mechanisms must be integrated into the existing system. There are two approaches to this situation: 1. State-based auditing 2. Transition-based auditing State-Based Auditing In this approach states of the system are analyzed to determine if a policy violation exists. A state-based logging mechanism records information about a system s state. A state-based auditing mechanism determines whether or not a state of the system is unauthorized. With state-based auditing you are basically taking a snapshot of the system. The HP B2 system did this at startup. Transition-Based Auditing In this approach actions that could violate the policy are checked to determine if they do indeed cause violations. A transition-based logging mechanism records information about an action on a system. A transition-based auditing mechanism examines the current state of the system and the proposed transition command to determine if the result will place the system in an unauthorized state. An important observation is that transition-based logging may not be sufficient to enable a transition-based auditing mechanism to determine if the system will enter an unauthorized state. If the system begins in a state that violates the security policy, a transition-based auditing mechanism will not detect the security problem if the transition alone was analyzed and determined not to move the system from a secure state to a nonsecure state. Transition-based logging is used only when specific transitions always require examination such as in the case of change of privilege or when some state analysis is also performed. AIM allows a user to sign on from at most one computer at a time. The mechanism that detects when a user tries to sign on from two computers simultaneously is a mixture of state-based and transitionbased auditing. It examines the transition, the sign-on, and the current state, whether or not that user is already signed on. If the transition would put the system in an unauthorized state, the audit mechanism reports the problem. The system responds by blocking the second sign on. The program tcp_wrappers intercepts TCP connections to UNIX systems and determines whether or not the connections are to be allowed. The connections that are to be denied are identified in the file

5 hosts.deny. The logging mechanism determines where the connection comes from. The auditing mechanism compares that point of origin with the data in the host.deny file. If the point of origin matches the data in the host.deny file, the connection is blocked. This is a transition-based auditing mechanism because the mechanism analyzes a command to determine if it will put the system in an unauthorized state. The current state of the system is not examined. Auditing to Detect Known Violations of a Policy In many cases, the security policy is not stated explicitly. However, certain behaviors are considered to be nonsecure. For example an attack that floods a network to the point that it is not usable or accessing of a computer by an unauthorized user would violate the implicit security policy. Under these conditions analysts can determine specific sequences of commands or properties of state that indicate a security violation and look for that violation.