I-0462: What Is A TSP?

TYPE:                 Guidance
NUMBER:               I-0462
STATUS:               Withdrawn
REASON:               Redundant with terminology work being done by TNO.

TITLE:                What Is A TSP?

SOURCE REFERENCE:     CC v2.1 Part 1 Subclause 2.3
RELATED TO:           <None>
CCIMB ENTRY:          CCIMB-INTERP-0117

ISSUE:

In the Part 1 definition of TSP, a TSP is defined as "A set of rules that regulate how assets are managed, protected, and distributed within a TOE.". This definition is unclear. Are all functional policies TSPs? For example, are I&A and Audit TSPs? Are the requirements in FPT, in particular, FPT_SEP and FPT_RVM, TSPs?

STATEMENT

A TSP is any security policy enforced by the TOE to protect either internal (i.e., TSF) or external (i.e., user) assets.

SUPPORT:

The Common Criteria is unclear on its use of the term TSP. In its upfront material, in Part 2 paragraph 14, the CC talks about the TOE Security Policy (TSP) being enforced over the TOE resources, and defines the rules by which the TOE governs access to its resources, and thus all information and services controlled by the TOE.

Based on this, one might conclude that the TSP includes both the access control policies defined in FDP, as well as the implied policy protecting TSF Data (FPT), as TSF Data is also a TOE resource. By extension, one might be able to apply it to both Identification and Authentication and Crypography, as these also govern access to resources. It is clear that Audit would be excluded, however, as that doesn't apply to access to resources.

However, the introduction to FPT says "This class contains families of functional requirements that relate to the integrity and management of the mechanisms that provide the TSF (independent of TSP specifics) and to the integrity of TSF data (independent of the specific contents of the TSP data)." The fact that this indicates FPT is independed of TSP specifics might imply that FPT is, by itself, not a TSP (and similarly, the FIA and FCS stuff are not TSPs).

However, the audit requirements indicate that security auditing involves recognising, recording, storing, and analysing information related to security relevant activities (i.e. activities controlled by the TSP). They refer to auditing potential violations of the TSP. Logically, one wouldn't want that to apply only to the data protection policies; one would like it to also apply to attempts to violate the cryptographic policies, the I&A policies, the TSF protection policies, etc.

What would be the impact of a broader TSP definition? On the positive side, there would more things that fall in the category of "security relevant" and "potential violation of the TSP", thus increasing the importance and usability of the audit trail. On the negative side, it would create more work for FPT_SEP, which at its highest level separates domains by the SFP they enforce.

Given that the higher level of FPT_SEP is optional (i.e., a PP/ST writer can choose a lower level), and the significant benefits of monitoring for violations of any TOE enforcement mechanism, not just those protecting user data, it makes sense to go with the broader definition of TSP.