The System Security Realization

	Role of the System Security Realization
	Aspects of the System Security Realization
		ADV_HLD: The High Level (Security) Design
		ADV_LLD: The Low Level (Security) Design
		ADV_INT: TSF Internals
		ADV_IMP: The Implementation Representation
		ADV_RCR: Representation Correspondence
	Techniques for Developing the System Security Realization

Role of the System Security Realization

	Describe the TOE Security Functions (TSF) as Seen From the Inside
	Provide the Basis For Understanding How the TSF Actually Meet ST Security Function Requirements
	Provide the Information Needed to Analyze the Correctness of the TSF With Respect to the System Security Concept Specifications
	Provide the Basis For Developing “White Box” Tests of the Security Functions

Points to Remember

	System Security Realization Families Seem to Require Top-Down Development
		NOT SO – they require that the realization be PRESENTED as a series of refinements
		There are NO requirements that the TOE be developed in a strict top-down fashion
	System Security Realization Families Are Specified To Facilitate Evaluation
		Challenge is to develop TOE so that all required information is captured

ADV_HLD – High Level Design

	Definition
	Aspects
	Components
		Descriptive HLD
		Security enforcing HLD
		Semiformal HLD
		Semiformal High-level Explanation
		Formal HLD

Definition

	The High Level Design of a TOE provides a description of the TSF in terms of major structural units (i.e., subsystems) and relates these units to the functions that they provide
		Provides support for argument that TOE architecture is appropriate for implementing the TOE security functional requirements

Aspects of the Family

	Define and describe “subsystems”
	Describe security functions provided by each subsystem
	Describe if and how each subsystem depends on the presences of security functions in the external IT environment
	Describe interactions between subsystems
	Externally visible subsystem interfaces

Subsystems

	Relatively small number of parts
	Structuring concept that doesn’t HAVE to be reflected in lower level decompositions
	Presentation must use something “like”subsystems
		e.g., layers, domains, servers, etc

Subsystem Security Functionality

	Operations that each subsystem performs as part of TOE security function realization
	Relationship between subsystems and security functions may be many-to-many
		One subsystem may wholly realize many security functions
		Aspects of one security function may be realized through the cooperation of many subsystems
	“TSP-enforcing subsystem” directly or indirectly contibutes to TSP enforcement

External IT Environment Dependencies

	Identify the security functions or protection mechanisms that the TSF requires be present in underlying
		hardware
		firmware
		software

Interactions Between Subsystems

	Identify all interfaces to each subsystem
		Callable functions
		Shared data structures
	Major data flows effected through the interfaces

Externally Visible Subsystem Interfaces

	Identify the subset of the interfaces to a subsystem that are directly exposed as external interfaces described in the functional specification

Descriptive HLD

	High-level design shall
		be informal.
		be internally consistent.
		describe the structure of the TSF in terms of subsystems.
		describe the security functionality provided by each subsystem of the TSF.
		identify any underlying hardware, firmware, and/or software required by the TSF with a presentation of the functions provided by the supporting protection mechanisms implemented in that hardware, firmware, or software.
		identify all interfaces to the subsystems of the TSF.
		identify which of the interfaces to the subsystems of the TSF are externally visible.

Security enforcing HLD

	Same as Descriptive HLD plus
		describe the purpose and method of use of all interfaces to the subsystems of the TSF, providing details of effects, exceptions and error messages, as appropriate.
		describe the separation of the TOE into TSP-enforcing and other subsystems.

Semiformal HLD

	Same as security enforcing, plus
		The presentation of the high-level design shall be semiformal.
		The high-level design shall describe the purpose and method of use of all interfaces to the subsystems of the TSF, providing complete details of all effects, exceptions and error messages.

Semiformal High-level Explanation

	Same as semiformal HLD, plus
		The high-level design shall justify that the identified means of achieving separation, including any protection mechanisms, are sufficient to ensure a clear and effective separation of TSP-enforcing from non-TSP-enforcing functions.
		The high-level design shall justify that the TSF mechanisms are sufficient to implement the security functions identified in the high-level design.

Formal HLD

	Same as Semiformal High-level Explanation,, except that
		The presentation of the high-level design shall be formal.

