1. Security Requirements
Module 2.1
Security Requirements
This is Module 2.1 of the Evaluator’s training course covering Security Requirements.
© Crown Copyright (2000)
This module may be reproduced in its entirety provided that this statement is included. Any other reproduction may only be made with the written consent of the Senior Executive of the UK IT Security Evaluation & Certification Scheme.
© Crown Copyright (2000)
M Issue 4.0, July 2000

2. “You Are Here” MODULE 2 - ASSURANCE M2.1 Security Requirements
M2.2 Development Representations
M2.3 Functional Testing
M2.4 Development Environment
M2.5 Operational Environment
M2.6 Vulnerability Analysis
This module focuses mainly on the Security Target, which is the key security requirements document, but also covers Security Policy Models which support the Security Target in clarifying the notion of security as enforced by the TOE. The Security Target acts as the baseline for all other evaluation activities, defining the ‘security problem’ to be solved together with the form of the ‘solution’ to the problem in the form of ‘security functions’ the TOE is to implement. Subsequent evaluation activities provide assurance that the security functions are correctly implemented by the TOE (M2.2, M2.3, M2.4), that the security features will be used as intended (M2.5) and that the TOE will in practice be effective in addressing the defined ‘security problem’ (M2.6, M2.7).
M2.7 Penetration Testing
M2.8 Assurance Maintenance/Composition
M Issue 4.0, July 2000

3. Introduction Security Target Security Policy Model
defines scope of security problem
specifies security functions
identifies assurance requirement
Security Policy Model
required at higher assurance levels
Evaluators need a clear definition of what it is they are trying to evaluate - what is included in the evaluation, and what they don’t have to worry about, i.e. what things are axiomatic for the evaluation. They must also know what the “security problem” is that the TOE is trying to address, and what the TOE’s “solution” to that problem is in the form of the security functions that the TOE implements.
All of these things are fully defined in the Security Target (ST), together with the required level of assurance in the TOE. The ST thus forms the baseline for the evaluation of the TOE.
Associated with the ST is an analysis which demonstrates that the security functions are actually suitable to counter the identified threats to the assets which need to be protected.
The task of the evaluator is to ensure that the ST provides a clear, complete and consistent definition of the security problem, the scope of evaluation and the countermeasures provided by the Target of Evaluation (TOE). The evaluators must independently confirm the suitability of the specified “solution” to the identified security problem.
At higher assurance levels a Security Policy Model is required. This provides an abstract but precise definition of the security policy implemented by the TOE, and the rules and characteristics of the policy.
M Issue 4.0, July 2000

4. Define the Security Problem
Assets
what are the protection needs?
Threats
asset at risk
threat agent
method of attack
Other constraints on the TOE
The first task of the Security Target is to define the security problem which the TOE is to address. This starts from an identification of the assets requiring protection, and their protection needs (confidentiality, integrity, availability).
The ST should define the threats to the assets, characterising them in terms of the threat agent (attacker) and the method of attack used (e.g. vulnerabilities exploited).
The ST may also identify other constraints on the TOE that will govern how it addresses the security problem, e.g. organisational requirements, legal requirements.
Evaluators must ensure that all assets, threats and constraints are clearly defined in the ST.
M Issue 4.0, July 2000

5. Scope the Security Problem
TOE boundary and interfaces
data in/out
links to underlying systems
Identify what is assumed:
IT dependencies, e.g. underlying O/S
connectivity to other systems
non-technical aspects (personnel, procedural, physical)
The ST must clearly define the boundary of the TOE and the interfaces to it in order to identify what assumptions are required.
Is the TOE a product or system? In the case of a system the TOE environment is known - whereas a product has an assumed environment.
Examples of interfaces may include:
1. Input of information to the system.
2. Power supply
3. System Administration
4. Connection to other systems.
Dependencies on other IT components (e.g. firewall or DBMS on an underlying O/S) should also be articulated (e.g. to identify and authenticate the TOE users). If the TOE imports data from, or exports data to, an external IT component, to what extent is that external IT component trusted to handle the data? Should the data be in a particular format?
M Issue 4.0, July 2000

