12 CLASS ADV: DEVELOPMENT
12.6 TOE design (ADV_TDS)
12.6.1 Detail about the Subsystems and Modules
282 The requirements define collections of details about subsystems and modules to be provided:
a) The subsystems and modules are identified with a simple list of what they are.
b) Subsystems and modules may be categorised (either implicitly or explicitly) as “SFR-enforcing”, “SFR-supporting”, or “SFR-non-interfering”; these terms are used the same as they are used in Functional specification (ADV_FSP).
c) A subsystem's behaviour is what it does. The behaviour may also be categorised as SFR-enforcing, SFR-supporting, or SFR-non-interfering. The behaviour of the subsystem is never categorised as more SFR-relevant than the category of the subsystem itself. For example, an SFR-enforcing subsystem can have SFR-enforcing behaviour as well as SFR-supporting or SFR-non-interfering behaviour.
d) A behaviour summary of a subsystem is an overview of the actions it performs (e.g. “The TCP subsystem assembles IP datagrams into reliable byte streams”).
e) A behaviour description of a subsystem is an explanation of everything it does. This description should be at a level of detail that one can readily determine whether the behaviour has any relevance to the enforcement of the SFRs.
f) A description of interactions among or between subsystems or modules identifies the reason that subsystems or modules communicate, and characterises the information that is passed. It need not define the information to the same level of detail as an interface specification. For example, it would be sufficient to say “subsystem
Class ADV: Development
September 2012 Version 3.1 Page 109 of 233
X requests a block of memory from the memory manager, which responds with the location of the allocated memory.
g) A description of interfaces provides the details of how the interactions among modules are achieved. Rather than describing the reason the modules are communicating or the purpose of their communication (that is, the description of interactions), the description of interfaces describes the details of how that communication is accomplished, in terms of the structure and contents of the messages, semaphores, internal process communications, etc.
h) The purpose describes how a module provides their functionality. It provides sufficient detail that no further design decisions are needed.
The correspondence between the implementation representation that implements the module, and the purpose of the module should be readily apparent.
i) A module is otherwise described in terms of whatever is identified in the element.
Subsystems and modules, and “SFR-enforcing”, etc. are all further explained in greater detail in A.4, ADV_TDS: Subsystems and Modules.
ADV_TDS.1 Basic design
Dependencies: ADV_FSP.2 Security-enforcing functional specification
Developer action elements:
ADV_TDS.1.1D The developer shall provide the design of the TOE.
ADV_TDS.1.2D The developer shall provide a mapping from the TSFI of the functional specification to the lowest level of decomposition available in the TOE design.
Content and presentation elements:
ADV_TDS.1.1C The design shall describe the structure of the TOE in terms of subsystems.
ADV_TDS.1.2C The design shall identify all subsystems of the TSF.
ADV_TDS.1.3C The design shall describe the behaviour of each supporting or SFR-non-interfering TSF subsystem in sufficient detail to determine that it is not SFR-enforcing.
ADV_TDS.1.4C The design shall summarise the enforcing behaviour of the SFR-enforcing subsystems.
Class ADV: Development
Page 110 of 233 Version 3.1 September 2012
ADV_TDS.1.5C The design shall provide a description of the interactions among SFR-enforcing subsystems of the TSF, and between the SFR-SFR-enforcing subsystems of the TSF and other subsystems of the TSF.
ADV_TDS.1.6C The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke.
Evaluator action elements:
ADV_TDS.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ADV_TDS.1.2E The evaluator shall determine that the design is an accurate and complete instantiation of all security functional requirements.
ADV_TDS.2 Architectural design
Dependencies: ADV_FSP.3 Functional specification with complete summary
Developer action elements:
ADV_TDS.2.1D The developer shall provide the design of the TOE.
ADV_TDS.2.2D The developer shall provide a mapping from the TSFI of the functional specification to the lowest level of decomposition available in the TOE design.
Content and presentation elements:
ADV_TDS.2.1C The design shall describe the structure of the TOE in terms of subsystems.
ADV_TDS.2.2C The design shall identify all subsystems of the TSF.
ADV_TDS.2.3C The design shall describe the behaviour of each SFR non-interfering subsystem of the TSF in detail sufficient to determine that it is SFR non-interfering.
ADV_TDS.2.4C The design shall describe the enforcing behaviour of the SFR-enforcing subsystems.
ADV_TDS.2.5C The design shall summarise the SFR-supporting and SFR-non-interfering behaviour of the SFR-enforcing subsystems.
ADV_TDS.2.6C The design shall summarise the behaviour of the SFR-supporting subsystems.
ADV_TDS.2.7C The design shall provide a description of the interactions among all subsystems of the TSF.
ADV_TDS.2.8C The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke.
Class ADV: Development
September 2012 Version 3.1 Page 111 of 233
Evaluator action elements:
ADV_TDS.2.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ADV_TDS.2.2E The evaluator shall determine that the design is an accurate and complete instantiation of all security functional requirements.
ADV_TDS.3 Basic modular design
Dependencies: ADV_FSP.4 Complete functional specification Developer action elements:
ADV_TDS.3.1D The developer shall provide the design of the TOE.
ADV_TDS.3.2D The developer shall provide a mapping from the TSFI of the functional specification to the lowest level of decomposition available in the TOE design.
Content and presentation elements:
ADV_TDS.3.1C The design shall describe the structure of the TOE in terms of subsystems.
ADV_TDS.3.2C The design shall describe the TSF in terms of modules.
ADV_TDS.3.3C The design shall identify all subsystems of the TSF.
ADV_TDS.3.4C The design shall provide a description of each subsystem of the TSF.
ADV_TDS.3.5C The design shall provide a description of the interactions among all subsystems of the TSF.
ADV_TDS.3.6C The design shall provide a mapping from the subsystems of the TSF to the modules of the TSF.
ADV_TDS.3.7C The design shall describe each SFR-enforcing module in terms of its purpose and relationship with other modules.
ADV_TDS.3.8C The design shall describe each SFR-enforcing module in terms of its SFR-related interfaces, return values from those interfaces, interaction with other modules and called related interfaces to other SFR-enforcing modules.
ADV_TDS.3.9C The design shall describe each SFR-supporting or SFR-non-interfering module in terms of its purpose and interaction with other modules.
ADV_TDS.3.10C The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke.
Class ADV: Development
Page 112 of 233 Version 3.1 September 2012
Evaluator action elements:
ADV_TDS.3.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ADV_TDS.3.2E The evaluator shall determine that the design is an accurate and complete instantiation of all security functional requirements.
ADV_TDS.4 Semiformal modular design
Dependencies: ADV_FSP.5 Complete semi-formal functional specification with additional error information
Developer action elements:
ADV_TDS.4.1D The developer shall provide the design of the TOE.
ADV_TDS.4.2D The developer shall provide a mapping from the TSFI of the functional specification to the lowest level of decomposition available in the TOE design.
Content and presentation elements:
ADV_TDS.4.1C The design shall describe the structure of the TOE in terms of subsystems.
ADV_TDS.4.2C The design shall describe the TSF in terms of modules, designating each module as SFR-enforcing, SFR-supporting, or SFR-non-interfering.
ADV_TDS.4.3C The design shall identify all subsystems of the TSF.
ADV_TDS.4.4C The design shall provide a semiformal description of each subsystem of the TSF, supported by informal, explanatory text where appropriate.
ADV_TDS.4.5C The design shall provide a description of the interactions among all subsystems of the TSF.
ADV_TDS.4.6C The design shall provide a mapping from the subsystems of the TSF to the modules of the TSF.
ADV_TDS.4.7C The design shall describe each SFR-enforcing and SFR-supporting module in terms of its purpose and relationship with other modules.
ADV_TDS.4.8C The design shall describe each SFR-enforcing and SFR-supporting module in terms of its SFR-related interfaces, return values from those interfaces, interaction with other modules and called SFR-related interfaces to other SFR-enforcing or SFR-supporting modules.
ADV_TDS.4.9C The design shall describe each SFR-non-interfering module in terms of its purpose and interaction with other modules.
ADV_TDS.4.10C The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke.
Class ADV: Development
September 2012 Version 3.1 Page 113 of 233
Evaluator action elements:
ADV_TDS.4.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ADV_TDS.4.2E The evaluator shall determine that the design is an accurate and complete instantiation of all security functional requirements.
ADV_TDS.5 Complete semiformal modular design
Dependencies: ADV_FSP.5 Complete semi-formal functional specification with additional error information
Developer action elements:
ADV_TDS.5.1D The developer shall provide the design of the TOE.
ADV_TDS.5.2D The developer shall provide a mapping from the TSFI of the functional specification to the lowest level of decomposition available in the TOE design.
Content and presentation elements:
ADV_TDS.5.1C The design shall describe the structure of the TOE in terms of subsystems.
ADV_TDS.5.2C The design shall describe the TSF in terms of modules, designating each module as SFR-enforcing, SFR-supporting, or SFR-non-interfering.
ADV_TDS.5.3C The design shall identify all subsystems of the TSF.
ADV_TDS.5.4C The design shall provide a semiformal description of each subsystem of the TSF, supported by informal, explanatory text where appropriate.
ADV_TDS.5.5C The design shall provide a description of the interactions among all subsystems of the TSF.
ADV_TDS.5.6C The design shall provide a mapping from the subsystems of the TSF to the modules of the TSF.
ADV_TDS.5.7C The design shall provide a semiformal description of each module in terms of its purpose, interaction, interfaces, return values from those interfaces, and called interfaces to other modules, supported by informal, explanatory text where appropriate.
ADV_TDS.5.8C The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke.
Evaluator action elements:
ADV_TDS.5.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
Class ADV: Development
Page 114 of 233 Version 3.1 September 2012
ADV_TDS.5.2E The evaluator shall determine that the design is an accurate and complete instantiation of all security functional requirements.
ADV_TDS.6 Complete semiformal modular design with formal high-level design presentation
Dependencies: ADV_FSP.6 Complete semi-formal functional specification with additional formal specification
Developer action elements:
ADV_TDS.6.1D The developer shall provide the design of the TOE.
ADV_TDS.6.2D The developer shall provide a mapping from the TSFI of the functional specification to the lowest level of decomposition available in the TOE design.
ADV_TDS.6.3D The developer shall provide a formal specification of the TSF subsystems.
ADV_TDS.6.4D The developer shall provide a proof of correspondence between the formal specifications of the TSF subsystems and of the functional specification.
Content and presentation elements:
ADV_TDS.6.1C The design shall describe the structure of the TOE in terms of subsystems.
ADV_TDS.6.2C The design shall describe the TSF in terms of modules, designating each module as SFR-enforcing, SFR-supporting, or SFR-non-interfering.
ADV_TDS.6.3C The design shall identify all subsystems of the TSF.
ADV_TDS.6.4C The design shall provide a semiformal description of each subsystem of the TSF, supported by informal, explanatory text where appropriate.
ADV_TDS.6.5C The design shall provide a description of the interactions among all subsystems of the TSF.
ADV_TDS.6.6C The design shall provide a mapping from the subsystems of the TSF to the modules of the TSF.
ADV_TDS.6.7C The design shall describe each module in semiformal style in terms of its purpose, interaction, interfaces, return values from those interfaces, and called interfaces to other modules, supported by informal, explanatory text where appropriate.
ADV_TDS.6.8C The formal specification of the TSF subsystems shall describe the TSF using a formal style, supported by informal, explanatory text where appropriate.
Class ADV: Development
September 2012 Version 3.1 Page 115 of 233
ADV_TDS.6.9C The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke.
ADV_TDS.6.10C The proof of correspondence between the formal specifications of the TSF subsystems and of the functional specification shall demonstrate that all behaviour described in the TOE design is a correct and complete refinement of the TSFI that invoked it.
Evaluator action elements:
ADV_TDS.6.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
ADV_TDS.6.2E The evaluator shall determine that the design is an accurate and complete instantiation of all security functional requirements.
Class AGD: Guidance documents
Page 116 of 233 Version 3.1 September 2012