ADV_LLD – Low Level Design

	Definition
	Aspects
	Components
		Descriptive Low Level Design
		Semiformal Low Level Design
		Formal Low Level Design

Definition

	“A … description of the internal workings of the TSF in terms of modules and their interrelationships and dependencies.”
	The role of the low level design in Common Criteria is to increase confidence the TSF subsystems are correctly and effectively refined.

Aspects of the Family

	TSF Modules
	Module Interrelationships
	Module Interfaces & Behavior
	Externally Visible Interfaces
	TSP-Enforcing Functions

TSF Modules

	Unit Of Implementation, e.g.,
		SW: source files, packages, modules, objects
		HW: ASICs, VHDL specs, CPUs
	TSP-Enforcing Modules
		“…any module that must be relied upon for correct enforcement of the TSP.”
		“The LLD shall describe the separation of the TOE into TSP-enforcing and other modules.”

Module Interrelationships

	Security Functionality Provided
		“…set of operations that a module performs in contribution to security functions implemented by the TOE.”
		Modules don’t necessarily have to relate to specific security functions
		Many-to-many relationship between security functions and modules
	Internal Consistency –Only Defined Interfaces Are Used For Inter-Module Interactions
	Dependencies On Other Modules
		Security Functions from other modules that a module uses to provide its security functions

Module Interfaces & Behavior

	Purpose
		How module fits into HLD
	Function
		The set of operations performed by the module
	Interface(s)
		Purpose: Operations to which access is provided
		Method-of-use: Syntax for calling on the module operations
		Effects: results of “standard” processing
		Exceptions: results of “non-standard” processing
		Error Messages: for faults and failure

Externally Visible Interfaces

	Module Interfaces That Are Exposed As Functional Specification Interfaces

TSP-Enforcing Functions

	“The low-level design shall describe how each TSP-enforcing function is provided.”
		Describe the approach being used to implement a module’s security functionality
		Experience shows that this description should also document other implementation approaches that were considered and the reasons they were not chosen

Descriptive Low Level Design

	The low-level design shall
		be presented informally.
		be internally consistent.
		describe the TSF in terms of modules.
		describe the purpose of each module.
		define the interrelationships between the modules in terms of provided security functionality and dependencies on other modules.
		describe how each TSP-enforcing function is provided.
		identify all interfaces to the modules of the TSF.
		identify which of the interfaces to the modules of the TSF are externally visible.
		describe the purpose and method of use of all interfaces to the modules of the TSF, providing details of effects, exceptions and error messages, as appropriate.
		describe the separation of the TOE into TSP-enforcing and other modules.

Semiformal Low Level Design

	The presentation of the low-level design shall be semiformal.
	The low-level design shall describe the purpose and method of use of all interfaces to the modules of the TSF, providing complete details of all effects, exceptions and error messages.

Formal Low Level Design

	The presentation of the low-level design shall be formal.

ADV_INT – TSF Internals

	Definition
	Aspects
	Components
		Modularity
		Reduction of Complexity
		Minimization of Complexity

Definition

	(Design patterns for) the internal structure of the TSF (that) result in a TSF that is simple enough to be analyzed.

Aspects of the Family

	Modularity
	Layering
	Complexity Minimization
	Functionality Minimization

Modularity

	Modular Design Reduces:
		Interdependence between elements of TSF
		Risk that change or error in one element will affect another element
	Modular Design Provides Basis For:
		Determining scope of interaction between TSF elements
		Assuring that unexpected effects don’t occur
		Designing and evaluating test suites

Layering

	“The use of layering and of simpler designs for the TSP-enforcing functionality reduces the complexity of the TSF.”
	Resulting In:
		Better understanding of the TSF
		More assurance that the TOE security functional requirements are accurately and completely instantiated in the implementation.

Complexity Minimization

	Increases assurance (confidence) that code is understood
	Based on premise that if the code in the TSF is less complex, it is more likely that the design of the TSF is comprehensible.
	“Design complexity minimization is a key characteristic of a reference validation mechanism.”