6. Specifying Countermeasures
Security Functions, e.g.
Access Control
Identification & Authentication
Audit
Non-IT countermeasures, e.g.
physical protection
procedural measures
Having identified the threats and the scope of the security problem, the ST must then specify the countermeasures to address the probem. These can be IT or non-IT.
The principal countermeasures of interest to the evaluators are the IT countermeasures, particularly those implemented by the TOE, i.e. the TOE’s security functions.
Non-IT countermeasures include physical, procedural or personnel measures. As far as the evaluators are concerned, these are presumed to be enforced within the TOE’s environment - they are only considered in respect of the support they provide to the TOE’s security functions in countering the threats.
Remember that the ST acts as the baseline for the TOE evaluation. The TOE’s security functions in particular must be clearly specified, so that the evaluators will be able to understand their intent, and ultimately be able to test the TOE against them.
M Issue 4.0, July 2000

7. Identifying the Assurance Requirement
What assurance is needed to reduce residual risk to assets to acceptable level?
asset value
threats and risk to assets
balance between IT and non-IT
What practical constraints apply?
Having specified the security functions, the Security Target must define what level of assurance or confidence is required. This is based on the following considerations:
1. How valuable are the assets, and what are the risks to the assets?
2. What balance is required between IT and non-IT countermeasures?
3. How much is the sponsor/developer prepared to spend in time and effort (development and evaluation)?
The Assurance Level will determine how much detail evaluators need about each of the aspects of the TOE, and how much time they spend assessing them.
The level is often controlled by the requirements of the sponsor, for example if a product is to be integrated into an existing system, or if the market demands that the product achieves a certain level.
In the case of Composite TOEs, it is possible to have a defined assurance level profile in which different components are evaluated to different assurance levels. In such cases it is important that components to be evaluated to a high assurance level do not depend on components that are to be evaluated to a lower level. For example, consider a high-assurance mail guard which depends on security attributes provided by a low assurance product - what assurance is there in the decisions made by the mail guard?
M Issue 4.0, July 2000

8. Suitability Countermeasures mapped to threats
all threats covered
no redundant countermeasures
Rationale or analysis demonstrating that the specified countermeasures will counter the threats
Closely associated with the ST is an analysis or rationale which demonstrates that the identified ‘security problem’ will be properly addressed by the specified ‘solution’. This analysis may be a separate document, or it may be included within the ST itself.
Typically, it will be based on defined mappings which link countermeasures to the threats to be countered -evaluators need to check that there are no threats left uncountered, and that there are no obviously redundant countermeasures (i.e. those not mapped to any threat).
This will then be supported by an analysis which justifies, for each threat, why the proposed countermeasures (IT and non-IT) are sufficient to counter the threat.
M Issue 4.0, July 2000

9. Specification Styles Informal Semi-formal Formal English
restricted notation, e.g. SSADM
Formal
mathematical concepts, e.g. ‘Z’
The specification of security requirements should, as far as possible, be precise and free from ambiguity.
Informal specifications- those written in natural language - are however prone to imprecision or ambiguity.
Semiformal or formal styles of specification can be used. Greater formality in a specification gives greater precision, and scope for better understanding.
Semi-formal - requires the use of some restricted notation in accordance with a set of conventions
Formal - written in a formal notation, based upon well-established mathematical concepts - used to define the syntax and semantics of the notation and proof rules.
In general, the three styles of specification can be characterised as follows:
informal - easy to write, easy to understand
semiformal - some skill needed to write, easy to understand
formal - difficult to write, difficult to understand
Specification styles are relevant to security functions (dependent on the evaluation criteria), the Security Policy model (see next slide) and design representations (see module M2.2)
M Issue 4.0, July 2000

10. Example Informal Specification
The TOE will prevent read access by a subject in respect of an object whose label is not dominated by the label of the subject.
English (natural language) specification of what the security function or requirement is.
Such specifications may be open to interpretation. For example, in the above specification the following questions could be raised:
what is meant by the relationship “dominated”: a separate definition of this term would be required;
no indication is given whether read access will be granted if the object label dominates the subject label.
M Issue 4.0, July 2000

