Security policy modelling (ADV_SPM)

Objectives

267 It is the objective of this family to provide additional assurance from the development of a formal security policy model of the TSF, and establishing a correspondence between the functional specification and this security policy model. Preserving internal consistency the security policy model is expected to formally establish the security principles from its characteristics by means of a mathematical proof.

Component levelling

268 This family contains only one component.

Application notes

269 Inadequacies in a TOE can result either from a failure in understanding the security requirements or from a flawed implementation of those security requirements. Defining the security requirements adequately to ensure their understanding may be problematic because the definition must be sufficiently precise to prevent undesired results or subtle flaws during implementation of the TOE. Throughout the design, implementation, and review processes, the modelled security requirements may be used as precise design and implementation guidance, thereby providing increased assurance that the modelled security requirements are satisfied by the TOE. The precision of the model and resulting guidance is significantly improved by casting the model in a formal language and verifying the security requirements by formal proof.

270 The creation of a formal security policy model helps to identify and eliminate ambiguous, inconsistent, contradictory, or unenforceable security policy elements. Once the TOE has been built, the formal model serves the evaluation effort by contributing to the evaluator's judgement of how well the developer has understood the security functionality being implemented and whether there are inconsistencies between the security requirements and the TOE design. The confidence in the model is accompanied by a proof that it contains no inconsistencies.

271 A formal security model is a precise formal presentation of the important aspects of security and their relationship to the behaviour of the TOE; it identifies the set of rules and practises that regulates how the TSF manages, protects, and otherwise controls the system resources. The model includes the set of restrictions and properties that specify how information and computing resources are prevented from being used to violate the SFRs, accompanied by a persuasive set of engineering arguments showing that these restrictions and properties play a key role in the enforcement of the SFRs. It consists both of the formalisms that express the security functionality, as well as ancillary text to explain the model and to provide it with context. The security behaviour of the TSF is modelled both in terms of

Class ADV: Development

September 2012 Version 3.1 Page 105 of 233

external behaviour (i.e. how the TSF interacts with the rest of the TOE and with its operational environment), as well as its internal behaviour.

272 The Security Policy Model of the TOE is informally abstracted from its realisation by considering the proposed security requirements of the ST. The informal abstraction is taken to be successful if the TOE's principles (also termed “invariants”) turn out to be enforced by its characteristics. The purpose of formal methods lies within the enhancement of the rigour of enforcement. Informal arguments are always prone to fallacies; especially if relationships among subjects, objects and operations get more and more involved. In order to minimise the risk of insecure state arrivals the rules and characteristics of the security policy model are mapped to respective properties and features within some formal system, whose rigour and strength can afterwards be used to obtain the security properties by means of theorems and formal proof.

273 While the term “formal security policy model” is used in academic circles, the CC's approach has no fixed definition of “security”; it would equate to whatever SFRs are being claimed. Therefore, the formal security policy model is merely a formal representation of the set of SFRs being claimed.

274 The term security policy has traditionally been associated with only access control policies, whether label-based (mandatory access control) or user-based (discretionary access control). However, a security policy is not limited to access control; there are also audit policies, identification policies, authentication policies, encryption policies, management policies, and any other security policies that are enforced by the TOE, as described in the PP/ST. ADV_SPM.1.1D contains an assignment for identifying these policies that are formally modelled.

ADV_SPM.1 Formal TOE security policy model

Dependencies: ADV_FSP.4 Complete functional specification Developer action elements:

ADV_SPM.1.1D The developer shall provide a formal security policy model for the [assignment: list of policies that are formally modelled].

ADV_SPM.1.2D For each policy covered by the formal security policy model, the model shall identify the relevant portions of the statement of SFRs that make up that policy.

ADV_SPM.1.3D The developer shall provide a formal proof of correspondence between the model and any formal functional specification.

ADV_SPM.1.4D The developer shall provide a demonstration of correspondence between the model and the functional specification.

Class ADV: Development

Page 106 of 233 Version 3.1 September 2012

Content and presentation elements:

ADV_SPM.1.1C The model shall be in a formal style, supported by explanatory text as required, and identify the security policies of the TSF that are modelled.

ADV_SPM.1.2C For all policies that are modelled, the model shall define security for the TOE and provide a formal proof that the TOE cannot reach a state that is not secure.

ADV_SPM.1.3C The correspondence between the model and the functional specification shall be at the correct level of formality.

ADV_SPM.1.4C The correspondence shall show that the functional specification is consistent and complete with respect to the model.

Evaluator action elements:

ADV_SPM.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.

Class ADV: Development

September 2012 Version 3.1 Page 107 of 233