Previous Next Functional Tool Requirements Homepage  
3.5 Service Complex: Security  
SSEC06 - Authenticity, Confidentiality and Liability  

  LSIC06 - Unverfälschtheit, Vertraulichkeit und Verbindlichkeit

  • 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

    The requirements defined in this service unit guarantee that definite relations between different data are preserved (consistency), that messages (data that are exchanged between different computers) are transmitted unmodified, that manipulations of data, messages or programs are detected. Further these requirements guarantee the confidentiality and liability of data.

    The service unit comprises all functions for

    3 Requirements

    3.1 Requirements for Interfaces

    SSEC06.I.1 Interface to SSEC02 - Identification and Authentication 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 it is prevented 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.
    SSEC06.I.2 Interface to SSEC05 - Preparation for Reuse The service unit "Authenticity, Confidentiality and Liability" is able to initiate the preparation for reuse of reusable storage media.

    3.2 Requirements for the Methods Support


    3.3 Requirements for Functions

    SSEC06.F.1 Plausibility control Format, plausibility and consistency checks are performed in order to protect the user against false data input and data modifications. The check has to be defined dependent on the type of a file.
    SSEC06.F.2 Confirming security-critical actions Sensitive actions have to be confirmed by the user before they are actually performed. This is to prevent an undesired initiation of an action possibly violating security. Thereby such an action may be stopped before being performed.
    SSEC06.F.3 Authenticity of data, messages and programs
    SSEC06.F.3.1 Confidentiality
    SSEC06.F.3.1.1 Encoding as a guarantee for confidentiality of data The confidentiality of data is guaranteed by (symmetric or asymmetric) encoding.
    Data to be specially protected should only be stored or saved in coded form. For data less sensitive the protection gained by admission and access control is sufficient. The decision about the level of protection and the treatment of the data in an actual case is done by the customer or the developer.
    Furthermore the encoding makes a well-aimed manipulation of data more difficult because an attacker often needs access to the decoded data for a well-aimed manipulation action.
    SSEC06.F.3.1.2 Encoding as a guarantee for confidentiality of messages The confidentiality of messages is guaranteed by (symmetric or asymmetric) encoding.
    Sensitive messages should only be transmitted in coded form. If the message exchange is to be performed totally encoded then an end-to-end encoding is required which precedes the network interface. Every computer required for the transmission of such messages has to be equipped with the corresponding encoding software and hardware.
    This mechanism is to guarantee the hiding of the user data and the receiver information for large parts of the transmission path. Furthermore the information hiding of the transmission amount on special data transmission channels has to be guaranteed.
    Also a well-aimed manipulation of messages is made more difficult by this encoding, because if the encoding algorithm was chosen well a well-aimed manipulation is only possible on decoded data.
    SSEC06.F.3.2 Integrity
    SSEC06.F.3.2.1 Integrity conditions It is possible to formulate integrity conditions.
    SSEC06.F.3.2.2 Integrity violations A violation of integrity conditions automatically causes the execution of measures that can be defined by the user.
    SSEC06.F.3.2.3 Integrity check It is possible to explicitly initiate integrity checks.
    SSEC06.F.3.2.4 Procedural language It is possible to define integrity conditions my means of a procedural language.
    SSEC06.F.3.3 Non-cryptographic check sums
    SSEC06.F.3.3.1 Integrity protection of data Check sums are calculated in order to guarantee the integrity of the data.
    When an attacker manipulates the data this is detected via the comparison of the original check sum and the actual check sum, provided that the attacker cannot adapt the original check sum or the manipulations are not performed in a way preserving the check sum.
    SSEC06.F.3.3.2 Integrity protection of programs analogous to the data, check sums are calculated. The check sums of these programs may be sorted write-protected since programs do not change.
    SSEC06.F.3.3.3 Integrity protection of messages analogous to the data, check sums are calculated. Transmission errors may be localized and corrected by means of different check sums of a message.
    SSEC06.F.3.4 Cryptographic check sums
    SSEC06.F.3.4.1 Integrity protection of data Cryptographic check sums (electronic sealing by means of symmetric or asymmetric encoding) guarantee the integrity of the data. When checking the data the cryptographic check sums are newly calculated via the same encoding algorithm (when using a symmetric procedure the same key or a key derived from it is used, when using asymmetric procedure the public key is used) and are compared with the stored check sum.
    SSEC06.F.3.4.2 Integrity protection of programs Cryptographic check sums guarantee the integrity of the programs. Preceding to every program call the cryptographic check sum is newly calculated by means of the same encoding algorithm and then compared with the stored check sum. Only if the comparison is true is the program started.
    SSEC06.F.3.4.3 Integrity protection of messages Similar to the data, the cryptographic check sum guarantees the integrity of messages.
    SSEC06.F.3.5 Transmission proof
    SSEC06.F.3.5.1 Proof of sending The receiver is able to prove that a definite data stream was sent to him by a uniquely identifiable sender.
    SSEC06.F.3.5.2 Proof of receiving The sender of a data stream is able to prove that this data stream has reached his addressee. For this the sender gets a forgery-safe receiver acknowledgement (e. g. electronic signature).
    SSEC06.F.4 Decoding It is possible to decode encoded data, messages and programs.
    SSEC06.F.5 Information labeling For information labeling the objects and subjects were allocated a complex information attribute, independent from the access control. The attribute of a subject/object is adopted in the attribute of another subject/object in case there is an information flow between them.
    This measure should be applied if the history of an object should be traceable. The label is not used for the access control but primarily is applied with regard to the protection against threats to integrity. The information label may contain for example the following information: origin, type and generation time of the data, function or meaning of the data, confidentiality of the data (e. g. actually real classification), list of users of the data (e. g. users that have performed a read/write access), warnings or hints for handling the data, version numbers and hints to rights or producers, recommendations for MAC/DAC settings.
    SSEC06.F.6 Covert channels No storage or time channels are known which have a bandwidth that exceeds an unacceptable limit and where the information may be transmitted without checking the access rights (i. e. covert).
    SSEC06.F.7 Protection against inference It is not possible to derive higher classified information out of various lower classified information.
    SSEC06.F.8 Virus location
    SSEC06.F.8.1 Virus location There is the possibility of pattern matching with regard to known virus strings.
    SSEC06.F.8.2 Automation initiation of virus detection It is possible to automatically initiate the virus location or the detection of program modifications at definite times/events.
    SSEC06.F.8.3 Recovery of virus-stricken files After the virus has been detected it is possible to recover the stricken files.

    3.4 Other Requirements


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