11. Example Semi-formal Specification
A subject is permitted to read an object only if:
a) the hierarchical part of the subject label is greater than or equal to that of the object label
and
b) the categories within the object label form a subset of the categories within the subject label.
Based on use of some restricted notation designed to reduce the possibility for ambiguity.
The above is based on the SADSEF notation (Semi-formal Approach to the Definition of Security Enforcing Functions) - which involves the use of English language representations of predicate logic constructs such as “only if”, “and”, “or” and so on.
This specifies the same security function as in the previous slide, but without needing to refer to a separate “dominance” relationship. In doing so it also shows that labels are constructed from two parts - one hierarchic marking and a (possibly empty) set of non-hierarchic markings or “categories”.
Use of the “X only if Y” form means that a subject is permitted to read an object (the “X” part) only when both conditions a) and b) are satisfied (the “Y” part). Use of the “only if” clause (as opposed to the stronger “if and only if” clause) means that there may be other reasons for denial of access to the object - possibly covered by other security functions.
M Issue 4.0, July 2000

12. Example Formal Specification
L1, L2 : class
L1 dominates L2 Û
security-level (L1) ³ security-level (L2) Ù
categories (L2) Í categories (L1)
The Security Function is defined by introducing the function canread:
sub canread obj Û max-level(sub) dominates level(obj)
The slide presents an (incomplete) specification of the same security function using mathematical notation.
It starts with a formal definition of the dominance relationship - it will be noted that “security-level” represents the “hierarchic part” of the label referred to in the previous slide.
Having defined dominance, the security function can be specified precisely and concisely. In practice more detail will be needed -
The notation would have to be defined (e.g. symbols need definition).
Other information would be required like the definition of ‘class’ and the functions ‘security-level’, ‘categories’, ‘canread’, ‘level’ and ‘max-level’.
A formal specification will express security features and interactions formally, after expression of “ground rules” or axioms - those properties which must be upheld if the TOE is to be secure. It should be possible to prove that the formally specified security functions uphold those properties.
M Issue 4.0, July 2000

13. Security Policy Models
Provides a precise and abstract definition of the security policies
Defines the policy rules and characteristics
Not all security policies can be modelled
Security Policy Models are required at higher assurance levels, providing additional assurance to that provided by the ST by requiring a precise (usually formal) expression of the rules and characteristics of the security policies of the TOE. The SPM “models” the security policies by relating security requirements to operations permitted by the TOE (e.g. read a file), but in a way that is independent of the TOE implementation.
Whilst the formal SPM may be complex, and require considerable effort to understand, once understood it should clearly be the correct definition of security for the TOE.
It is accepted that not all security policies can be formally modelled given the current state of the art. However, it is essential that all policies that can be modelled actually are modelled - usually these will be access control or information flow control policies where it is possible to model in terms of:
policy rules governing granting and denial of access/information flow;
characteristics, e.g. active and passive entities involved, the security atttributes used to make policy decisions, and the access modes controlled.
M Issue 4.0, July 2000

14. Evaluation Reporting Confirm required content is provided
Confirm specifications exhibit required characteristics
Confirm absence of ambiguities, inconsistencies, and justify search
Confirm suitability of countermeasures to address the ‘security problem’
As with all other evaluation activities, the report in the ETR must support repeatability and justify all verdicts assigned.
ETR should therefore show how and/or where each applicable ST or SPM requirement is satisfied by the documentation provided.
Where semiformal or formal specifications are required by the criteria, the verdict justification should say why the specifications do or do not exhibit the required characteristics. In the case of SPMs, coverage of policies and abstractness of definition should also be addressed.
A key part of the ST (and SPM) review is the search for inconsistencies or ambiguities - evaluators must demonstrate that they have considered all applicable types of inconsistency, e.g. ambiguous threats, imprecise scope of evaluation, ambiguous security functions, conflict between security functions, and so on.
Finally, evaluators must confirm whether they agree with the rationale or analysis presented demonstrating that the security functions are suitable to counter the identified threats.
M Issue 4.0, July 2000

