The System Security Concept

	Role of the System Security Concept
	Aspects of the System Security Concept
		ADV_FSP: The Functional Specification
		ADV_SPM: The Security Policy Model

Role of the System Security Concept

	Describe the TOE Security Characteristics as Seen From the Outside
	Provide the Basis For Correlating the TOE Capabilities with the ST Security Function Requirements
	Provide the Basis For Developing Tests of the Security Functions

ADV_FSP – Functional Specification

	Definition
	Aspects
	Components
		Informal Functional Specification
		Fully Defined External Interfaces
		Semiformal Functional Specification
		Formal Functional Specification

Definition

	Describe the collection of TOE Security Functions (TSF) that satisfy the ST SFRs
	Describe the External Interfaces to the TSF
		Syntax and behavior of callable interfaces
		Content of information interfaces (e.g. audit logs)
	Levels Reflect Increasing:
		Formalism of the interface specification notation
		Coverage of the TOE interfaces

Aspects of the TSF Specification

	Purpose
	Method of use
	Effects
	Exceptions
	Error messages

Interface - Purpose

	A description of the role of the TSF in realizing the ST requirements
	Can be interleaved with descriptions of any non-security roles of the TSF in the TOE

Interface – Method of Use

	A Description of When and How the Interface is used, comprised of:
		The TSF invoked through the interface
		Syntax (signature) for invoking the interface
		Name and meaning of the security-relevant input parameters
		Name and meaning of security-relevant system-wide options that act as implicit parameters

Interface - Effects

	Describe the Usual Result of Invoking the Interface
		Name and meaning of explicit return values
		Describe affect of interface invocation on system security state
		Describe processing that occurs when function is invoked and how input parameters and system-wide options affect that processing
		Pre- and post-conditions for invoking the interface (especially for more formal FSPs)

Interface - Exceptions

	Describe Conditions Under Which Interface Behaves Differently
		E.g., in presence of security privileges
		Use same format as Effects

Interface – Error Messages

	Describe Conditions Under Which Interface Invocation Will Not Complete Successfully
	Affect of Such Failure On
		System security state
		Explicit return values

Specification Formalism

	Informal – Natural Language Prose
	Semi-Formal – Restricted Natural Language
		Precise, consistent definition and use of terms
		Stereotyped use of grammar
	Formal – Specialized Specification Language That
		Is unambiguous and precise
		Facilitates reasoning about the correctness of implementations of the specification

Informal Functional Specification

	“describe the TSF and its external interfaces using informal style”
	“internally consistent”
	“describe the purpose and method of use of all external TSF interfaces, providing details of effects, exceptions, and error messages, as appropriate”
	“completely represent the TSF”

Fully Defined External Interfaces

	“describe the purpose and method of use of all external TSF interfaces, providing complete details of all effects, exceptions, and error messages, as appropriate”
	“include rationale that TSF is completely represented”

Semiformal Functional Specification

	“describe the TSF and its external interfaces using a semiformal style, supported by informal, explanatory text where appropriate”

Formal Functional Specification

	“describe the TSF and its external interfaces using a formal style, supported by informal, explanatory text where appropriate”

ADV_SPM – Security Policy Modeling

	Definition
	Aspects
	Components
		Informal TOE Security Policy (TSP) Model
		Semiformal TSP Model
		Formal TSP Model

Definition – Security Policy Model

	Description of the security rules and characteristics that determine the operation of the TOE Security Functions, as accessed through the external TOE interfaces

Aspects of the Family

	Rules and Characteristics of All Policies That Can be Modeled
	TOE Security Policy (TSP) Model Rationale
	Demonstrate Correspondence Between the  Model and the TSF and Interfaces Described In the Functional Specification

Rules and Characteristics

	System Security State is defined by
		Resources that will be kept in a secure state
		Definition of secure state for each resource
		Enumeration of, or criteria for, secure states
		Active entities that can cause changes in the security state of secured resources
		Enumeration of, or allowed algorithms for, transitions among secure states

Rationale

	Link TSP Model to ST
		ST Security Functional Requirements define explicit policies that must be modeled
	Show that all policies that can be modeled are completely modeled
	Show that SPM is consistent with the policies that can, and have, been modeled
		Granularity of policy matches granularity of ST Security Functional Requirements

Correspondence

	Link TSP Model to Functional Specification
	Show that, with respect to the TSP Model, the external interfaces in the Functional Specification are all
		Consistent – i.e., implement the modeled semantics of security
		Complete – i.e., all elements of the TSP model are realized in at least one external interface

Informal TSP Model

	“The TSP model shall be informal”
	“…describe rules and characteristics of all policies of TSP that can be modeled”
	“…include a rationale that demonstrates that it (the TSP Model) is consistent and complete with respect to all TSP policies that can be modeled”
	“The demonstration of correspondence … shall show that all security functions in FSP are consistent and complete with respect to the TSP model

Semiformal TSP Model

	“The TSP model shall be semiformal”
	“Where the functional specification is at least semiformal, the demonstration of correspondence between the TSP Model and the functional specification shall be semiformal”

Formal TSP Model

	The TSP model shall be formal”
	“Where the functional specification is at least semiformal, the demonstration of correspondence between the TSP Model and the functional specification shall be semiformal”
	“Where the functional specification is formal, the proof of correspondence between the TSP Model and the functional specification shall be formal”