Previous Next Functional Tool Requirements Homepage  
System Development Submodel  
SSD31 - Analysis of Covert Channels  

  LSE31 - Analyse verdeckter Kanäle

Contents  
  • 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

    V-Model

    SD2.5 - Interface Description

  • Interface Description.Description of the Interfaces

    • SD4.1 - SW Architecture Design

  • SW Architecture.Solution Proposals
  • SW Architecture.Modularization/Database Design
  • SW Architecture.Interfaces
  • Interface Overview.System-Internal Interfaces

    • SD4.2 - Design of Internal and External SW Interfaces

  • Interface Description.Description of the Interfaces

    • SD5.1 - Description of SW Component/Module/Database

  • SW Design (Database).Database Description
  • SW Design (Module).SW Component/SW Module Description (in object-oriented Databases)

    • SD5.2 - Analysis of Resources and Time Requirements

  • SW Design (Module).Characteristic Quantities
  • SW Design (Database).Characteristic Quantities

    • SD6.1 - Coding of SW Modules

  • SW Modules

    • SD6.2 - Realization of Database

  • Database

    • SD6.3 - Self-Assesment of the SW Module/Database

  • Implementation Document: SW Modules
  • SW Modules
  • Implementation Document: Database
  • Database

    • Method

    ACC - Analysis of Covert Channels

    2 Brief Characteristics

    This service unit defines the requirements for tools used to support the ACC - Analysis of Covert Channels. The Analysis of Covert Channels is important when the information flow in the security parameters is regulated. The functionality classes F-B2 and F-B3 do require such an analysis, according to ITSEC.

    The analysis consists of the following steps:

    1. Identification of the covert channels,
    2. Definition of scenarios to utilize the channels,
    3. Estimation of the bandwidths of the channels,
    4. Planning and utilization of correction measures.

    In particular, a tool should support steps 1 to 3, whereby the first step must be considered as the main task of the tool; this first task can be further segmented into the following substeps:

    1. Identification of all objects that might possibly be utilized,
    2. Identification of all operations modifying or reading these objects,
    3. Analysis of the information flows between these objects when executing the operations,
    4. Definition of the objects that are possible candidates for non-permitted information transmission or generation of verification conditions which have to be proven to show that the system is safe,
    5. Investigation if the found possible candidates may be utilized as covert channels.

    3 Requirements

    3.1 Requirements for Interfaces

    SSD31.I.1 Granularity The exchange of control parameters with SWFM01 - Workflow Management is possible for individual closed function packages of the tool by means of a disclosed, documented interface.
    SSD31.I.2 Input Interface to SSD23 - Supporting Subsystem Modeling It is possible to access information about the logical system structure defined with SSD23 via the object management.
    SSD31.I.3 Input Interface to SSD24 - Supporting Module Diagrams It is possible to access information about the module structure defined with SSD24 via the object management.
    SSD31.I.4 Input Interface to SSD25 - Supporting Process Diagrams It is possible to access information about the process structure defined with SSD25 via the object management.
    SSD31.I.5 Input Interface to SSD26 - Supporting Use Case Modeling It is possible to access use cases defined with SSD26 via the object management.
    SSD31.I.6 Input Interface to SSD27 - Supporting State Modeling in the Object-Oriented Field" It is possible to access information about states, events and actions defined with SSD27 via the object management.
    SSD31.I.7 Input Interface to SSD28 - Supporting Interaction Modeling It is possible to access information abut objects and interactions defined with SSD28 via the object management.
    SSD31.I.8 Input Interface to SSD29 - Formal Specification It is possible to have the generated formal specification further processed for the formal verification by the tool.
    SSD31.I.9 Output Interface to SSD30 - Formal Verification It is possible to verify the verification conditions generated in the tool for the analysis of covert channels in the verifier of the "Formal Verification". Alternatively it is possible that also the tool for the analysis of covert channels has such a verifier.

    3.2 Requirements for the Methods Support

    SSD31.M.1 ACC - Analysis of Covert Channels
    SSD31.M.1.1 Supporting the formal Specification Language The utilized formal specification language(s) are/will be supported.
    I. e. it must be possible to derive the Analysis of Covert Channels (memory channels).
    SSD31.M.1.2 Supporting the Target Language It is possible to deviate the Analysis of Covert Channels (memory channels) from a program in the target language.
    SSD31.M.1.3 Security Politics The Analysis of Covert Channels depends on the security politics or the security presettings. The tool is not adjusted to a certain security politic but can be parameterized.

    3.3 Requirements for Functions

    SSD31.F.1 Identification of Objects It is possible to identify objects from the formal specification or the program that can be utilized as covert memory channels.
    SSD31.F.2 Identification of Operations It is possible to define the possible operations.
    SSD31.F.3 Identification of Information Flows It is possible to define the information flows between the objects on the basis of the way the operations are realized.
    SSD31.F.4 Generation of Verification Conditions It is possible to generate verification conditions that have to be adhered to so the system is safe (i. e. without covert channels). This can be verified with the simplifier and the verifier in SSD30 "Formal Verification".
    SSD31.F.5 Definition of Candidates for Covert Channels Possible candidates for covert channels are defined from the information flow analysis and the verification conditions.
    SSD31.F.5.1 Completeness It is possible to list all objects by means of which the memory channels (and possible time channels) are possible.
    SSD31.F.5.2 Exactness It is possible to list only objects that are actually possible via the covert channels.
    SSD31.F.6 Development of possible Scenarios It is possible to develop scenarios that may be used to utilize the objects as covert channels.
    SSD31.F.7 Determination of the Band Width It is possible to support the determination of the bandwidth of the covert channels.
    SSD31.F.8 Editor
    SSD31.F.8.1 Entry of Objects, Operations, Information Flows There are user-friendly resources for the entry of objects, operations and information flows so the tool can also be used with informal specifications.
    A uniform, easy-to-handle editor should be available.
    SSD31.F.8.2 Structured Representation The context of tool versions is clear. They are easy-to-read, easy to understand and precise. The verification can be followed up by the user. This also means that the applied rules must be entered for the individual verification steps.

    3.4 Other Requirements

    SSD31.O.1 Upward Compatibility It must be possible to process objects that were generated with an older release of the tool with the later release of that tool, without loss of information and functionality.
    SSD31.O.2 Procedural Command Language The tool has a procedural command language that can be applied by the user to generate and run macros or procedures.
    SSD31.O.3 Complexity There is no limitation of the complexity caused by the tool itself.
    SSD31.O.4 Uniform User Interface
    SSD31.O.4.1 The user interface is uniform for all parts of the specification tool.
    SSD31.O.4.2 The user interface of the specification tool and the verification tool are the same.
    SSD31.O.5 Efficiency Compared with the state-of-the-art, the developments with the tool can be realized in an acceptable time and with acceptable memory requirements.
    SSD31.O.6 Installation
    SSD31.O.6.1 Procedure A procedure for the installation of the specification tool has been defined and documented with all parameters.
    SSD31.O.6.2 Configuration possibilities All configuration possibilities for the tool start by the user and the corresponding parameters have been documented, together with the effects on the overall behavior of the tool.
    SSD31.O.6.3 Authentication of the binary code The procedure to guarantee the authentication of the binary code, the installation and the tool start will be described. The procedure to maintenance the tool with the corresponding version control has also been documented.
    SSD31.O.7 Documentation
    SSD31.O.7.1 User Documentation The user documentation addresses a user with know-how of the formal specification and includes all information required for working with the tool.
    SSD31.O.7.2 Other Documentation The methodology used and the mathematical basis are described in detail.
    SSD31.O.8 Independence of Verifiers and Specification Languages or Target Languages The tool is independent of verifiers, specification languages and target languages.
    I. e. the interfaces to verifiers, specification languages and target languages should be kept as small as possible. Necessary dependencies should be limited to individual modules that might be exchanged, if necessary.

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