15. ITSEC Requirements Key points:
At all levels an ST and a suitability analysis is required - the former always incorporating an informal specification of the Security Enforcing Functions (SEFs) implemented by the TOE.
At E4 to E6, greater precision is required in the SEF specifications. This is provided by:
a semiformal specification of SEFs at E4-E5
a formal specification of SEFs at E6
a formal Security Policy Model (may be a reference to a published model), which is related to the ST by means of an informal interpretation of the model.
Note that at E4-E6 two styles of specification of the SEFs are required - these must be consistent.
All other parts of the ST (e.g. threats, assumptions) are always specified informally.
M Issue 4.0, July 2000

16. ITSEC Security Target ITSEC ST Objectives Assumptions Threats
SEFs
ITSEC ST
Suitability Analysis
In an ITSEC ST the ‘security problem’ is defined by:
security objectives (optional for a product ST, mandatory for a system ST), identifying the need to protect the identified assets
threats which may compromise the assets (thus undermining the objectives)
assumptions or assertions about the TOE environment, e.g. relating to the intended method of use, assumed physical or procedural countermeasures.
These three collectively form the key parts of what ITSEC terms the System Security Policy (system ST) or Product Rationale (product ST).
The ITSEC ST contains a specification of the SEFs, to the required level of formality. These are mapped to the threats they counter.
The ITSEC requires the suitability analysis to demonstrate that the SEFs, in conjunction with the assumed non-IT countermeasures, are suitable to counter the identified threats. This analysis may be a separate document from the ST, or it may be contained within it (e.g. as an annex).
An ITSEC ST may claim conformance with a Functionality Class (e.g. F-C2), which is a standard specification of SEFs. Such claimed conformance must be demonstrated by the ST and verified by the evaluators.
M Issue 4.0, July 2000

17. CC Requirements
An ST is required at all EALs - the requirements for an ST do not change from EAL1 to EAL7.
A TOE security policy model is mandated at EAL4+. At EAL4 this has to be informal (ADV_SPM.1) whilst at EAL5+ it has to be formally specified (ADV_SPM.3). Within the ADV_SPM family there is also a component for a semiformal SPM (ADV_SPM.2), but this does not feature in any EAL.
The SPM is not directly related to the ST - however the TOE Security Policy (TSP) is implicitly defined by the ST (specifically by the security functional requirements).
M Issue 4.0, July 2000

18. Protection Profile Rationale Rationale Threats Organisational
Security Policies
Assumptions
TOE
Security Objectives
Environment
Functional
Assurance IT
SECURITY
ENVIRONMENT
Rationale
SECURITY
OBJECTIVES
Rationale
The Protection Profile (PP) is a standard Security Requirements documentation - in effect a “generic Security Target” to which a particular type of TOE (e.g. operating system, firewall, smartcard) can (through its ST) claim conformance.
The PP is intended to be structured in such a way as to help the reader understand how the identified ‘Security Problem’ (security environment) is solved by the identified ‘Security Solution’ (objectives and requirements).
The Security Environment defines the ‘Security Problem’ in terms of:
- Threats to identified assets (as in an ITSEC Security Target).
- Organisational Security Policies (OSPs), which identify any policies specific to the organisation for which the TOE is targeted (e.g. HMG requirements for password algorithms)
- Assumptions about the TOE’s environment.
The Security Objectives provide an abstract definition of how the threats, OSPs and assumptions will be addressed, providing a link to…
The Security Requirements - which should be constructed from CC Part 2 functional components and CC Part 3 assurance components - though deviation is permitted if necessary. It also specifies requirements on the IT Environment (e.g. an underlying operating system).
The PP Rationale shows that the:
a) objectives are suitable to meet the threats, OSPs and assumptions
b) requirements are suitable to meet the objectives and are mutually supportive.
SECURITY
REQUIREMENTS
M Issue 4.0, July 2000

