[Public Interpretations Database]

I-0054: Support Code Need Not Meet All Architecture Requirements

 
NUMBER:               I-0054
STATUS:               Ready to Prepare for Management/CCIMB

TITLE:                Support Code Need Not Meet All Architecture Requirements

FIRST POST:            [criteria 2347]
MOST RECENT REPOST:    [criteria 2476]

REQUIREMENT:          System Architecture
CRITERIA CLASSES:     C1, C2, B1, B2, B3, A1
DOCUMENT(S):          Design Documentation
RELATED TO:           <None>

STATEMENT:

The following interprets the entire System Architecture requirement.

TCB Support Code shall be required to meet only the following elements of the system architecture requirement:

  1. Such code must be non-invocable through TCB interfaces, and must not be invoked by the TCB, once the TCB has reached secure state.

  2. Such code must be protected from external interference or tampering (e.g., by modification of code or data structures).

  3. At B2 and above, all interfaces to such code must be defined.

  4. At B2 and above, all elements categorized as support code must be identified.

Definitions of some terms used in this statement are contained in the SUPPORT section of this interpretation.

PROJECTED IMPACT:

Negligible impact anticipated.

SUPPORT:

The goal of this interpretation is to address the requirements for code that is in some sense part of the TCB. This code is called Support Code, and is defined as code that is part of the evaluated configuration, but is neither executed nor executable by the TCB once it has reached secure state. Examples of "support code" include:

  • Initialization code, whose task is to bring a system to a secure initial state, configures available peripherals and initializes TCB data structures.

  • System integrity test code that is unavailable once the TCB is operational. Such code might be available only in a restricted maintenance mode.

  • Code supporting trusted recovery, if it is available only in maintenance mode.

  • Code supporting installaction and TCB generation, if it is unavailable once the system is operational.

Product evaluations are concerned with the design of the system security features and the behavior/performance of those security features in the operational product. Intermediate states, before the TCB exists on a running system, are not of primary concern. The evaluation team must understand the function of the code that executes during these states but testing is performed on the resulting TCB to ensure that the TCB satisfies the requirements of the targetted TCSEC class.

At B2 and above, the issue arises of whether initialization code must meet the architectural structuring requirements. Per this interpretation, the answer is ``no'', although such code must have its design clearly documented. The goal of the architectural structuring requirements is to increase the assurance of correctness of the operational TCB. This is done by having highly modular code, information hiding, layering, and conceptual simiplicity. This is significant for the operational TCB as such code is regularly executed.

Support code, on the other hand, tends to be executed infrequently. It is either executed once per system load (such as initialization code), or in a restricted access mode such as maintenance mode. Support code must be non executable once the TCB has reached an operational secure state. If the code is invocable, it is subject to the same requirements as any other element of the TCB.