Previous Next Functional Tool Requirements Homepage  
3.5 Service Complex: Security  
SSEC02 - Identification and Authentication  

  LSIC02 - Identifikation und Authentisierung

  • 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 that support the determination and the supervision of those users that access to resources which are controlled by the SDE especially the product library.

    The service unit contains all functions that help

    3 Requirements

    3.1 Requirements for Interfaces

    SSEC02.I.1 Interface to SUI01 - User Interface Functions It is possible to activate the Identification and Authentication via the service unit SUI01 - User Interface Functions by the user himself (e. g. login procedure) as well as by the SDE (e. g. after lengthy inactivity of the user).
    SSEC02.I.2 Interface to SSEC03 - Access Control
    SSEC02.I.2.1 Protection of the identification and authentication data The service unit SSEC03 - Access Control guarantees that only the system manager can access the identification and authentication data.
    SSEC02.I.2.2 Making the identification and authentication data available The service unit SSEC03 requires a correctly functioning mechanism for the identification and authentication not possible to be bypassed. The service unit "SSEC02 - Identification and Authentication" puts all the identification and authentication data necessary for the administration and control of access rights at the disposal of the service unit SSEC03.
    Besides other items this contains the information about the clearance and authorization of individual users.
    SSEC02.I.3 Interface to SSEC04 - Auditing By means of the mechanism for the identification and authentication of users it is possible to identify uniquely 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.
    SSEC02.I.4 Interface to SSEC06 - Authenticity, Confidentiality and Liability The authentication data are stored or transmitted only in coded form. The service unit "Authenticity, Confidentiality and Liability" applies here a secure single-way procedure.
    In this way, forgeries of the authentication data are detected and it is guaranteed that in general a look at the authentication data (e. g. passwords) is not possible-also not possible for the system manager. Beside other things what is prevented is that an intruder achieves knowledge of an uncoded password by bugging a transmission line (e. g. between terminal and computer) or by reading access to the password file.

    3.2 Requirements for the Methods Support


    3.3 Requirements for Functions

    SSEC02.F.1 Mechanisms
    SSEC02.F.1.1 Existence There is a mechanism for the identification and authentication for local as well as remote users.
    SSEC02.F.1.2 Uniqueness It is possible to identify uniquely and authenticate users.
    SSEC02.F.1.3 Authentication by knowledge
    SSEC02.F.1.3.1 Password length A minimum password length is enforced. This is configurable by the system manager (6 characters are the lower limit).
    SSEC02.F.1.3.2 Complexity It is enforced of the passwords to contain at least one special character and one digit.
    SSEC02.F.1.3.3 Non-trivial passwords Trivial password, i. e. possible to derive from the corresponding user information (like user name, first name, computer name) are not accepted.
    SSEC02.F.1.3.4 Protection against covert channels When having entered an invalid identification the session is not canceled either but only after having entered the password.
    In this way it is not possible for an intruder to detect whether the identity was valid and only the password was wrong or whether the identification was already invalid.
    SSEC02.F.1.3.5 Covered input The entered password is not displayed.
    SSEC02.F.1.3.6 Password replacement The system forces regular password replacement. It is possible to determine the time period.
    SSEC02.F.1.3.7 History Over a set time the system stores all chosen passwords of a user identity and prevents a repeated choice of the same password within this time period.
    In this way what is prevented is that a user formally replaces his password but that the new one is identical to the old one and therefore the purpose of the password replacement is obviated.
    SSEC02.F.1.3.8 Exclusion list It is possible to enter all those passwords that shall not be accepted by the system into an exclusion list.
    SSEC02.F.1.4 Authentication by ownership
    SSEC02.F.1.4.1 Availability The availability of a machine-readable badge is checked.
    SSEC02.F.1.4.2 Identification flag It is checked whether the badge contains a unique and valid ID flag.
    SSEC02.F.1.4.3 Identification number The system allocates an individual number (PIN) to every badge. This identification number has to contain at least six digits.
    SSEC02.F.1.4.4 System admission System admission is only allowed when a machine-readable badge was presented that contains a unique and valid ID flag and when in addition the right identification number (PIN) was entered by the user.
    SSEC02.F.1.4.5 Covered input The identification number entered by the user is not displayed.
    SSEC02.F.1.5 Authentication by personal characteristics Characteristic features (e. g. fingerprint, background of the eyes, speed of typing) are stored as authentication data and are checked whether they match the actual input of an authentication.
    SSEC02.F.2 Administration of the identification and authentication data
    SSEC02.F.2.1 User administration The system manager has the possibility to enter new users as well as to delete or to disable old ones.
    SSEC02.F.2.2 Identification data Within the system administration the system manager has the possibility to have a look at the identification data.
    This includes the user name and the user identification.
    SSEC02.F.3 Separation of identification and authentication data The authentication data are separated from the identification data and are stored in an individual file to which only the system manager has access.
    The system manager must possess writing access to the authentication data. Beside other things he must be able to enter new users (with an initial password), to give authorized access and the possibility to enter a new password for a user who has forgotten his password.
    SSEC02.F.4 Admission protection The user is forced to pass a successful identification and authentication test before he is able to perform further interactions.
    SSEC02.F.5 Retrial lock After repeated failure of identification and authentication of a user his user identification is disabled. It is possible to determine the number of allowed trials.
    SSEC02.F.6 Trustworthy path The identification and authentication always is done via a trustworthy path between user and system. Only the corresponding user and the trustworthy components of the SDE are able to initiate communications via this path. They are logically isolated from other paths and unequivocally distinguishable.
    By means of this it is guaranteed that the authentication is performed by the SDE and not by a (not trustworthy) application program. The trustworthy path is used always when a trustworthy SDE-user-connection is required. This is the case at the login or when modifying the actual security level of a subject.
    SSEC02.F.7 Identifiability It is possible to determine the identity of a user at every interaction.
    SSEC02.F.8 Partner authentication Preceding every setup of a communication connection the communication partner (computer, process or user) is uniquely identified and authenticated. Only after a successful identification and authentication the transmission of user data may start.
    SSEC02.F.9 Transmitter authentication When receiving messages the sender is uniquely identified and authenticated.
    SSEC02.F.10 Terminal allocation It is possible to allocate certain terminals to individual users from which the login process may be started. Login trials from other terminals are rejected.
    SSEC02.F.11 Individual periods of time It is possible to allocate individual periods of time to every user within them he may start login processes. Outside these periods of time the login trials are rejected generally.
    SSEC02.F.12 Login display After having passed a successful login procedure data and time of the last login procedure is displayed to the user.
    SSEC02.F.13 Renewed authentication
    SSEC02.F.13.1 Manually activated admission protection Every user has the possibility to blank the screen of his computer (e. g. by means of a pause instruction). Work can only be continued after a renewed identification and authentication.
    SSEC02.F.13.2 Automatically activated admission protection It is possible to force renewed authentication.
    Are there not inputs of the users, e. g. for a set period of time, then the user may only continue his activities after a renewed identification and authentication. The period of time decisive for the activation of the admission protection is configurable. Beside the login it is possible to determine further actions (e. g. highly sensitive) that require an additional identification and authentication preceding execution.

    3.4 Other Requirements


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