19. CC Security Target Rationale SECURITY REQUIREMENTS Functional
Assurance IT
Environment
TOE SUMMARY
SPECIFICATION
IT Security
Functions
Measures
SECURITY ENVIRONMENT
SECURITY OBJECTIVES
Rationale
A CC Security Target (ST) has a very similar structure and content to a PP.
Additionally, however, it contains the TOE Summary Specification which provides the TOE-specific instantiation of how the Security Requirements are satisfied by the TOE:
- The IT Security Functions are the functions provided by the TOE to meet the SFRs (to which they are mapped). Where no further (TOE-specific) elaboration is appropriate, they may be identical to the SFRs.
- The Assurance Measures are mapped onto the Assurance Requirements they are claimed to satisfy, e.g. references to quality plans, methodologies, tools, analysis techniques, documents mapped onto specific requirements.
The ST Rationale is similar to the PP Rationale but additionally must show that:
a) the specified IT Security Functions are suitable to meet the SFRs;
b) the specified Assurance Measures meet the Security Assurance Requirements.
Finally, if the ST claims conformance with any PPs, it must demonstrate conformance in a separate PP Claims and PP Claims Rationale - noting that a TOE may still be evaluated against an ST that does not claim compliance with any PP.
M Issue 4.0, July 2000

20. CC Part 2 Organisation Class Family Component Element
e.g. FAU Security audit
Family
e.g FAU_GEN Security audit data generation
Component
e.g. FAU_GEN.1 Audit data generation
Element
e.g. FAU_GEN.1.1
CC Part 2 provides a catalogue of functional components which are the building blocks used (where possible) to construct the specification of security functional requirements in a PP or ST.
CC Part 2 is divided into a number of classes of related functional requirements components, each of which is assigned a three-letter label, where ‘F’ indicates ‘Functional’ (as opposed to ‘A’ for Assurance) and the other two indicate the specific class.
Each class contains one or more families of components, each of which has its own unique label. Within each family there is one or more components, at which level the requirements are selected.
Each component comprises one or more requirements elements, which are the indivisible requirements. If a component is selected, all elements must be included for that component.
Note that CC permits deviation from CC Part 2 if there is no appropriate component - however the requirements have to be written in the same style.
In a similar way CC Part 3 defines a catalogue of assurance components - which also has the Class - Family - Component - Element structure.
M Issue 4.0, July 2000

21. CC Functional Components - 1
Assignment and selection, e.g.
FAU_SAR.3.1 The TSF shall provide the ability to perform [selection: searches, sorting, ordering] of audit data based on [assignment: criteria with logical relations].
Refinement, e.g.
FMT_MTD.3.1 The TSF shall ensure that only secure values are accepted for TSF data.
Refinement: the TSF shall ensure that the minimum password length enforced by the TOE is configured to a value of at least 6 characters.
CC Part 2 functional components are intended to provide a “common language” for expressing security functional requirements in a precise manner. This is intended to facilitate comparison between different STs or different PPs. In a sense, CC Part 2 could be said to define a restricted notation for defining such requirements - akin to a semiformal style (although it is not explicitly characterised as such).
A number of different operations are permitted on a functional component to enable the PP/ST author to tailor the requirement:
assignment, where the PP/ST author specifies the value of a parameter, e.g. a list of criteria in the above example
selection, where CC Part 2 allows the choice of one or more options
refinement, permitting the capability of further constraining the requirement, provided that a TOE that complies with the refined requirement also complies with the unrefined component, and no new requirements are introduced
The fourth type of operation, iteration, is illustrated on the next slide.
M Issue 4.0, July 2000

22. CC Functional Components - 2
Iteration, e.g.
FMT_MTD.1.1;1 The TSF shall restrict the ability to create, delete, and clear the audit trail to authorised administrators.
FMT_MTD.1.1;2 The TSF shall restrict the ability to modify or observe the set of audited events to authorised administrators.
FMT_MTD.1.1;3 The TSF shall restrict the ability to initialize the authentication data to authorised administrators.
The iteration operation simply involves use of the same component to express different security requirements.
As the examples show, the iterated component will be tailored in a different way for each resultant SFR, by use of the other permitted operations. Completion of these assignment and selection operations is indicated by the italicised text.
In these examples - taken from the Controlled Access PP (CAPP) - the component FMT_MTD.1 “Management of TSF data” is iterated once for each type of “TSF data” that is subject to the security management functional requirement, i.e. “audit trail”, “set of audited events” and “authentication data”.
Note that a further iteration may be needed to cover the modification of the authentication data.
M Issue 4.0, July 2000

