The Official Unofficial Zorp project
 
Overview| Examples| Bugs| FAQ | White papers | Download | Help wanted | SourceForge Project page | Filltable utility  
 
 
SourceForge.net: SF.net Project News: Zorp unofficial
  • zorp 2.0.9-6 has been released
  • iptables-utils zorp-unoff version has been released
  • New whitepaper, even more FAQs
  • Zorp whitepapers released, new FAQs
  • New tproxy versions
  • New Zorp version: get the DN
  • The best bughunter
  • Bughunting contest extended
  • Valentine day bughunting contest!
  • Site updates: FAQ, design
    		•
    SourceForge.net: Project File Releases: Zorp unofficial
  • zorp 2.0.9-6 released (Mon, 01 Nov 2004 21:49:58 GMT)
  • zorp 2.0.9-6 released (Mon, 01 Nov 2004 21:40:56 GMT)
  • iptables-utils 1.21-1 released (Mon, 01 Nov 2004 21:19:42 GMT)
  • zorp 2.0.9-1 released (Sat, 12 Jun 2004 00:00:00 GMT)
  • zorplibll 2.0.26.24-1 released (Sat, 12 Jun 2004 00:00:00 GMT)
  • zorp zorp_2.0.8-1 released (Thu, 11 Dec 2003 00:00:00 GMT)
  • zorp zorp_2.0.7-2 released (Wed, 03 Dec 2003 00:00:00 GMT)
  • zorp zorp_2.0.7-1 released (Tue, 11 Nov 2003 00:00:00 GMT)
  • zorplibll zorplibll_2.0.26.23-1 released (Mon, 10 Nov 2003 00:00:00 GMT)
    		•
    		Next Previous Contents

    7. Assurance requirements

    7.1 Configuration Management (ACM)

    Authorization Controls (ACM_CAP.3)

    • The developer shall provide a reference for the TOE.
    • The developer shall use a CM system.
    • The developer shall provide CM documentation.
    • The reference for the TOE shall be unique to each version of the TOE.
    • The TOE shall be labelled with its reference.
    • The CM documentation shall include a configuration list and a CM plan.
    • The configuration list shall describe the configuration items that comprise the TOE.
    • The CM documentation shall describe the method used to uniquely identify the configuration items.
    • The CM system shall uniquely identify all configuration items.
    • The CM plan shall describe how the CM system is used.
    • The evidence shall demonstrate that the CM system is operating in accordance with the CM plan.
    • The CM documentation shall provide evidence that all configuration items have been and are being effectively maintained under the CM system.
    • The CM system shall provide measures such that only authorized changes are made to the configuration items.
    • The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

    Coverage (ACM_SCP.1)

    • The developer shall provide CM documentation.
    • The CM documentation shall show that the CM system, as a minimum, tracks the following: the TOE implementation representation, design documentation, test documentation, user documentation, administrator documentation, and CM documentation.
    • The CM documentation shall describe how configuration items are tracked by the CM system.
    • The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

    7.2 Delivery and Operation (ADO)

    Delivery Procedures (ADO_DEL.1)

    • The developer shall document procedures for delivery of the TOE or parts of it to the user.
    • The developer shall use the delivery procedures.
    • The delivery documentation shall describe all procedures that are necessary to maintain security when distributing versions of the TOE to a user's site.
    • The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

    Installation, Generation, and Start-up Procedures (ADO_IGS.1)

    • The developer shall document procedures necessary for the secure installation, generation, and start-up of the TOE.
    • The documentation shall describe the steps necessary for secure installation, generation, and start-up of the TOE.
    • The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
    • The evaluator shall determine that the installation, generation, and start-up procedures result in a secure configuration.

    7.3 Development (ADV)

    Functional Specification (ADV_FSP.1)

    • The developer shall provide a functional specification.
    • The functional specification shall describe the TSF and its external interfaces using an informal style.
    • The functional specification shall be internally consistent.
    • The functional specification shall describe the purpose and method of use of all external TSF interfaces, providing details of effects, exceptions and error messages, as appropriate.
    • The functional specification shall completely represent the TSF.
    • The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
    • The evaluator shall determine that the functional specification is an accurate and complete instantiation of the TOE security functional requirements.

    High-Level Design (ADV_HLD.2)

    • The developer shall provide the high-level design of the TSF.
    • The presentation of the high-level design shall be informal.
    • The high-level design shall be internally consistent.
    • The high-level design shall describe the structure of the TSF in terms of subsystems.
    • The high-level design shall describe the security functionality provided by each subsystem of the TSF.
    • The high-level design shall identify any underlying hardware, firmware, and/or software required by the TSF with a presentation of the functions provided by the supporting protection mechanisms implemented in that hardware, firmware, or software.
    • The high-level design shall identify all interfaces to the subsystems of the TSF.
    • The high-level design shall identify which of the interfaces to the subsystems of the TSF are externally visible.
    • The high-level design shall describe the purpose and method of use of all interfaces to the subsystems of the TSF, providing details of effects, exceptions and error messages, as appropriate.
    • The high-level design shall describe the separation of the TSF into TSP-enforcing and other subsystems.
    • The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
    • The evaluator shall determine that the high-level design is an accurate and complete instantiation of the TOE security functional requirements.

    Correspondence Demonstration (ADV_RCR.1)

    • The developer shall provide an analysis of correspondence between all adjacent pairs of TSF representations that are provided.
    • For each adjacent pair of provided TSF representations, the analysis shall demonstrate that all relevant security functionality of the more abstract TSF representation is correctly and completely refined in the less abstract TSF representation.
    • The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

    Security Policy Modeling (ADV_SPM.1)

    • The developer shall provide a TSP model.
    • The developer shall demonstrate correspondence between the functional specification and the TSP model.
    • The TSP model shall be informal.
    • The TSP model shall describe the rules and characteristics of all policies of the TSP that can be modeled.
    • The TSP model shall include a rationale that demonstrates that it is consistent and complete with respect to all of the TSP that can be modeled.
    • The demonstration of the correspondence between the TSP model and the functional specification shall show that all the security functions in the functional specification are consistent and complete with respect to the TSP model.
    • The developer shall provide a TSP model.
    • The developer shall demonstrate correspondence between the functional specification and the TSP model.
    • The TSP model shall be informal.
    • The TSP model shall describe the rules and characteristics of all policies of the TSP that can be modeled.
    • The TSP model shall include a rationale that demonstrates that it is consistent and complete with respect to all of the TSP that can be modeled.
    • The demonstration of the correspondence between the TSP model and the functional specification shall show that all the security functions in the functional specification are consistent and complete with respect to the TSP model.
    • The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

    7.4 Guidance Documents (AGD)

    Administrator Guidance (AGD_ADM.1)

    • The developer shall provide administrator guidance addressed to system administrative personnel.
    • The administrator guidance shall describe the administrative functions and interfaces available to the administrator of the TOE.
    • The administrator guidance shall describe how to administer the TOE in a secure manner.
    • The administrator guidance shall contain warnings about functions and privileges that should be controlled in a secure processing environment.
    • The administrator guidance shall describe all assumptions regarding user behavior that are relevant to secure operation of the TOE.
    • The administrator guidance shall describe all security parameters under the control of the administrator, indicating secure values as appropriate.
    • The administrator guidance shall describe each type of security-relevant event relative to the administrative functions that need to be performed, including changing the security characteristics of entities under the control of the TSF.
    • The administrator guidance shall be consistent with all other documents supplied for evaluation.
    • The administrator guidance shall describe all security requirements on the IT environment that are relevant to the administrator.
    • The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

    User Guidance (AGD_USR.1)

    • The developer shall provide user guidance.
    • The user guidance shall describe the functions and interfaces available to the non-administrative users of the TOE.
    • The user guidance shall describe the use of user-accessible security functions provided by the TOE.
    • The user guidance shall contain warnings about user-accessible functions and privileges that should be controlled in a secure processing environment.
    • The user guidance shall clearly present all user responsibilities necessary for secure operation of the TOE, including those related to assumptions regarding user behavior found in the statement of TOE security environment.
    • The user guidance shall be consistent with all other documentation supplied for evaluation.
    • The user guidance shall describe all security requirements on the IT environment that are relevant to the user.
    • The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

    7.5 Life Cycle Support (ALC)

    Identification of Security Measures (ALC_DVS.1)

    • The developer shall produce development security documentation.
    • The development security documentation shall describe all the physical, procedural, personnel, and other security measures that are necessary to protect the confidentiality and integrity of the TOE design and implementation in its development environment.
    • The development security documentation shall provide evidence that these security measures are followed during the development and maintenance of the TOE.
    • The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
    • The evaluator shall confirm that the security measures are being applied.

    7.6 Security Testing (ATE)

    Coverage (ATE_COV.2)

    • The developer shall provide an analysis of the test coverage.
    • The analysis of the test coverage shall demonstrate the correspondence between the tests identified in the test documentation and the TSF as described in the functional specification.
    • The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

    Depth (ATE_DPT.1)

    • The developer shall provide the analysis of the depth of testing.
    • The depth analysis shall demonstrate that the tests identified in the test documentation are sufficient to demonstrate that the TSF operates in accordance with its high-level design.
    • The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

    Functional Testing (ATE_FUN.1)

    • The developer shall test the TSF and document the results.
    • The developer shall provide test documentation.
    • The test documentation shall consist of test plans, test procedure descriptions, expected test results and actual test results.
    • The test plans shall identify the security functions to be tested and describe the goal of the tests to be performed.
    • The test procedure descriptions shall identify the tests to be performed and describe the scenarios for testing each security function. These scenarios shall include any ordering dependencies on the results of other tests.
    • The expected test results shall show the anticipated outputs from a successful execution of the tests.
    • The test results from the developer execution of the tests shall demonstrate that each tested security function behaved as specified.
    • The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

    Independent Testing (ATE_IND.2)

    • The developer shall provide the TOE for testing.
    • The TOE shall be suitable for testing.
    • The developer shall provide an equivalent set of resources to those that were used in the developer's functional testing of the TSF.
    • The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
    • The evaluator shall test a subset of the TSF as appropriate to confirm that the TOE operates as specified.
    • The evaluator shall execute a sample of tests in the test documentation to verify the developer test results.

    7.7 Vulnerability Assessment (AVA)

    Examination of Guidance (AVA_MSU.1)

    • The developer shall provide guidance documentation.
    • The guidance documentation shall identify all possible modes of operation of the TOE (including operation following failure or operational error), their consequences and implications for maintaining secure operation.
    • The guidance documentation shall be complete, clear, consistent and reasonable.
    • The guidance documentation shall list all assumptions about the intended environment.
    • The guidance documentation shall list all requirements for external security measures (including external procedural, physical and personnel controls).
    • The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
    • The evaluator shall repeat all configuration and installation procedures to confirm that the TOE can be configured and used securely using only the supplied guidance documentation.
    • The evaluator shall determine that the use of the guidance documentation allows all insecure states to be detected.

    Strength of TOE Security Function Evaluation (AVA_SOF.1)

    • The developer shall perform a strength of TOE security function analysis for each mechanism identified in the ST as having a strength of TOE security function claim.
    • For each mechanism with a strength of TOE security function claim the strength of TOE security function analysis shall show that it meets or exceeds the minimum strength level defined in the PP/ST.
    • For each mechanism with a specific strength of TOE security function claim the strength of TOE security function analysis shall show that it meets or exceeds the specific strength of function metric defined in the PP/ST.
    • The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
    • The evaluator shall confirm that the strength claims are correct.

    Developer Vulnerability Analysis (AVA_VLA.1)

    • The developer shall perform and document an analysis of the TOE deliverables searching for obvious ways in which a user can violate the TSP.
    • The developer shall document the disposition of obvious vulnerabilities.
    • The documentation shall show, for all identified vulnerabilities, that the vulnerability cannot be exploited in the intended environment for the TOE.
    • The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
    • The evaluator shall conduct penetration testing, building on the developer vulnerability analysis, to ensure obvious vulnerabilities have been addressed.

    Next Previous Contents