Previous Next Functional Tool Requirements Homepage  
3.5 Service Complex: Security  
SSEC04 - Auditing  

  LSIC04 - Auditing

  • 1 Allocation to V-Model and Methods Allocation
  • 2 Brief Characteristics
  • 3 Requirements
  •       3.1 Requirements for Interfaces
  •       3.2 Requirements for the Methods Support
  •       3.3 Requirements for Functions
  •       3.4 Other Requirements
  • 1 Allocation to V-Model and Methods Allocation

    not applicable

    2 Brief Characteristics

    In this service unit requirements are defined to guarantee that information about actions (which are performed by users or by processes in the name of such users) are recorded in order to be able to later allocate the consequences of these actions to the corresponding user and to hold the user responsible for his actions. In the system administration manual shall be a hint for the audit representative to act in agreement with the relevant laws (e. g. Federal Data Protection Act and National Data Protection Act) when recording the user behavior.

    This includes also later analyses in order to detect whether the security was violated actually and which information or other resources were concerned.

    The service unit includes all functions

    3 Requirements

    3.1 Requirements for Interfaces

    SSEC04.I.1 Interface to SSEC02 - Identification and Authentication By means of the mechanism for the identification and authentication of users it is possible to uniquely identify authorized users with regard to the service unit "Auditing". The information required for recording this event (e. g. parameters, success or failure of the event) are transmitted to the service unit "Auditing" with every authentication, with a successful one as well as with an unsuccessful one.
    SSEC04.I.2 Interface to SSEC03 - Access Control
    SSEC04.I.2.1 Transfer of logging information All information necessary for the logging of access trials are transferred from the service unit "Access Control" to the service unit "Auditing".
    SSEC04.I.2.2 Protection of audit mechanisms, data and parameters The service unit SSEC03 - Access Control guarantees that beside the person in charge of the audit no user can access the audit mechanisms, parameters and logging data.
    Especially the access to logging data in storage, e. g. buffers, is only possible via the service unit SSEC04 "Auditing" and only for the audit representative.
    SSEC04.I.2.3 Protection of user profiles The service unit SSEC03 - Access Control guarantees that beside the person in charge of the audit no user can access the user profiles for intrusion detection.
    This guarantees data protection.
    SSEC04.I.3 Interface to trustworthy components There is an interface to trustworthy components. This facilitates trustworthy components to write their own audit records for the audit trail. In order to prevent redundant recording these trustworthy components obtain the privilege to deactivate the logging of their activities.
    This interface enables a recording of audit data considerably richer in content than it is possible for the service unit "Auditing" itself.

    3.2 Requirements for the Methods Support


    3.3 Requirements for Functions

    SSEC04.F.1 Audit administrator It is possible to define the role of an audit administrator. This role stands out due to special privileges with regard to the proving.
    Special privileges are activation, deactivation of logging or access to the mechanisms, parameters, and protocol data.
    SSEC04.F.2 Generating and administrating audit trails
    SSEC04.F.2.1 Recording mechanism The service unit "Auditing" makes a recording mechanism for security-relevant events available. For every security-relevant event (see SSEC04.F.4) this mechanism has to generate, to store, to administrate data and to make the required data available for an evaluation.
    SSEC04.F.2.2 Activating and deactivating There is a mechanism to activate and to deactivate logging.
    SSEC04.F.2.3 Buffer The audit trail is stored in a buffer (in the kernel memory). It is possible to initiate writing the buffer content onto a non-volatile medium.
    SSEC04.F.2.4 Administration There are trustworthy mechanisms for the administration of logging data. This includes mechanisms for the initialization, the modification of control parameters, data compression and expansion.
    SSEC04.F.3 Selection of events
    SSEC04.F.3.1 Default According to the default setting all recordable events are logged in the audit trail.
    SSEC04.F.3.2 Preselection
    SSEC04.F.3.2.1 Positive Selection there is a mechanism for the selection of events that shall be logged in the audit trail. It is not possible to make an exception for any one event. All actions of privileged users are logged without exception.
    This prevents the audit representative making an exception for himself.
    SSEC04.F.3.2.2 Negative Selection The mechanism facilitates the selection of events explicitly not to be logged.
    SSEC04.F.3.3 Later Selection There is a mechanism for the later selection.
    Thereby the audit representative may select these events out of the audit trail that he wants to analyze.
    SSEC04.F.3.4 Granularity It is possible to select events on the basis of user identity, user groups and objects. Users and objects may also be selected on the basis of special attributes (like: classification higher than confidential).
    SSEC04.F.3.5 Basic setting There is a basic setting for new users.
    Through this it is guaranteed that at least the most important events initiated by a new user are logged up to the time when the audit representative individually incorporates the new user to the audit control.
    SSEC04.F.4 Recordable events
    SSEC04.F.4.1 Identification and Authentication It is possible to log the utilization of the identification and authentication mechanisms. Beside other things, this includes the procedures for local and remote login and for changing the password.
    SSEC04.F.4.2 Access to objects
    SSEC04.F.4.2.1 Creating and deleting objects It is possible to log the creating and deleting of an object being subject to the rights administration.
    SSEC04.F.4.2.2 Entering and removing objects It is possible to log the entering of objects in the address area of a user (e. g. opening files or loading programs) and the removing of objects out of the address area of a user (closing files or finishing a session).
    SSEC04.F.4.3 Entering and removing data media It is possible to log the entering and removing of data media.
    SSEC04.F.4.4 Roles with special rights It is possible to log the occupation of roles with special rights.
    SSEC04.F.4.5 Usage of privileges It is possible to log actions of persons with special rights, e. g. audit administrator or system manager.
    SSEC04.F.4.6 Modifications of security-relevant system files It is possible to log all modifications of security-relevant system files.
    This includes entering, disabling and deleting of user entries.
    SSEC04.F.4.7 Attribution It is possible to log the initialization and modification of attributes of subjects and objects.
    Examples for such attributes are: access rights of subjects to objects, classifications of users, processes, data objects or export channels.
    SSEC04.F.4.8 Type administration It is possible to log the generation and deletion of object types and the appointment of types to an object.
    SSEC04.F.4.9 System recovery It is possible to log all actions for the system recovery after a system crash.
    SSEC04.F.4.10 Starting and stopping the system It is possible to log all actions for starting and stopping the system.
    SSEC04.F.4.11 Generating printer output It is possible to log the generating of printer output.
    SSEC04.F.4.12 Covert channels It is possible to log known events that may be utilized for creating a non-authorized information flow by means of a covert channel.
    SSEC04.F.4.13 Data transmission With regard to data transmission, it is possible to log the connection setup, detected errors during data transmission, data losses and modifications during data import and special data transmission actions.
    SSEC04.F.5 Required data per event
    SSEC04.F.5.1 Date and time For every event, the occurrence data and time is recorded in the audit trail.
    SSEC04.F.5.2 User identity For every event, the unique identification of the user who has initiated the event is recorded in the audit trail.
    SSEC04.F.5.3 Type of event For every event, the kind of event is recorded in the audit trail.
    SSEC04.F.5.4 Success/Failure For every event it is recorded whether it was successful or not.
    SSEC04.F.5.5 Origin For every event, the origin of the event is recorded in the audit trail, e. g. terminal ID or network address.
    SSEC04.F.5.6 Object name When objects are concerned by events then the name of the object is recorded.
    SSEC04.F.5.7 Attributes All attributes of subjects and objects involved in an event are recorded.
    Within the data transmission the sender and the receiver are the corresponding subjects and the user data correspond to the object.
    SSEC04.F.5.8 Identification and Authentication When using the identification and authentication mechanism the name of the subject to be identified is recorded.
    SSEC04.F.5.9 Password protection It is possible to prevent the recording of the name when having entered the wrong name within an identification/authentication procedure (e. g. login procedure). This guarantees a password not being compromised when it was erroneously entered at the wrong position.
    In an actual case it has to be discussed whether the identification name should be recorded in favor of a later enlightenment despite the danger of password compromise.
    SSEC04.F.5.10 Modification descriptions Modifications are described which have been performed by the system manager in files relevant for user administration and system security.
    SSEC04.F.5.11 Transmission setup When setting up the data transmission the name of the receiver (computer, process or user) and the parameters of the transmission setup are recorded.
    SSEC04.F.5.12 Detected errors in data transmission When having detected errors in the data transmission, the type of error, the success or failure of the correcting action and the user ID of the communication partners are recorded.
    SSEC04.F.5.13 Data transmission With regard to data transmission, it is possible to record the user ID of sender and receiver, the transmitted user information and data and time of data reception.
    SSEC04.F.6 Particularly critical events
    SSEC04.F.6.1 System behavior at particularly critical events It is possible to control events that are especially security-relevant or that represent a critical threat to the security of the SDE on the basis of the frequency of their occurrence. If such events occur, the person responsible for the audit is informed immediately and actions are initiated preventing any further occurrences of this kind.
    SSEC04.F.6.2 Overflow
    SSEC04.F.6.2.1 Detection It is possible to detect when the storage medium for the audit trail is full. The action initiated as a result of that is logged.
    SSEC04.F.6.2.2 Warning The audit manager is informed as soon as the storage capacities for the audit trail are full.
    SSEC04.F.6.2.3 Saving the logging data All data of the audit trail are filed even in the case of a storage overflow.
    SSEC04.F.7 Availability of the audit data Within some minutes after recording the audit data are available for the audit manager.
    SSEC04.F.8 Trustworthy evaluation mechanisms
    SSEC04.F.8.1 Intrusion detection Trustworthy evaluation mechanisms exist for, beside other things, the statistical evaluation and for the direct data query via different event parameters and for the output of the corresponding data. They facilitate the analysis of the audit data on-line and independent of the controlling SDE with regard to intrusion trials. For that the behavior of subjects is investigated for deviations from their "normal behavior".
    SSEC04.F.8.2 Subjects It is possible to define individual users, groups of users, remote hosts and the whole system as subjects.
    The advantage when considering a whole group as subject is to be able to determine deviations not possible to be allocated to a single group member (e. g. increase of the unsuccessful login trials of different user identifications).
    SSEC04.F.8.3 User profile It is possible to store a behavior profile for every defined subject in the database. The profile describes the normal (i. e. the expected) behavior of a subject with regard to a number of parameters which point to possible security violations.
    Examples for the parameters are
    • for individual users:
      • used up CPU time,
      • number of I/O activities,
      • number of audit records,
      • directory accesses,
      • the active working time (days, hours, ...),
      • devices used for the accesses;
    • for remote hosts:
      • number of unsuccessful login trials,
      • type of network activities;
    • for controlled systems:
      • number of unsuccessful login trials,
      • number of system errors.
    The profiles are adjusted concurrently to the actual user behavior by considering newly measured parameter values. Unsuccessful and successful intrusion trials are detected by means of significant deviations from the typical behavior.
    SSEC04.F.8.4 Security gaps in system admission Known system gaps that facilitate an unauthorized intrusion are controlled specifically.
    SSEC04.F.8.5 Security gaps in object access Activities that facilitate bypassing the right control or to obtain rights in an unauthorized way are controlled specifically.
    SSEC04.F.9 Information A mechanism is available for determining whether a recordable event has to be logged in the audit trail.

    3.4 Other Requirements


    Previous Next GDPA Online Last Updated 01.Jan.2002 Updated by Webmaster Last Revised 01.Jan.2002 Revised by Webmaster