Previous Next V-Model Official Homepage by IABG  
Part 3: Collection of Manuals Homepage  
SEC  Homepage  

  SEC. Anwendung des V-Modells und der ITSEC

  • SEC.1 Introduction
  • SEC.2 Explanations to Submodel SD
  • SEC.3 Explanations to Submodel QA
  • SEC.4 Explanations to Submodel CM
  • SEC.5 Explanations to Submodel PM
  • Links to the V-Model Mailinglist
  • SEC.1 Introduction

    This manual describes the activities and products relevant for the evaluation of Systems. It describes what is to be done in the individual activities, particularly with regard to evaluation or which product contents are expected for the evaluation.

    The individual activities and products might have different requirements on the various E levels. Not all activities and products are required for each E level of the ITSEC either. These deviations with regard to the individual activities and products also refer to the evaluation document their results might be contributing to.

    For activities and products not commented on no relevance for the evaluation according to ITSEC could be discovered.

    SEC.2 Explanations to Submodel SD

    SD1 - System Requirements Analysis
    SD1.1 - Recording of Actual Status and Analysis If security measures already exist for an available system they must be analyzed and evaluated with regard to a newly specified security concept and the changed system environment.
    SD1.2 - Description of Application System In addition to the operational requirements to the system, the customer has to specify the security concept. This security concept is the basis for the specification of the security requirements. After the realization of the threats and risks analysis, they are defined with regard to this security concept in activity SD1.6 - Threat and Risk Analysis.

    Based on the tolerable remaining risk, the intended strength of the mechanisms for the realization of the security functions and the desired E level will be defined by taking into consideration the tolerable remaining risk.

    SD1.5 - User-Level System Structure When structuring the system professionally, the IT measures of the security concept are converted into security functions used to prevent the threats. These functions are referred to as "security-related functions" since they contribute directly to the system security. These security functions are selected for the prevention of threats and may correspond with a predefined functionality class of the ITSEC. However, there may also be freely defined security functions.

    The security functions have to be separated from the other operational functions.

    SD1.6 - Threat and Risk Analysis Based on the operational requirements and with regard to the Security Concept to be adhered to, the corresponding threats and risks are found out according to the IT Security Manual or to AU 248. Threats containing risks that are not acceptable (probability that threat will come true and probable total damage) will be classified as relevant.

    In order to avoid these threats classified as relevant, appropriate measures have to be taken. Such measures might be IT measures, but also measures of an administrative, organizational, personnel or infrastructural kind. The combined measures comprise the security concept. The development of non-IT measures are not explicitly regulated in the V-Model. However, they have been considered during evaluation since they contribute to the security of the system.

    The IT measures are realized by security functions. These security functions require a certain trustworthiness that is determined both by the strength of the mechanisms and by the quality of its realization (E level). The determination of the strength of the mechanisms and of the E level for the security functions are not regulated in the V-Model.

    SD2 - System Design
    SD2.1 - Technical System Design Apart from the security-related functions, there will also be such functions where the correct behavior of which is indispensable for the security functions. When one or several security functions depend on these functions, these functions contribute directly to the security. Therefore, they are referred to as "functions relevant for security".

    During system design it has to be observed that both the security functions themselves and the security-related functions are sufficiently separated from the software not considered relevant for security by keeping the number of interfaces as low as possible. The need for each interface must be described and justified. It must also be observed that the size of the entire security part (security-related and security-relevant functions) which is subject of the evaluation is kept as small as possible (minimization of the trustworthy part).

    The interfaces to the operational environment have to be described accurately.

    SD2.3 - Investigation of Feasibility It must be investigated if the security-relevant part can be separated from the non-security-relevant part.

    The feasibility of the desired E level has to be investigated. Another criterion for the feasibility of a high E level is the expected complexity of the security part.

    It is also necessary to take into consideration the economic efficiency of the demanded E level. The required investigations must, by taking into consideration the tolerable remaining risk, compare the cost for a certain E level with the possible damages that might occur if the threats become effective.

    SD2.4 - Allocation of User Requirements It is necessary to prove that all security requirements in the security concept (IT measures and non-IT measures) are taken into consideration. This facilitates also the determination of the still existing remaining risk.
    SD2.6 - Specification of System Integration It is necessary to specify how the security-relevant part that is to be evaluated directly or later is to be integrated into that part that is not to be evaluated.
    SD3 - SW/HW Requirements Analysis
    SD3.1 - Definition of General Requirements from SW/HW Unit Point of View It is necessary to check if the security-relevant part has an impact on this SW/HW Unit, i. e. if certain functions related with or relevant for security have to be realized in this SW/HW Unit.
    SD3.2 - Specification of Requirements for External Interfaces of SW/HW Unit In case this SW/HW Unit contains security-related or security-relevant functions, an exact interface description to the remaining security-related or security-relevant part that might be contained in other SW/HW Units has to be available. The cooperation of these functions with the other functions via this interface has to be described.
    SD3.3 - Definition of Requirements for the Functionality The requirements for security functions and the necessary data have to be defined.
    SD3.4 - Definition of Requirements for the Quality of the SW/HS Unit In case the SW/HW Unit contains a security-relevant part this has to be realized with the demanded E level
    SD3.5 - Definition of Requirements for the Development and SWMM Environment The various E levels have different requirements for the development environment.

    The requirements refer to the use of methods and tools like

    • the method of the specification and the specification language,
    • the programming language and the compilers in use,
    • the configuration management and the performance of a tool for configuration control.
    Requirements are also defined with regard to the possibility to differentiate between different users in the development environment and to guarantee accountability in order to
    • give users authorizations for activities and actions,
    • enable the separation of roles in order to realize activities,
    • to make it possible to prove activities and actions during the development process.
    SD4 - Preliminary SW Design
    SD4.1 - SW Architecture Design This activity is required for all E levels. The type of the demanded representation varies for the different E levels. It starts with an informal description and ends with the necessity for a formal notation.

    The threat and risk analysis has to be updated. It is necessary to investigate if new threats and risks occur after an improvement.

    In levels E1 to E3, an informal description of the architecture is required.

    Between these three E levels different requirements exist, however, concerning how exact the separation into security-relevant components and other components has to be represented and if the separation has to be documented.

    In levels E4 to E5, a semi-formal description of the security-relevant part is required.

    Different requirements with regard to the degree of specification of these semi-formal representation exist between the two E levels. It refers predominantly to the highest possible independence of the security-related components and the inherent dependencies.

    In level E6, a formal description of the security-relevant part is required.

    SD4.2 - Design of Internal and External SW Interfaces All interfaces to the security-related and security-relevant SW components/processes/SW modules have to be described with regard to their purpose and their parameters. The separation from the part that is not security-relevant must be distinct. The interfaces have to be minimized. The use of certain documentation methods depends on the E level.
    SD4.3 - Specification of SW Integration The integration of the security-relevant part to be evaluated into the part that must not be evaluated, has to be specified.
    SD5 - Detailed SW Design
    SD5.1 - Description of SW Component/Module/Database Beginning with evaluation level E2, the Detailed Design according to the tailoring must be included.

    In levels E2 and E3, an informal description of the security part of the Detailed Design is sufficient.

    In levels E4 to E6, a semi-formal description of the security part of the Detailed Design is required.

    The Detailed Design must be compared with the Preliminary Design.

    SD5.2 - Analysis of Resources and Time Requirements This aspect may be relevant for the security requirements.
    SD6 - SW Implementation
    SD6.3 - Self-Assesment of the SW Module/Database It is necessary compare the code with the Detailed Design.
    SD8 - System Integration
    SD8.2 - Self-Assessment of the System The cooperation of the mechanisms must be investigated, and penetration analyze is to be realized.
    SD8.3 - Product Supply The correct use of security functions by the staff in charge and by the user must be guaranteed. Therefore, this information must be included in the corresponding manuals for the system administration and the user documentation.

    SEC.3 Explanations to Submodel QA

    QA1 - QA Initialization A manual configuration management is possible up to E3.

    Beginning with E4, tool-supported configuration management is demanded.

    Beginning with E5, the strict separation of roles is required between development and QA.

    QA2 - Assessment Preparation
    QA2.1 - Definition of Assessment Methods and Criteria As assessment criteria for security functions must be taken into consideration:
    • cooperation of security functions
    • efficiency of the mechanisms
    • separation, i. e. interfaces to software that is not considered trustworthy
    As assessment methods for the security functions must be taken into consideration:
    • weak point analysis
    • efficiency analysis
    • penetration test
    QA4 - Product Assessment
    QA4.2 - Assessment of the Content of the Product Runtime libraries are integrated into the system or product and must be handled according to the desired evaluation level.

    SEC.4 Explanations to Submodel CM

    CM1 - CM Planning Configuration control is required for all E levels. Beginning with level E4, the control must be tool-supported.

    For E6, not only the security-relevant products but also the applied tools must be subject to the configuration control.

    CM2 - Product and Configuration Management Beginning with E4, this must take place with the support of tools. The requirements for the performance of these tools get higher after every evaluation level.
    CM3 - Change Management (Configuration Control)
    CM3.3 - Completion of Change Beginning with E4, protocol information about product changes that are subject to the configuration control must be submitted.

    SEC.5 Explanations to Submodel PM

    PM1 - Project Initialization
    PM1.2 - Definition of Project Criteria and Development Strategy It is essential to define if the system or product to be generated should be evaluated or not. Only if it is to be evaluated, the ITSEC criteria are relevant and have to be observed.

    Beginning with evaluation level E5, the runtime libraries must be made available in the source code. Therefore it is necessary to make sure at the beginning if the compiler manufacturer is ready to deliver the sources to the evaluating agency/department.

    PM1.3 - Generation of Project-Specific V-Model A final project-related V-Model can only be generated after the demanded E level has been defined.
    PM1.4 - Toolset Management Minimum requirements for methods and tools have been defined in the individual E levels.
    PM1.5 - Generation of Preliminary Plan Since starting with evaluation level E4 or higher, special requirements are expected of the development procedure and it is necessary to guarantee that special tools that have the required functionality or respectively quality are available on time.

    The staff employed must have enough experience to be able to complete an analysis of the cooperation of the selected security functions. These staff must also be able to complete an efficiency analysis for the mechanisms selected for the implementation of the security functions.

    If higher E levels were selected, the availability of the staff with sufficient experience in handling semi-formal or respectively formal specifications must be guaranteed.

    If an accompanying evaluation is to be realized, the cooperation of the evaluators and the BSI during the planning period must also be ensured of.

    PM10 - Training/Instruction In case the project staff have not enough expertise and insufficient experience (see activity PM 1.3) to handle the development according to a certain E level, this staff must be trained accordingly. Sensitization with regard to security is compulsory.

    Links to the V-Model Mailinglist

    Mail 0399 - Re: Evaluierungsstufen (399)
    Mail 0343 - Re: Kritikalitaet u. Qualitaetsstufen
    Mail 0341 - Re: Kritikalitaet u. Qualitaetsstufen
    Mail 0340 - Kritikalitaet u. Qualitaetsstufen

    Previous Next This page online  •  GDPA Online  •  Last Updated 03.Mar.2004 by C. Freericks