Functionality Minimization

	Goal is to minimize the amount of functionality in the TSF that doesn’t enforce the TSP, thus:
		reducing the possibility of flaws in the TSF, and
		with modularity and layering, allowing the evaluator to focus only on that functionality which is necessary for TSP enforcement
	Also allows cleaner mapping from security policy model to implementation

Modularity

	The developer shall design and structure the TSF in a modular fashion that avoids unnecessary interactions between the modules of the design.
	The developer shall provide an architectural description.
	The architectural description shall identify the modules of the TSF.
	The architectural description shall describe the purpose, interface, parameters, and effects of each module of the TSF.
	The architectural description shall describe how the TSF design provides for largely independent modules that avoid unnecessary interactions.

Reduction of Complexity

	The developer shall design and structure the TSF in a layered fashion that minimizes mutual interactions between the layers of the design.
	The developer shall design and structure the TSF in such a way that minimizes the complexity of the portions of the TSF that enforce any access control and/or information flow control policies.
	The architectural description shall identify the modules of the TSF and shall specify which portions of the TSF enforce the access control and/or information flow control policies.
	The architectural description shall describe the layering architecture.
	The architectural description shall show that mutual interactions have been minimized, and justify those that remain.
	The architectural description shall describe how the portions of the TSF that enforce any access control and/or information flow control policies have been structured to minimize complexity.

Minimization of Complexity

	The developer shall design and structure the TSF in such a way that minimizes the complexity of the entire TSF.
	The developer shall design and structure the portions of the TSF that enforce any access control and/or information flow control policies such that they are simple enough to be analyzed.
	The developer shall ensure that functions whose objectives are not relevant for the TSF are excluded from the TSF modules.
	The architectural description shall describe how the entire TSF has been structured to minimize complexity.
	The architectural description shall justify the inclusion of any non-TSP-enforcing modules in the TSF.

ADV_IMP – Implementation Representation

	Definition
	Aspects
	Components
		Subset of TSF Implementation
		TSF Implementation
		Structured TSF Implementation

Definition

	Least abstract representation of the TSF
	The representation that is used without further refinement to create (or generate) the TSF
		Software source code
		Hardware drawings

Aspects of the Family

	Implementation Representation
	Implementation Structuring
	Internal Consistency

Implementation Representation

	Must be provided
		Possibly for only a subset of the TSF
	Must “unambiguously define TSF to level of detail such that the TSF can be generated without further design decisions”

Implementation Structuring

	Describe the relationships between portions of implementation
	Language or coding style should ensure that Implementation Representation is structured into small and comprehensible sections

Internal Consistency

	All portions of the Implementation Representation
		Conform to the rules of the representation format (programming language or drafting guidelines)
		Match with each other
			Function calls match function definition
			Circuit traces have source and sink
			Cross-checked by successful compilation or fabrication

Subset of TSF Implementation

	“Developer shall provide implementation representation for a selected subset of the TSF”
		Negotiated between developer and evaluator
	“The implementation representation shall unambiguously define the TSF to a level of detail such that the TSF can be generated without further design decisions.”
	“The implementation representation shall be internally consistent”

TSF Implementation

	“…provide implementation representation for the entire TSF.”
	“…implementation representation shall describe the relationships between all portions of the implementation.”

Structured TSF Implementation

	“implementation representation shall be structured into small and comprehensible sections.”

ADV_RCR – Representation Correspondence

	Definition
	Aspects
	Components
		Informal Correspondence Demonstration
		Semiformal Correspondence Demonstration
		Formal Correspondence Demonstration

Definition

	Demonstration that, for all adjacent abstractions of representation, the less abstract representation correctly refines the more abstract representation
	Goal is to attain confidence that the least abstract representation of the TSF is a complete and correct realization of the ST security functional requirements

Aspects of the Family

	Pair-wise Correspondence
	All Relevant Security Functionality
	Exclusion of TSP or TSP Model

Pair-wise Correspondence

	Adjacent Representations
		TOE Summary Spec to Functional Spec
		Functional Spec to High Level Design
		High Level Design to Low Level Design
		Low Level Design to Implementation Representation
	Demonstration of Correspondence Should Be As Formal As Possible, Limited Only By the Formality Of The Representations