23. CC Functional Components - 3
Dependencies, e.g.
FAU_GEN.1 (Audit data generation) depends on
FPT_STM.1 (Reliable timestamps)
Mutual support
bypass and tampering attacks
absence of conflict
CC requires that the PP/ST rationale gives due consideration to interrelationships between the security requirements.
Firstly, CC Part 2 identifies dependencies between components that need to be considered. For example, FAU_GEN.1, which requires audit records to contain the date and time of the event, is dependent on the provision of reliable timestamps. This implies that FPT_STM.1 must also be satisfied by the TOE, or its IT environment (e.g. underlying operating system). Dependencies are not mandatory, but if they are not satisfied the PP./ST rationale must justify why the dependency is not needed to ensure the security objectives are met.
The PP/ST rationale also requires that the set of security requirements be shown to be mutually supportive and provide an integrated and effective whole. This will include consideration of:
requirements which aim to protect TSF integrity, e.g. defence against bypass or tampering attacks (these are covered in more detail in M2.6); note that there is a separate class - FPT - devoted to requirements which protect the TSF.
potential for conflict between requirements, e.g. user anonymity vs. requirements for individual user accountability.
M Issue 4.0, July 2000

24. Summary The Security Target provides:
a precise definition of the security problem
a formal statement of the scope of evaluation
a specification of the TOE’s security functions, to solve the security problem
the baseline for the evaluation of the TOE
Security Policy Models provide additional clarification of notion of TOE security
The slide highlights the key learning points to emphasise in this module. Since the ST forms the baseline for the evaluation it is important to ensure that it is complete, consistent, precise and, as far as practical, free from ambiguities. It is important in particular that the evaluators gain a clear understanding of the security problem that the TOE is intended to address, the scope of the problem, and the security functions it provides in order to address it.
The SPM supplements the understanding of the notion of security as enforced by the TOE, at higher assurance levels, providing a precise, abstract and implementation-independent definition of the rules and characteristics of the security policies enforced by the TOE.
M Issue 4.0, July 2000

25. Further Reading ITSEC evaluation ITSEC Section 2
UKSP 05 Part III, Chapters 3-4
CC evaluation
CC Part 1, Annexes B & C
CEM Part 2, Chapters 3 and 4
CC Part 3, Section 10.7 and CEM Part 2, Chapter 8 (ADV_SPM section)
ITSEC Section 2 discusses the specification of security functionality, and the content of ITSEC security targets in particular.
UKSP 05 Part III Chapter 4 covers the ITSEC evaluator actions for the ST and SPM (whilst Chapter 3 includes a section to cover the ITSEC evaluator actions for suitability analysis)
CC Part 1 Annex B defines the required content of a Protection Profile. Annex C similarly describes the required content of a Security Target.
CEM Part 2 Chapters 3 and 4 deal, respectively, with PP and ST evaluation.
The CC Part 3 reference provides background to the ADV_SPM (Security policy modelling) family of assurance requirements. More detailed guidance can be found in the ADV_SPM section within CEM Chapter 8 (EAL4)
M Issue 4.0, July 2000

26. Ideas for Exercise - 1
For a simple example TOE, identify the content of its security target in terms of:
assets to be protected
threats
environmental assumptions
security functions.
An example TOE could be, for example:
the laptop being used for the presentation
the DBMS protecting the salaries database (discussed in Module 1).
M Issue 4.0, July 2000

27. Ideas for Exercise - 2
Perform a high-level evaluation of an existing security target. Read through the security target and identify where the key aspects are defined:
threats
environmental assumptions
security functions
assurance requirement
This second option may be more applicable when the course is being given in house.
Clearly students will not have sufficient time to perform a full evaluation. A detailed examination is not required, and students should be discouraged from trying to find minor errors. However, an example security target with a few obvious flaws (e.g. ambiguous threats or security functions) may be useful.
M Issue 4.0, July 2000