All Relevant Security Functionality

	Between TSS and FSP
		Only TOE security functions: assurance measures not required
	Between LLD and Implementation
		For subset implementation of TSF, required refinements limited to security functionality in the subset
	For all other cases, all parts of more abstract TSF representation must be refined into less abstract TSF representation

Exclusion of TSP or TSP Model

	Correspondence demonstrations related to TSP or TSP Model are explicitly addressed in other families or components and not repeated in ADV_RCR.

Informal Correspondence

	The developer shall provide an analysis of correspondence between all adjacent pairs of TSF representations that are provided.
	For each adjacent pair of provided TSF representations, the analysis shall demonstrate that all relevant security functionality of the more abstract TSF representation is correctly and completely refined in the less abstract TSF representation.

Semiformal Correspondence

	For each adjacent pair of provided TSF representations, where portions of both representations are at least semiformally specified, the demonstration of correspondence between those portions of the representations shall be semiformal.

Formal Correspondence

	For those corresponding portions of representations that are formally specified, the developer shall prove that correspondence.
	For each adjacent pair of provided TSF representations, where portions of one representation are semiformally specified and the other at least semiformally specified, the demonstration of correspondence between those portions of the representations shall be semiformal.
	For each adjacent pair of provided TSF representations, where portions of both representations are formally specified, the proof of correspondence between those portions of the representations shall be formal.

Techniques

	Stepwise Refinement
	Reverse Engineering
	Interviews
	Hybrids

Stepwise Refinement

	Also Called Top-Down Development
	Goal Is To Develop System As A Series of Progressively Less Abstract Representations – With Source Code As the Least Abstract Representation
	Implicitly Assumed Approach In CC

Stepwise Refinement (2)

	Great In Theory, BUT…
		Few people are able to establish and maintain separation among abstract representations
		Most project managers are too impatient to tolerate a design process that doesn’t result in immediate production of executable code
		“The devil is in the details…”
			Creating a less abstract representation almost always forces changes to the more abstract representation
			The notation used for each abstract representation can introduce arbitrary restrictions and dependencies that aren’t strictly part of the refinement process

Reverse Engineering

	Also Called Bottom-Up Development
	Develops a Least Abstract Representation From a Rough Notion Of Requirements
	More Abstract Representations Are Developed By Summarizing the Details In Less Abstract Representations

Reverse Engineering (2)

	VERY Common Practice, BUT…
		Labor intensive
		Doesn’t directly result in running code and is therefore considered “busywork” by those most qualified to do it
			More abstract representations usually not kept current with the least abstract representation
		Few people are able to establish and maintain separation among abstract representations
			Worse here, since “out” is to refer to less (or usually least) abstract representation – “Read the Code!!”
		Natural focus is on what is built rather than what is needed

Interviews

	Data Mining On the Developers Or Maintainers
	Especially Useful When
		HLD is least abstract representation required
		System is horribly complex legacy code
		Access to source code, and therefore use of reverse engineering, is hard
		There exist one or more “gurus” who can answer all, or most, questions about the system after thinking for a short time

Interviews (2)

	Goal is to Get The Guru’s Internal Model of The System
	“Drink From Fire Hose” Since Gurus Usually
		Are in short supply and high demand
		Have a short attention span and low tolerance for those who don’t understand

Interviews (3)

	“Oracle” Mode
		One guru seems to know everything
		Frame interview as “training” that will reduce “stupid” questions later on
	“Inner Circle” Mode
		Multiple gurus with interlocking and/or overlapping expertise in system realization
		Use moderated discussion with easy whiteboard access
		Use “same answer three times” rule

Hybrids

	In Most Real Systems, A Combination Of  Techniques Is Needed
	Plan How To Reconcile Equivalent Material Gained From Multiple Techniques
	Stepwise Refinement is Quite Effective For
		Security Target development
		Security Policy Model development
		Functional Spec and High-Level Design in new systems development

Hybrids (2)

	Reverse Engineering Is Obviously Most Useful For
		Implementation Representation
		TSF Internals
		Low Level Design
		FSP and HLD in lower assurance systems
	Interviews Are Most Effective For
		HLD and LLD in any existing system
		FSP, as a starting point in existing systems